Guys, lets move this discussion to the Jira. Thats the best way to
capture all these points...
On Thu 16 Aug 2012 09:25:58 AM CDT, Scott Marlow wrote:
> 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, 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
>>
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
--
st...@hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
