9:25 a.m.
Does the Bundle-Activator really belong in the Hibernate core project?
Or should it be in the external OSGI container? Or perhaps someone may
want to maintain an external project that generates the "ready to be
used" Hibernate Bundle-Activator.
On 08/16/2012 05:58 AM, mailing(a)bibbernet.org wrote:
Hi Steve,
> Not being well-versed in OSGi, could you explain what 'blueprint.xml'
> is?
> I guess the purpose is the same/similar to
> /META-INF/services/javax.persistence.spi.PersistenceProvider defined by
> JPA, yet OSGi specific?
Ok, to give some background information, I will cite a section of the
"OSGI Service Platform Release 4, Enterprise Specification Version 4.2":
<cite>
127.5.1 Managed Model
A JPA Provider that supports running in managed mode should register a
specific service for the Java EE Containers: the Persistence Provider
service. The interface is the standard JPA PersistenceProvider interface.
See Dependencies on page 402 for the issues around the multiple versions
that this specification supports.
The service must be registered with the following service property:
javax.persistence.provider – The JPA Provider implementation class name, a
documented name for all JPA Providers.
The Persistence Provider service enables a Java EE Container to find a
particular JPA Provider. This service is intended for containers only, not
for Client Bundles because there are implicit assumptions
in the JPA Providers about the Java EE environment. A Java EE Container
must obey the life cycle of the Persistence Provider service. If this
service is unregistered then it must close all connections and
clean up the corresponding resources.
</cite>
This means we need to generate a service which announces the existence of
a new persistence provider. There are in general two ways:
The programmatic way:
- Create a BundleActivator.class which generates the service.
- Add the Bundle-Activator (needed) and Export-Service (only informative
nature) manifest headers
A non complete example could be:
--------------------------
package org.hibernate.ejb.osgi;
import java.util.Properties;
import javax.persistence.spi.PersistenceProvider;
import org.hibernate.ejb.HibernatePersistence;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
public class PersistenceProviderActivator implements BundleActivator {
public void start(final BundleContext context) throws Exception {
Properties properties = new Properties();
properties.put("javax.persistence.provider",
HibernatePersistence.class.getName());
context.registerService(PersistenceProvider.class.getName(),
HibernatePersistence.class.newInstance(), properties);
}
public void stop(final BundleContext context) throws Exception {
}
}
+
Bundle-Activator: org.hibernate.ejb.osgi.PersistenceProviderActivator
--------------------------
The descriptive way:
- Create a blueprint.xml file to describe and announce the service (See
OSGI Enterprise Specification Version 4.2 - Section 121 for more
information about blueprint)
- The file must be located under OSGI-INF/blueprint
- Add the Export-Service manifest headers (only informative nature)
Some background about blueprint bundles:
<cite>
121.3 Blueprint Life-Cycle
A bundle is a Blueprint bundle if it contains one or more blueprint XML
definition resources in the OSGI-INF/blueprint directory or it contains
the Bundle-Blueprint manifest header referring to existing resources.
</cite>
A non complete Example could be:
--------------------------
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
<bean id="hibernateJpaProvider"
class="org.hibernate.ejb.HibernatePersistence" />
<service ref="hibernateJpaProvider"
interface="javax.persistence.spi.PersistenceProvider">
<service-properties>
<entry key="javax.persistence.provider"
value="org.hibernate.ejb.HibernatePersistence" />
</service-properties>
</service>
</blueprint>
--------------------------
I prefere the descriptive way - but I am open for discussions.
> I'd much rather see this in 5.0 which is slated as the next release atm,
> or 4.2 if we end up needing a JPA 2.1 specific release.
Working against master is not a problem for me. It was one of the main
purposses of my post to clarify the surrounding conditions for my work :)
We should narrow down the target versions for hibernate-commons-annotation
and the other needed bundles too.
regards
Martin Neimeier
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev