[jbosstools-dev] BIRT Deployment

[Max Rydahl Andersen]

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

> 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 ;(

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

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

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

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

/max