db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Russell (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JDO-465) Add description for making JDO implementations compliant with OSGi component packaging
Date Fri, 01 Feb 2008 19:49:08 GMT

     [ https://issues.apache.org/jira/browse/JDO-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Craig Russell resolved JDO-465.
-------------------------------

    Resolution: Fixed

I've added this to chapter 11 in the unpublished spec dated 2008-02-15:

11.11 OSGi Service Discovery
The objective of OSGi when used with JDO is to provide fewer development-time dependencies
on specific JDO vendors. Without runtime discovery, the implementation class name is required
to be put into persistence manager factory properties.
Typical usage is an application deployed in production which uses a JDO implementation A that
is not performing well. To fix the issue the user decides to replace the implementation with
a different vendor. Without runtime discovery, the procedure consists of replacing the JDO
vendor jar in the classpath and updating the persistence manager factory properties to refer
to the new vendor persistence manager factory class.
With runtime service discovery, this procedure would be simplified to replacing only the JDO
vendor jar. The new vendor would be found dynamically.
>From the user perspective
There is a small change needed to deployment to use service discovery. As before, the application
uses JDOHelper.getPersistenceManagerFactory using properties or configuration name. However
there is no need to set the property javax.jdo.PersistenceManagerFactoryClass if there is
only one JDO vendor jar in the classpath.
>From the implementation perspective
In the JDO implementation jar file, add the file META-INF/services/javax.jdo.PersistenceManagerFactory,
which contains a single line with the fully qualified class name of the PersistenceManagerFactory
implementation.
The JDOHelper.getPersistenceManagerFactory(String) will do the service discovery, by using
the standard jar spec.
This service discovery is most likely to be used in Java SE environments.
Examples
An OSGi application is usually split into several jars, something like:
mycomponent1.jar (OSGi bundle)
mycomponent2.jar (OSGi bundle)
mycomponent3.jar (OSGi bundle)

Each OSGi bundle is loaded by a different classloader, with the java runtime classloader the
parent for the bundle classlaoders.
Each component can include libraries inside, for instance JDO. 
mycomponent1.jar (OSGi bundle)
  - jdo.jar
  - Person.class (PersistenceCapable)
  - Company.class (PersistenceCapable)
mycomponent2.jar (OSGi bundle)
mycomponent3.jar (OSGi bundle)

Only mycomponent1 currently uses the persistence-capable classes. But if mycomponent3 now
needs to read Company instances, you will also need the persistence-capable classes and jdo.jar
in the classpath for mycomponent3. You might decide to duplicate the classes in both OSGi
bundles:
mycomponent1.jar (OSGi bundle)
  - jdo.jar
  - Person.class (PersistenceCapable)
  - Company.class (PersistenceCapable)
mycomponent2.jar (OSGi bundle)
mycomponent3.jar (OSGi bundle)
  - jdo.jar
  - Person.class (PersistenceCapable)
  - Company.class (PersistenceCapable)

But actually this will fail with ClassCastException at runtime, since Person of mycomponent1
is not the same class, and instances cannot be cast to Person of mycomponent3. The solution
is to reorganize the dependencies:
mycomponent1.jar (OSGi bundle) - depends on mydomainclasses.jar and jdo.jar OSGi
bundles
mycomponent2.jar (OSGi bundle)
mycomponent3.jar (OSGi bundle) - depends on mydomainclasses.jar and jdo.jar OSGi
bundles
jdo.jar (OSGi bundle)
  - jdo.jar
mydomainclasses.jar (OSGi bundle) - depends on jdo.jar
  - Person.class (PersistenceCapable)
  - Company.class (PersistenceCapable)

This fixes the issue of ClassCastException.since both components depend on classes loaded
by the same class loader.
The jdo vendor implementation can be put anywhere, unless you also want to share instances
of the JDO vendor classes at runtime between OSGi bundles. The best choice is this:
mycomponent1.jar (OSGi bundle) - depends on mydomainclasses.jar, jdo.jar and
VENDOR_X.jar OSGi bundles
mycomponent2.jar (OSGi bundle)
mycomponent3.jar (OSGi bundle) - depends on mydomainclasses.jar, jdo.jar and
VENDOR_X.jar OSGi bundles
jdo.jar (OSGi bundle)
  - jdo.jar
mydomainclasses.jar (OSGi bundle) - depends on jdo.jar
  - Person.class (PersistenceCapable)
  - Company.class (PersistenceCapable)
VENDOR_X.jar (OSGi bundle)


> Add description for making JDO implementations compliant with OSGi component packaging
> --------------------------------------------------------------------------------------
>
>                 Key: JDO-465
>                 URL: https://issues.apache.org/jira/browse/JDO-465
>             Project: JDO
>          Issue Type: New Feature
>          Components: specification
>    Affects Versions: JDO 2 final
>            Reporter: Craig Russell
>            Assignee: Craig Russell
>            Priority: Minor
>             Fix For: JDO 2 maintenance release 1
>
>
> Proposal for J2SE Service Discovery and OSGi Service Discovery for JDO
> Provide transparent and less development time (in terms of pmf properties)
> dependencies to JDO vendors, enabling runtime discovery.
> J2SE Service Discovery
> -------------------------------
> The goal is provide more transparent replacement of implementation for
> operations/deployment or easier bootstrap mechanism for creating JDO instances.
> For awareness this proposal uses a similar mechanism to JPA.
> An Use Case is an application deployed to production environment which uses JDO
> implementation A and is not performing well. It was identified the problem was
> within the JDO implementation A, and to fix the issue it was decided to replace
> the implementation with a different vendor. The procedure consists in replacing
> the JDO vendor jar in the classpath and update the PMF properties pointing to
> the new vendor PMF class.
> With a service discovery this procedure would be reduced down to replacing only
> the JDO vendor jar.
> To implement such thing we can use the standard jar specification.
> How does it work for the jdo user :
> As before, by using the JDOHelper.getPMF(properties). However there is no need
> to set the property javax.jdo.PersistenceManagerFactoryClass if there is only
> one JDO vendor jar in the classpath.
> How does it work for the implementation :
> In the JDO jar file, add the file
> /META-INF/services/javax.jdo.PersistenceManagerFactory, and inside the
> file set the fully qualified class name for the PMF implementation.
> The JDOHelper.getPMF(properties) will do the service discovery, by using the
> standard jar spec.
> This service discovery is very likely to be used in J2SE environments.
> See:
> jar spec
> jpa spec (for an example of this service)
> OSGi Service Discovery for JDO
> -------------------------------
> The idea here is make better integration between JDO and OSGi, and the ultimate
> goal is to provide an OSGi service that can instantiates JDO PMFs.
> In OSGi containers, the service discovery uses similar concepts, but has
> different implementations, plut the way classloaders are handled is much more
> complex.
> From points 1 to 6 I expose the problems that occurs with OSGi development and
> JDO.
> 1)
> An OSGi application is usually split into several jars, something like:
> mycomponent1.jar (OSGi bundle)
> mycomponent2.jar (OSGi bundle)
> mycomponent3.jar (OSGi bundle)
> 2)
> Each OSGi bundle is loaded by a different classloader, java runtime classloader
> is parent for the bundle classlaoders.
> Each component can include libraries inside, for instance JDO. So:
> mycomponent1.jar (OSGi bundle)
>   - jdo.jar
>   - Person.class (PersistenceCapable)
>   - Company.class (PersistenceCapable)
> mycomponent2.jar (OSGi bundle)
> mycomponent3.jar (OSGi bundle)
> 3)
> For the moment only component1 uses the Persistent classes, but if mycomponent3
> needs to read Company instances, you will
> also need the Persistent classes + jdo.jar in the classpath. Then you decide to
> duplicate the classes to both OSGi bundles
> mycomponent1.jar (OSGi bundle)
>   - jdo.jar
>   - Person.class (PersistenceCapable)
>   - Company.class (PersistenceCapable)
> mycomponent2.jar (OSGi bundle)
> mycomponent3.jar (OSGi bundle)
>   - jdo.jar
>   - Person.class (PersistenceCapable)
>   - Company.class (PersistenceCapable)
> 4)
> Easy?? No, actually it will fail with ClassCastException at runtime, since
> Person of component1 is not castable
> to Person of component3. Solution:
> mycomponent1.jar (OSGi bundle) - depends on mydomainclasses.jar and jdo.jar OSGi
> bundles
> mycomponent2.jar (OSGi bundle)
> mycomponent3.jar (OSGi bundle) - depends on mydomainclasses.jar and jdo.jar OSGi
> bundles
> jdo.jar (OSGi bundle)
>   - jdo.jar
> mydomainclasses.jar (OSGi bundle) - depends on jdo.jar
>   - Person.class (PersistenceCapable)
>   - Company.class (PersistenceCapable)
> So this fixes the issue of ClassCastException.
> 5)
> Problem: Where to put the jdo vendor implementation?
> Actually it can be put anywhere, unless you also want to share instances of the
> JDO vendor classes at runtime between
> OSGi bundles. The best choice is this:
> mycomponent1.jar (OSGi bundle) - depends on mydomainclasses.jar, jdo.jar and
> VENDOR_X.jar OSGi bundles
> mycomponent2.jar (OSGi bundle)
> mycomponent3.jar (OSGi bundle) - depends on mydomainclasses.jar, jdo.jar and
> VENDOR_X.jar OSGi bundles
> jdo.jar (OSGi bundle)
>   - jdo.jar
> mydomainclasses.jar (OSGi bundle) - depends on jdo.jar
>   - Person.class (PersistenceCapable)
>   - Company.class (PersistenceCapable)
> VENDOR_X.jar (OSGi bundle)
> 6)
> Problem: How to remove the dependency to the JDO vendor jar at build time?
> Have an OSGi Service that discovers the implementation in the OSGi container and
> permits to create a PMF instance.
> mycomponent1.jar (OSGi bundle) - depends on mydomainclasses.jar and jdo.jar OSGi
> bundles
> mycomponent2.jar (OSGi bundle)
> mycomponent3.jar (OSGi bundle) - depends on mydomainclasses.jar and jdo.jar OSGi
> bundles
> jdo.jar (OSGi bundle) - provides Service JDOPMF
>   - jdo.jar
> mydomainclasses.jar (OSGi bundle) - depends on jdo.jar
>   - Person.class (PersistenceCapable)
>   - Company.class (PersistenceCapable)
> VENDOR_X.jar (OSGi bundle) - implements Service JDOPMF
> See
> osgi spec for more details on osgi services (osgi.org)
> Finally, how is this service implemented in OSGi?
> A sample will come soon. As soon as I have time to pack something, but I must
> say the implementation is very stupid.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message