[jbosstools-dev] BIRT Deployment

[Snjezana Peco]

Max Rydahl Andersen wrote:
>>>> There is a problem with deploying a BIRT web project when using
>>>> Hibernate. Hibernate classes can't be loaded from within the OSGi
>>>> framework because they have already been loaded with web classloader.
>>>>
>>>>         
>>> ...this just sounds like a really broken design in BIRT...I can't beleive
>>> they don't support using classes from the sourrounding webapp.
>>>
>>>
>>>       
>> BIRT is executed within OSGi; it adds a web application loader as a
>> context classloader.
>> The rest of the problem is related to OSGi (and Hibernate), not to BIRT.
>>     
>
> But if Birt has the web app as a context classloader how come hibernate can't be loaded 
> when it exists in there ?
>
>   

If hibernate classes aren't in the plugin's classloader, they can be 
loaded only using reflection.
This way you loads the Ejb3Configuration to the 
ConsoleConfiguration.buildJPAConfiguration method. Ejb3Configuration is 
available in the context classloader, but not in the plugin classloader.
Fortunatelly, I have succeeded to solve this issue using OSGi Equinox 
properties. Now, I can control which classes to load from the web 
classloader (for ODA BIRT driver, only hibernate classes are necessary)

>>>> 2) Using JNDI SessionFactory and reflection.
>>>> The server has to bind the SessionFactory in JNDI, using
>>>> <property name="hibernate.session_factory_name"
>>>> value="java:/[ODA_DATASOURCE_NAME]"/>
>>>> in the persistence.xml file, for instance.
>>>> I have implemented this solution.
>>>>
>>>>         
>>> hmm...not sure how many binds it to jndi...not sure even if Seam does that?
>>>
>>>
>>>       
>> I am not sure that I understand your question. Seam doesn't bind a
>> session factory. Binding the session factory can be done by adding the
>> above mentioned Hibernate property.
>> This can be made within the BIRT facet.
>>     
>
> Yes, but I would much rather prefer that we had a way to inject a hibernate session to birt
> via a Seam component than tying a dependency to JNDI.
>
>   

Now, since we can load classes from the web app classloader, I need to 
find out a way how to grab a session factory.
One way is JNDI (I solved it). I think that adding a Seam component is a 
good way, but, in that case, Seam will be required.
I propose to add new properties to the Hibernate ODA datasource like the 
following:
- configuration name - it already exists and is used in the design time 
as the name of a console configuration (solved)
- Seam component name - if it exists, we would use a Seam component as a 
session factory helper
- JNDI name - if Seam component name doesn't exist, we would use it as a 
session factory helper (solved)
We can even add a JDBC datasource if some users are interested in 
creating a session factory that way (they don't have Seam and don't want 
to bind a session factory to JNDI, for instance).

Snjeza

>>>> 3) Creating a Session Facade Bean that would execute and analyze a query
>>>> for clients (BIRT OSGi engine)
>>>> This solution can be easily implemented, but requires an EJB environment.
>>>>
>>>>         
>>> hmm...why ? I don't follow this ?
>>>
>>>
>>>       
>> We could enable a user to choose a type of deployment (by adding a
>> property to the Hibernate datasource, for instance). Then we would
>> create a stateful session bean that would implement the
>> IOdaSessionFactory interface (it is defined in the
>> org.jboss.tools.birt.oda plugin). The client (HibernateConnection) would
>> use this bean in a similar way as it uses
>> ConsoleConfigurationOdaSessionFactory in the design mode or
>> ServerOdaSessionFactory in the deploy mode.
>>     
>
> Ok, but why does it require a stateful session bean ? Why not just a normal java class ?
>
>   
>>>> 4) Injecting web classloader into OSGi bundles using Adaptor Hooks
>>>> (http://wiki.eclipse.org/index.php/Adaptor_Hooks). I haven't implemented
>>>> this method yet, but think that the problem can be solved this way. I
>>>> will try it ASAP.
>>>>
>>>>         
>>> Ok - sounds interesting.
>>>
>>>
>>>       
>>>> I have committed the org.jboss.tools.birt.core plugin that fixes the
>>>> BIRT facet (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=235206)
>>>> and changed the o.j.t.b.oda and o.j.t.b.oda.ui plugins in order to
>>>> implement solution #2.
>>>> Tested using Ganymede RC2.
>>>>
>>>>         
>>> Ok, when I get my ganymede updated ill try.
>>> Do we need our Birt facet going forward ? Birt it self accepted the patch, right?
>>>
>>>
>>>       
>> The BIRT facet will be available in BIRT RC4, I assume.
>> I will refactor org.jboss.tools.birt.core after that and probably use
>> post-install delegate instead the facet.
>>     
>
> ok.
>
> /max
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>