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, mail...@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
>
>
--
st...@hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
