[jbosstools-dev] BIRT Deployment

[Snjezana Peco]

Max Rydahl Andersen wrote:
>>> 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.
>>     
>
> I only do that to avoid having to bundle the JPA specific binaries with our plugin.
>
> And I understand this, but I cannot believe Birt find it Ok to require users to 
> bundle their jars and configuration *twice* to use Birt - even for jdbc drivers and setup.
>
>   

No, BIRT doesn't require users to bundle their jars and configuration 
twice. However, OSGi doesn't use the app. classloader or system 
classpath by default.

>> 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)
>>     
>
> Yes, this will probably work but again weird hacky flags needs to be set to enable this ;(
>
>   

It is an OSGi feature.

>>>> 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)
>>     
>
> But this requires/usages whatever random hibernate jar our plugin has, correct ?
> It would not be using the same hibernate version as done by the user...
>
>   

This is used in the design time within an Eclipse application and 
hibernate jars from  hibernate tools plugins are used by the Hibernate 
ODA driver.
The user creates BIRT reports in this mode. This isn't related to a web 
application.
>> - Seam component name - if it exists, we would use a Seam component as a
>> session factory helper
>>     
>
> Well, we would probably want to hand in the actual session to be able to utilize
> the existing loaded data in the session ? Maybe something to look into later.
>
>   

The BIRT ODA driver requires a component to implement IOdaSessionFactory 
interface that will execute and analyze a hibernate query. The component 
can do it in any way.

>> - JNDI name - if Seam component name doesn't exist, we would use it as a
>> session factory helper (solved)
>>     
>
> Which jars would be used in this case ? 
>   

jars from the web app loader. The Hibernate ODA driver doesn't contain 
any jars.

>   
>> 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).
>>     
>
> How can a JDBC datasource be enough for a Hibernate query to work ?
>   

The user would add the hibernate.cfg.xml (or hibernate.properties) file.
However, this is just my suggestion. We don't have to implement it.

Snjeza
> /max
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>