[hibernate-dev] OSGI manifests for hibernate-orm

[Steve Ebersole]

BTW, on master commons-annotations is in fact still needed so yes we 
need to account for it.  However, just a heads up that on the metamodel 
branch, we no longer use commons-annotations.

Some background that I alluded to before...  Master is 4.1 + (ongoing) 
JPA 2.1 support.  There is also a shared branch called metamodel that 
represents the new way of parsing mapping information and some other 
changes.  The hope is that we will never ever do a release from master 
as it is right now, but instead integrate metamodel back into master and 
release 5.0 with the new metamodel approach and JPA 2.1 support. 
Current master is a contingency plan in case we need to do 4.2 with just 
JPA 2.1 support.

What does that mean?  Well, ok, lets do OSGi for commons-annotations if 
we have to, but lets not spend a lot of time on it since it is 
throw-away work.  Is it needed?  It should never be getting exposed via 
exported contracts.  Maybe there are alternatives?

On 08/16/2012 04:58 AM, mailing at 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
>
>

-- 
steve at hibernate.org
http://hibernate.org