On Apr 26, 2007, at 9:54 AM, Joe Bohn wrote:
Sorry about that. We had all agreed that was the correct approach
and it did fix the jstl issue. I should have thought to check jsf
as well.
It seems that these components (jsf, jstl) assume a flat
classloader. Our classloader structure is making this very
difficult. I hope that we can come up with a solution within our
classloader structure that allows everything to work but so far
this has proven elusive.
Is there not a work-around so that this milestone can still go out?
Does it help to add JSF & JSTL as dependencies of the application?
I have an idea I'll try that I hope will let us put the jstl jar back
into specs. Maybe we can write a Driver that delegates to a
datasource it looks up in jndi. No one should be using
DriverManager.getConnection in an enterprise app anyway, so I think
this might be an OK workaround.
thanks
david jencks
Joe
Paul McMahan wrote:
This may be related to the changes made in https://
issues.apache.org/jira/browse/GERONIMO-3051. It seems that there
are some classloader related problems with the sql tags in jstl.
After trying out the M5 release candidate just now I needed to
reopen that JIRA because the changes made for it in rev 532106
prevent myfaces from seeing the jstl classes.
Unfortunately, since JSF is no longer working I must vote -1 on
the M5 release. Reverting 532106 locally fixed the JSF problem
for me.
Best wishes,
Paul
On Apr 26, 2007, at 11:34 AM, Hernan Cunico wrote:
Folks, I'm still having some issues while accessing the embedded
Derby databases.
I can create a database using the embedded Derby from the Admin
Console.
I can insert some sample data and browse it from the Admin
Console too.
I can create a connection pool and test it from the console.
Testing is part of the GUI before the actual deployment.
So far so good but when I use a web app to access that DB via the
pool I just created I get "java.sql.SQLException: Database
'SomeDB' not found."
This only occurs on the embedded Derby DBs I create, I can access
and list content from the system-database without any problems
from this app.
It also works well with other pools for external DB and earlier
milestones so I guess the app is not the issue.
Folks, we pretty much have the same issue on every release, we
fix it in trunk and we break it again. Maybe we should look into
"desensitizing" the embedded Derby. ;-)
Cheers!
Hernan
Matt Hogstrom wrote:
Starting DISCUSS thread if necessary for this release.
