[jbosstools-dev] BIRT Deployment

[Max Rydahl Andersen]

>>> 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.

Ok, so if it cannot use our classes nor jars how does Birt avoid rebundling of jars and configuration twice ?

>>> 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.

Yes ? Does not change the fact that it is a hack caused by Birt requiring us to start an osgi app 
inside our web app to just freaking render a pdf/html report.

>>>>> 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.

k.

>>> - 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.

A sessionfactory cannot execute and analyze a hibernate query - I assume you create a Session to get it.

>>> - 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.

And that works without messing with the classloader or does it still require the classloader/osgi tweaks ?

/max