Re: [Vote] 1.1-rc1 Now Available

2006-06-12 Thread David Jencks


I think that we may need to recut the release due to http:// 
issues.apache.org/jira/browse/GERONIMO-2108


Apparently I forgot to convert message-destination elements in  
geronimo plans to the naming namespace and as a consequence it is  
impossible to use them in web plans.  Aside from rewriting your spec  
dds to not use message-destination or renaming stuff to auto-resolve  
I don't know of a workaround.


I think I've fixed the issue but want to think if there are any more  
cases before I close it.


My apologies,

thanks
david jencks




Matt Hogstrom wrote:

I apologize for resending this to the lists.  I inadvertantly did not
put [vote] in the subject line so it may not have been apparent.  The
remainder of this e-mail is the same content that was distributed  
last

night.

Matt Hogstrom wrote:

Over the past few days the outstanding issues that were raised about
the first candidate have been addressed.

They were that we were missing the LICENSE.txt as well as Notices  
from

the distribution.  I added them.  Guillaume also pointed out that he
noted that there should be a Third Party Notices.  This was not
included in the original 1.0 or previous distributions so I did not
follow it up.  Thoughts?

Also, the 1.0 release notes were removed and updated the thread
started by Hernan.  The Wiki has been updated and the wiki was the
source used to create the RELEASE-NOTES-1.1.txt file you will  
find in

the build.

To avoid issues with the version number and the plugins I used rc1
which Aaron had added in the plugins for supported versions so I  
trust

that works here.

JSisson addressed the problem with not being able to run Geronimo
under CygWin and Kevan worked with Aaron to address a new deployment
problem that left partially deployed artifacts in the repository.

I have taken this build and run some performance tests on it and we
are significantly better in 1.1 than we were in 1.0.  We have a  
lot of

improvement left for CMP EJBs.  It appears that the performance
improvements in the EJB tier has changed a race condition when  
running
under DB2.  I'm afraid that the only way to address the problem  
is to
add a new feature to TranQL and OEJB that allow for the  
specification
of Isolation Levels for individual beans.  This is a relatively  
simple
change but the build as it stands is specification compliant.  I  
would

prefer to let this release go forward since CMP 2.1 EJBs are not
nearly as common as the other J2EE components.  I would like to
address this in 1.1.1 however I don't think we've locked down  
whether

that would be allowed or not.  The change would affect TranQL and
OpenEJB so they are really included components so I'd be  
interested in

people's feedback.

So please accept a named RC1.  Your voting and feedback are for:

Geronimo 1.1
DayTrader 1.1
Specs 1.1

The vote will stand for 72 hours.  Issues raised will be  
discussed and
if we conclude that there is a bug that must be addressed then we  
will

mitigate the problem and respin a new rc for a 72 hour vote.

If this is accepted all three of the above components will be  
released

simultaneously.

Here are the builds for your review and comment:

http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1- 
rc1.tar.gz
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1- 
rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-j2ee-1.1- 
rc1.tar.gz


http://people.apache.org/~hogstrom/rc1/geronimo-romcat-j2ee-1.1- 
rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1- 
rc1.tar.gz


http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1- 
rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat- 
minimal-1.1-rc1.tar.gz


http://people.apache.org/~hogstrom/rc1/geronimo-tomcat- 
minimal-1.1-rc1.zip



http://people.apache.org/~hogstrom/rc1/daytrader-ear-1.1-rc1.zip


Looking forward to your comments and feedback.






Re: [Vote] 1.1-rc1 Now Available

2006-06-12 Thread Matt Hogstrom

John,

I'm not aware of what does or does not go into the NOTICES file.  If we need the notices does anyone 
have a list of them lying around on their harddisk ?


Otherwise, any volunteers to pull them together?

Hernan, could you start a Wiki page for people to post their findings to?

Cheers,

Matt

John Sisson wrote:
I have started some due diligence checking on the release candidate and 
have a few questions.


AFAIK, the NOTICE.txt file should contain required third-party 
notices/attributions, yet it seems pretty empty to me.


For example, I was expecting to see the text from 
http://www.bouncycastle.org/licence.html in there since we have a copy 
of some of their code (no crypto though) in geronimo's util module.  The 
page on their website indicates that a notice may be required.


What about other 3rd party binaries that we include in the 
distribution?  For example, I had a quick look at the repository 
directory in the assemblies and there are libraries we ship where their 
project website requires attributions etc to be included with binary 
distributions (e.g. ASM , http://asm.objectweb.org/license.html ).


Please speak up if I am misinterpreting the use of the NOTICE.txt file.

Thanks,

John

Matt Hogstrom wrote:
I apologize for resending this to the lists.  I inadvertantly did not 
put [vote] in the subject line so it may not have been apparent.  The 
remainder of this e-mail is the same content that was distributed last 
night.


Matt Hogstrom wrote:
Over the past few days the outstanding issues that were raised about 
the first candidate have been addressed.


They were that we were missing the LICENSE.txt as well as Notices 
from the distribution.  I added them.  Guillaume also pointed out 
that he noted that there should be a Third Party Notices.  This was 
not included in the original 1.0 or previous distributions so I did 
not follow it up.  Thoughts?


Also, the 1.0 release notes were removed and updated the thread 
started by Hernan.  The Wiki has been updated and the wiki was the 
source used to create the RELEASE-NOTES-1.1.txt file you will find in 
the build.


To avoid issues with the version number and the plugins I used rc1 
which Aaron had added in the plugins for supported versions so I 
trust that works here.


JSisson addressed the problem with not being able to run Geronimo 
under CygWin and Kevan worked with Aaron to address a new deployment 
problem that left partially deployed artifacts in the repository.


I have taken this build and run some performance tests on it and we 
are significantly better in 1.1 than we were in 1.0.  We have a lot 
of improvement left for CMP EJBs.  It appears that the performance 
improvements in the EJB tier has changed a race condition when 
running under DB2.  I'm afraid that the only way to address the 
problem is to add a new feature to TranQL and OEJB that allow for the 
specification of Isolation Levels for individual beans.  This is a 
relatively simple change but the build as it stands is specification 
compliant.  I would prefer to let this release go forward since CMP 
2.1 EJBs are not nearly as common as the other J2EE components.  I 
would like to address this in 1.1.1 however I don't think we've 
locked down whether that would be allowed or not.  The change would 
affect TranQL and OpenEJB so they are really included components so 
I'd be interested in people's feedback.


So please accept a named RC1.  Your voting and feedback are for:

Geronimo 1.1
DayTrader 1.1
Specs 1.1

The vote will stand for 72 hours.  Issues raised will be discussed 
and if we conclude that there is a bug that must be addressed then we 
will mitigate the problem and respin a new rc for a 72 hour vote.


If this is accepted all three of the above components will be 
released simultaneously.


Here are the builds for your review and comment:

http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.tar.gz 


http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-j2ee-1.1-rc1.tar.gz 


http://people.apache.org/~hogstrom/rc1/geronimo-romcat-j2ee-1.1-rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.tar.gz 

http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.zip 

http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.tar.gz 

http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.zip 



http://people.apache.org/~hogstrom/rc1/daytrader-ear-1.1-rc1.zip


Looking forward to your comments and feedback.











[jira] Resolved: (AMQ-737) for consumers especially but for producers too, it'd be good to do a brief summary on the command line of the throughput

2006-06-12 Thread Adrian Co (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-737?page=all ]
 
Adrian Co resolved AMQ-737:
---

Resolution: Fixed

Done.

> for consumers especially but for producers too, it'd be good to do a brief 
> summary on the command line of the throughput
> 
>
>  Key: AMQ-737
>  URL: https://issues.apache.org/activemq/browse/AMQ-737
>  Project: ActiveMQ
> Type: Improvement

>   Components: Performance Test
> Versions: 4.0
> Reporter: james strachan
> Assignee: Adrian Co
>  Fix For: 4.1

>
>
> e.g. after running
> mvn activemq-perf:consumer
> it'd be nice to output a little summary something like
> Average throughtput: 1234.45 message/second.
> For average calulation it might be nice to ignore the first couple or the 
> highest & lowest values or something.
> Also for multiple consumers inside the JVM it might be nice to show something 
> like...
> Average throughput : 5000 msg/sec. Average per consumer: 1000 msg/sec, Min 
> consumer: 200 msg/sec, Max consumer: 1400 msg/sec
> so its easy at a glance to get a feel for the results if you are running the 
> tests from a command line

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



[jira] Commented: (AMQ-737) for consumers especially but for producers too, it'd be good to do a brief summary on the command line of the throughput

2006-06-12 Thread Adrian Co (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-737?page=comments#action_36321 ] 

Adrian Co commented on AMQ-737:
---

See the manual for usage.

> for consumers especially but for producers too, it'd be good to do a brief 
> summary on the command line of the throughput
> 
>
>  Key: AMQ-737
>  URL: https://issues.apache.org/activemq/browse/AMQ-737
>  Project: ActiveMQ
> Type: Improvement

>   Components: Performance Test
> Versions: 4.0
> Reporter: james strachan
> Assignee: Adrian Co
>  Fix For: 4.1

>
>
> e.g. after running
> mvn activemq-perf:consumer
> it'd be nice to output a little summary something like
> Average throughtput: 1234.45 message/second.
> For average calulation it might be nice to ignore the first couple or the 
> highest & lowest values or something.
> Also for multiple consumers inside the JVM it might be nice to show something 
> like...
> Average throughput : 5000 msg/sec. Average per consumer: 1000 msg/sec, Min 
> consumer: 200 msg/sec, Max consumer: 1400 msg/sec
> so its easy at a glance to get a feel for the results if you are running the 
> tests from a command line

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



[jira] Commented: (GERONIMO-2094) All geronimo jars and distributions should include at least the required LICENSE and NOTICE files

2006-06-12 Thread Matt Hogstrom (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-2094?page=comments#action_12415950
 ] 

Matt Hogstrom commented on GERONIMO-2094:
-

Added appropriate versions to the Geronimo build process.

> All geronimo jars and distributions should include at least the required 
> LICENSE and NOTICE files
> -
>
>  Key: GERONIMO-2094
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2094
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: general
> Versions: 1.0
> Reporter: Guillaume Nodet
> Priority: Critical
>  Fix For: 1.1

>
> The presence of the LICENSE and NOTICE files are a legal requirements for all 
> ASF software published.
> For distributions, they must be in the root folder.
> For jars publicly available (via maven repos), they should be in the META-INF 
> dir.
> Also, the distributions should include third party licenses for included jars.

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



[jira] Updated: (GERONIMO-2094) All geronimo jars and distributions should include at least the required LICENSE and NOTICE files

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2094?page=all ]

Matt Hogstrom updated GERONIMO-2094:


Comment: was deleted

> All geronimo jars and distributions should include at least the required 
> LICENSE and NOTICE files
> -
>
>  Key: GERONIMO-2094
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2094
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: general
> Versions: 1.0
> Reporter: Guillaume Nodet
> Priority: Critical
>  Fix For: 1.1

>
> The presence of the LICENSE and NOTICE files are a legal requirements for all 
> ASF software published.
> For distributions, they must be in the root folder.
> For jars publicly available (via maven repos), they should be in the META-INF 
> dir.
> Also, the distributions should include third party licenses for included jars.

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



[jira] Closed: (GERONIMO-2094) All geronimo jars and distributions should include at least the required LICENSE and NOTICE files

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2094?page=all ]
 
Matt Hogstrom closed GERONIMO-2094:
---

Resolution: Fixed

Added the LICENSE as well.

> All geronimo jars and distributions should include at least the required 
> LICENSE and NOTICE files
> -
>
>  Key: GERONIMO-2094
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2094
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: general
> Versions: 1.0
> Reporter: Guillaume Nodet
> Priority: Critical
>  Fix For: 1.1

>
> The presence of the LICENSE and NOTICE files are a legal requirements for all 
> ASF software published.
> For distributions, they must be in the root folder.
> For jars publicly available (via maven repos), they should be in the META-INF 
> dir.
> Also, the distributions should include third party licenses for included jars.

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



[jira] Created: (GERONIMO-2111) Change Default WebContainer behaviour to disable AccessLogging

2006-06-12 Thread Matt Hogstrom (JIRA)
Change Default WebContainer behaviour to disable AccessLogging
--

 Key: GERONIMO-2111
 URL: http://issues.apache.org/jira/browse/GERONIMO-2111
 Project: Geronimo
Type: Task
Security: public (Regular issues) 
Reporter: Matt Hogstrom
 Assigned to: Matt Hogstrom 
 Fix For: 1.2


Currently Tomcat and Jetty have access logging enabled by default.  This should 
be changed to have it disabled by default for all geronimo assemblies.

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



Re: [Vote] 1.1-rc1 Now Available

2006-06-12 Thread John Sisson
I have started some due diligence checking on the release candidate and 
have a few questions.


AFAIK, the NOTICE.txt file should contain required third-party 
notices/attributions, yet it seems pretty empty to me.


For example, I was expecting to see the text from 
http://www.bouncycastle.org/licence.html in there since we have a copy 
of some of their code (no crypto though) in geronimo's util module.  The 
page on their website indicates that a notice may be required.


What about other 3rd party binaries that we include in the 
distribution?  For example, I had a quick look at the repository 
directory in the assemblies and there are libraries we ship where their 
project website requires attributions etc to be included with binary 
distributions (e.g. ASM , http://asm.objectweb.org/license.html ).


Please speak up if I am misinterpreting the use of the NOTICE.txt file.

Thanks,

John

Matt Hogstrom wrote:
I apologize for resending this to the lists.  I inadvertantly did not 
put [vote] in the subject line so it may not have been apparent.  The 
remainder of this e-mail is the same content that was distributed last 
night.


Matt Hogstrom wrote:
Over the past few days the outstanding issues that were raised about 
the first candidate have been addressed.


They were that we were missing the LICENSE.txt as well as Notices 
from the distribution.  I added them.  Guillaume also pointed out 
that he noted that there should be a Third Party Notices.  This was 
not included in the original 1.0 or previous distributions so I did 
not follow it up.  Thoughts?


Also, the 1.0 release notes were removed and updated the thread 
started by Hernan.  The Wiki has been updated and the wiki was the 
source used to create the RELEASE-NOTES-1.1.txt file you will find in 
the build.


To avoid issues with the version number and the plugins I used rc1 
which Aaron had added in the plugins for supported versions so I 
trust that works here.


JSisson addressed the problem with not being able to run Geronimo 
under CygWin and Kevan worked with Aaron to address a new deployment 
problem that left partially deployed artifacts in the repository.


I have taken this build and run some performance tests on it and we 
are significantly better in 1.1 than we were in 1.0.  We have a lot 
of improvement left for CMP EJBs.  It appears that the performance 
improvements in the EJB tier has changed a race condition when 
running under DB2.  I'm afraid that the only way to address the 
problem is to add a new feature to TranQL and OEJB that allow for the 
specification of Isolation Levels for individual beans.  This is a 
relatively simple change but the build as it stands is specification 
compliant.  I would prefer to let this release go forward since CMP 
2.1 EJBs are not nearly as common as the other J2EE components.  I 
would like to address this in 1.1.1 however I don't think we've 
locked down whether that would be allowed or not.  The change would 
affect TranQL and OpenEJB so they are really included components so 
I'd be interested in people's feedback.


So please accept a named RC1.  Your voting and feedback are for:

Geronimo 1.1
DayTrader 1.1
Specs 1.1

The vote will stand for 72 hours.  Issues raised will be discussed 
and if we conclude that there is a bug that must be addressed then we 
will mitigate the problem and respin a new rc for a 72 hour vote.


If this is accepted all three of the above components will be 
released simultaneously.


Here are the builds for your review and comment:

http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.tar.gz 


http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-j2ee-1.1-rc1.tar.gz 


http://people.apache.org/~hogstrom/rc1/geronimo-romcat-j2ee-1.1-rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.tar.gz 

http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.zip 

http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.tar.gz 

http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.zip 



http://people.apache.org/~hogstrom/rc1/daytrader-ear-1.1-rc1.zip


Looking forward to your comments and feedback.








Re: Thoughts about what a release is

2006-06-12 Thread Matt Hogstrom



David Blevins wrote:


On Jun 11, 2006, at 6:14 PM, Alan D. Cabrera wrote:


Aaron Mulder wrote:

I'd feel a lot better about tight restrictions on 1.1.1 if we really
made 1.2 a "minor release" and put all the stuff on the plate for 1.2
into 2.0.  But so long as 1.2 is a major release, then 1.1.1 needs
more than hot fixes.  On a related point, I'm not sure we want
multiple big version releases per year.


I agree with you here.  The nice thing about the policy that I 
outlined below is that we can safely time box patch releases.


As for what gets scheduled for what release, I think that it's not 
realistic to start by stacking a release w/ issues and hope that 
people will "show up" to get them done in the scheduled time frame; 
this only works if we are making shoes ;).  With that said, time 
boxing is what would work best with our unique body of developers.
Working within the strict interpretation of releases that I outlined 
below, people would schedule themselves in with concrete commitments.
Bugs would not get scheduled in until someone actually picked it up 
and started working on it.  At that time, the developer would mark 
what releases his changes would fix.


Features would not get scheduled in until someone actually commits to 
doing that feature.


I like this approach for most things.  There will always be the need to 
say "x needs to be fixed to ship this release" even if no one is signed 
up to work on it.  I just wish we'd vote or come to a consensus on items 
like these *before* they get assigned to a release.  IMHO, having to +1 
it to be added to the release means among many things you 1) saw it, 2) 
know about it, 3) are fully aware of what is outstanding and not yet 
being worked on, and 4) you agree with it.




Based on our past experience over the last two releases and a couple of Milestones we all feel the 
urgent need to get things fixed.  However, as I was clearing out 1.1 there were lots of assigned 
issues with relatively low overhead in applying and verifying them but the assignee was busy with 
other things.  This is fine.


IMHO JIRA's should not be assigned to a version number until there is someone that will be working 
on them.  That way we'll end up with things people are planning on completing for a release in the 
release.  We have had "important bugs" in JIRA (some older than two years).


In short, I think we should try it David.


I'm fine voting on blocks of related issues all at once to speed up the 
process.


I think having to agree before hand on what goes in and what's required 
for a release will force us to talk about things earlier in the release 
cycle rather than later.




Yes, it will also have people think about what's important for the release.

