You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Dr. Michael Lipp" <Mi...@danet.de> on 2005/08/10 13:42:16 UTC
Is using LocalDataSourceConnectionFactory really necessary? And:
getting rid of @PLATFORM@
Hi,
I apologize for the lengthy mail but the issue is not easy to understand
(at least it took me some time) and I want to make things as clear as
possible.
I'm trying to get the JBoss security module back to work after the
changes made in the recent weeks. The really big problem is that
OJB.properties has changed and uses LocalDataSourceConnectionFactory now:
ConnectionFactoryClass=org.springframework.orm.ojb.support.LocalDataSourceConnectionFactory
This is rather fatal (at least until we get and use dbojb 1.1). Let me
briefly explain why.
There is a problem when using dbojb in a library or framework or simply
anything that is meant to integrate with other code. The problem is the
usage of static classes and singletons for configuration in dbojb. It
implies that you can configure only a single instance of OJB (within the
same classloader). The issue is known and to be resolved with dbojb 1.1
(http://nagoya.apache.org/eyebrowse/ReadMsg?listName=ojb-dev@db.apache.org&msgNo=11150).
Jetspeed uses dbojb and is thus "in control" of dbojb. Anything that
wants to use dbojb too must either live with the configuration provided
by Jetspeed (at least the parts Jetspeed relies on, some things can
certainly be changed in OJB.properties without breaking Jetspeed) or
somehow use dbojb in its own classloader (not that easily achievable in
the J2EE environment).
The JBoss security module for Jetspeed is provided by an MBean in the
form of a "server extension". Obviously, this MBean cannot depend on the
deployment of some WebApplication (Jetspeed) and therefore the MBean
needs its own "instance" of dbojb. Up to M3, this has been no problem
because the MBean simply used the dbojb classes with the configuration
information also used by Jetspeed and thus the Jetspeed web applications
never "noticed" that it wasn't really them that instantiated dbojb (or
vice vera, whoever caused loading first). The MBean augmented the dbojb
configuration, however, by specifying a new JDBC connection description
(using the API). This is necessary because the datasource used by the
web application is not available outside the web application. This has
been no problem, the JDBC connection description has simply been
registered in the dbojb ConnectionRepository as another connection that
uses the "global" JNDI entry for the data source.
All this has worked fine up to M3 because the ConnectionRepository is
used to lookup connections by the ConnectionFactoryManagedImpl. But
currently, the LocalDataSourceConnectionFactory is used in place of the
ConnectionFactoryManagedImpl. This means that connection descriptions
are no longer looked up in the ConnectionRespository but must rather
exist in a specific Spring BeanContext (set once). Of course, this is
the BeanContext used (and set) by Jetspeed and this context is not
accessible outside Jetspeed, i.e. it is not accessible by the MBean.
What has been achieved by using LocalDataSourceConnectionFactory? IMO
very little: the connection used by Jetspeed is now configured using a
Spring controlled JavaBean instead of providing the information in
repository_database.xml. What has been lost? A lot: the possibility to
sustain (within the ojb configuration restrictions of Jetspeed) other
data base connections in parallel and thus use dbojb for more object
persistence tasks in parallel to Jetspeed.
I therefore propose to revert this change. Configuration of the db
connection in a JavaBean could still be done (even better) by writing a
JavaBean that creates the JDBC connection description in the
ConnectionRepository. Most of the code can be taken from
JetspeedSecurityService. boot/datasource.xml would instantiate this
JavaBean and thus create the entry in the ConnectionRepository (it is
the currently used solution provided by Spring that leads to the
problems). There would be another major advantage to this solution:
dbojb 1.0.3 provides JdbcMetadataUtils.fillJCDFromDataSource which can
be used to obtain initial information for the JDBC connection descriptor
from the JDBC data source. Among this information is the value of
"platform". I.e. we could get rid of the necessity to provide this
information by patching it in the maven scripts (ending up with a WAR
that can be deployed with a single RDBMS type only). The Jetspeed web
application would then automatically adapt to the RDBMs used (as does
JetspeedSecurityService already)!
It is not a big task to write the JavaBean I have described and should
best be best done by someone who can checkin all the changes. But of
course I am willing to do this (just tell me a package for the new
JavaBean) and provide patches.
What do you think?
- Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Is using LocalDataSourceConnectionFactory really necessary? And:
getting rid of @PLATFORM@
Posted by "Dr. Michael Lipp" <Mi...@danet.de>.
> - If you could, please provide an example/patch (chose a package to
> your liking for now)
> and create an JIRA issue for it so you can attach the code.
>
see JS2-326
Regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Is using LocalDataSourceConnectionFactory really necessary? And:
getting rid of @PLATFORM@
Posted by Ate Douma <at...@douma.nu>.
Michael,
I don't have time right now to look into the possible impact of your proposal
but I like to make the following comments already:
- a big +1 on getting rid of @PLATFORM@
- AFAIK the LocalDataSourceConnectionFactory was also created to make it
easier to setup testcases.
Your solution should not break the testcases or or make it more difficult
to set them up.
If it doesn't, I'll be +1 all the way.
- If you could, please provide an example/patch (chose a package to your liking for now)
and create an JIRA issue for it so you can attach the code.
If I find more time later this evening or tomorrow, I'll try to look more into this.
Regards, Ate
Dr. Michael Lipp wrote:
> Hi,
>
> I apologize for the lengthy mail but the issue is not easy to understand
> (at least it took me some time) and I want to make things as clear as
> possible.
>
> I'm trying to get the JBoss security module back to work after the
> changes made in the recent weeks. The really big problem is that
> OJB.properties has changed and uses LocalDataSourceConnectionFactory now:
>
> ConnectionFactoryClass=org.springframework.orm.ojb.support.LocalDataSourceConnectionFactory
>
> This is rather fatal (at least until we get and use dbojb 1.1). Let me
> briefly explain why.
>
> There is a problem when using dbojb in a library or framework or simply
> anything that is meant to integrate with other code. The problem is the
> usage of static classes and singletons for configuration in dbojb. It
> implies that you can configure only a single instance of OJB (within the
> same classloader). The issue is known and to be resolved with dbojb 1.1
> (http://nagoya.apache.org/eyebrowse/ReadMsg?listName=ojb-dev@db.apache.org&msgNo=11150).
>
> Jetspeed uses dbojb and is thus "in control" of dbojb. Anything that
> wants to use dbojb too must either live with the configuration provided
> by Jetspeed (at least the parts Jetspeed relies on, some things can
> certainly be changed in OJB.properties without breaking Jetspeed) or
> somehow use dbojb in its own classloader (not that easily achievable in
> the J2EE environment).
>
> The JBoss security module for Jetspeed is provided by an MBean in the
> form of a "server extension". Obviously, this MBean cannot depend on the
> deployment of some WebApplication (Jetspeed) and therefore the MBean
> needs its own "instance" of dbojb. Up to M3, this has been no problem
> because the MBean simply used the dbojb classes with the configuration
> information also used by Jetspeed and thus the Jetspeed web applications
> never "noticed" that it wasn't really them that instantiated dbojb (or
> vice vera, whoever caused loading first). The MBean augmented the dbojb
> configuration, however, by specifying a new JDBC connection description
> (using the API). This is necessary because the datasource used by the
> web application is not available outside the web application. This has
> been no problem, the JDBC connection description has simply been
> registered in the dbojb ConnectionRepository as another connection that
> uses the "global" JNDI entry for the data source.
>
> All this has worked fine up to M3 because the ConnectionRepository is
> used to lookup connections by the ConnectionFactoryManagedImpl. But
> currently, the LocalDataSourceConnectionFactory is used in place of the
> ConnectionFactoryManagedImpl. This means that connection descriptions
> are no longer looked up in the ConnectionRespository but must rather
> exist in a specific Spring BeanContext (set once). Of course, this is
> the BeanContext used (and set) by Jetspeed and this context is not
> accessible outside Jetspeed, i.e. it is not accessible by the MBean.
>
> What has been achieved by using LocalDataSourceConnectionFactory? IMO
> very little: the connection used by Jetspeed is now configured using a
> Spring controlled JavaBean instead of providing the information in
> repository_database.xml. What has been lost? A lot: the possibility to
> sustain (within the ojb configuration restrictions of Jetspeed) other
> data base connections in parallel and thus use dbojb for more object
> persistence tasks in parallel to Jetspeed.
>
> I therefore propose to revert this change. Configuration of the db
> connection in a JavaBean could still be done (even better) by writing a
> JavaBean that creates the JDBC connection description in the
> ConnectionRepository. Most of the code can be taken from
> JetspeedSecurityService. boot/datasource.xml would instantiate this
> JavaBean and thus create the entry in the ConnectionRepository (it is
> the currently used solution provided by Spring that leads to the
> problems). There would be another major advantage to this solution:
> dbojb 1.0.3 provides JdbcMetadataUtils.fillJCDFromDataSource which can
> be used to obtain initial information for the JDBC connection descriptor
> from the JDBC data source. Among this information is the value of
> "platform". I.e. we could get rid of the necessity to provide this
> information by patching it in the maven scripts (ending up with a WAR
> that can be deployed with a single RDBMS type only). The Jetspeed web
> application would then automatically adapt to the RDBMs used (as does
> JetspeedSecurityService already)!
>
> It is not a big task to write the JavaBean I have described and should
> best be best done by someone who can checkin all the changes. But of
> course I am willing to do this (just tell me a package for the new
> JavaBean) and provide patches.
>
> What do you think?
>
> - Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
RE: Is using LocalDataSourceConnectionFactory really necessary? And: getting rid of @PLATFORM@
Posted by Scott T Weaver <sc...@binary-designs.net>.
Michael,
I did not realize that moving the datasource to Spring would cause so many
issues, feel free to move it back to its previous state if that is the only
to solve the issue. The reason for the change was to move as many of the
configuration tasks into a single format, the Spring format. This would
alleviate users from having to understand both Spring and OJB configuration
idiosyncrasies. It also makes it very easy for a user to switch out JNDI
datasource for a locally pooled one without touching OJB at all.
Regards,
-Scott
> -----Original Message-----
> From: Dr. Michael Lipp [mailto:Michael.Lipp@danet.de]
> Sent: Wednesday, August 10, 2005 7:42 AM
> To: Jetspeed Developers List
> Subject: Is using LocalDataSourceConnectionFactory really necessary? And:
> getting rid of @PLATFORM@
>
> Hi,
>
> I apologize for the lengthy mail but the issue is not easy to understand
> (at least it took me some time) and I want to make things as clear as
> possible.
>
> I'm trying to get the JBoss security module back to work after the
> changes made in the recent weeks. The really big problem is that
> OJB.properties has changed and uses LocalDataSourceConnectionFactory now:
>
> ConnectionFactoryClass=org.springframework.orm.ojb.support.LocalDataSource
> ConnectionFactory
>
> This is rather fatal (at least until we get and use dbojb 1.1). Let me
> briefly explain why.
>
> There is a problem when using dbojb in a library or framework or simply
> anything that is meant to integrate with other code. The problem is the
> usage of static classes and singletons for configuration in dbojb. It
> implies that you can configure only a single instance of OJB (within the
> same classloader). The issue is known and to be resolved with dbojb 1.1
> (http://nagoya.apache.org/eyebrowse/ReadMsg?listName=ojb-
> dev@db.apache.org&msgNo=11150).
>
> Jetspeed uses dbojb and is thus "in control" of dbojb. Anything that
> wants to use dbojb too must either live with the configuration provided
> by Jetspeed (at least the parts Jetspeed relies on, some things can
> certainly be changed in OJB.properties without breaking Jetspeed) or
> somehow use dbojb in its own classloader (not that easily achievable in
> the J2EE environment).
>
> The JBoss security module for Jetspeed is provided by an MBean in the
> form of a "server extension". Obviously, this MBean cannot depend on the
> deployment of some WebApplication (Jetspeed) and therefore the MBean
> needs its own "instance" of dbojb. Up to M3, this has been no problem
> because the MBean simply used the dbojb classes with the configuration
> information also used by Jetspeed and thus the Jetspeed web applications
> never "noticed" that it wasn't really them that instantiated dbojb (or
> vice vera, whoever caused loading first). The MBean augmented the dbojb
> configuration, however, by specifying a new JDBC connection description
> (using the API). This is necessary because the datasource used by the
> web application is not available outside the web application. This has
> been no problem, the JDBC connection description has simply been
> registered in the dbojb ConnectionRepository as another connection that
> uses the "global" JNDI entry for the data source.
>
> All this has worked fine up to M3 because the ConnectionRepository is
> used to lookup connections by the ConnectionFactoryManagedImpl. But
> currently, the LocalDataSourceConnectionFactory is used in place of the
> ConnectionFactoryManagedImpl. This means that connection descriptions
> are no longer looked up in the ConnectionRespository but must rather
> exist in a specific Spring BeanContext (set once). Of course, this is
> the BeanContext used (and set) by Jetspeed and this context is not
> accessible outside Jetspeed, i.e. it is not accessible by the MBean.
>
> What has been achieved by using LocalDataSourceConnectionFactory? IMO
> very little: the connection used by Jetspeed is now configured using a
> Spring controlled JavaBean instead of providing the information in
> repository_database.xml. What has been lost? A lot: the possibility to
> sustain (within the ojb configuration restrictions of Jetspeed) other
> data base connections in parallel and thus use dbojb for more object
> persistence tasks in parallel to Jetspeed.
>
> I therefore propose to revert this change. Configuration of the db
> connection in a JavaBean could still be done (even better) by writing a
> JavaBean that creates the JDBC connection description in the
> ConnectionRepository. Most of the code can be taken from
> JetspeedSecurityService. boot/datasource.xml would instantiate this
> JavaBean and thus create the entry in the ConnectionRepository (it is
> the currently used solution provided by Spring that leads to the
> problems). There would be another major advantage to this solution:
> dbojb 1.0.3 provides JdbcMetadataUtils.fillJCDFromDataSource which can
> be used to obtain initial information for the JDBC connection descriptor
> from the JDBC data source. Among this information is the value of
> "platform". I.e. we could get rid of the necessity to provide this
> information by patching it in the maven scripts (ending up with a WAR
> that can be deployed with a single RDBMS type only). The Jetspeed web
> application would then automatically adapt to the RDBMs used (as does
> JetspeedSecurityService already)!
>
> It is not a big task to write the JavaBean I have described and should
> best be best done by someone who can checkin all the changes. But of
> course I am willing to do this (just tell me a package for the new
> JavaBean) and provide patches.
>
> What do you think?
>
> - Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org