You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Matt Hogstrom <ma...@hogstrom.org> on 2007/04/26 08:39:24 UTC
[DISCUSS] 2.0-M5 (rc1) binaries available
Starting DISCUSS thread if necessary for this release.
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Kevan Miller <ke...@gmail.com>.
On Apr 26, 2007, at 10:40 PM, Prasad Kashyap wrote:
> Strange behavior. On a server from
> http://people.apache.org/~prasad/binaries/20070425/ I was able to
> deploy/undeploy a testsupport app multiple times.
>
> On the M5 server up for review, the undeploy first leaves behind the
> groupId/artifactId. Then after a redeploy and the second undeploy, it
> leaves behind a lot more files. This prevents further deployment of
> the same app.
>
> I tried this on 2 separate apps.
Hey Prasad,
Which testsupport app? I assume there's more than one...
--kevan
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Prasad Kashyap <go...@gmail.com>.
Strange behavior. On a server from
http://people.apache.org/~prasad/binaries/20070425/ I was able to
deploy/undeploy a testsupport app multiple times.
On the M5 server up for review, the undeploy first leaves behind the
groupId/artifactId. Then after a redeploy and the second undeploy, it
leaves behind a lot more files. This prevents further deployment of
the same app.
I tried this on 2 separate apps.
Cheers
Prasad
On 4/26/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> Starting DISCUSS thread if necessary for this release.
>
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Paul McMahan <pa...@gmail.com>.
OK I was confused about the intent of these milestone releases and
thought a -1 was appropriate given the impact of this regresssion.
I'll go with a -0 then. Is it possible to crack open the binaries to
update the release notes and mention that JSF is not available in
this milestone?
Best wishes,
Paul
On Apr 26, 2007, at 1:12 PM, Matt Hogstrom wrote:
>
> On Apr 26, 2007, at 12:37 PM, 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.
>
> Lots of things are broken still and this is just a point in time
> statement of where we are at. I'd agree that a regression is
> unfortunate but the intent of the milestone is a peek at where
> we're at on a monthly basis. See my other post on unstables as I
> think we're reading more into this being a release than we should.
> Perhaps its confusing to users as well.
>
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Apr 26, 2007, at 12:37 PM, 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.
Lots of things are broken still and this is just a point in time
statement of where we are at. I'd agree that a regression is
unfortunate but the intent of the milestone is a peek at where we're
at on a monthly basis. See my other post on unstables as I think
we're reading more into this being a release than we should. Perhaps
its confusing to users as well.
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by David Jencks <da...@yahoo.com>.
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.
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Joe Bohn <jo...@earthlink.net>.
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?
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.
>
>
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Paul McMahan <pa...@gmail.com>.
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.
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
> Do you remember what the problem/solution is? I'd guess that to make
>
> it work you'd have to include a dependency on the system-database
> module and not include any jar dependencies on derby. Is this even
> possible using the db wizard?
Yes, that works. I tested it on 2.0-M5 from command line. Currently
it is not possible to do this from DB wizard.
Thanks
Anita
Does the earlier connector-deployer
> gbean have system-database in the defaultEnvironment but it's now
> been removed? (IMO it should not be in the default environment).
>
> thanks
> david jencks
>
> >
> > Cheers!
> > Hernan
> >
> > Matt Hogstrom wrote:
> >> Starting DISCUSS thread if necessary for this release.
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by David Jencks <da...@yahoo.com>.
On Apr 26, 2007, at 8: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. ;-)
Do you remember what the problem/solution is? I'd guess that to make
it work you'd have to include a dependency on the system-database
module and not include any jar dependencies on derby. Is this even
possible using the db wizard? Does the earlier connector-deployer
gbean have system-database in the defaultEnvironment but it's now
been removed? (IMO it should not be in the default environment).
thanks
david jencks
>
> Cheers!
> Hernan
>
> Matt Hogstrom wrote:
>> Starting DISCUSS thread if necessary for this release.
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Hernan Cunico <hc...@gmail.com>.
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.
>
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Sachin Patel <sp...@gmail.com>.
I would not have any objection to doing this. The reason being we
have no formal test process in place for our milestone drivers and GA
releases as everyone has a different opinion as to what constitutes a
+1. Until we have a process in place and are in agreement of what
defines a daily, integration, milestone, and GA release a non-voting
weekly unstable driver is a good idea.
-sachin
On Apr 26, 2007, at 1:05 PM, Matt Hogstrom wrote:
> Here is a question to ponder. Would anyone object if I simply made
> these binaries available from people as a monthly unstable
> release? Given the amount of time it takes to spin this up and
> vote I'd rather just pick an svn version and make it available. I
> think it burns up a lot of people's time to follow the release
> process. Simply pop out the binary, let people play with it and if
> things are broken there is always trunk. Perhaps we could move to
> a weekly unstable.
>
> Anyway, I'd like some thoughts on this.
>
>
> On Apr 26, 2007, at 2:39 AM, Matt Hogstrom wrote:
>
>> Starting DISCUSS thread if necessary for this release.
>>
>
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Hernan Cunico <hc...@gmail.com>.
Agreed. I'm not changing my +1, I would really like to see a new milestone out.
We can update the release notes with what we observe in this thread.
Cheers!
Hernan
Matt Hogstrom wrote:
> Here is a question to ponder. Would anyone object if I simply made
> these binaries available from people as a monthly unstable release?
> Given the amount of time it takes to spin this up and vote I'd rather
> just pick an svn version and make it available. I think it burns up a
> lot of people's time to follow the release process. Simply pop out the
> binary, let people play with it and if things are broken there is always
> trunk. Perhaps we could move to a weekly unstable.
>
> Anyway, I'd like some thoughts on this.
>
>
> On Apr 26, 2007, at 2:39 AM, Matt Hogstrom wrote:
>
>> Starting DISCUSS thread if necessary for this release.
>>
>
>
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Matt Hogstrom <ma...@hogstrom.org>.
In the beginning I think we were tracking more of a clearly defined
content but as we get toward the end of 2.0 from a function complete
perspective the line does tend to blur. The goals from my
perspective were really twofold. One was to put a regular drop of
code to our users. The second was to help refine our process as
every release we ran into new issues that led to delays in getting a
release out.
User's clearly want to have builds they can get ahold of and test
with. Looking at the User mailing list I see several references to
M3, or where is M4 so its clear that users find them valuable.
Toward that end a continuous stream of builds is good.
I think we've also helped to refine our process. At this point
cranking out a release is significantly better and many of the legal
and packaging issues that has plagued us have been resolved. I'm not
sure we need to continue releasing on a monthly basis. That said, we
still need to keep up on the process so it doesn't fall apart over
time. Also, one added benefit to doing the drill is people take a
slightly more critical look at the content of the build. Overall,
there is benefit to doing it but it is expensive. Just like Jason
has observed on several occasions that if we don't keep an eye on
things they fall into disrepair (like the build). Anyway, probably
more of a balancing act; we're better off than we were and we're just
finding the right balance.
Thoughts?
On Apr 27, 2007, at 12:10 PM, Dain Sundstrom wrote:
> I think doing a monthly or simi-monthy unstable would be excellent,
> and would save a lot of work. As for naming, I don't really care.
> We are releasing milestones right now, and they don't really
> represent "defined" goals anyway.
>
> -dain
>
>
> On Apr 26, 2007, at 10:56 AM, Donald Woods wrote:
>
>> I like the idea of publishing monthly builds, but calling them a
>> Milestone when there was no defined and met milestone doesn't
>> quite make sense...
>>
>> Why not just ask Prasad (or Jason w/ GBuild) to include the
>> testsuite in the daily run that includes the unit tests -
>>
>> Subject: [BUILD] TRUNK: Successful for Revision: 532672
>> Date: 26 Apr 2007 09:37:43 -0000
>> From: prasad@apache.org
>> Reply-To: dev@geronimo.apache.org
>> To: scm@geronimo.apache.org
>>
>> OpenEJB trunk at 532669
>> Geronimo Revision: 532672 built with tests included
>> . . .
>>
>> and then just pick one of those that passes every week to publish
>> to the snapshot repo and to publish for users to download? That
>> way, as the testsuite gains more component coverage, we'll
>> naturally move towards a more formal test process before releases
>> are selected to vote on.
>>
>>
>> -Donald
>>
>> Matt Hogstrom wrote:
>>> Here is a question to ponder. Would anyone object if I simply
>>> made these binaries available from people as a monthly unstable
>>> release? Given the amount of time it takes to spin this up and
>>> vote I'd rather just pick an svn version and make it available.
>>> I think it burns up a lot of people's time to follow the release
>>> process. Simply pop out the binary, let people play with it and
>>> if things are broken there is always trunk. Perhaps we could
>>> move to a weekly unstable.
>>> Anyway, I'd like some thoughts on this.
>>> On Apr 26, 2007, at 2:39 AM, Matt Hogstrom wrote:
>>>> Starting DISCUSS thread if necessary for this release.
>>>>
>
>
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Dain Sundstrom <da...@iq80.com>.
I think doing a monthly or simi-monthy unstable would be excellent,
and would save a lot of work. As for naming, I don't really care.
We are releasing milestones right now, and they don't really
represent "defined" goals anyway.
-dain
On Apr 26, 2007, at 10:56 AM, Donald Woods wrote:
> I like the idea of publishing monthly builds, but calling them a
> Milestone when there was no defined and met milestone doesn't quite
> make sense...
>
> Why not just ask Prasad (or Jason w/ GBuild) to include the
> testsuite in the daily run that includes the unit tests -
>
> Subject: [BUILD] TRUNK: Successful for Revision: 532672
> Date: 26 Apr 2007 09:37:43 -0000
> From: prasad@apache.org
> Reply-To: dev@geronimo.apache.org
> To: scm@geronimo.apache.org
>
> OpenEJB trunk at 532669
> Geronimo Revision: 532672 built with tests included
> . . .
>
> and then just pick one of those that passes every week to publish
> to the snapshot repo and to publish for users to download? That
> way, as the testsuite gains more component coverage, we'll
> naturally move towards a more formal test process before releases
> are selected to vote on.
>
>
> -Donald
>
> Matt Hogstrom wrote:
>> Here is a question to ponder. Would anyone object if I simply
>> made these binaries available from people as a monthly unstable
>> release? Given the amount of time it takes to spin this up and
>> vote I'd rather just pick an svn version and make it available. I
>> think it burns up a lot of people's time to follow the release
>> process. Simply pop out the binary, let people play with it and
>> if things are broken there is always trunk. Perhaps we could move
>> to a weekly unstable.
>> Anyway, I'd like some thoughts on this.
>> On Apr 26, 2007, at 2:39 AM, Matt Hogstrom wrote:
>>> Starting DISCUSS thread if necessary for this release.
>>>
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Donald Woods <dw...@apache.org>.
I like the idea of publishing monthly builds, but calling them a Milestone when
there was no defined and met milestone doesn't quite make sense...
Why not just ask Prasad (or Jason w/ GBuild) to include the testsuite in the
daily run that includes the unit tests -
Subject: [BUILD] TRUNK: Successful for Revision: 532672
Date: 26 Apr 2007 09:37:43 -0000
From: prasad@apache.org
Reply-To: dev@geronimo.apache.org
To: scm@geronimo.apache.org
OpenEJB trunk at 532669
Geronimo Revision: 532672 built with tests included
. . .
and then just pick one of those that passes every week to publish to the snapshot
repo and to publish for users to download? That way, as the testsuite gains more
component coverage, we'll naturally move towards a more formal test process
before releases are selected to vote on.
-Donald
Matt Hogstrom wrote:
> Here is a question to ponder. Would anyone object if I simply made
> these binaries available from people as a monthly unstable release?
> Given the amount of time it takes to spin this up and vote I'd rather
> just pick an svn version and make it available. I think it burns up a
> lot of people's time to follow the release process. Simply pop out the
> binary, let people play with it and if things are broken there is always
> trunk. Perhaps we could move to a weekly unstable.
>
> Anyway, I'd like some thoughts on this.
>
>
> On Apr 26, 2007, at 2:39 AM, Matt Hogstrom wrote:
>
>> Starting DISCUSS thread if necessary for this release.
>>
>
>
>
Re: [DISCUSS] 2.0-M5 (rc1) binaries available
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Here is a question to ponder. Would anyone object if I simply made
these binaries available from people as a monthly unstable release?
Given the amount of time it takes to spin this up and vote I'd rather
just pick an svn version and make it available. I think it burns up
a lot of people's time to follow the release process. Simply pop out
the binary, let people play with it and if things are broken there is
always trunk. Perhaps we could move to a weekly unstable.
Anyway, I'd like some thoughts on this.
On Apr 26, 2007, at 2:39 AM, Matt Hogstrom wrote:
> Starting DISCUSS thread if necessary for this release.
>