One are we need to bone up on is making sure that we look at JIRAs when they come in.  There are a 
number I moved to 1.1.1 and plan on integrating where people did the work and created a patch.  It 
will help us grow the community a lot if they see we are attentive to their contributions and that 
the contributions actually get in.  If the patch won't work, then we need to give them feedback on 
what will work.  I think this is an ethic change for us.




-David






Key Generator Questions

2006-06-12 Thread Neal Sanche

Hi All,

Yesterday I had some fun with the sequence-table key generator. I had 
this fragment at the end of my Entity deployment plan.


 
   
 sequence
 reminder
 1
   
 

I know, I should increase my batch-size, but really I am only doing one 
at a time. But that's not my problem. Why doesn't the key-generator 
create the table if it doesn't already exist? It took me quite some time 
to figure out that it was looking for a table with two columns, one 
called 'name' and one called 'value'. Yeah, I know, it's pretty easy to 
guess it, but I couldn't find it documented. I'm sure I didn't look 
everywhere, and could have looked in the source code to find the columns.


Once I created my table, the application started throwing exceptions 
like crazy! It turned out the misleading 'Transaction already rolled 
back' errors were because the record in the table didn't exist. I'm sure 
it would be super easy to create the record if it wasn't already there, 
and start the numbering at 1. I'm just so surprised it doesn't already 
have this ability. I'm sure I'm missing something, right?


So, as far as I know, in order to get the key generator to work, I have 
to create the sequence table:


create table sequence (name varchar(240) not null primary key, value 
integer);


And then add the sequence key:

insert into sequence values ('reminder',1);

And then it'll go. Before that it just complains loudly and rolls back 
my transaction.


What am I missing?

Cheers.

-Neal




[jira] Updated: (GERONIMO-2103) Console config declares dependency on Jetty/Tomcat JAR instead of Jetty/Tomcat CAR

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2103?page=all ]

Matt Hogstrom updated GERONIMO-2103:


Fix Version: 1.2
 (was: 1.1)

> Console config declares dependency on Jetty/Tomcat JAR instead of 
> Jetty/Tomcat CAR
> --
>
>  Key: GERONIMO-2103
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2103
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: buildsystem, console
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
>  Fix For: 1.2

>


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



[jira] Commented: (GERONIMO-2103) Console config declares dependency on Jetty/Tomcat JAR instead of Jetty/Tomcat CAR

2006-06-12 Thread Matt Hogstrom (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-2103?page=comments#action_12415948
 ] 

Matt Hogstrom commented on GERONIMO-2103:
-

Aaron, does this need to be applied to trunk?  I'm moving to 1.2 to track the 
remaining actions.

Thanks

> Console config declares dependency on Jetty/Tomcat JAR instead of 
> Jetty/Tomcat CAR
> --
>
>  Key: GERONIMO-2103
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2103
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: buildsystem, console
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
>  Fix For: 1.2

>


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



[jira] Updated: (GERONIMO-2106) Document the modules included in each assembly on our Wiki

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2106?page=all ]

Matt Hogstrom updated GERONIMO-2106:


Fix Version: 1.2
 (was: 1.1)

> Document the modules included in each assembly on our Wiki
> --
>
>  Key: GERONIMO-2106
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2106
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: documentation
> Versions: 1.1
> Reporter: Donald Woods
> Assignee: Donald Woods
> Priority: Trivial
>  Fix For: 1.2
>  Attachments: Geronimo1.1-Config-20060512.ppt
>
> Info needed inorder to enable upgrades from minimal-server to j2ee-server -
> If you get a chance, could you look at project.xml for the J2EE
> assemblies vs. the minimal assemblies and make a list of all the
> Geronimo modules in the two?  Such as:
> module  J2EE  minimal
> system  yes  yes
> unavailable-webservices-deployer  no  yes
> ...
> We can use a list like that to create the plugin metadata to upgrade
> minimal to full J2EE.
> Thanks,
>Aaron 

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



[jira] Updated: (GERONIMO-2083) Use howl-logger-1.0.1-1.jar

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2083?page=all ]

Matt Hogstrom updated GERONIMO-2083:


Fix Version: 1.2
 (was: 1.1)

> Use howl-logger-1.0.1-1.jar
> ---
>
>  Key: GERONIMO-2083
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2083
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: dependencies
> Versions: 1.1
> Reporter: David Jencks
> Assignee: David Jencks
>  Fix For: 1.2

>
> I figures out the m2 howl build and created an upload request 
> http://jira.codehaus.org/browse/MAVENUPLOAD-930.
> When this completes we can change the howl dependency to
> org.objectweb.howl
> howl-logger
> 1.0.1-1
> Hopefully this will occur before 1.1 :-)

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



[jira] Closed: (GERONIMO-2081) Concurrency problems in Daytrader or AMQ

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2081?page=all ]
 
Matt Hogstrom closed GERONIMO-2081:
---

Resolution: Fixed

> Concurrency problems in Daytrader or AMQ
> 
>
>  Key: GERONIMO-2081
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2081
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: sample apps
> Versions: 1.1
> Reporter: David Jencks
> Assignee: Hiram Chirino
>  Fix For: 1.1

>
> Brian Noll found a bunch of ConcurrentModificationException problems when 
> running daytrader PingServlet2MDBQueue under mutltithread load.  These are 
> due either to PingServlet2MDBQueue sharing a connection between all 50+ 
> threads or activemq not allowing such connection sharing.  I'm going to 
> remove the connection sharing in daytrader and ask Hiram to figure out if AMQ 
> needs more synchronization.
> Here's the stack trace Brian got, showing at least 2 concurrency problems:
> 18:35:41,171 ERROR [Log] Error: PingServlet2MDBQueue.doGet(...):exception 
> posting message to TradeBrokerQueue destination
> 18:35:41,172 ERROR [Log] Error: PingServlet2MDBQueue.doGet(...): error
>  
> java.util.ConcurrentModificationException
> java.util.ConcurrentModificationException
> at 
> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448)
> at java.util.AbstractList$Itr.next(AbstractList.java:419)
> at java.util.AbstractCollection.remove(AbstractCollection.java:254)
> at 
> org.activemq.TransactionContext.removeSession(TransactionContext.java:116)
> at 
> org.activemq.ra.RATransactionContext.removeSession(RATransactionContext.java:57)
> at org.activemq.ActiveMQSession.doClose(ActiveMQSession.java:466)
> at org.activemq.ActiveMQSession.close(ActiveMQSession.java:447)
> at org.activemq.ra.JMSSessionProxy.cleanup(JMSSessionProxy.java:87)
> at org.activemq.ra.JMSSessionProxy.close(JMSSessionProxy.java:76)
> at 
> org.apache.geronimo.samples.daytrader.web.prims.PingServlet2MDBQueue.doGet(PingServlet2MDBQueue.java:127)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> at 
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
> at 
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> at 
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
> at 
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:534)
> java.util.ConcurrentModificationException
> at 
> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448)
> at java.util.AbstractList$Itr.next(AbstractList.java:419)
> at java.util.AbstractCollection.remove(AbstractCollection.java:254)
> at 
> org.activemq.TransactionContext.removeSession(TransactionContext.java:116)
> at 
> org.activemq.ra.RATransactionContext.removeSession(RATransactionContext.java:57)
> at org.activemq.ActiveMQSession.doClose(ActiveMQSession.java:466)
> at org.activemq.ActiveMQSession.close(ActiveMQSession.java:447)
> at org.activemq.ra.JMSSessionProxy.cleanup(JMSSessionProxy.java:87)
> at org.activemq.ra.JMSSessionProxy.close(JMSSessionProxy.java:76)
> at 
> org.apache.geronimo.samples.daytrader.web.prims.PingServlet2MDBQueue.doGet(PingServlet2MDBQueue.java:127)
> at javax

[jira] Updated: (GERONIMO-2073) Copyright date in the console needs to be updated

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2073?page=all ]

Matt Hogstrom updated GERONIMO-2073:


Fix Version: 1.1.1
 (was: 1.1)

> Copyright date in the console needs to be updated
> -
>
>  Key: GERONIMO-2073
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2073
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.1
> Reporter: Hernan Cunico
>  Fix For: 1.1.1

>
> The welcome page, once you logged in the Geronimo Administration Console 
> shows:
> "Copyright © 1999-2005 Apache Software Foundation All Rights Reserved"
> it needs to be updated to 2006
> "Copyright © 1999-2006 Apache Software Foundation All Rights Reserved"

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



[jira] Updated: (GERONIMO-2072) Client-Deployer config is using wrong/hardcoded commons-primitives version

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2072?page=all ]

Matt Hogstrom updated GERONIMO-2072:


Fix Version: 1.1.1
 (was: 1.1)

> Client-Deployer config is using wrong/hardcoded commons-primitives version
> --
>
>  Key: GERONIMO-2072
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2072
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: dependencies
> Versions: 1.2, 1.1, 1.1.1
> Reporter: Donald Woods
>  Fix For: 1.1.1
>  Attachments: Geronimo-2072.patch
>
> Client-Deployer config is using a hardcoded commons-primitives version of 1.0 
> instead of using the project.properties value of 20041207.202534.

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



Re: Eclipse Plugin V1.1.0 unstable driver now available

2006-06-12 Thread Neal Sanche
You mention, here, that there is a driver available that we can test 
with, is that the one released on June 6th? I am still finding it 
impossible to get that version to start up an deploy to a Geronimo 1.1 
server. It does nearly everything else wonderfully. I've been forced to 
Export .EAR files to the Geronimo 1.1 /deploy directory to test my 
application. Is there anything we can do to get something that at least 
deploys before you get the EMF team to fix a bug in 1.5? I'm perfectly 
happy using 1.0.2 WTP since I tried 1.5 WTP and found that the CMP EJB 
creation is not finished yet. So, since it's the only reason I'd 
consider moving on, I don't see why the Geronimo Eclipse plugin should 
need to yet either.


I haven't seen any movement in the Devtools SVN repository either, so if 
there's a 1.0.2 working version, I don't see it. Am I looking in the 
wrong place?


Thanks Sachin!

Cheers.

-Neal

Sachin Patel wrote:
They are going fine. The driver that is available should be a good 
driver to start testing on.  I've been working on moving up to WTP 
1.5, EMF 2.2, etc... and have run across a build breaking EMF bug I'm 
awaiting a fix for.  Hopefully we'll get the fix before EMF 2.2 is 
released.


On Jun 12, 2006, at 6:43 PM, Jay D. McHugh wrote:


How are the Eclipse plugin changes going?

Jay

Sachin Patel wrote:
Hold off on the V11 testing, as I'm finding issues you may run into. 
I'm working on resolving the issues this morning and will let u know 
when I'm done.


On Jun 7, 2006, at 12:02 AM, Neal Sanche wrote:


Okay Sachin,

I have found what I believe to be the main problem. I looked in my 
Eclipse configuration settings, and found that the Geronimo plugin 
had a little red X on it indicating it was unhappy. So I looked 
into why that could be ant found a small complaint it was making:


Plug-in "org.apache.geronimo.st.v11.ui" version "1.0.0" referenced 
by this feature is missing.


I looked all over and sure enough I do not have a copy of this 
Jarfile anywhere in my Eclipse directory. Where would I find such a 
thing? I'm not brave enough to try this build myself at the moment 
otherwise I would try and make my own version of this. I will see 
if maybe one of the distributions you posted has it.


-Neal

Sachin Patel wrote:
I just posted a new driver. Could you verify that the problem is 
fixed?


You should be able to just extract over your existing image. Be 
sure to re-invoke eclipse with "-clean".


Thanks.

On Jun 6, 2006, at 9:53 PM, Neal Sanche wrote:


Fair enough,

I have put in a JIRA, let me know (though the JIRA) what else you 
need from me. I am trying out the other features and will see if 
I get stuck. I can't start the server from inside Eclipse, but 
maybe I can still develop a small application.


-Neal

Sachin Patel wrote:
I'd have to dig into it, I'm not quite sure looking at just the 
stack trace.


On Jun 6, 2006, at 9:32 PM, Neal Sanche wrote:

I will put in a JIRA, for sure. Can you tell me what might be 
going on?


-Neal

Sachin Patel wrote:

Ah shoot, can you open a jira? I can investigate.

On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:


Sachin Patel wrote:
The following driver can run on both JDK 1.4 or 1.5. It 
should be run with WTP 1.0x and will eventually but not 
currently run on WTP 1.5.


http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-SNAPSHOT-deployable.zip 



-sachin


Hi Sachin,

I am currently trying to get Eclipse 1.0.2 All In One bundle 
to run your new eclipse plugin with the following result. I 
have installed the plugin, and set up a Geronimo 1.1 server 
that I compiled myself about a week ago. I am going to try a 
recompile in the meantime, but what do you think the 
following means?


Thanks.

-Neal


!ENTRY org.eclipse.osgi 2006-06-05 21:44:07.125
!MESSAGE An error occurred while automatically activating 
bundle org.apache.geronimo.st.jmxagent (14).

!STACK 0
org.osgi.framework.BundleException: The activator 
org.apache.geronimo.st.jmxagent.Activator for bundle 
org.apache.geronimo.st.jmxagent is invalid
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:149) 

at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:965) 

at 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:316) 

at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:264) 

at 
org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:116) 

at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:337) 

at 
org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) 

at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:386) 

at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350) 

at 
org.eclipse.osgi.framework.adaptor.

[jira] Updated: (AMQ-702) `bstat --help` should display something useful

2006-06-12 Thread Adrian Co (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-702?page=all ]

Adrian Co updated AMQ-702:
--

Attachment: AMQ702.patch

Patch for trunk version attached.

> `bstat --help` should display something useful
> --
>
>  Key: AMQ-702
>  URL: https://issues.apache.org/activemq/browse/AMQ-702
>  Project: ActiveMQ
> Type: Improvement

> Versions: 4.0 RC3
> Reporter: Jason Dillon
> Assignee: Adrian Co
>  Fix For: 4.1, 4.0.1
>  Attachments: AMQ702.patch
>
>
> `bstat --help` should display something useful.  Right now using a 
> non-standard connectorPort for the managementContext I get this:
> {noformat}
> [EMAIL PROTECTED]:...bator-activemq-4.0-RC3/bin>./bstat --help
> ACTIVEMQ_HOME: 
> /Users/jason/ws/paybytouch/ea/activemq/node1/incubator-activemq-4.0-RC3
> ERROR: java.lang.RuntimeException: Failed to execute query task. Reason: 
> java.io.IOException: Failed to retrieve RMIServer stub: 
> javax.naming.ServiceUnavailableException [Root exception is 
> java.rmi.ConnectException: Connection refused to host: localhost; nested 
> exception is: 
> java.net.ConnectException: Connection refused]
> ERROR: java.lang.Exception: java.io.IOException: Failed to retrieve RMIServer 
> stub: javax.naming.ServiceUnavailableException [Root exception is 
> java.rmi.ConnectException: Connection refused to host: localhost; nested 
> exception is: 
> java.net.ConnectException: Connection refused]
> {noformat}
> `bstat localhost --help` works, showing that this is really calling `query`.  
> Anyways, not very helpful when the JMX URL is changed from the default.

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



[jira] Updated: (GERONIMO-2063) Stopping a TSSbean also stops the orb it's attached to

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2063?page=all ]

Matt Hogstrom updated GERONIMO-2063:


Fix Version: 1.1.1
 (was: 1.1)

> Stopping a TSSbean also stops the orb it's attached to
> --
>
>  Key: GERONIMO-2063
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2063
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: CORBA
> Versions: 1.1
> Reporter: David Jencks
>  Fix For: 1.1.1

>
> While working with the MagicGBall I noticed that you can't stop and start the 
> application: when you try to start it again you get an exception saying the 
> orb is shut down.
> I deployed the app using the console, the magicGBall ear, and either one of 
> the plans in magicgball/target/plan.  I stopped and tried to start the app 
> after deployment using the console.
> I won't argue much if this gets taken out of 1.1.

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



[jira] Updated: (GERONIMO-2040) MagicGBall application not working in AG 1.1

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2040?page=all ]

Matt Hogstrom updated GERONIMO-2040:


Fix Version: 1.2
 (was: 1.1)

> MagicGBall application not working in AG 1.1
> 
>
>  Key: GERONIMO-2040
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2040
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: CORBA
> Versions: 1.1
>  Environment: Windows
> Reporter: Ted Kirby
> Assignee: David Jencks
> Priority: Critical
>  Fix For: 1.2

>
> See this thread in user mailing list: 
> http://mail-archives.apache.org/mod_mbox/geronimo-user/200605.mbox/[EMAIL 
> PROTECTED]

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



[jira] Resolved: (AMQ-702) `bstat --help` should display something useful

2006-06-12 Thread Adrian Co (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-702?page=all ]
 
Adrian Co resolved AMQ-702:
---

Resolution: Fixed

Done. Added fix to 4.0.1 and trunk. Sorry, it took a awhile. ;)

> `bstat --help` should display something useful
> --
>
>  Key: AMQ-702
>  URL: https://issues.apache.org/activemq/browse/AMQ-702
>  Project: ActiveMQ
> Type: Improvement

> Versions: 4.0 RC3
> Reporter: Jason Dillon
> Assignee: Adrian Co
>  Fix For: 4.1, 4.0.1

>
>
> `bstat --help` should display something useful.  Right now using a 
> non-standard connectorPort for the managementContext I get this:
> {noformat}
> [EMAIL PROTECTED]:...bator-activemq-4.0-RC3/bin>./bstat --help
> ACTIVEMQ_HOME: 
> /Users/jason/ws/paybytouch/ea/activemq/node1/incubator-activemq-4.0-RC3
> ERROR: java.lang.RuntimeException: Failed to execute query task. Reason: 
> java.io.IOException: Failed to retrieve RMIServer stub: 
> javax.naming.ServiceUnavailableException [Root exception is 
> java.rmi.ConnectException: Connection refused to host: localhost; nested 
> exception is: 
> java.net.ConnectException: Connection refused]
> ERROR: java.lang.Exception: java.io.IOException: Failed to retrieve RMIServer 
> stub: javax.naming.ServiceUnavailableException [Root exception is 
> java.rmi.ConnectException: Connection refused to host: localhost; nested 
> exception is: 
> java.net.ConnectException: Connection refused]
> {noformat}
> `bstat localhost --help` works, showing that this is really calling `query`.  
> Anyways, not very helpful when the JMX URL is changed from the default.

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



[jira] Closed: (GERONIMO-2031) cvs.apache.org/repository has been moved (temporarily?) to people.apache.org/repository

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2031?page=all ]
 
Matt Hogstrom closed GERONIMO-2031:
---

