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?

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.

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 >

In fact splitting those purposes alone solves the problem with org.hibernate.engine.spi.JpaCascadingAction I believe As for org.hibernate.engine.spi.JpaCascadeStyle, TBH, I am not sure exactly why we need this split between persist() handling for hibernate-core versus persist() handling for hibernate-entitymanager. I asked Hardy about this a few weeks ago when I was working on integrating JPA 2.1 on master. But I forget the reasoning. Hardy? I just remember that the end result was we decided it was best to leave them separate. Even leaving them split, I would think we could do something like having the org.hibernate.jpa.internal.event.JpaIntegrator register the override, rather than doing it in static loading blocks.

On 08/15/2012 05:08 PM, mailing(a)bibbernet.org wrote: > Hello, > > because I need clean OSGI bundles for Hibernate and especially Envers, > I am working on some patches for the 4.1 branch of hibernate-orm to > enable generation of OSGI compatible jar files. > > During the work I have found the following problems, and need some > help and/or feedback. The problems are: > > - The package org.hibernate.engine.spi is exported by two jar files, > hibernate-core and hibernate-entitymanager, which is not possible in > OSGI. The Problem is the STYLES map in CascadeStyle in hibernate-core > which prevent that the package in hibernate-entitymanager can be > refactored from org.hibernate.engine.spi to > org.hibernate.ejb.engine.spi, to solve the duplicate export. > I think to fix this problem, the following steps should be done: > - Add a setter method to CascadeStyle to allow subclasses to add > CascadeStyles to the map STYLES > - Refactor the package org.hibernate.engine.spi in hibernate-envers to > org.hibernate.ejb.engine.spi > - Use the setter method to add the new CascadeStyle in EJB3CascadeStyle > > - The package org.hibernate.tool.ant is exported by to jars, > hibernate-tools (version: 3.2.0.ga) and hibernate-envers, which is > also a duplicate export problem. The problem is that HibernateToolTask > in hibernate-tools has no getters/setters for configurationTask and > thus hibernate-envers is directly reading/modyifing the property > configurationTask. I think to fix this problem, the following steps > should be done: > - hibernate-tools should add public getters/setters for > configurationTask in class HibernateToolTask > - the package org.hibernate.tool.ant in hibernate-envers should be > refactored to org.hibernate.envers.tool.ant > - the property configurationTask should be accessed sole thru the > getters/setters . > > It would be nice if someone could check and comment my planned and > already done changes. > > I have already done the CascadeStyle fix, the configurationTask fix is > outstanding because I need to know against which version of > hibernate-tools I should create the fix. > > In generally the following tasks are done until now: > - added configuration to gradle scripts to generate the osgi manifests > for all jar files in hibernate-orm (needs maybe some cleanup) - right > now the build files for hibernate-core, hibernate-entitymanager and > hibernate-envers are modified. > - added blueprint.xml to hibernate-entitymanager to announce the > availabillity of a javax.persistence.provider > > Next steps: > - add osgi manifests to the other jars of hibernate-orm > - write integration tests with pax exam and karaf 2.2.x > - finish refactoring of hibernate-tools > - add patches for other needed dependencies > (hibernate-commons-annotations and more) > - more testing, more integration tests > > Help, reviews and comments are welcome, and if someone has already > done the work or parts, please drop me a note. > > Attached find a patch against the branch 4.1 of hibernate-orm. > > regards > Martin Neimeier > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- steve(a)hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev