Mailing-List: contact jetspeed-dev-help@portals.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@portals.apache.org>
Message-ID: <799288523.1124818449052.JavaMail.jira@ajax.apache.org>
Date: Tue, 23 Aug 2005 19:34:09 +0200 (CEST)
From: "Ate Douma (JIRA)" <jetspeed-dev@portals.apache.org>
To: jetspeed-dev@jakarta.apache.org
Subject: [jira] Commented: (JS2-326) Problem with
 LocalDataSourceConnectionFactory
In-Reply-To: <1337326071.1123754273728.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

    [ http://issues.apache.org/jira/browse/JS2-326?page=3Dcomments#action_1=
2319754 ]=20

Ate Douma commented on JS2-326:
-------------------------------

I can now confirm this patch, amended with the fix as described above by Mi=
chael works 100% with hsqldb, Oracle(9i), MySQL and PostgreSQL.
Not yet confirmed is MsSqlServer but I expect Scott Weaver can provide that=
.
And to be sure, I tested not only with Tomcat but also with WebSphere 5.1.1=
.
Although I didn't test with JBoss, I'll trust Michael will have covered tha=
t just fine :-)

Very good work Michael, and keep them coming, we very much appreciate it!

After I commit this later this evening we've gained a very important featur=
e: database independence of the portal war.
No longer do we require a hard coded OJB database platform in the configura=
tion.
Because of this, the build property  org.apache.jetspeed.production.databas=
e.ojb.platform is no longer needed
and I will remove it as well as the @platform@ filtering from the code.


> Problem with LocalDataSourceConnectionFactory
> ---------------------------------------------
>
>          Key: JS2-326
>          URL: http://issues.apache.org/jira/browse/JS2-326
>      Project: Jetspeed 2
>         Type: Bug
>   Components: Persistence and DAO
>     Versions: 2.0-M4
>  Environment: JBoss/HSQL
>     Reporter: Michael Lipp
>     Assignee: Ate Douma
>  Attachments: j2-LocalDS-patches-20050811.txt.gz, j2-LocalDS-patches-2005=
0817.txt.gz, j2-LocalDS-patches-20050820.txt
>
> I'm trying to get the JBoss security module back to work after the change=
s made in the recent weeks. The really big problem is that OJB.properties h=
as changed and uses LocalDataSourceConnectionFactory now:
> ConnectionFactoryClass=3Dorg.springframework.orm.ojb.support.LocalDataSou=
rceConnectionFactory
> This is rather fatal (at least until we get and use dbojb 1.1). Let me br=
iefly explain why.
> There is a problem when using dbojb in a library or framework or simply a=
nything that is meant to integrate with other code. The problem is the usag=
e of static classes and singletons for configuration in dbojb. It implies t=
hat you can configure only a single instance of OJB (within the same classl=
oader). The issue is known and to be resolved with dbojb 1.1 (http://nagoya=
.apache.org/eyebrowse/ReadMsg?listName=3Dojb-dev@db.apache.org&msgNo=3D1115=
0).
> Jetspeed uses dbojb and is thus "in control" of dbojb. Anything that want=
s to use dbojb too must either live with the configuration provided by Jets=
peed (at least the parts Jetspeed relies on, some things can certainly be c=
hanged in OJB.properties without breaking Jetspeed) or somehow use dbojb in=
 its own classloader (not that easily chievable in the J2EE environment).
> The JBoss security module for Jetspeed is provided by an MBean in the for=
m of a "server extension". Obviously, this MBean cannot depend on the deplo=
yment of some WebApplication (Jetspeed) and therefore the MBean
> needs its own "instance" of dbojb. Up to M3, this has been no problem bec=
ause the MBean simply used the dbojb classes with the configuration informa=
tion also used by Jetspeed and thus the Jetspeed web applications never "no=
ticed" that it wasn't really them that instantiated dbojb (or vice vera, wh=
oever caused loading first). The MBean augmented the dbojb configuration, h=
owever, by specifying a new JDBC connection description (using the API). Th=
is is necessary because the datasource used by the web application is not a=
vailable outside the web application. This has been no problem, the JDBC co=
nnection description has simply been registered in the dbojb ConnectionRepo=
sitory 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 use=
d to lookup connections by the ConnectionFactoryManagedImpl. But currently,=
 the LocalDataSourceConnectionFactory is used in place of the ConnectionFac=
toryManagedImpl. This means that connection descriptions are no longer look=
ed up in the  ConnectionRespository but must rather exist in a specific Spr=
ing BeanContext (set once). Of course, this is the BeanContext used (and se=
t) 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 ver=
y little: the connection used by Jetspeed is now configured using a Spring =
controlled JavaBean instead of providing the information in repository_data=
base.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 connec=
tion in a JavaBean could still be done (even better) by writing a JavaBean =
that creates the JDBC connection description in the ConnectionRepository. M=
ost of the code can be taken from JetspeedSecurityService. boot/datasource.=
xml would instantiate this JavaBean and thus create the entry in the Connec=
tionRepository (it is the currently used solution provided by Spring that  =
leads to the problems). There would be another major advantage to this solu=
tion: dbojb 1.0.3 provides JdbcMetadataUtils.fillJCDFromDataSource which ca=
n 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 pa=
tching it in the maven scripts (ending up with a WAR that can be deployed w=
ith a single RDBMS type only). The Jetspeed web application would then auto=
matically adapt to the  RDBMs used (as does JetspeedSecurityService already=
)!
> As has been discussed on the developer's list I'm going to provide the pa=
tches for the proposed change.

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org