Resolution: Fixed

> cvs.apache.org/repository has been moved (temporarily?) to 
> people.apache.org/repository
> ---
>
>  Key: GERONIMO-2031
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2031
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: buildsystem
> Versions: 1.1
> Reporter: Kevan Miller
> Assignee: Kevan Miller
>  Fix For: 1.1

>
> ASF infrastructure has moved cvs.apache.org/repository to 
> people.apache.org/repository. The redirect is not handled by maven (at least 
> not without throwing exceptions during the build). 

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



[jira] Updated: (GERONIMO-2028) Plugin export errors don't stop process, but cause it to fail much later

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2028?page=all ]

Matt Hogstrom updated GERONIMO-2028:


Fix Version: 1.2
 (was: 1.1)

> Plugin export errors don't stop process, but cause it to fail much later
> 
>
>  Key: GERONIMO-2028
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2028
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: Plugins
> Versions: 1.1
> Reporter: Aaron Mulder
>  Fix For: 1.2

>
> When exporting a plugin, if there are any errors loading the existing XML 
> document, the console goes on to the export screen and just renders it 
> entirely empty (including the module ID).  It should instead produce an error 
> message.
> To reproduce, edit 
> repository/geronimo/welcome-jetty/1.1-SNAPSHOT/welcome-jetty-1.1-SNAPSHOT.car/META-INF/geronimo-plugin.xml
>  to make it invalid, go to the console, select the plugins screen, pick 
> geronimo/welcome-jetty/* as the configuration to export, and click the export 
> button.  You presently get a screen with a bunch of blank text fields, and 
> should instead get an error message / page.

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



[jira] Updated: (GERONIMO-2007) Avoid Classloader warnings generated by BasicProxyManager

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2007?page=all ]

Matt Hogstrom updated GERONIMO-2007:


Fix Version: 1.1.1
 (was: 1.1)

> Avoid Classloader warnings generated by BasicProxyManager
> -
>
>  Key: GERONIMO-2007
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2007
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.1
> Reporter: Paul McMahan
> Assignee: Matt Hogstrom
>  Fix For: 1.1.1
>  Attachments: GERONIMO-2007.patch
>
> Several views in the console create proxies for objects that implement 
> interfaces not available in the console's classloader.   The warning messages 
> look like:
> 08:56:26,315 WARN [BasicProxyManager] Could not load interface 
> org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for 
> geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer
> This warning message can be avoided by getting the classloader for the 
> proxied object from the kernel and then using it to create the proxy.

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



[jira] Updated: (GERONIMO-1996) Serialization failure during deployment leaves a config.ser in the repository but doesn't write a config.info causing problems later.

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1996?page=all ]

Matt Hogstrom updated GERONIMO-1996:


Fix Version: 1.1.1
 (was: 1.1)

> Serialization failure during deployment leaves a config.ser in the repository 
> but doesn't write a config.info causing problems later.
> -
>
>  Key: GERONIMO-1996
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1996
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.1
> Reporter: John Sisson
> Assignee: John Sisson
>  Fix For: 1.1.1
>  Attachments: jira-g-1996.zip
>
> If an exception occurs during the serialization phase of deployment, the 
> failure causes an (incomplete?) config.ser in the repository but doesn't 
> write a config.info file.
> If Geronimo is restarted the configuration will attempt to be started and you 
> will get a FileNotFoundException for the config.info file (exception shown 
> below).
> If you attempt to undeploy the configuration you also get a 
> FileNotFoundException (also shown below).
> =
> Example of exception during serialization phase of deployment:
> java.lang.ClassCastException
> at org.apache.xerces.parsers.DOMParser.(Unknown Source)
> at org.apache.xerces.parsers.DOMParser.(Unknown Source)
> at com.foo.common.xml.XMLNode.loadXML(XMLNode.java:534)
> at com.foo.common.xml.XMLNode.loadXML(XMLNode.java:520)
> 
> at com.foo.server.ejb.Bar.(FooBean.java:104)
> at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
> at 
> java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1557)
> at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:47)
> at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:173)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> java.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:170)
> at java.io.ObjectStreamClass.writeNonProxy(ObjectStreamClass.java:557)
> at 
> java.io.ObjectOutputStream.writeClassDescriptor(ObjectOutputStream.java:591)
> at 
> java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1142)
> at 
> java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1100)
> at java.io.ObjectOutputStream.writeClass(ObjectOutputStream.java:1082)
> at 
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:996)
> at 
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
> at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
> at 
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
> at 
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
> at 
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
> at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
> at 
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
> at 
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
> at 
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
> at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
> at 
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
> at 
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
> at 
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
> at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
> at 
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
> at 
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
> at 
> org.apache.geronimo.gbean.GBeanData.writeExternal(GBeanData.java:186)
> at 
> org.apache.geronimo.kernel.config.SerializedGBeanState.storeGBeans(SerializedGBeanState.java:139)
> at 
> org.apache.geronimo.kernel.config.SerializedGBeanState.writeObject(SerializedGBeanState.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at 
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809)
> at 
> j

[jira] Updated: (GERONIMO-1995) The installer should allow the default settings to be restored

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1995?page=all ]

Matt Hogstrom updated GERONIMO-1995:


Fix Version: Wish List
 (was: 1.1)

> The installer should allow the default settings to be restored
> --
>
>  Key: GERONIMO-1995
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1995
>  Project: Geronimo
> Type: Wish
> Security: public(Regular issues) 
>   Components: installer
> Versions: 1.1
>  Environment: All
> Reporter: Anita Kulshreshtha
> Priority: Trivial
>  Fix For: Wish List

>
> The panel that allows the selection of components should have a 'restore 
> defaults' button. New users might want to 
> check/uncheck boxes to see the dependencies. It would be nice if they could 
> go back to the default state.

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



[jira] Updated: (GERONIMO-1984) New Keystore portlet - Add Trust Certificate throws exception

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1984?page=all ]

Matt Hogstrom updated GERONIMO-1984:


Fix Version: 1.1.1
 (was: 1.1)

> New Keystore portlet - Add Trust Certificate throws exception
> -
>
>  Key: GERONIMO-1984
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1984
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.1
>  Environment: Win XP, Sun JDK 1.4.2_08
> Reporter: Vamsavardhana Reddy
>  Fix For: 1.1.1
>  Attachments: myownrootca-cert.txt
>
> "Add Trust Certificate" function in the new KeyStore portlet is throwing 
> exception upon selecting the certificate file and clicking "Review 
> Certificate" button.  Log entry is given below.
> 14:48:45,617 ERROR [MultiPagePortlet] Unable to render portlet
> java.io.FileNotFoundException: C: (Access is denied)
>   at java.io.FileInputStream.open(Native Method)
>   at java.io.FileInputStream.(Unknown Source)
>   at java.io.FileInputStream.(Unknown Source)
>   at 
> org.apache.geronimo.console.keystores.ConfirmCertificateHandler.renderView(ConfirmCertificateHandler.java:61)
>   at 
> org.apache.geronimo.console.MultiPagePortlet.doView(MultiPagePortlet.java:146)
>   at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250)
>   at javax.portlet.GenericPortlet.render(GenericPortlet.java:178)
>   at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218)
>   at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>   at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>   at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
>   at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
>   at 
> org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119)
>   at 
> org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70)
>   at 
> org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168)
>   at 
> org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:60)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>   at 
> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
>   at 
> org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:57)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>   at 
> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
>   at 
> org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:61)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>  

[jira] Updated: (GERONIMO-1980) Move Plugin Installer from rmi-naming to j2ee-system

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1980?page=all ]

Matt Hogstrom updated GERONIMO-1980:


Fix Version: 1.2
 (was: 1.1)

> Move Plugin Installer from rmi-naming to j2ee-system
> 
>
>  Key: GERONIMO-1980
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1980
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: buildsystem, Plugins
> Versions: 1.1
> Reporter: Aaron Mulder
>  Fix For: 1.2

>
> Ideally, the plugin installer will be as high in the food chain as possible, 
> so it can replace as much as possible without shutting itself down.  
> Currently it is in rmi-naming.
> I tried moving it to j2ee-system, which requires the following new 
> dependencies for j2ee-system:
>  - geronimo-core
>  - geronimo-management
>  - geronimo-util
>  - geronimo-j2ee-management_1.0_spec
>  - concurrent
> Somehow, the net result of this was that the OpenEJB config could not load 
> javax.ejb.EJBObject, so there's something funky going on with the class 
> loaders when the above changes are made.

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



[jira] Updated: (GERONIMO-1967) /remote-deploy url link throws Error 404.

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1967?page=all ]

Matt Hogstrom updated GERONIMO-1967:


Fix Version: 1.1.1
 (was: 1.1)

> /remote-deploy url link throws Error 404.
> -
>
>  Key: GERONIMO-1967
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1967
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: usability
> Versions: 1.1
> Reporter: Prasad Kashyap
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1.1
>  Attachments: logo_head_570x86.gif, remote-deploy.patch
>
> The following page on the console 
> (http://localhost:8080/console/portal/apps/apps_war) lists all the WARs with 
> their URL links. Accessing the /remote-deploy link throws an Error 404. 
> Though this app is used by the CLI tool to deploy apps remotely, we should 
> handle this gracefully instead of showing it as an error.
> Please review and apply the patch.

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



[jira] Updated: (GERONIMO-1959) Console: plugin % complete shoudl reset to 0 while preparing a download

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1959?page=all ]

Matt Hogstrom updated GERONIMO-1959:


Fix Version: 1.1.1
 (was: 1.1)

> Console: plugin % complete shoudl reset to 0 while preparing a download
> ---
>
>  Key: GERONIMO-1959
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1959
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Minor
>  Fix For: 1.1.1

>
> The console progress bar should go back to 0 if the percent complete is set 
> to -1 (which should handle resetting it to 0 during the "preparing to 
> download" phase, whereas now it stays at whatever value it had for the last 
> status message)

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



[jira] Updated: (GERONIMO-1945) Console's web application list does not show WARs that are deployed inside EARs

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1945?page=all ]

Matt Hogstrom updated GERONIMO-1945:


Fix Version: 1.2
 (was: 1.1)

> Console's web application list does not show WARs that are deployed inside 
> EARs
> ---
>
>  Key: GERONIMO-1945
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1945
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.0
> Reporter: Erin Mulder
> Assignee: Erin Mulder
>  Fix For: 1.2

>
> In the console, click on "Applications -> Web App WARs".   The resulting list 
> of web applications does not include any web application that is packaged as 
> part of an EAR.
> (The list is populated inside ConfigManagerPortlet.doView)

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



[jira] Updated: (GERONIMO-1942) InPlace deployment does not work with EjbModules

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1942?page=all ]

Matt Hogstrom updated GERONIMO-1942:


Fix Version: 1.1.1
 (was: 1.1)

> InPlace deployment does not work with EjbModules
> 
>
>  Key: GERONIMO-1942
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1942
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.1
> Reporter: Sachin Patel
> Priority: Critical
>  Fix For: 1.1.1

>
> In place deployment fails with EJBModules.  When pointing to the exploded 
> ejbjar using the --inPlace option the classes to not resolve...
>  Error: Unable to distribute temp: Remote interface class not found:
> org.apache.test.My

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



[jira] Closed: (GERONIMO-1938) Plugins portlet 'help' link throws PortletException

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1938?page=all ]
 
Matt Hogstrom closed GERONIMO-1938:
---

Resolution: Fixed

> Plugins portlet 'help' link throws PortletException
> ---
>
>  Key: GERONIMO-1938
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1938
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.1
> Reporter: Chris Cardona
> Assignee: Aaron Mulder
>  Fix For: 1.1
>  Attachments: 1938-plugin-portlet-fixes.patch
>
> Not sure if this 'help' link should be removed since the 'view' link already 
> gives a description of the portlet including how to use it.

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



[jira] Updated: (GERONIMO-1930) Make security real types into GBeans so they can be added in new/updated configurations

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1930?page=all ]

Matt Hogstrom updated GERONIMO-1930:


Fix Version: Wish List
 (was: 1.1)

> Make security real types into GBeans so they can be added in new/updated 
> configurations
> ---
>
>  Key: GERONIMO-1930
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1930
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: security, console
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
>  Fix For: Wish List

>


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



[jira] Updated: (GERONIMO-1926) Changes to navigation break remote clients

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1926?page=all ]

Matt Hogstrom updated GERONIMO-1926:


Fix Version: 1.2
 (was: 1.1)

> Changes to navigation break remote clients
> --
>
>  Key: GERONIMO-1926
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1926
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: core
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.2
>  Attachments: peek-remote.jar, peek.jar
>
> From an e-mail:
> I have created a simple program that calls J2EEDomain.getServerInstances() on 
> J2EEDomain obtained from remote kernel.  Detatch the two jars to bin 
> directory and run the program using the cmd "java -jar peek.jar".  Here is 
> the code in the main() method.
> public static void main(String[] args) throws Exception {
> String host = "localhost";
> String username = "system";
> String password = "manager";
> for(int i = 0; i < args.length-1; ++i) {
> if("--username".equalsIgnoreCase(args[i])) username = args[i+1];
> if("--host".equalsIgnoreCase(args[i])) host = args[i+1];
> if("--password".equalsIgnoreCase(args[i])) password = args[i+1];
> }
> System.out.println("Using host="+host+", username="+username+", 
> password="+password);
> KernelManagementHelper mgr = 
> KernelManagementHelper.getRemoteKernelManager(host, username, password);
> System.out.println("KernelManagementHelper = "+mgr);
> J2EEDomain domain = mgr.getDomains()[0];
> System.out.println("J2EEDomain = "+domain);
> J2EEServer[] j2eeServers = domain.getServerInstances();
> System.out.println("J2EEServer = "+j2eeServers[0]);
> }

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



[jira] Commented: (GERONIMO-1924) Need to register the tomcat jndi url handler somehow

2006-06-12 Thread Matt Hogstrom (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-1924?page=comments#action_12415946
 ] 

Matt Hogstrom commented on GERONIMO-1924:
-

Ping Jeff

> Need to register the tomcat jndi url handler somehow
> 
>
>  Key: GERONIMO-1924
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1924
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: Tomcat
> Versions: 1.1
> Reporter: David Jencks
> Assignee: Jeff Genender
> Priority: Blocker
>  Fix For: 1.1

>
> Until recently we were using the Tomcat WebappLoader which has this code:
> // Register a stream handler factory for the JNDI protocol
> URLStreamHandlerFactory streamHandlerFactory =
> new DirContextURLStreamHandlerFactory();
> if (first) {
> first = false;
> try {
> URL.setURLStreamHandlerFactory(streamHandlerFactory);
> } catch (Exception e) {
> // Log and continue anyway, this is not critical
> log.error("Error registering jndi stream handler", e);
> } catch (Throwable t) {
> // This is likely a dual registration
> log.info("Dual registration of jndi stream handler: " 
>  + t.getMessage());
> }
> }
> This is how tomcat finds anything in the web app when you call 
> servletContext.getResource(location_in_WEB_INF).
> Since we recently stopped using the tomcat classloader, we need  to do this 
> ourselves somewhere.

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



[jira] Updated: (GERONIMO-1922) Plugin Export should check for shared libs

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1922?page=all ]

Matt Hogstrom updated GERONIMO-1922:


Fix Version: 1.2
 (was: 1.1)
Version: 1.1.1

> Plugin Export should check for shared libs
> --
>
>  Key: GERONIMO-1922
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1922
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.1, 1.1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.2

>
> The export process should check configation.findGBeans(new 
> AbstractNameQuery(SharedLib.class.getName())

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



[jira] Updated: (GERONIMO-1921) Console should display context root for the installed web apps

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1921?page=all ]

Matt Hogstrom updated GERONIMO-1921:


Fix Version: 1.1.1
 (was: 1.1)

> Console should display context root for the installed web apps
> --
>
>  Key: GERONIMO-1921
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1921
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.1
>  Environment: all
> Reporter: Anita Kulshreshtha
> Priority: Minor
>  Fix For: 1.1.1

>
> Console should display context root for the web apps in these two places - 
> 1. Web App Wars --> Installed Web Apps
> 2. plugins --> .--> Import/Export configuraitons  - if has web apps
>  Currently user has no way of determining context root for the sample 
> apps supplied with geronimo.

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



[jira] Closed: (GERONIMO-1919) AG 1.1-SNAPSHOT has a memory leak when running DayTrader in Direct Mode

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1919?page=all ]
 
Matt Hogstrom closed GERONIMO-1919:
---

Resolution: Fixed

Fixed with the introduction of the Stmt Cache in TranQL Connector 1.2

> AG 1.1-SNAPSHOT has a memory leak when running DayTrader in Direct Mode
> ---
>
>  Key: GERONIMO-1919
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1919
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>  Environment: Linux SuSE 64-bit with Sun VM 1.4.2_09 (32-bit VM)
> TranQL Vendors DB2 Embed XA RAR 1.0-SNAPSHOT
> Reporter: Matt Hogstrom
> Assignee: Matt Hogstrom
>  Fix For: 1.1

>
> I am testing DayTrader 1.1-SNAPSHOT and discovered a memory leak when putting 
> the server under load.  I am investigating.  Currently it take about 10 
> minutes to blow out a 128MB heap.

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



[jira] Updated: (GERONIMO-1915) Geronimo server built by installer will not start

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1915?page=all ]

Matt Hogstrom updated GERONIMO-1915:


Fix Version: Wish List
 (was: 1.2)
 (was: 1.1)

> Geronimo server built by installer will not start
> -
>
>  Key: GERONIMO-1915
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1915
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: installer
>  Environment: Windows XP
> Reporter: Rick McGuire
> Priority: Minor
>  Fix For: Wish List
>  Attachments: G-installer.xml
>
> Created a Geronimo server using the installer (see attached installer script 
> for installation options used).  When attempting to start the server, the 
> server died with the following exception:
> C:\Geronimo\servers\1.1\bin>geronimo run
> Using GERONIMO_BASE:   C:\Geronimo\servers\1.1
> Using GERONIMO_HOME:   C:\Geronimo\servers\1.1
> Using GERONIMO_TMPDIR: C:\Geronimo\servers\1.1\var\temp
> Using JRE_HOME:c:\j2sdk1.4.2_08
> Booting Geronimo Kernel (in Java 1.4.2_08)...
> Starting Geronimo Application Server
> [***-] 13%   3s  Loading 
> geronimo/j2ee-security...13:45:46,9
> 44 ERROR [GBeanInstanceState] Error while starting; GBean is now in the 
> FAILED s
> tate: 
> abstractName="geronimo/j2ee-security/1.1-SNAPSHOT/car?configurationName=ge
> ronimo/j2ee-security/1.1-SNAPSHOT/car"
> org.apache.geronimo.kernel.config.InvalidConfigException: No attribute: url 
> for
> gbean: 
> geronimo/j2ee-security/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-secur
> ity/1.1-SNAPSHOT/car,j2eeType=GBean,name=JMXService
> at 
> org.apache.geronimo.system.configuration.LocalAttributeManager.setAtt
> ributes(LocalAttributeManager.java:178)
> at 
> org.apache.geronimo.system.configuration.LocalAttributeManager.applyO
> verrides(LocalAttributeManager.java:135)
> at 
> org.apache.geronimo.system.configuration.LocalAttributeManager$$FastC
> lassByCGLIB$$b20ef545.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod
> Invoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
> n.java:122)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
> java:816)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5
> 7)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat
> ionInvoker.java:35)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro
> xyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.kernel.config.PersistentConfigurationList$$Enhanc
> erByCGLIB$$424cb200.applyOverrides()
> at 
> org.apache.geronimo.kernel.config.Configuration.(Configuration.
> java:279)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
> orAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
> onstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
> nstance.java:932)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
> (GBeanInstanceState.java:267)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta
> nceState.java:102)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j
> ava:525)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.j
> ava:361)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.load(Ker
> nelConfigurationManager.java:143)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConf
> iguration(SimpleConfigurationManager.java:277)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConf
> iguration(SimpleConfigurationManager.java:245)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConf
> iguration(SimpleConfigurationManager.java:220)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConf
> iguration(KernelConfigurationManager.java:111)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastCla
> ssByCGLIB$$b117102f.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod
> Invoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
> n.java:12

[jira] Updated: (GERONIMO-1917) repository doesn't deal well with case insensitive file systems

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1917?page=all ]

Matt Hogstrom updated GERONIMO-1917:


Fix Version: 1.1.1
 (was: 1.1)

> repository doesn't deal well with case insensitive file systems
> ---
>
>  Key: GERONIMO-1917
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1917
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: kernel
> Versions: 1.1
> Reporter: David Jencks
> Assignee: David Jencks
>  Fix For: 1.1.1

>
> If you've installed a configuration A/B/1/car and then look for a/b/1/car, 
> the repository will claim it's there on a case insensitive file system, but 
> then further logic in the config store/ manager blows up because those are 
> different artifacts.  Solution appears to be to check when locating an 
> artifact that the case from the file system matches the case you are asking 
> for.

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



[jira] Updated: (GERONIMO-1914) Installer option for creating an installation script should give more information.

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1914?page=all ]

Matt Hogstrom updated GERONIMO-1914:


Fix Version: Wish List
 (was: 1.1)

> Installer option for creating an installation script should give more 
> information.
> --
>
>  Key: GERONIMO-1914
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1914
>  Project: Geronimo
> Type: Wish
> Security: public(Regular issues) 
>   Components: installer
> Reporter: Rick McGuire
> Priority: Minor
>  Fix For: Wish List

>
> The final panel of the installation gives the option to create an installer 
> script for repeating the installation on another system.  However, the 
> installer doesn't give any information about what sort of script this is 
> (batch file, shell script, etc.), and prompts for a filename with no 
> suggested file extension, so the user doesn't know what sort of file to 
> create.  I guessed .bat, which was clearly wrong when I looked at the 
> generated script.  Also, it would be nice if the installer gave some 
> suggestions on how to actually use this generated script to repeat the 
> install. 

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



[jira] Updated: (GERONIMO-1909) Errors in JMS Server portlet

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1909?page=all ]

Matt Hogstrom updated GERONIMO-1909:


Fix Version: 1.1.1
 (was: 1.1)

> Errors in JMS Server portlet
> 
>
>  Key: GERONIMO-1909
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1909
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.1
>  Environment: Win XP, Sun JDK 1.4.2_08
> Reporter: Vamsavardhana Reddy
>  Fix For: 1.1.1

>
> Editing JMS Newtork Listneres and adding new JMS Network Listeners is not 
> functional.  The following exceptions are logged to the console window.
> 15:31:50,887 WARN  [BasicProxyManager] Could not load interface 
> org.activemq.gbe
> an.ActiveMQContainerGBean in provided ClassLoader for 
> geronimo/activemq-broker/1
> .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType
> =JMSServer,name=ActiveMQ
> 15:31:50,897 WARN  [BasicProxyManager] Could not load interface 
> org.activemq.gbe
> an.ActiveMQContainer in provided ClassLoader for 
> geronimo/activemq-broker/1.1-SN
> APSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSS
> erver,name=ActiveMQ
> 15:31:51,078 WARN  [BasicProxyManager] Could not load interface 
> org.activemq.gbe
> an.ActiveMQContainerGBean in provided ClassLoader for 
> geronimo/activemq-broker/1
> .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType
> =JMSServer,name=ActiveMQ
> 15:31:51,078 WARN  [BasicProxyManager] Could not load interface 
> org.activemq.gbe
> an.ActiveMQContainer in provided ClassLoader for 
> geronimo/activemq-broker/1.1-SN
> APSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSS
> erver,name=ActiveMQ
> 15:31:51,088 WARN  [BasicProxyManager] Could not load interface 
> org.activemq.gbe
> an.ActiveMQConnectorGBean in provided ClassLoader for 
> geronimo/activemq-broker/1
> .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType
> =JMSConnector,name=ActiveMQ.tcp.default
> 15:31:51,088 WARN  [BasicProxyManager] Could not load interface 
> org.activemq.gbe
> an.ActiveMQConnectorGBean in provided ClassLoader for 
> geronimo/activemq-broker/1
> .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType
> =JMSConnector,name=ActiveMQ.vm.localhost
> 15:31:51,108 WARN  [BasicProxyManager] Could not load interface 
> org.activemq.gbe
> an.ActiveMQContainerGBean in provided ClassLoader for 
> geronimo/activemq-broker/1
> .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType
> =JMSServer,name=ActiveMQ
> 15:31:51,128 WARN  [BasicProxyManager] Could not load interface 
> org.activemq.gbe
> an.ActiveMQContainer in provided ClassLoader for 
> geronimo/activemq-broker/1.1-SN
> APSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSS
> erver,name=ActiveMQ

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



[jira] Updated: (GERONIMO-1907) Deploy command should redeploy if the app is already deployed

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1907?page=all ]

Matt Hogstrom updated GERONIMO-1907:


Fix Version: Wish List
 (was: 1.1)

> Deploy command should redeploy if the app is already deployed
> -
>
>  Key: GERONIMO-1907
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1907
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: deployment, usability
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: Wish List

>


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



Re: GBeans representing separately persistent data

2006-06-12 Thread John Sisson

Aaron Mulder wrote:

On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
 I think that there is an important distinction here.  There's a 
difference
between providing JMX access and what features deployment 
capabilities have.
 For example, while I may have access to an individual instance of an 
entity
bean, I'm not sure because, thank god, I do not know JSR-77, I am 
certain
that one cannot *create* an instance of an entity bean using GBean.  
One can

only create its container.


I'm not sure what the distinction is.  If you deploy a EJB JAR full of
classes and XML, the end result is that the EJB container runs EJBs.
I'm suggesting that if you deploy a "jobs" JAR full of classes and
XML, the end result will be that the scheduler runs jobs.

Thanks,
   Aaron

How scalable would this be?  I would imagine there would be applications 
that may create thousands of jobs (possibly per day).  Wouldn't startup 
be slow if we had to de-serialize thousands of jobs at startup in the 
process of loading all the GBeans that represent the jobs.  Not having 
looked at quartz myself, it seems it would be much better to have jobs 
in a database.  For example, thousands of Jobs could be created that 
aren't to be executed until next year.   I would expect that a job 
management engine would optimize processing, e.g. only read jobs from 
the database into memory that are to be executed today or in the next hour.


John


[jira] Updated: (GERONIMO-1892) Make JMS Provider Properties a GBean

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1892?page=all ]

Matt Hogstrom updated GERONIMO-1892:


Fix Version: Wish List
 (was: 1.1)

> Make JMS Provider Properties a GBean
> 
>
>  Key: GERONIMO-1892
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1892
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Minor
>  Fix For: Wish List

>
> It would be great to declare an interface and GBean for the JMS provider 
> properties.  Then the portlet could look up all matching GBeans by interface. 
>  So, if you want to add another JMS provider, you just include that GBean in 
> your JMS server module and it's immediately available in the console.

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



[jira] Updated: (GERONIMO-1888) Better help for bad references

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1888?page=all ]

Matt Hogstrom updated GERONIMO-1888:


Fix Version: Wish List
 (was: 1.1)

> Better help for bad references
> --
>
>  Key: GERONIMO-1888
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1888
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: usability
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Minor
>  Fix For: Wish List

>
> If a GBean can't start beacuse of a missing reference, it would be great to 
> give a more helpful error message.  Like if the reference included the name 
> "Foo", print a list of all AbstractNames including name="Foo" in the format 
> you'd expect for the reference in question (slightly different for 
> GBean-to-GBean references vs J2EE Component-to-Resource references, etc.).  
> It would be great if it came out like this:
> Unable to resolve reference to barFoo.  
> Did you mean one of these instead?
>  * bazFoo
>  * otherFoo
> Unable to resolve reference to barFoo.  
> There are no components with Foo in this module or any of its 
> dependencies.  Perhaps you need to add a  to this module and 
> point it to one of the following modules which has a component with 
> Foo:
>  * mygroup/myartifact/1.0/car
>  * other/something/3.4/rar
> This is aggravated by the fact that our resource target names are no longer 
> JMX names, so we can't tell people to look up the component in the JMX debug 
> tool.  However, it's mitigated by the fact that you have to declare 
> dependencies explicitly and can more often just use Foo.

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



[jira] Updated: (GERONIMO-1887) Remove unneeded jars from console WEB-INF/lib directories

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1887?page=all ]

Matt Hogstrom updated GERONIMO-1887:


Fix Version: 1.1.1
 (was: 1.1)

> Remove unneeded jars from console WEB-INF/lib directories
> -
>
>  Key: GERONIMO-1887
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1887
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.x
> Reporter: Paul McMahan
> Assignee: Aaron Mulder
> Priority: Minor
>  Fix For: 1.1.1

>
> Several of the jars in the console's WEB-INF/lib directories are unneeded
> -  both copies of jasper-compiler-5.5.12.jar (400K each)
> -  both copies of jasper-runtime-5.5.12.jar (80K each)
> -  the copy of castor-0.9.5.3.jar in console-standard (1.7M)
> Removing these jars will decrease the server footprint and binary image 
> download size.

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



[jira] Updated: (GERONIMO-1885) Resource/EJB Refs search top-level deployments (or change docs)

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1885?page=all ]

Matt Hogstrom updated GERONIMO-1885:


Fix Version: Wish List
 (was: 1.1)

> Resource/EJB Refs search top-level deployments (or change docs)
> ---
>
>  Key: GERONIMO-1885
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1885
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: naming
> Versions: 1.0
> Reporter: Aaron Mulder
>  Fix For: Wish List

>
> In 1.0 if you declare a resource-link in a Geronimo deployment plan, the 
> deployer will search your own configuration, (any parent configurations?), 
> and any top-level deployments in the server.
> In 1.1, we reportedly current search only the parent configurations to 
> resolve references, no longer checking all top-level deployments in the 
> server.
> I would like to search top-level deployments like we did before, and if we 
> find something not in the parent path emit a warning that this application 
> cannot be safely exported as a plugin or to other Geronimo servers due to an 
> unrecorded dependency.
> If we instead keep the new behavior of searching only parents, we need to 
> ensure that all documentation is updated accordingly (including the DB pool 
> usage screen in the console).

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



[jira] Updated: (GERONIMO-1884) Samples not installed properly in G1.1 - several issues

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1884?page=all ]

Matt Hogstrom updated GERONIMO-1884:


Fix Version: 1.2
 (was: 1.1)

> Samples not installed properly in G1.1 - several issues
> ---
>
>  Key: GERONIMO-1884
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1884
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: sample apps
> Versions: 1.1
> Reporter: Dave Colasurdo
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.2

>
> IT appears that the Geronimo samples have recently been removed from the 
> default distributions and replaced with the ability to download them through 
> the admin console.  There are several issues that need to be addressed:
> 1) The Sample links on the Geronimo welcome page are dead.. This needs to be 
> updated with instructions on how to download, start and access the samples..
> 2) Assuming that the admin console "plugins" is the correct spot to download 
> the samples.. 
>  2a) The initial panel presented to the user is a bit confusing and is 
> missing the ldap-demo..
>  2b) After downloading the jsp or servlet examples.. The user is presented 
> with a "start examples" box..  Selecting this does not work and results in an 
> exception (attached below)
>  2c) "start examples" box does not return any status 
>  2d) Manually starting the example via the command  line also does not work. 
> and results in an exception...
> Exception for 2b
> Geronimo Application Server started
> 
> # Installed configuration
> #   id = geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car
> #   location = 
> /home/davecola/geronimo-1.1-041906/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/repository/geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/jsp-examples-tomcat-1.1-SNAPSHOT.car
> 
> 14:12:04,651 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state: 
> abstractName="geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car?configurationName=geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car"
> java.lang.ClassCastException
> at 
> org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:380)
> at 
> org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322)
> at 
> org.apache.geronimo.kernel.config.Configuration.(Configuration.java:267)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:932)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:525)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:376)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:143)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:267)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:235)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:210)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.

[jira] Updated: (GERONIMO-1879) Make ConfigurationManager take a list of configurations/versions to reload

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1879?page=all ]

Matt Hogstrom updated GERONIMO-1879:


Fix Version: Wish List
 (was: 1.1)

> Make ConfigurationManager take a list of configurations/versions to reload
> --
>
>  Key: GERONIMO-1879
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1879
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: kernel
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: Wish List

>
> Currently each call to ConfigurationManager.reload provides only one 
> artifact/version per call.  This may make it challenging to perform a large 
> upgrade, where it may not be easy to find an order to apply all the changes 
> in.
> It would be nice to be able to pass e.g. a Map of artifacts to versions to 
> cause a bunch of things to be updated to new versions all at once.

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



[jira] Commented: (GERONIMO-1874) synthetic ears should allow use of modules outside the g repository

2006-06-12 Thread Matt Hogstrom (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-1874?page=comments#action_12415943
 ] 

Matt Hogstrom commented on GERONIMO-1874:
-

David, 

I think this can be closed but wanted to confirm that 

> synthetic ears should allow use of modules outside the g repository
> ---
>
>  Key: GERONIMO-1874
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1874
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.1
> Reporter: David Jencks
> Assignee: David Jencks
>  Fix For: 1.1

>
> Currently synthetic ears or external modules in an ear only accept external 
> artifacts that are in the geronimo repo, identified by an Artifact.  We 
> should also allow specification of a path that is not in the repository.  
> Perhaps this could be resolved using ServerInfo if the path is not absolute.  
> I think that changing the meaning of the current  to actually 
> mean a path and introducing a new element such as  perhaps with all 
> the parts to indicate an artifact in the repo would be a good idea.

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



[jira] Updated: (GERONIMO-1873) Deployment must handle dynamically-registered module builders

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1873?page=all ]

Matt Hogstrom updated GERONIMO-1873:


Fix Version: 1.2
 (was: 1.1)

> Deployment must handle dynamically-registered module builders
> -
>
>  Key: GERONIMO-1873
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1873
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.2

>
> Currently the deployment infrastructure does some things specific to 
> different module types -- like identifying the embedded deployment plan in a 
> xAR so it can look up the config ID, and searching for child modules of an 
> EAR.  This is currently hardcoded to the specific set of module types 
> supported by Geronimo by default.  It should be able to handle builders 
> deployed later (e.g. Spring, ServiceMix, whatever), which probably means it 
> needs to be able to ask something on the server-side what modules are 
> available, what their nested plan files are called, and what their j2eeType 
> would be.

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



[jira] Updated: (GERONIMO-1869) Percent complete goes over 100% when installing configurations

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1869?page=all ]

Matt Hogstrom updated GERONIMO-1869:


Fix Version: 1.1.1
 (was: 1.1)

> Percent complete goes over 100% when installing configurations
> --
>
>  Key: GERONIMO-1869
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1869
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: core
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1.1

>
> Looks like the UnpackArtifactTypeHandler counts the "uncompressed" bytes, 
> whereas the % is based on the content size returned by the server for the 
> download (the "compressed" byte count).
> Probably should use an InputStream between the download stream and the ZIP 
> stream that performs the count on read(byte[],int,int) and them use that 
> count instead of the uncompressed count.

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



[jira] Commented: (GERONIMO-1865) Add ability to restart and reload configurations

2006-06-12 Thread Matt Hogstrom (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-1865?page=comments#action_12415941
 ] 

Matt Hogstrom commented on GERONIMO-1865:
-

Aaron, would you consider this closed out or do you have some additional work 
you want to do on this in 1.2?

> Add ability to restart and reload configurations
> 
>
>  Key: GERONIMO-1865
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1865
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: kernel, console
> Versions: 1.1
> Reporter: Dain Sundstrom
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1

>
> Add the ability to restart and reload configurations.  The core feature has 
> been added to the ConfigurationManager, and now we just need to expose it via 
> the CLI and web console.

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



[jira] Updated: (GERONIMO-1858) Bootstrap configuation should not be stopable from the configuation manager

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1858?page=all ]

Matt Hogstrom updated GERONIMO-1858:


Fix Version: 1.2
 (was: 1.1)

> Bootstrap configuation should not be stopable from the configuation manager
> ---
>
>  Key: GERONIMO-1858
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1858
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: kernel
> Reporter: Dain Sundstrom
> Assignee: Dain Sundstrom
>  Fix For: 1.2

>
> The bootstrap configuration contains the configuration manager so it should 
> not be able stop the bootstrap configuration via the configuration manager.

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



[jira] Updated: (GERONIMO-1857) Prompt before stopping a stopping a cofiguration that outher configurations depend on

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1857?page=all ]

Matt Hogstrom updated GERONIMO-1857:


Fix Version: 1.2
 (was: 1.1)

> Prompt before stopping a stopping a cofiguration that outher configurations 
> depend on
> -
>
>  Key: GERONIMO-1857
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1857
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: kernel
> Versions: 1.1
> Reporter: Dain Sundstrom
> Assignee: Aaron Mulder
>  Fix For: 1.2

>
> The cli and webconsole should prompt before stopping any configuration that 
> other configurations depend on.  The cli should provide a --force flag to 
> bypass this prompt.

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



[jira] Closed: (GERONIMO-1832) Non-public Sun classes dependencies in tests

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1832?page=all ]
 
Matt Hogstrom closed GERONIMO-1832:
---

Resolution: Fixed

> Non-public Sun classes dependencies in tests
> 
>
>  Key: GERONIMO-1832
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1832
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: security
> Versions: 1.0
> Reporter: Nellya Udovichenko
> Assignee: Matt Hogstrom
>  Fix For: 1.1
>  Attachments: SubjectCarryingProtocolTest.patch
>
> org.apache.geronimo.security.network.protocol.SubjectCarryingProtocolTest 
> imports 
> com.sun.security.auth.login.ConfigFile class
> Test uses hardcoded internal Sun class so it doesn't work on non-Sun's VM.
> Attached patch adds the property 'auth.login.config' to file 
> security/project.properties 
> to setup needed configuration in test.

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



[jira] Updated: (GERONIMO-1817) "Test a Login" while adding LDAP Realm fails with NullPointerException

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1817?page=all ]

Matt Hogstrom updated GERONIMO-1817:


Fix Version: 1.1.1
 (was: 1.1)

> "Test a Login" while adding LDAP Realm fails with NullPointerException
> --
>
>  Key: GERONIMO-1817
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1817
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
> Versions: 1.0, 1.2, 1.1
>  Environment: WinXP, Sun JDK 1.4.2_08
> Reporter: Vamsavardhana Reddy
>  Fix For: 1.1.1
>  Attachments: GERONIMO-1817.patch
>
> "Test a Login" function while adding LDAP Realm through Admin Console fails 
> with NullPointerException due to connectionProtocol parameter.  The problem 
> is similar to GERONIMO-1791.

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



[jira] Updated: (GERONIMO-1816) XML based serialized configurations

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1816?page=all ]

Matt Hogstrom updated GERONIMO-1816:


Fix Version: 1.2
 (was: 1.1)

> XML based serialized configurations
> ---
>
>  Key: GERONIMO-1816
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1816
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: kernel
> Reporter: Dain Sundstrom
> Assignee: Dain Sundstrom
>  Fix For: 1.2

>
> Configurations should be stored in an XML format instead of using Java Object 
> Serialization.  This will provide the maximum flexibility and make our 
> configuration more future proof.  It also allows an admin to directly modify 
> the server in the case of a production outage.

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



[jira] Updated: (GERONIMO-1810) Improve the "Error: Unable to distribute foo.ear: Cannot deploy the requested application module" message

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1810?page=all ]

Matt Hogstrom updated GERONIMO-1810:


Fix Version: 1.1.1
 (was: 1.1)

> Improve the "Error: Unable to distribute foo.ear: Cannot deploy the requested 
> application module" message
> -
>
>  Key: GERONIMO-1810
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1810
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.0
> Reporter: John Sisson
> Assignee: John Sisson
> Priority: Trivial
>  Fix For: 1.1.1

>
> Need to provide more information in the following error message, giving the 
> user a bit more of a hint as to what the problem may be.
> C:\test>geronimo-1.0.1-SNAPSHOT\bin\deploy --user system --password manager 
> deploy jstest.ear jstest.xml
> Using GERONIMO_BASE:   C:\test\geronimo-1.0.1-SNAPSHOT
> Using GERONIMO_HOME:   C:\test\geronimo-1.0.1-SNAPSHOT
> Using GERONIMO_TMPDIR: C:\test\geronimo-1.0.1-SNAPSHOT\var\temp
> Using JRE_HOME:C:\j2sdk1.4.2_10
> Error: Unable to distribute jstest.ear: Cannot deploy the requested
> application module (planFile=C:\test\jstest.xml,
> 
> moduleFile=C:\test\geronimo-1.0.1-SNAPSHOT\var\temp\geronimo-deployer59948.tmpdir\jstest.ear)
> In the case above it was due to my ear file accidentially having all the 
> files under a directory.
> I propose we add the following to the end of the message:
> Check that the module file contains the expected deployment files and 
> directory structure.  If problems persist, ensure the appropriate module 
> builder is running.

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



[jira] Updated: (GERONIMO-1791) LDAP Security Realm created via Console can fail deployment

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1791?page=all ]

Matt Hogstrom updated GERONIMO-1791:


Fix Version: 1.1.1
 (was: 1.1)

> LDAP Security Realm created via Console can fail deployment
> ---
>
>  Key: GERONIMO-1791
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1791
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: security
> Versions: 1.0, 1.1, 1.2
>  Environment: Geronimo 1.0.0
> Reporter: Donald Woods
> Assignee: Donald Woods
> Priority: Minor
>  Fix For: 1.1.1
>  Attachments: G1791.patch, Geronimo-1791.patch
>
> Creation of an LDAP Security Realm through the Console can fail at runtime, 
> due to a NullPointerException being thrown by the LDAPLoginModule not 
> checking that the optional connectionProtocl and authentication attributes 
> have not been supplied, while other attributes are being checked for null and 
> empty string.
>  655: 17:43:45,328 WARN [TomcatGeronimoRealm] Login exception authenticating 
> username "system"
> 656: javax.security.auth.login.LoginException: Error filling callback list
> 657:  at 
> org.apache.geronimo.security.jaas.client.ServerLoginProxy.login(ServerLoginProxy.java:78)
> 658:  at 
> org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.performLogin(JaasLoginCoordinator.java:189)
> 659:  at 
> org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.login(JaasLoginCoordinator.java:113)
> 660:  at sun.reflect.GeneratedMethodAccessor218.invoke(Unknown Source)
> 661:  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled
>  Code))
> 662:  at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
> 663:  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:699)
> 664:  at 
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:151)
> 665:  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:634)
> 666:  at java.security.AccessController.doPrivileged1(Native Method)
> 667:  at 
> java.security.AccessController.doPrivileged(AccessController.java(Compiled 
> Code))
> 668:  at 
> javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:631)
> 669:  at javax.security.auth.login.LoginContext.login(LoginContext.java:557)
> 670:  at 
> org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.authenticate(TomcatGeronimoRealm.java:332)
> 671:  at 
> org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.authenticate(TomcatGeronimoRealm.java:282)
> 672:  at 
> org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:256)
> 673:  at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:391)
> 674:  at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:273)
> 675:  at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
> 676:  at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 677:  at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 678:  at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 679:  at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526)
> 680:  at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 681:  at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> 682:  at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
> 683:  at 
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 684:  at 
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
> 685:  at 
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> 686:  at java.lang.Thread.run(Thread.java:570)
> 687: Caused by: javax.security.auth.login.LoginException: LDAP Error
> 688:  at 
> org.apache.geronimo.security.realm.providers.LDAPLoginModule.login(LDAPLoginModule.java:162)
> 689:  at 
> org.apache.geronimo.security.jaas.server.JaasLoginService.performLogin(JaasLoginService.java:236)
> 690:  at 
> org.apache.geronimo.security.jaas.server.JaasLoginService$$FastClassByCGLIB$$95b84fc9.invoke()
> 691:  at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java(Inlined 
> Compiled Code))
> 692:  at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java(Compiled
>  Code))
> 693:  at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java(Inlined
>  Compiled Code))
> 694:  at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java(Compiled
>  Code))
> 695:  at 
> org.apache.geronimo.gbean.runtime.Ra

[jira] Updated: (GERONIMO-1716) Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1716?page=all ]

Matt Hogstrom updated GERONIMO-1716:


Fix Version: 1.1.1
 (was: 1.2)
 (was: 1.1)

> Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console
> 
>
>  Key: GERONIMO-1716
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1716
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: security
> Versions: 1.0, 1.1, 1.2
>  Environment: Any
> Reporter: Donald Woods
> Assignee: Donald Woods
> Priority: Minor
>  Fix For: 1.1.1
>  Attachments: Geronimo-1716.patch
>
> Enhancement to the default PropertiesFileLoginModule and Console to encrypt 
> user passwords in users.properties.
> To do this, PropertiesFileLoginModule and Console will be updated to use the 
> SimpleEncryption utility class, just like the deployer, to read/write 
> passwords that have the {Simple} key in front of encrypted passwords.
> The loadProperties() method in PropertiesFileLoginModule will also be updated 
> to rewrite the users.properties file if it detects unencrypted passwords, 
> which will allow users to manually edit the file to update a password and 
> then have it automatically encrypted when the next login event occurs.

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



[jira] Updated: (GERONIMO-1704) Console security realm doesn't let you pick a JAR

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1704?page=all ]

Matt Hogstrom updated GERONIMO-1704:


Fix Version: Wish List
 (was: 1.1)

> Console security realm doesn't let you pick a JAR
> -
>
>  Key: GERONIMO-1704
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1704
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console, security
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: Wish List

>
> It's not possible to use the console to deploy a custom login module because 
> we don't let you specify a JAR that holds the login module and principal 
> classes!

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



[jira] Updated: (GERONIMO-1703) ServerInfo.getBaseDirectory() returns null

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1703?page=all ]

Matt Hogstrom updated GERONIMO-1703:


Fix Version: 1.1.1
 (was: 1.1)

> ServerInfo.getBaseDirectory() returns null
> --
>
>  Key: GERONIMO-1703
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1703
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: startup/shutdown
>  Environment: Sun JDK 1.4.2_08, Win XP, Geronimo-Tomcat
> Reporter: Vamsavardhana Reddy
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1.1
>  Attachments: ServerInfoWebApp.war, ServerInfoWebApp_g1.1.war
>
> Calling getBaseDirectory on org.apache.geronimo.system.serverinfo.ServerInfo 
> returned by KernelManagementHelper.getServerInfo() returns null instead of 
> Geronimo Base Directory.

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



[jira] Updated: (GERONIMO-1690) Additional support for Targets passed into JSR88

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1690?page=all ]

Matt Hogstrom updated GERONIMO-1690:


Fix Version: 1.1.1
 (was: 1.1)

> Additional support for Targets passed into JSR88
> 
>
>  Key: GERONIMO-1690
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1690
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.1
> Reporter: Sachin Patel
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1.1
>  Attachments: patch.txt
>
> From an earlier dev list note...
> 1) The Target is currently discarded by our JSR-88 code because the
> Deployer GBean does not accept a Target/ConfigStore as an argument. 
> That needs to be changed, but it should be pretty straightforward.
> 2) I think the Target name is the full ObjectName of the ConfigStore,
> which means it would be pretty heinous to type on the command line. 
> Hopefully we can make it just the name= component of the ObjectName or
> something like that, but that would require some thought about what to
> do in case of non-unique names.
> 3) I don't think the Hot Deploy Dir GBean lets you specify a Target,
> and it probably should take that as a config param.

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



[jira] Updated: (GERONIMO-1687) NPE during deployment related to EJB Ref

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1687?page=all ]

Matt Hogstrom updated GERONIMO-1687:


Fix Version: 1.1.1
 (was: 1.1)

> NPE during deployment related to EJB Ref
> 
>
>  Key: GERONIMO-1687
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1687
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: OpenEJB, naming
> Versions: 1.0
>  Environment: Geronimo 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1.1

>
> In my case this was caused by an EAR containing an EJB JAR and WAR but only 
> the WAR was listed in application.xml.  Clearly a user error, but obviously 
> we should have an error message not an NPE. 
> 15:45:22,432 ERROR [Deployer] Deployment failed due to
> java.lang.NullPointerException
> at 
> org.apache.geronimo.j2ee.deployment.RefContext.getEJBLocalRef(RefContext.java:111)
> at 
> org.apache.geronimo.naming.deployment.ENCConfigBuilder.addEJBLocalRefs(ENCConfigBuilder.java:507)
> at 
> org.apache.geronimo.naming.deployment.ENCConfigBuilder.buildComponentContext(ENCConfigBuilder.java:781)
> at 
> org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildComponentContext(JettyModuleBuilder.java:1291)
> at 
> org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:464)
> at 
> org.apache.geronimo.jetty.deployment.JettyModuleBuilder$$FastClassByCGLIB$$b30bba8a.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans()
> at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:160)
> at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans()
> at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402)
> at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration()
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102)
> at 
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
> at 
> org.apache.geronimo.gbean.runtime

Re: 1.1-rc1 Now Available

2006-06-12 Thread Matt Hogstrom
I talked with Hiram tonight (before catching up on e-mail so I hadn't seen this note) about getting 
3.2.4 closed out.  Apparently the Codehaus outage left AMQ in an indeterminent state.  We've tested 
the existing 3.2.4-SNAPSHOT against CTS.  I would prefer to close out AMQ 3.2.4 as is and fix this 
for 1.1.1.  Small changes can set us back several days if there is some secondary effect.


Aaron Mulder wrote:

As far as I know, the patch is valid, it just needs to be applied to a
different module than it was created against.  I'm not sure if we're
waiting for this for the release or not.  I had hoped it would go in.
Hiram, do you want to look at it or do you want me to?

Thanks,
   Aaron

On 6/12/06, John Sisson <[EMAIL PROTECTED]> wrote:

I thought that we were waiting for
http://issues.apache.org/jira/browse/GERONIMO-1451 to be fixed.

Aaron and Hiram do you know what is happening here?

John

Kevan Miller wrote:
> My first response went to the user list. I'm repeating on dev...
>
> ActiveMQ 3.2.4 hasn't been released yet? I see we're still including
> ActiveMQ 3.2.4-SNAPSHOT in our repository. What's the plan, there?
>
> I don't think we can release until ActiveMQ has released... Is there
> some problem?
>
> --kevan
>
> On Jun 11, 2006, at 11:48 PM, Matt Hogstrom wrote:
>
>> Over the past few days the outstanding issues that were raised about
>> the first candidate have been addressed.
>>
>> They were that we were missing the LICENSE.txt as well as Notices
>> from the distribution.  I added them.  Guillaume also pointed out
>> that he noted that there should be a Third Party Notices.  This was
>> not included in the original 1.0 or previous distributions so I did
>> not follow it up.  Thoughts?
>>
>> Also, the 1.0 release notes were removed and updated the thread
>> started by Hernan.  The Wiki has been updated and the wiki was the
>> source used to create the RELEASE-NOTES-1.1.txt file you will find in
>> the build.
>>
>> To avoid issues with the version number and the plugins I used rc1
>> which Aaron had added in the plugins for supported versions so I
>> trust that works here.
>>
>> JSisson addressed the problem with not being able to run Geronimo
>> under CygWin and Kevan worked with Aaron to address a new deployment
>> problem that left partially deployed artifacts in the repository.
>>
>> I have taken this build and run some performance tests on it and we
>> are significantly better in 1.1 than we were in 1.0.  We have a lot
>> of improvement left for CMP EJBs.  It appears that the performance
>> improvements in the EJB tier has changed a race condition when
>> running under DB2.  I'm afraid that the only way to address the
>> problem is to add a new feature to TranQL and OEJB that allow for the
>> specification of Isolation Levels for individual beans.  This is a
>> relatively simple change but the build as it stands is specification
>> compliant.  I would prefer to let this release go forward since CMP
>> 2.1 EJBs are not nearly as common as the other J2EE components.  I
>> would like to address this in 1.1.1 however I don't think we've
>> locked down whether that would be allowed or not.  The change would
>> affect TranQL and OpenEJB so they are really included components so
>> I'd be interested in people's feedback.
>>
>> So please accept a named RC1.  Your voting and feedback are for:
>>
>> Geronimo 1.1
>> DayTrader 1.1
>> Specs 1.1
>>
>> The vote will stand for 72 hours.  Issues raised will be discussed
>> and if we conclude that there is a bug that must be addressed then we
>> will mitigate the problem and respin a new rc for a 72 hour vote.
>>
>> If this is accepted all three of the above components will be
>> released simultaneously.
>>
>> Here are the builds for your review and comment:
>>
>> 
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.tar.gz

>>
>> http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.zip
>> 
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-j2ee-1.1-rc1.tar.gz 


>>
>> 
http://people.apache.org/~hogstrom/rc1/geronimo-romcat-j2ee-1.1-rc1.zip
>> 
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.tar.gz 


>>
>> 
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.zip

>>
>> 
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.tar.gz 


>>
>> 
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.zip 


>>
>>
>> http://people.apache.org/~hogstrom/rc1/daytrader-ear-1.1-rc1.zip
>>
>>
>> Looking forward to your comments and feedback.
>>
>
>








[jira] Updated: (GERONIMO-1680) MDB without activation-config in openejb-jar.xml silently fails

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1680?page=all ]

Matt Hogstrom updated GERONIMO-1680:


Fix Version: 1.1.1
 (was: 1.1)

> MDB without activation-config in openejb-jar.xml silently fails
> ---
>
>  Key: GERONIMO-1680
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1680
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: OpenEJB, ActiveMQ
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1.1

>
> I created a queue and sent a couple messages to it.
> Then I created an MDB with a message-destination-type of javax.jms.Queue and 
> a message-destination-link pointing to a message-destination with the name of 
> the Queue.  It seems like this is enough information to point the MDB to that 
> queue, assuming that openejb-jar.xml lists the resource adapter for the MDB.
> This deployed successfully, but no messages were received by the MDB.
> Adding an activation-config section to openejb-jar.xml fixed the problem -- 
> the pending messages were received during deployment.
> One of these two issues strikes me as a bug:
>  1) Why wasn't the MDB hooked up to the queue without needing an 
> activation-config block in openejb-jar.xml?
>  2) If that's an error, why is activation-config optional for an MDB in 
> openejb-jar.xml and why didn't it cause a deployment error?
> In any case, I think deployment should always fail if an MDB is not actually 
> hooked up to a destination.

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



[jira] Updated: (GERONIMO-1642) Deployment plan namespace validation

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1642?page=all ]

Matt Hogstrom updated GERONIMO-1642:


Fix Version: 1.1.1
 (was: 1.1)
Version: 1.1
 (was: 1.0)

> Deployment plan namespace validation
> 
>
>  Key: GERONIMO-1642
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1642
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: web, deployment, OpenEJB
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1.1

>
> When you deploy with a geronimo deployment plan packaged in the archive, but 
> it has the wrong namespace, the file is ignored.  If anything, you get a 
> message saying the plan is required, or that the archive is not a 
> WAR/JAR/etc.  We should have special detection for geronimo-application.xml, 
> geronimo-ra.xml, geronimo-web.xml, and openejb-jar.xml that notices if the 
> file is present but has the wrong namespace, and prints a suggestive WARN or 
> ERROR message to the console.  Probably for the application.xml, web.xml, 
> ra.xml, and ejb-jar.xml too.
> People have asked for help on the mailing list several times recently when 
> they had this (bad namespace) problem.

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



[jira] Updated: (GERONIMO-1641) Using default Console Realm, when delete a user it will not be removed from the groups

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1641?page=all ]

Matt Hogstrom updated GERONIMO-1641:


Fix Version: 1.1.1
 (was: 1.1)
Version: 1.1
 (was: 1.0)

> Using default Console Realm, when delete a user it will not be removed from 
> the groups
> --
>
>  Key: GERONIMO-1641
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1641
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.1
> Reporter: Hernan Cunico
> Assignee: Aaron Mulder
>  Fix For: 1.1.1
>  Attachments: G-1641.patch
>
> When using the default console realm and you add a user to a group, if that 
> user is deleted later it will not be removed from the group it was added.
> The Geronimo console shows that the user has been removed but the 
> groups.properties still shows the user.

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



Re: 1.1-rc1 Now Available

2006-06-12 Thread Matt Hogstrom
Based on your feedback Kevan I have sent a few notes requesting the release of AMQ to the dev 
thread.  Perhaps Hiram is not monitoring this thread so I will ping him on this.


Kevan Miller wrote:

My first response went to the user list. I'm repeating on dev...

ActiveMQ 3.2.4 hasn't been released yet? I see we're still including 
ActiveMQ 3.2.4-SNAPSHOT in our repository. What's the plan, there?


I don't think we can release until ActiveMQ has released... Is there 
some problem?


--kevan

On Jun 11, 2006, at 11:48 PM, Matt Hogstrom wrote:

Over the past few days the outstanding issues that were raised about 
the first candidate have been addressed.


They were that we were missing the LICENSE.txt as well as Notices from 
the distribution.  I added them.  Guillaume also pointed out that he 
noted that there should be a Third Party Notices.  This was not 
included in the original 1.0 or previous distributions so I did not 
follow it up.  Thoughts?


Also, the 1.0 release notes were removed and updated the thread 
started by Hernan.  The Wiki has been updated and the wiki was the 
source used to create the RELEASE-NOTES-1.1.txt file you will find in 
the build.


To avoid issues with the version number and the plugins I used rc1 
which Aaron had added in the plugins for supported versions so I trust 
that works here.


JSisson addressed the problem with not being able to run Geronimo 
under CygWin and Kevan worked with Aaron to address a new deployment 
problem that left partially deployed artifacts in the repository.


I have taken this build and run some performance tests on it and we 
are significantly better in 1.1 than we were in 1.0.  We have a lot of 
improvement left for CMP EJBs.  It appears that the performance 
improvements in the EJB tier has changed a race condition when running 
under DB2.  I'm afraid that the only way to address the problem is to 
add a new feature to TranQL and OEJB that allow for the specification 
of Isolation Levels for individual beans.  This is a relatively simple 
change but the build as it stands is specification compliant.  I would 
prefer to let this release go forward since CMP 2.1 EJBs are not 
nearly as common as the other J2EE components.  I would like to 
address this in 1.1.1 however I don't think we've locked down whether 
that would be allowed or not.  The change would affect TranQL and 
OpenEJB so they are really included components so I'd be interested in 
people's feedback.


So please accept a named RC1.  Your voting and feedback are for:

Geronimo 1.1
DayTrader 1.1
Specs 1.1

The vote will stand for 72 hours.  Issues raised will be discussed and 
if we conclude that there is a bug that must be addressed then we will 
mitigate the problem and respin a new rc for a 72 hour vote.


If this is accepted all three of the above components will be released 
simultaneously.


Here are the builds for your review and comment:

http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.tar.gz
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-j2ee-1.1-rc1.tar.gz 


http://people.apache.org/~hogstrom/rc1/geronimo-romcat-j2ee-1.1-rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.tar.gz 


http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.tar.gz 

http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.zip 



http://people.apache.org/~hogstrom/rc1/daytrader-ear-1.1-rc1.zip


Looking forward to your comments and feedback.








[jira] Updated: (GERONIMO-1638) Multiple servers sharing the same repo and config store

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1638?page=all ]

Matt Hogstrom updated GERONIMO-1638:


Fix Version: 1.2
 (was: 1.1)

> Multiple servers sharing the same repo and config store
> ---
>
>  Key: GERONIMO-1638
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1638
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: usability
> Versions: 1.0
> Reporter: Gianny Damour
> Assignee: John Sisson
>  Fix For: 1.2
>  Attachments: GERONIMO-1638.patch
>
> David J. sent to the dev mailing list:
> Many people have talked on and off about how to set up multiple  servers 
> sharing the same repository and config-store, but we haven't  arrived at an 
> agreed on way to do it.  We have a prospective customer  for this feature 
> (Vincent Massol with Cargo) so I'd like to move  beyond thinking about it in 
> my head, discuss it, and have someone  implement it.  I believe any 
> implementation will be more or less  trivial, the hard part is figuring out 
> what to do.
> I've only thought of ways to extend what we have now, rather than  
> restructure anything or add big new capabilities.  If someone sees a  better 
> way, please speak up.
> So, we have a ServerInfo gbean that knows where geronimo is located  and can 
> resolve absolute locations for other components.  Then we  have things like 
> the repository and config store gbeans that  typically are "located" outside 
> the var dir and things like the  logging framework,  local attribute manager, 
> derby, and tomcat, that  typically keep stuff in the var directory.
> All or most of these start with the first configuration loaded so  they can't 
> have any attributes overridden by config.xml: in fact this  file is read by 
> one of the gbeans that we need to "relocate".
> I've thought of two related solutions.  Both of them involve giving  
> ServerInfo knowledge of another path and another resolve method.
> One would be something like "resolveVar" and would normally resolve  to 
> geronimo_home/var.  This would involve all the gbeans currently  looking 
> inside var having the "var" trimmed off the front of their  paths and using 
> the new resolveVar method.  In this case we'd have  different servers 
> represented as e.g.
> var1
> var2
> var3
> ...
> The other would give ServerInfo something like resolveServer which  would 
> normally resolve to geronimo_home.  The gbeans looking inside  var would keep 
> their current paths and just call the new resolve  method instead of the old 
> one.  In this case we'd have servers like
> var
> server1/var
> server2/var
> ...
> In either case I think starting geronimo with a command line argument  
> pointing to the var directory is the only way to specify which server  you 
> want to run; the default would presumably be as now "var".
> Several people have suggested putting an additional config-store into  var 
> for "private" use by a particular server.  At the moment I think   that 
> providing a different config-store class that uses the new  resolve  method 
> on server info would be the best way to do this.
> I'm not attached to these ideas but this is as far as my thinking has  gone.  
> Please comment.
> thanks
> david jencks

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



[jira] Closed: (GERONIMO-1616) CSS GSSUP token encoding sets username to [EMAIL PROTECTED] but decoding does not reverse that

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1616?page=all ]
 
Matt Hogstrom closed GERONIMO-1616:
---

Resolution: Fixed

> CSS GSSUP token encoding sets username to [EMAIL PROTECTED] but decoding does 
> not reverse that
> 
>
>  Key: GERONIMO-1616
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1616
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: OpenEJB, CORBA
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
>  Fix For: 1.2, 1.1

>
> When a dynamic GSSUP client authenticates, the username sent to the server is 
> [EMAIL PROTECTED], but when the GSSUP server decodes the token, it takes the 
> whole string as the username, and therefore authentication from Geronimo to 
> Geronimo using dynamic GSSUP always fails.
> Since there's a separate field in the GSSUP token for the domain name, I 
> assume the username should just be the username and not [EMAIL PROTECTED]

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



[jira] Updated: (GERONIMO-1695) CORBA for EJB with Local interface only causes NPE

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1695?page=all ]

Matt Hogstrom updated GERONIMO-1695:


Fix Version: 1.1.1
 (was: 1.1)

> CORBA for EJB with Local interface only causes NPE
> --
>
>  Key: GERONIMO-1695
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1695
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: CORBA
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.2, 1.1.1

>
> I have an EJB with a local interface and I tried applying CORBA settings.  It 
> blows up during deployment.  My guess is that it wants a remote interface to 
> be there, but somehow, the checks in StandardServant:126 are not working and 
> the interface just comes up as null.
> Caused by: java.lang.NullPointerException
> at org.openejb.corba.util.Util.getAllInterfaces(Util.java:593)
> at org.openejb.corba.util.Util.getAllMethods(Util.java:815)
> at org.openejb.corba.util.Util.iiopMap(Util.java:608)
> at org.openejb.corba.util.Util.mapOperationToMethod(Util.java:604)
> at org.openejb.corba.StandardServant.(StandardServant.java:135)
> at org.openejb.corba.StandardServant.(StandardServant.java:116)
> at org.openejb.corba.Adapter.(Adapter.java:100)
> ... 67 more

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



[jira] Updated: (GERONIMO-2105) When redeploying with no version number, new entries in config.xml break

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2105?page=all ]

Matt Hogstrom updated GERONIMO-2105:


Fix Version: 1.1.1
 (was: 1.1)

> When redeploying with no version number, new entries in config.xml break
> 
>
>  Key: GERONIMO-2105
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2105
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: kernel
> Versions: 1.1
> Reporter: Aaron Mulder
> Priority: Blocker
>  Fix For: 1.1.1

>
> Let's say you deploy foo with no version number and config.xml content.  Then 
> through the console or some other mechanism, you set a property on a 
> previously unlisted GBean.  Now you get something like this:
>   
>  name="default/foo/1149955208117/war?J2EEApplication=null,WebModule=default/foo/1149955208117/war,j2eeType=GBean,name=MyGBean">
>   value
> Now you redeploy foo, and it migrates the config.xml entry to the new version 
> number.  However, what you actually get is this:
>   
>  name="default/foo/1149955223470/war?J2EEApplication=null,WebModule=default/foo/1149955223470/war,j2eeType=GBean,name=MyGBean">
>   value
> Note the different version numbers between module and gbean elements.  In 
> other words, the version in the main config.xml entry is updated, but the 
> version in the GBean entries is not.  This means that the module will fail to 
> start, as it will treat the GBean as a brand new GBean declaration and crap 
> out when it has no GBeanInfo defined.

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



[jira] Updated: (GERONIMO-1860) Tests of optional ConfigID components

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1860?page=all ]

Matt Hogstrom updated GERONIMO-1860:


Fix Version: 1.1.1
 (was: 1.1)

> Tests of optional ConfigID components
> -
>
>  Key: GERONIMO-1860
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1860
>  Project: Geronimo
> Type: Test
> Security: public(Regular issues) 
>   Components: general
> Versions: 1.1
> Reporter: Aaron Mulder
> Priority: Blocker
>  Fix For: 1.1.1
>  Attachments: testplans.zip
>
> Before shipping 1.1, we need to make sure the following things work:
>  - deploy a web app with no Geronimo plan
>  - redeploy the same web app with no Geronimo plan
>  - deploy a module with a Geronimo plan with an environment with no configId
>  - redeploy the same module with a Geronimo plan with an environment with no 
> configId
>  - deploy a module with a Geronimo plan with no type in the configId
>  - redeploy the same module with a Geronimo plan with no type in the configId
>  - deploy a module with a Geronimo plan with no version in the configId
>  - redeploy the same module with a Geronimo plan with no version in the 
> configId
>  - deploy a module with a Geronimo plan with no type or version in the 
> configId
>  - redeploy the same module with a Geronimo plan with no type or version in 
> the configId
>  - deploy a module with a Geronimo plan with only an artifactId in the 
> configId
>  - redeploy the same module with a Geronimo plan with only an artifactId in 
> the configId
>  - deploy a module with a JAR dependency where only the artifactId is 
> specified
>  - deploy a module with a JAR dependency where only the artifactId and 
> groupId are specified
>  - deploy a module with a JAR dependency where the type is not specified
>  - deploy a module with a JAR dependency where the version is not specified
>  - deploy a module with a configuration dependency where only the artifactId 
> is specified
>  - deploy a module with a configuration dependency where only the artifactId 
> and groupId are specified
>  - deploy a module with a configuration dependency where the type is not 
> specified
>  - deploy a module with a configuration dependency where the version is not 
> specified

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



[jira] Updated: (GERONIMO-1596) Repeated interface in JMS connection factory plan causes deployment failure

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1596?page=all ]

Matt Hogstrom updated GERONIMO-1596:


Fix Version: 1.1.1
 (was: 1.1)
Version: 1.1
 (was: 1.0)

> Repeated interface in JMS connection factory plan causes deployment failure
> ---
>
>  Key: GERONIMO-1596
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1596
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: ActiveMQ, deployment
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1.1

>
> If you deploy a connection factory with an implemented-interface that has the 
> same value as the connectionfactory-interface, then there are explosions 
> during deployment.  However, the deployment is not actually rejected, it just 
> ends up deploying something that doesn't work.  The cause appears to be 
> generating code that implements the same interface twice -- we should either 
> silently ignore one of them (preferable) or reject the deployment alltogether 
> (workable, I guess).
> The plan that caused this contained:
> ...
> 
>   
> 
>   javax.jms.TopicConnectionFactory
> 
> 
>   jms/MyTopicConnectionFactory
>   
> javax.jms.TopicConnectionFactory
>   
> ...
> And the error is:
> 23:39:59,747 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state: 
> objectName="geronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=MyTopicConnectionFactory,j2eeType=JCAManagedConnectionFactory,name=jms/MyTopicConnectionFactory"
> net.sf.cglib.core.CodeGenerationException: 
> java.lang.reflect.InvocationTargetException-->null
> at 
> net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237)
> at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
> at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:304)
> at 
> org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrapper.doStart(ManagedConnectionFactoryWrapper.java:215)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208)
> at 
> org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315)
> at 
> org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173)
> at 
> org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142)
> at 
> org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
> at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125)
> at 
> org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
>  

[jira] Updated: (GERONIMO-1592) Add NamedUPCredentialLoginModule to Console Realm Wizard

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1592?page=all ]

Matt Hogstrom updated GERONIMO-1592:


Fix Version: Wish List
 (was: 1.1)

> Add NamedUPCredentialLoginModule to Console Realm Wizard
> 
>
>  Key: GERONIMO-1592
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1592
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: console, security, webservices
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: Wish List

>
> The console currently has a checkbox to store credentials (using the 
> GeronimoPasswordCredentialLoginModule).  It should likewise have a checkbox 
> and text field to store credentials using the NamedUPCredentialLoginModule 
> (where the text field specifies the name to save under).

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



[jira] Updated: (GERONIMO-1586) In naming schema, make uri optional in portType

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1586?page=all ]

Matt Hogstrom updated GERONIMO-1586:


Fix Version: 1.1.1
 (was: 1.1)

> In naming schema, make uri optional in portType
> ---
>
>  Key: GERONIMO-1586
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1586
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: naming, webservices
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Minor
>  Fix For: 1.1.1

>
> Currently the portType requires .  If you only want to add security 
> settings to the web service, and are happy to default to the URI in the WSDL, 
> you should not need to repeat the URI here.  So technically, you should need 
> either the  or  or both, but I think it's easier to 
> model in the schema as making them both optional, and if you add a  
> with nothing but a name, well then, nothing will change from the original 
> J2EE DD service-ref and WSDL.

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



[jira] Updated: (GERONIMO-1585) Web app security on /* causes deployment exception

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1585?page=all ]

Matt Hogstrom updated GERONIMO-1585:


Fix Version: 1.1.1
 (was: 1.1)
Version: 1.1
 (was: 1.0)

> Web app security on /* causes deployment exception
> --
>
>  Key: GERONIMO-1585
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1585
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: web, security
> Versions: 1.1
>  Environment: Geronimo 1.0 with Jetty and tomcat
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1.1
>  Attachments: security.patch
>
> Deploying a web app with the following security block causes a deployment 
> error:
> 
> 
> All Pages
> /*
> GET
> POST
> PUT
> 
> 
> User
> 
> 
> Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 
> 2.4 spec).
> The error is:
> org.apache.geronimo.common.DeploymentException: Unable to initialize 
> webapp GBean
> at 
> org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842)
> ...
> Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the 
> URLPatternSpec cannot match the first URLPattern
> at javax.security.jacc.URLPatternSpec.(URLPatternSpec.java:54)
> at 
> javax.security.jacc.WebResourcePermission.(WebResourcePermission.java:54)
> at 
> org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215)
> at 
> org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821)
> ... 70 more
> Changing the url-pattern to / fixes the problem, but it seems to me that /* 
> ought to work too.

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



[jira] Updated: (GERONIMO-1492) Many "org/apache/geronimo" configIds still live in source tree

2006-06-12 Thread Matt Hogstrom (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1492?page=all ]

Matt Hogstrom updated GERONIMO-1492:


Fix Version: 1.1.1
 (was: 1.1)
Version: 1.1
 (was: 1.0)

> Many "org/apache/geronimo" configIds still live in source tree
> --
>
>  Key: GERONIMO-1492
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1492
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
> Versions: 1.1
> Reporter: Aaron Mulder
> Priority: Blocker
>  Fix For: 1.1.1
>  Attachments: GERONIMO-1492-1.patch, GERONIMO-1492.diff, 
> annotated-grep-output.txt
>
> I created a couple separate issues, but beyond those a quick search brought 
> up a few more in magic G ball and day trader -- I stopped before it went any 
> further, but we should grep for that and try to eliminate all the references 
> to old-style config IDs.

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



Re: 1.1-rc1 Now Available

2006-06-12 Thread Aaron Mulder

As far as I know, the patch is valid, it just needs to be applied to a
different module than it was created against.  I'm not sure if we're
waiting for this for the release or not.  I had hoped it would go in.
Hiram, do you want to look at it or do you want me to?

Thanks,
   Aaron

On 6/12/06, John Sisson <[EMAIL PROTECTED]> wrote:

I thought that we were waiting for
http://issues.apache.org/jira/browse/GERONIMO-1451 to be fixed.

Aaron and Hiram do you know what is happening here?

John

Kevan Miller wrote:
> My first response went to the user list. I'm repeating on dev...
>
> ActiveMQ 3.2.4 hasn't been released yet? I see we're still including
> ActiveMQ 3.2.4-SNAPSHOT in our repository. What's the plan, there?
>
> I don't think we can release until ActiveMQ has released... Is there
> some problem?
>
> --kevan
>
> On Jun 11, 2006, at 11:48 PM, Matt Hogstrom wrote:
>
>> Over the past few days the outstanding issues that were raised about
>> the first candidate have been addressed.
>>
>> They were that we were missing the LICENSE.txt as well as Notices
>> from the distribution.  I added them.  Guillaume also pointed out
>> that he noted that there should be a Third Party Notices.  This was
>> not included in the original 1.0 or previous distributions so I did
>> not follow it up.  Thoughts?
>>
>> Also, the 1.0 release notes were removed and updated the thread
>> started by Hernan.  The Wiki has been updated and the wiki was the
>> source used to create the RELEASE-NOTES-1.1.txt file you will find in
>> the build.
>>
>> To avoid issues with the version number and the plugins I used rc1
>> which Aaron had added in the plugins for supported versions so I
>> trust that works here.
>>
>> JSisson addressed the problem with not being able to run Geronimo
>> under CygWin and Kevan worked with Aaron to address a new deployment
>> problem that left partially deployed artifacts in the repository.
>>
>> I have taken this build and run some performance tests on it and we
>> are significantly better in 1.1 than we were in 1.0.  We have a lot
>> of improvement left for CMP EJBs.  It appears that the performance
>> improvements in the EJB tier has changed a race condition when
>> running under DB2.  I'm afraid that the only way to address the
>> problem is to add a new feature to TranQL and OEJB that allow for the
>> specification of Isolation Levels for individual beans.  This is a
>> relatively simple change but the build as it stands is specification
>> compliant.  I would prefer to let this release go forward since CMP
>> 2.1 EJBs are not nearly as common as the other J2EE components.  I
>> would like to address this in 1.1.1 however I don't think we've
>> locked down whether that would be allowed or not.  The change would
>> affect TranQL and OpenEJB so they are really included components so
>> I'd be interested in people's feedback.
>>
>> So please accept a named RC1.  Your voting and feedback are for:
>>
>> Geronimo 1.1
>> DayTrader 1.1
>> Specs 1.1
>>
>> The vote will stand for 72 hours.  Issues raised will be discussed
>> and if we conclude that there is a bug that must be addressed then we
>> will mitigate the problem and respin a new rc for a 72 hour vote.
>>
>> If this is accepted all three of the above components will be
>> released simultaneously.
>>
>> Here are the builds for your review and comment:
>>
>> http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.tar.gz
>>
>> http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.zip
>> http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-j2ee-1.1-rc1.tar.gz
>>
>> http://people.apache.org/~hogstrom/rc1/geronimo-romcat-j2ee-1.1-rc1.zip
>> http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.tar.gz
>>
>> http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.zip
>>
>> http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.tar.gz
>>
>> http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.zip
>>
>>
>> http://people.apache.org/~hogstrom/rc1/daytrader-ear-1.1-rc1.zip
>>
>>
>> Looking forward to your comments and feedback.
>>
>
>




[jira] Work started: (AMQ-702) `bstat --help` should display something useful

2006-06-12 Thread Adrian Co (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-702?page=all ]
 
Work on AMQ-702 started by Adrian Co

> `bstat --help` should display something useful
> --
>
>  Key: AMQ-702
>  URL: https://issues.apache.org/activemq/browse/AMQ-702
>  Project: ActiveMQ
> Type: Improvement

> Versions: 4.0 RC3
> Reporter: Jason Dillon
> Assignee: Adrian Co
>  Fix For: 4.1, 4.0.1

>
>
> `bstat --help` should display something useful.  Right now using a 
> non-standard connectorPort for the managementContext I get this:
> {noformat}
> [EMAIL PROTECTED]:...bator-activemq-4.0-RC3/bin>./bstat --help
> ACTIVEMQ_HOME: 
> /Users/jason/ws/paybytouch/ea/activemq/node1/incubator-activemq-4.0-RC3
> ERROR: java.lang.RuntimeException: Failed to execute query task. Reason: 
> java.io.IOException: Failed to retrieve RMIServer stub: 
> javax.naming.ServiceUnavailableException [Root exception is 
> java.rmi.ConnectException: Connection refused to host: localhost; nested 
> exception is: 
> java.net.ConnectException: Connection refused]
> ERROR: java.lang.Exception: java.io.IOException: Failed to retrieve RMIServer 
> stub: javax.naming.ServiceUnavailableException [Root exception is 
> java.rmi.ConnectException: Connection refused to host: localhost; nested 
> exception is: 
> java.net.ConnectException: Connection refused]
> {noformat}
> `bstat localhost --help` works, showing that this is really calling `query`.  
> Anyways, not very helpful when the JMX URL is changed from the default.

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



[jira] Assigned: (GERONIMO-2108) web app deployment fails with strange error if geronimo-web.xml defines a message-destination

2006-06-12 Thread David Jencks (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2108?page=all ]

David Jencks reassigned GERONIMO-2108:
--

Assign To: David Jencks

> web app deployment fails with strange error if geronimo-web.xml defines a 
> message-destination
> -
>
>  Key: GERONIMO-2108
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2108
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.1
>  Environment: geronimo 1.1-rc1 on jdk 1.4.2 on osx
> Reporter: Christoph Sturm
> Assignee: David Jencks

>
> deploying this geronimo-web.xml: 
> 
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1";
>xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1";
>xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1";>
>
>
>   geronimo
>   wtf
>   1.1
>   war
>
>
>
>
>x
>
>
>y
>
>
> 
> results in this error message:
> org.apache.geronimo.common.DeploymentException: xml problem for web app .
>at 
> org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.getTomcatWebApp(TomcatModuleBuilder.java:241)
>at 
> org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.createModule(TomcatModuleBuilder.java:158)
>at 
> org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.createModule(AbstractWebModuleBuilder.java:114)
>at 
> org.apache.geronimo.web.deployment.AbstractWebModuleBuilder$$FastClassByCGLIB$$459e0cc.invoke()
>at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>at 
> org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$23aaf839.createModule()
>at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModule(SwitchingModuleBuilder.java:94)
>at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke()
>at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>at 
> org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$23aaf839.createModule()
>at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:275)
>at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke()
>at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>at 
> org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$2f9800ab.getDeploymentPlan()
>at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232)
>at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
>at 
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke()
>at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>at 
> 

[jira] Commented: (GERONIMO-2108) web app deployment fails with strange error if geronimo-web.xml defines a message-destination

2006-06-12 Thread David Jencks (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-2108?page=comments#action_12415940
 ] 

David Jencks commented on GERONIMO-2108:


I believe I've fixed this in trunk rev 413779 and 1.1 rev. 413780

I want to think about this a little more before closing the issue in case I 
missed more cases.

> web app deployment fails with strange error if geronimo-web.xml defines a 
> message-destination
> -
>
>  Key: GERONIMO-2108
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2108
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.1
>  Environment: geronimo 1.1-rc1 on jdk 1.4.2 on osx
> Reporter: Christoph Sturm

>
> deploying this geronimo-web.xml: 
> 
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1";
>xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1";
>xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1";>
>
>
>   geronimo
>   wtf
>   1.1
>   war
>
>
>
>
>x
>
>
>y
>
>
> 
> results in this error message:
> org.apache.geronimo.common.DeploymentException: xml problem for web app .
>at 
> org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.getTomcatWebApp(TomcatModuleBuilder.java:241)
>at 
> org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.createModule(TomcatModuleBuilder.java:158)
>at 
> org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.createModule(AbstractWebModuleBuilder.java:114)
>at 
> org.apache.geronimo.web.deployment.AbstractWebModuleBuilder$$FastClassByCGLIB$$459e0cc.invoke()
>at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>at 
> org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$23aaf839.createModule()
>at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModule(SwitchingModuleBuilder.java:94)
>at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke()
>at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>at 
> org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$23aaf839.createModule()
>at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:275)
>at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke()
>at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>at 
> org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$2f9800ab.getDeploymentPlan()
>at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232)
>at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
>at 
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke()
>at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastM

RE: cwiki.apache.org [longish]

2006-06-12 Thread Zakharov, Vasily M
Hernan,

Thank you very much!

Now it works fine for me too.

 Vasily


-Original Message-
From: Hernan Cunico [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 13, 2006 12:05 AM
To: dev@geronimo.apache.org
Subject: Re: cwiki.apache.org [longish]

Hi Vasily,
I just copied the page from Atlassian to cwiki and I was able to save it
with no problems. It all 
seems to work just fine now, let me know if you find any issues.

Cheers!
Hernan

Zakharov, Vasily M wrote:
> Hernan,
> 
> Thank you very much!
> 
>  Vasily
> 
> 
> -Original Message-
> From: Hernan Cunico [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 08, 2006 7:56 PM
> To: dev@geronimo.apache.org
> Subject: Re: cwiki.apache.org [longish]
> 
> Hi Vasily,
> I just reported this issue to Atlassian
> (https://support.atlassian.com/browse/CSP-4236).
> Not sure why confluence is complaining, that page is not that big and
I
> was able to migrate it from 
> the other installation. It actually is failing to save any changes,
> there might be some "confluence" 
> code in the doc that this new version is not too happy with.
> 
> I'll review the page markup as soon as I have a min, if I can't find
> anything suspicious I could 
> re-import it from an XML (a new one from the Atlassian install) while
we
> still look for the final 
> solution.
> 
> Cheers!
> Hernan
> 
> Zakharov, Vasily M wrote:
> 
>>Hernan,
>>
>>Thank you alot for your great work on new G wiki!
>>
>>But oops, I was trying to copy my doc from the old location at:
>>
> 
>
http://opensource.atlassian.com/confluence/oss/display/GERONIMO/SPECjApp
> 
>>Server2004
>>to the new location at:
>>
> 
>
http://cwiki.apache.org/confluence/display/GMOxDOC10/SPECjAppServer2004
> 
>>I copied the wiki content and got a successful preview, but when I
> 
> press
> 
>>"Save", I get a System Error:
>>
>>java.lang.IllegalStateException: Form too large
>>at org.mortbay.http.HttpRequest.extractParameters()V(Unknown
> 
> Source)
> 
>>I see that my doc is rather big, but it worked fine on the old
>>Confluence at opensource.atlassian.com.
>>
>>Is it some new feature of Confluence 2.1.5a? :)
>>
>>Vasily Zakharov
>>Intel Middleware Products Division
>>
>>
>>
>>-Original Message-
>>From: Hernan Cunico [mailto:[EMAIL PROTECTED] 
>>Sent: Thursday, June 08, 2006 5:30 PM
>>To: dev@geronimo.apache.org
>>Subject: Re: cwiki.apache.org [longish]
>>
>>All the groups have been updated, you all should have edit
> 
> permissions.
> 
>>Cheers!
>>Hernan
>>
>>John Sisson wrote:
>>
>>
>>>Who has access to fix this?
>>>
>>>John
>>>
>>>Jason Dillon wrote:
>>>
>>>
>>>
It appears that the other spaces need their permissions updated.

--jason


On Jun 7, 2006, at 2:39 PM, Erin Mulder wrote:



>Hernan Cunico wrote:
>
>
>
>>Hi All,
>>I have enabled public signup so now you can register and
contribute
>>directly to the documentation.
>
>
>Thanks for setting this up!  I just signed up, but once I was
logged
>>
>>in,
>>
>>
>I could no longer see most of the Geronimo spaces.  Is it possible
>>
>>that
>>
>>
>permissions have been set for Anonymous, but not for
>>
>>confluence-users
>>
>>
>(or whatever the equivalent role is in this installation)?
>
>When I'm logged out, I see:
>
>Apache Geronimo Documentation  (geronimo)Apache Geronimo
Project
>>
>>
>Management (GMOxPMGT)Apache Geronimo SandBox (GMOxSBOX)
>>
>>Apache 
>>
>>
>Geronimo v1.0 (GMOxDOC10)Apache Geronimo v1.1 (GMOxDOC11)
>
>When I'm logged in, I see:
>
>Apache Geronimo v1.0  (GMOxDOC10)Cayenne Documentation 
>(cayenne)Demonstration Space (ds)Test Space (test)
>
>Cheers,
>Erin



> 


Re: [Vote] 1.1-rc1 Now Available

2006-06-12 Thread Kevan Miller

Alan,
Are you asking for Matt to change the subject line of the vote? That  
would be appropriate. Something like "[Vote] Release Geronimo 1.1  
based on 1.1-rc1"


Or were you not aware of what you were voting on? The note states:


Your voting and feedback are for:

Geronimo 1.1
DayTrader 1.1
Specs 1.1


--kevan

On Jun 12, 2006, at 7:42 PM, Alan D. Cabrera wrote:


We vote for release candidates?  I don't recall doing that before.

+1


Regards,
Alan


Matt Hogstrom wrote:
I apologize for resending this to the lists.  I inadvertantly did  
not put [vote] in the subject line so it may not have been  
apparent.  The remainder of this e-mail is the same content that  
was distributed last night.


Matt Hogstrom wrote:
Over the past few days the outstanding issues that were raised  
about the first candidate have been addressed.


They were that we were missing the LICENSE.txt as well as Notices  
from the distribution.  I added them.  Guillaume also pointed out  
that he noted that there should be a Third Party Notices.  This  
was not included in the original 1.0 or previous distributions so  
I did not follow it up.  Thoughts?


Also, the 1.0 release notes were removed and updated the thread  
started by Hernan.  The Wiki has been updated and the wiki was  
the source used to create the RELEASE-NOTES-1.1.txt file you will  
find in the build.


To avoid issues with the version number and the plugins I used  
rc1 which Aaron had added in the plugins for supported versions  
so I trust that works here.


JSisson addressed the problem with not being able to run Geronimo  
under CygWin and Kevan worked with Aaron to address a new  
deployment problem that left partially deployed artifacts in the  
repository.


I have taken this build and run some performance tests on it and  
we are significantly better in 1.1 than we were in 1.0.  We have  
a lot of improvement left for CMP EJBs.  It appears that the  
performance improvements in the EJB tier has changed a race  
condition when running under DB2.  I'm afraid that the only way  
to address the problem is to add a new feature to TranQL and OEJB  
that allow for the specification of Isolation Levels for  
individual beans.  This is a relatively simple change but the  
build as it stands is specification compliant.  I would prefer to  
let this release go forward since CMP 2.1 EJBs are not nearly as  
common as the other J2EE components.  I would like to address  
this in 1.1.1 however I don't think we've locked down whether  
that would be allowed or not.  The change would affect TranQL and  
OpenEJB so they are really included components so I'd be  
interested in people's feedback.


So please accept a named RC1.  Your voting and feedback are for:

Geronimo 1.1
DayTrader 1.1
Specs 1.1

The vote will stand for 72 hours.  Issues raised will be  
discussed and if we conclude that there is a bug that must be  
addressed then we will mitigate the problem and respin a new rc  
for a 72 hour vote.


If this is accepted all three of the above components will be  
released simultaneously.


Here are the builds for your review and comment:

http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1- 
rc1.tar.gz
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1- 
rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-j2ee-1.1- 
rc1.tar.gz
http://people.apache.org/~hogstrom/rc1/geronimo-romcat-j2ee-1.1- 
rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1- 
rc1.tar.gz
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1- 
rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat- 
minimal-1.1-rc1.tar.gz
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat- 
minimal-1.1-rc1.zip


http://people.apache.org/~hogstrom/rc1/daytrader-ear-1.1-rc1.zip


Looking forward to your comments and feedback.








Re: 1.1-rc1 Now Available

2006-06-12 Thread John Sisson
I thought that we were waiting for 
http://issues.apache.org/jira/browse/GERONIMO-1451 to be fixed.


Aaron and Hiram do you know what is happening here?

John

Kevan Miller wrote:

My first response went to the user list. I'm repeating on dev...

ActiveMQ 3.2.4 hasn't been released yet? I see we're still including 
ActiveMQ 3.2.4-SNAPSHOT in our repository. What's the plan, there?


I don't think we can release until ActiveMQ has released... Is there 
some problem?


--kevan

On Jun 11, 2006, at 11:48 PM, Matt Hogstrom wrote:

Over the past few days the outstanding issues that were raised about 
the first candidate have been addressed.


They were that we were missing the LICENSE.txt as well as Notices 
from the distribution.  I added them.  Guillaume also pointed out 
that he noted that there should be a Third Party Notices.  This was 
not included in the original 1.0 or previous distributions so I did 
not follow it up.  Thoughts?


Also, the 1.0 release notes were removed and updated the thread 
started by Hernan.  The Wiki has been updated and the wiki was the 
source used to create the RELEASE-NOTES-1.1.txt file you will find in 
the build.


To avoid issues with the version number and the plugins I used rc1 
which Aaron had added in the plugins for supported versions so I 
trust that works here.


JSisson addressed the problem with not being able to run Geronimo 
under CygWin and Kevan worked with Aaron to address a new deployment 
problem that left partially deployed artifacts in the repository.


I have taken this build and run some performance tests on it and we 
are significantly better in 1.1 than we were in 1.0.  We have a lot 
of improvement left for CMP EJBs.  It appears that the performance 
improvements in the EJB tier has changed a race condition when 
running under DB2.  I'm afraid that the only way to address the 
problem is to add a new feature to TranQL and OEJB that allow for the 
specification of Isolation Levels for individual beans.  This is a 
relatively simple change but the build as it stands is specification 
compliant.  I would prefer to let this release go forward since CMP 
2.1 EJBs are not nearly as common as the other J2EE components.  I 
would like to address this in 1.1.1 however I don't think we've 
locked down whether that would be allowed or not.  The change would 
affect TranQL and OpenEJB so they are really included components so 
I'd be interested in people's feedback.


So please accept a named RC1.  Your voting and feedback are for:

Geronimo 1.1
DayTrader 1.1
Specs 1.1

The vote will stand for 72 hours.  Issues raised will be discussed 
and if we conclude that there is a bug that must be addressed then we 
will mitigate the problem and respin a new rc for a 72 hour vote.


If this is accepted all three of the above components will be 
released simultaneously.


Here are the builds for your review and comment:

http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.tar.gz 


http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-j2ee-1.1-rc1.tar.gz 


http://people.apache.org/~hogstrom/rc1/geronimo-romcat-j2ee-1.1-rc1.zip
http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.tar.gz 

http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.zip 

http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.tar.gz 

http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.zip 



http://people.apache.org/~hogstrom/rc1/daytrader-ear-1.1-rc1.zip


Looking forward to your comments and feedback.








Re: Should scripts be executable in releases

2006-06-12 Thread John Sisson
We should be able to do this, as it was introduced in Ant 1.5.2 ( Maven 
1.0.2 uses Ant 1.5.3-1 ).


The jelly in Geronimo's assembly plugin needs would need to be updated 
(look at the differences between the tarfileset and the zipfileset), 
plus have the assembly plugin version number bumped. 


I'm not convinced this needs to be in 1.1 though.  Can you raise a JIRA?

John

Jason Dillon wrote:
Do you know of some secret way to get execution bits retained in a 
zip file?


Its not really a secret...

Maven2 assembly plugin fileMode will propagate to tar.gz + zips.

Ant zip task has a zipfileset that takes a filemode.

I've used both techniques and they work to add the right exec modes to 
scripts in tgz or zip.


GShell assembly is currently setup to put the right exec flags on the 
gsh script.


--jason






Re: Frustrations of a Release Manager

2006-06-12 Thread Rodent of Unusual Size

Aaron Mulder wrote:

Dims,

Please don't imply that the PMC chair has sent an at-all useful 
message.


Perhaps -- and evidently -- not useful to you, but it appears
that others have caught on.


(Why is the PMC different today than 4 weeks ago?  I don't know --
you have made the first announcement of this just today. What's the
message?)


'Why': because it was evident that some of the PMC members
were experiencing serious conflicts of interest, and it
appeared that they were being resolved to the project's
detriment.
'The message': No particular message; their project responsibilities
shouldn't have to complete unfavourably with their work or
personal desires, and now don't.


You in your e-mail right here have said what you though went wrong
and how you think it could be corrected in the future.  One of my
biggest complaints with the board and the PMC chair is that they have
done neither.


Untrue.  There were extended discussions in the PMC.  You
voluntarily resigned from the PMC, and wouldn't reconsider
even when I explicitly asked you.  That you have thereby
deprived yourself of a source of information and excluded
yourself from some project-related meta-discussions is a
condition you have chosen.  To more directly address
your remark: just because you are unaware of a fact does not
make it nonexistent.


In conversation with the PMC chair I practically begged him to tell
me I had done something wrong WRT the JavaOne meeting and what should
be done differently next time.  He declined.


Let me quote some of the exchanges, interspersed from the
back-and-forth thread:

===

Aaron wrote:

What's the point of posting the invitation to the dev list?


I responded:

I asked you to post the invitation because there is some confusion
about it, and seeing the actual message would clear that up.


Aaron wrote:
I'm especially confused by the implication that any development has 
been done in private.  What development is that?


I responded:

That's part of the confusion surrounding the invitation.


Aaron wrote:

On whose part?


I responded:

Primarily on the part of people who heard about it but weren't
included even though they're on the project, and others who heard
about it who *aren't* on the project.


Aaron wrote:

Also, who has accused who of intimidation and how?


I responded:

People who feel intimidated don't speak up about it until/unless they
feel comfortable.  It's not for me to reveal their information; they
can do so themselves on the dev list.  If they feel comfortable doing
so.


Aaron wrote:

And why is there concern over a gathering of friends at a conference?


I responded:

Because there are concerns that it was rather more than that.  For
one thing, you don't typically get corporate sponsors for 'gatherings
of friends.'  And people charged with oversight of an open project
have to be sensitive to what they do that relates to the project.


Aaron wrote:
It should be pretty clear from the invitation there was no secret 
development nor intimidation of non-invited project members.


[*** Note that it certainly couldn't be clear, one way or the other,
 to anyone who hadn't *seen* the invitation; hence the desire to
 make it available to people so they could draw their own
 conclusions from it about any concerns they might have had.]

I responded:

The Monday meeting and the development model change are separate
issues.  The 'intimidation' aspect has nothing to do with the
invitation.  The 'secret development' aspect comes in when some
committers are invited to participate and others are deliberately
excluded.


Aaron wrote:

Further, since you have not shared any specific concerns regarding
intimidation or secret development with me, I'm going to assume there
are none that are pertinent to me.  Not trying to be a jerk here, but
no wrongdoing has been pointed out to me, so my plan is to not lose
sleep over what didn't happen.


I responded:

That's cool.


[*** Note that this is an unsatisfactory end to this issue;
 I said I wasn't going to name names, and Aaron said he was
 going to regard that as meaning he wasn't involved.  Not
 necessarily a valid conclusion to draw.]

===


I asked him to provide concrete examples of behavior of any kind that
he thought needed to be changed.  He declined.  I think the message
you provided below "If I had known about the meeting I would have
done this...  What Apache projects usually do is this...  All it 
would have taken was this..." was extremely useful.  Please, please 
encourage the PMC chair to take this approach in the future.


That approach has been taken, but you seem unwilling to
acknowledge it.  The message is: Apache Geronimo is a
collaborative effort.  Committers are peers.  Cliques
are inappropriate, as are significant changes made
unilaterally and without community input.

Is that message sufficiently clear?
--
#kenP-|}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist  http://Apache-

Re: Frustrations of a Release Manager

2006-06-12 Thread Rodent of Unusual Size

Openness indeed.

Aaron Mulder wrote:


Yes, of course, that's a domain we got, because the project needs
one


Which project?  Geronimo?  The plugins effort?


and it can't be at Apache (due to the LGPL issue).  I've offered
a number of times to give people accounts to help manage the site,
and so far, no one's taken me up on it.  My goals are to provide a
Maven repository (=HTTP site) that can hold *all* plugins, ASF, LGPL,
GPL, proprietary.  Since I didn't see one out there, Erin was
gracious enoguh to provide one.  And now you're jumping on her for
it?  That's gratitude!


The problem here is perceptual.  There wasn't a 'hey, what do people
think about this?' message first, and being presented with the site
as a fait accompli was unsettling.


What is your counter-proposal?


IMHO, more 'what do people think' before doing things that
are high-profile or difficult to back out.  Or at all, for that
matter.

Gosh, I didn't really think I was hijacking Jira.  I thought I was 
using it for its intended purpose, which is to say, tracking the 
issues with the project, what should be worked on, and who was

willing to work on what.  Including, of course, a todo list for
myself.


If a release is in process, assigning a bunch of bugs into it
without at least consulting the people involved in it --
especially the release manager -- is bad form.  For one thing,
it can make the release manager look like a jerk.


By all means, if you object to something I do like that, please say
something!  "Aaron, I'm trying to use Jira to track the tasks for
1.1, please don't put anything in there unless it's *definitely*
going to happen in the next 2 weeks" or whatever.  I don't remember
having those discussions until well after the fact.


But it didn't occur to you that the versioning of the
JIRAs was related to the versioning of the release?  And
that the release manager should maybe be consulted?

Well, actually, it was kind of a joint idea between myself and a few 
other people who thought there were some things we ought to talk

about so long as we were all together.  I'm sorry that there's a
perception of an exclusionary wall.


I can't see that as anything but a handwave.  At least
one person, possibly two, has told me that at the meeting
he asked, 'Can I tell Geir where we are?' and received an
emphatic, 'No.  Geir's not welcome here.'  That's pretty
clearly exclusionary.  Perhaps that question wasn't asked
of *you*.  I'll let the querist(s) speak up with exact
details of who asked whom what and got what response if
he/they don't mind.

Also, now that you've given blanket permission, here's what
you said when I asked for a copy of the invitation message:


Here is a copy for you, but I feel pretty strongly that this is not
an appropriate subject for the dev list.


Not exclusionary?  You felt even the *subject* wasn't appropriate
for discussion.  And from the text of the invitation itself:


I'd like to keep this group fairly focused...  thus the limited
distribution.


That doesn't sound like 'let's keep the numbers small so
we can afford lunch.'


If you objected, why am I first hearing about it now?


Here is where some of the intimidation issue raises its
head.  Matt says:


I did object at the meeting but there seemed to be strong avoidance
to including some people so I backed off.


Jeff has also mentioned:


Relative to the private emails, I received an email from you privately
after I brought up the geronimoplugins that was very aggressive, along
with verbiage that bordered on threatening language.  Your private email
to me started out with "Watch your tone".  This is the intimidation
stuff that I have referred to in the past, and it concerns me quite a bit.


That's directed specifically at you, and about offline
interactions; but re the J1 meeting, that someone felt
he had to back down rather than argue his point sounds
like peer pressure brought to bear.

And anyway, what is the perception of the "right" thing to do?  If 
it's not economically feasible for every user, contributor,

committer, and PMC member to get together does that mean no meeting
should happen?


Of course not.  But selecting who's allowed to be there
and who isn't, and actively excluding project committers,
isn't the "right" thing under any circumstances.  So what's
the right thing?  We can figure it out.. but we now have an
example of a *wrong* thing.  No amount of handwaving,
persiflage, or rhetoric is going to turn this sow's ear
into a silk purse.

I'm glad you've changed your mind and want all of the
back-channel crap brought out into the open.  I consider
that to be progress.  For myself, the purpose of not being
specific was to protect people who didn't want to be
directly identified.
--
#kenP-|}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist  http://Apache-Server.Com/

"Millennium hand and shrimp!"


Re: A bad idea whose time has come to an end

2006-06-12 Thread Jason Dillon

+1 to uber-jar death.

--jason


On Jun 12, 2006, at 4:49 PM, Alan D. Cabrera wrote:


Rick McGuire wrote:

Alan D. Cabrera wrote:
The way the specs are currently organized is way too cumbersome  
and confusing.  I propose that we get rid of the root POM for  
specs and that each spec gets its own branches, tags, and trunk,  
so that each may be released independently on its own.


I think that we should do this post v1.1.

Thoughts?
Sounds like a great idea for the individual specs.  How is the  
uber-jar going to be handled?  Will it be re-released/reversioned  
whenever any of the specs reversion, or only at some major release  
boundary?
Now it all comes flooding back.  We're doing all these shenanigans  
for the uber jar.

I, for one, would *love* to get rid of that thing.


Regards,
Alan






[jira] Closed: (AMQ-748) Add request-id and response-id headers to STOMP connect/connected handshake

2006-06-12 Thread Nathan Mittler (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-748?page=all ]
 
Nathan Mittler closed AMQ-748:
--

Resolution: Fixed

Fixed.

> Add request-id and response-id headers to STOMP connect/connected handshake
> ---
>
>  Key: AMQ-748
>  URL: https://issues.apache.org/activemq/browse/AMQ-748
>  Project: ActiveMQ
> Type: New Feature

>   Components: Transport
> Reporter: Nathan Mittler
> Assignee: Nathan Mittler
> Priority: Minor
>  Fix For: 4.1

>
> Original Estimate: 1 week
> Remaining: 1 week
>
> For the new activemq-cpp library, we need to extend the STOMP 
> connect/connected handshake so that we get back a response-id for our 
> response correlator.  To do this, we need to send something in the connect 
> request that contains a client-defined request-id.  My first thought was to 
> just reuse the message-id header, but that is typically reserved for cases 
> when a client is expecting to acknowledge a message.  So rather than risk 
> breaking that paradigm, I propose a new header "request-id" that is just used 
> on the connect message.  When the broker receives a connect request with a 
> request-id header, it creates a connected response with a response-id set to 
> the request-id of the original request.  This way the client can treat the 
> handshake as a true request/response.

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



Re: STOMP and JMSType

2006-06-12 Thread Brian McCallister

On Jun 12, 2006, at 4:14 PM, Nathan Mittler wrote:


Agreed ... using the "type" header is not an option.


--- From the bug report ---
It isn't possible to reuse the "type" header (JMSType) for the  
purpose of sending through the information as to what type of message  
it is (text or bytes).  So this means that we need to add another  
activemq extension header.   I propose "amq-msg-type".

--- / From the bug report --

I like this a lot better, and think it would be a reasonable default  
rule for mapping in 4.X.



I am not convinced we need this, but I much prefer it to a hardcoded
transform, as this would allow for much more useful transforms (ie,
aplication-aware).



Although I agree conceptually, I'm thinking this might be a bit of an
overkill for the task at hand.


Agreed. I just hate to layer on another backwards compatibility issue  
beyond what we already have. By designing it to be forward compatible  
with an arbitrary mapping we can grow into a future solution more  
easily. Once we add this header we will need to support it ~forever.



Right now the STOMP transport only works
with bytes and text messages, and creating this transform model  
won't change
that.  I think if we one day decide to refactor the transport to  
accept
other message types - that would be the time to make this sort of  
change.


What if I want to switch on "Content-type" to decide between text or  
bytes? It is a common header to use, but is not part of the spec (as  
stomp doesn;t care, but is happy to pass it along). This makes more  
sense to me in terms of mapping between Stomp and JMS, but it is not  
compatible with switching on a specific content header.


The mapping between Stomp and JMS is actually rather important to get  
right as it is the low level interop mapping between various  
platforms and Java. As such, I want to make sure we are building  
towards a correct solution.


Aside from all this, controlling the protocol <--> (semi-)protocol  
mapping should be a configuration thing, not a flag the client must  
put on every message it sends.


The end goal for me is to have all messages coming in from the Stomp  
adaptor be bytes messages, unless someone has an overriding need for  
something else (quote possible). The current behavior is pretty bad  
as a default, but we just released 4.0 with it, so we are stuck until  
we make another backwards incompatible release (5.0).


In 4.1 we can add the amq-msg-type header to allow people to force  
things to bytes (or text) but for the 5.0 end game we will need to  
make the mapping pluggable in order to make the upgrade path as easy  
as possible. if we are going to need pluggable eventually, why not do  
it now in order to allow people to fix the bytes/text mistake (I can  
say it is a mistake, I wrote it =) at the server level instead of  
having to add a header to every message.


We have, then, three configurations which people are likely to want:

1) Current (3.2 and 4.0 compatible) one which is made more palatable  
by letting the client specify via the amq-msg-type.


2) Map everything to bytes, which I would like to make the default in  
5.0.


3) Map everything to Text (which is what I would actually use if we  
had it as I convert all the bytes ones I send now into strings anyway).


If we are going to have it be sufficiently pluggable to support these  
three, we should consider letting users provide their own.


-Brian




[jira] Updated: (GERONIMO-1801) Restart/Shutdown functionality for Geronimo when using Java Service Wrapper

2006-06-12 Thread John Sisson (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1801?page=all ]

John Sisson updated GERONIMO-1801:
--

Version: 1.0
 1.1
 (was: 1.x)

> Restart/Shutdown functionality for Geronimo when using Java Service Wrapper
> ---
>
>  Key: GERONIMO-1801
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1801
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: startup/shutdown
> Versions: 1.0, 1.1
>  Environment: Windows, Linux, Mac OS X, Solaris, HP-UX
> Reporter: Mario Ruebsam
> Priority: Minor
>  Fix For: 1.x

>
> If running Geronimo with Java Service Wrapper (also mentioned in 
> GERONIMO-693),
> easy restart/shutdown functionality could be added to the JSW configuration 
> by adding the following lines to the Java Service Wrapper "wrapper.conf".
> # Filter settings. Add parameters as needed starting from 1
> wrapper.filter.trigger.1=JSWRestartGeronimo
> wrapper.filter.action.1=RESTART
> wrapper.filter.trigger.2=JSWShutdownGeronimo
> wrapper.filter.action.2=SHUTDOWN
> wrapper.filter.trigger.3=java.lang.OutOfMemoryError
> wrapper.filter.action.3=RESTART
> The Servlet/JSP code for triggering shutdown/restart is then very
> simple by printing an output to the standard out or err e.g.
> System.out.println("JSWRestartGeronimo");
> or 
> System.out.println("JSWShutdownGeronimo");
> Also the "java.lang.OutOfMemoryError" which is not easy to
> catch in the JVM can be handled this way using the JSW.
> If added to some JSW configuration scripts packaged with
> Geronimo the above configuration should also described
> in the JSW section in the current documentation.

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



[jira] Updated: (GERONIMO-1801) Restart/Shutdown functionality for Geronimo when using Java Service Wrapper

2006-06-12 Thread John Sisson (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-1801?page=all ]

John Sisson updated GERONIMO-1801:
--

Fix Version: 1.x

> Restart/Shutdown functionality for Geronimo when using Java Service Wrapper
> ---
>
>  Key: GERONIMO-1801
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1801
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: startup/shutdown
> Versions: 1.x
>  Environment: Windows, Linux, Mac OS X, Solaris, HP-UX
> Reporter: Mario Ruebsam
> Priority: Minor
>  Fix For: 1.x

>
> If running Geronimo with Java Service Wrapper (also mentioned in 
> GERONIMO-693),
> easy restart/shutdown functionality could be added to the JSW configuration 
> by adding the following lines to the Java Service Wrapper "wrapper.conf".
> # Filter settings. Add parameters as needed starting from 1
> wrapper.filter.trigger.1=JSWRestartGeronimo
> wrapper.filter.action.1=RESTART
> wrapper.filter.trigger.2=JSWShutdownGeronimo
> wrapper.filter.action.2=SHUTDOWN
> wrapper.filter.trigger.3=java.lang.OutOfMemoryError
> wrapper.filter.action.3=RESTART
> The Servlet/JSP code for triggering shutdown/restart is then very
> simple by printing an output to the standard out or err e.g.
> System.out.println("JSWRestartGeronimo");
> or 
> System.out.println("JSWShutdownGeronimo");
> Also the "java.lang.OutOfMemoryError" which is not easy to
> catch in the JVM can be handled this way using the JSW.
> If added to some JSW configuration scripts packaged with
> Geronimo the above configuration should also described
> in the JSW section in the current documentation.

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



[jira] Updated: (GERONIMO-693) Provide Java Service Wrapper scripts in bin directory

2006-06-12 Thread John Sisson (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-693?page=all ]

John Sisson updated GERONIMO-693:
-

Version: 1.0
 1.1

> Provide Java Service Wrapper scripts in bin directory
> -
>
>  Key: GERONIMO-693
>  URL: http://issues.apache.org/jira/browse/GERONIMO-693
>  Project: Geronimo
> Type: New Feature

>   Components: usability, startup/shutdown
> Versions: 1.0-M4, 1.0, 1.1
>  Environment: Windows, Linux, Mac OS X
> Reporter: Erin Mulder
> Assignee: John Sisson
> Priority: Minor
>  Fix For: 1.x
>  Attachments: wrapper.tar.gz
>
> It would be nice to have obvious startup.sh and startup.bat scripts in the 
> bin directory so that the user doesn't need to look at the README file to 
> figure out how to start the server.  (java -jar bin/server.jar isn't hard -- 
> it's just not quite as brainless as a script called "startup").

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



  1   2   3   >