date:20060907

I have checked out the specs from
https://svn.apache.org/repos/asf/geronimo/specs/branches/1_1_1.
When I am building the specs, maven is downloading and using
http://repo1.maven.org/maven2/org/apache/geronimo/specs/specs/1.1/specs-1.1.pom
. The file pom.xml in the root directory is ignored.

[jira] Created: (SM-567) Allow the soap style to be set for jsr181 endpoint

2006-09-07 Thread Guillaume Nodet (JIRA)

Allow the soap style to be set for jsr181 endpoint
--

 Key: SM-567
 URL: https://issues.apache.org/activemq/browse/SM-567
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-jsr181
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 3.0-M3


Styles supported by XFire include rpc, document, wrapped, message.
The default should be wrapped to ensure compatibility.

-- 
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] Resolved: (SM-567) Allow the soap style to be set for jsr181 endpoint

2006-09-07 Thread Guillaume Nodet (JIRA)

 [ https://issues.apache.org/activemq/browse/SM-567?page=all ]

Guillaume Nodet resolved SM-567.


Resolution: Fixed

Author: gnodet
Date: Thu Sep  7 02:51:50 2006
New Revision: 441037

URL: http://svn.apache.org/viewvc?view=revrev=441037
Log:
SM-567: Allow the soap style to be set for jsr181 endpoint
Modify the wsdl-first example to use document style

Added:

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/itests/PersonTest.java

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/wsdl_first/

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/wsdl_first/Person.java

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/wsdl_first/PersonImpl.java

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/wsdl_first/PersonServiceImpl.java

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/wsdl_first/PersonServiceService.java

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/wsdl_first/UnknownPersonFault.java

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/wsdl_first/types/

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/wsdl_first/types/GetPerson.java

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/wsdl_first/types/GetPersonResponse.java

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/wsdl_first/types/ObjectFactory.java

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/wsdl_first/types/UnknownPersonFault.java

incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/samples/wsdl_first/types/package-info.java

incubator/servicemix/trunk/servicemix-itests/src/test/resources/org/apache/servicemix/itests/person.wsdl

incubator/servicemix/trunk/servicemix-itests/src/test/resources/org/apache/servicemix/itests/person.xml
Modified:
incubator/servicemix/trunk/samples/wsdl-first/client.html

incubator/servicemix/trunk/samples/wsdl-first/wsdl-first-jsr181-su/src/main/java/org/apache/servicemix/samples/wsdl_first/PersonImpl.java

incubator/servicemix/trunk/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl

incubator/servicemix/trunk/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml

incubator/servicemix/trunk/servicemix-jsr181/src/main/java/org/apache/servicemix/jsr181/Jsr181Endpoint.java



 Allow the soap style to be set for jsr181 endpoint
 --

 Key: SM-567
 URL: https://issues.apache.org/activemq/browse/SM-567
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-jsr181
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 3.0-M3


 Styles supported by XFire include rpc, document, wrapped, message.
 The default should be wrapped to ensure compatibility.

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

Soap style on jsr181 endpoint

2006-09-07 Thread Guillaume Nodet


I have just added a new attribute on the sr181:endpoint /
which is
  style=rpc|document|wrapped|message
The default being wrapped to keep compatibility.

This allows the expected xml message to be conformant
to the generated wsdl.  The wsdl-first example can
now be tested using SoapUI or Web Service Explorer
from Eclipse :)

--
Cheers,
Guillaume Nodet

[jira] Created: (AMQ-914) OutOfMemoryError

2006-09-07 Thread Daniel Aioanei (JIRA)

OutOfMemoryError


 Key: AMQ-914
 URL: https://issues.apache.org/activemq/browse/AMQ-914
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0.1
Reporter: Daniel Aioanei
 Attachments: activemq.xml

I was doing some testing with a single MDP listening to a queue which had about 
247300 messages, with a postgres backend. ActiveMQ server was started using the 
default activemq startup script (on Linux). In this configuration the cpu 
normally stays mostly idle and I described this behaviour in another bug report.

Another issue came to surface when I tried to profile the client application 
with EclipseColorer to see why a single MDP can't hog my machine. But when I 
tried so, 4 OutOfMemoryError messages were logged by ActiveMQ server. Note that 
I was *not* profiling the server, but the client which is a totally different 
process.


-- 
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-914) OutOfMemoryError

2006-09-07 Thread Daniel Aioanei (JIRA)

[ 
https://issues.apache.org/activemq/browse/AMQ-914?page=comments#action_36915 ] 

Daniel Aioanei commented on AMQ-914:


Just got the same problem in the same configuration without running anything 
under a profiler.

INFO  Service- Sync error occurred: 
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
INFO  Service- Sync error occurred: 
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
INFO  Service- Sync error occurred: 
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
INFO  Service- Sync error occurred: 
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
INFO  Service- Sync error occurred: 
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space

I guess I could specify some larger -xmx value, but because the back end is 
postgres I don't think the number of messages in the queue should have anything 
to do with the amount of memory the ActiveMQ server needs.

 OutOfMemoryError
 

 Key: AMQ-914
 URL: https://issues.apache.org/activemq/browse/AMQ-914
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0.1
Reporter: Daniel Aioanei
 Attachments: activemq.xml


 I was doing some testing with a single MDP listening to a queue which had 
 about 247300 messages, with a postgres backend. ActiveMQ server was started 
 using the default activemq startup script (on Linux). In this configuration 
 the cpu normally stays mostly idle and I described this behaviour in another 
 bug report.
 Another issue came to surface when I tried to profile the client application 
 with EclipseColorer to see why a single MDP can't hog my machine. But when I 
 tried so, 4 OutOfMemoryError messages were logged by ActiveMQ server. Note 
 that I was *not* profiling the server, but the client which is a totally 
 different process.

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

Adding items to NameFactory

2006-09-07 Thread Rick McGuire

I'm going to be adding several new GBean types to openejb for ORB 
configuration as part of the Yoko work.  Each of these new GBeans is 
defined with a j2ee type to be consistent with the other openejb CORBA 
GBeans.  Right now, I'm using hard coded strings, but adding these types 
to NameFactory represents an interesting bootstrapping problem.  It 
appears I need to add these to a build first, build and publish that 
build to my repository, then build my openejb code that uses the new 
NameFactory entries, then build my Geronimo code that dependent on the 
new openejb version (ugh).


Is this assumption correct?  Can I go and add the new NameFactory 
entries now in anticipation of my future need so I can avoid the 
bootstrapping problem?


Rick

JIRA's under Patch Avaliable

I have uploaded patches for some JIRA's and also checked Patch
Available option. But, I do not see these JIRA's listed under
Patch Available. What am I missing?

Vamsi

Re: [VOTE] Publish Genesis 1.0 to m2 central

2006-09-07 Thread Bill Dudney


Hi Jason,

Did this ever get done? I'm +1 on releasing something (1.1, 1.0.1 1.0- 
oops whatever) since we are forced to build it after a complete  
bootstrap.


TTFN,

-bd-
On Aug 30, 2006, at 7:19 PM, Jason Dillon wrote:

Well... it was actually released... and then pulled back... which  
is my fault.


But, I don't see any reason why 1.0 needs to be re-released.  I've  
already updated the tree to use 1.1-SNAPSHOT and have been making  
changes to it to fix the noted problems as well as a few other  
enhancements... IMO it is much more confusing to look at the SVN  
logs and see that 1.0 was made from a 1.1-SNAPSHOT.


I think that the unfortunate practice of making a release then  
voting on it and then possibly re-cutting the same release is very  
poor.  I'd much rather consider 1.0 dead and release 1.1 so that  
there is no confusion as to which is which.


In almost every other software project I have worked on, a release  
is cut, if there are changes, then a new revision is made and then  
a new release is cut for the changes.  If you wanted to keep the  
1.0 bits in there then 1.0-1 and then 1.0-2 is common practice for  
minor fix iterations.


While I can understand since the time to run the tck for the  
Geronimo server on the release binaries and then after that has run  
we vote... that the server release is a bit different.  I don't  
think this needs to be or should be the case for other projects.  I  
believe it is much, much better to test the latest SNAPSHOT, then  
vote to make the release and then make the release.


Anyways, I don't think that the version matters very much here.   
This is an internal project used to support internal builds.  I  
don't expect anyone outside of Geronimo to even care.  So, I still  
recommend that 1.0 is dead and next to be released w/proper  
oversight and vote is 1.1.


--jason


On Aug 30, 2006, at 6:02 PM, Alan D. Cabrera wrote:

I'm confused, how do we vote for 1.1 if 1.0 was never released?   
We need to keep the version number the same.



Regards,
Alan

Jason Dillon wrote:
Okay, I'm canceling this vote.  I've removed the clover bits from  
Genesis, and added headers to scripts... will start a new vote  
for 1.1 soonish.


Thanks for all of your input.  Sorry I jumped the gun and created  
the release before the vote.


--jason


On Aug 29, 2006, at 9:10 AM, Kevan Miller wrote:



On Aug 28, 2006, at 11:25 PM, Jason Dillon wrote:


On Aug 28, 2006, at 7:59 PM, Kevan Miller wrote:
I appreciate that, I applaud your efforts, and apologize if  
I'm being a PITA. However, we also have a responsibility as a  
community when releasing software. I'm trying to be sure we  
are addressing that responsibility.


Mmmkay.  I'm taking deep breaths... :-]


For instance, I see that genesis-1.0 includes a software  
license for Clover? News to me, but I confess that genesis has  
been a bit of an unknown to me...


from
Product: Clover
License: Open Source License, 0.x, 1.x
Issued: Sun May 14 2006 21:59:13 CDT
Expiry: Never
Maintenance Expiry: Never
Key: 965016739f4031c43d67e61b0
Name: Jason Dillon
Org: Apache Geronimo

Clause 5 of the Clover license says The Licensee may copy the  
Software for back-up purposes only. The Licensee may not  
assign or otherwise transfer the Software to any third party.  
IANAL ADNWTB, however, this gives me cause for concern. Can  
you explain what this is about?


I have no idea what IANAL ADNWTB means.  But Clover grants  
licenses for open source projects.  I used the license they  
granted to me to be used to run the site builds.  This is  
shared configuration, which was checked into genesis to  
simplify the configuration of modules which need it to run the  
plugin.


Sorry..
I Am Not A Lawyer
And Don't Want To Be

I don't think we can put this license in on ibiblio. I also  
don't think it should be public in our source tree... I  
understand that this may make things more difficult, but it sure  
seems to me that we're violating the terms of the license  
agreement... Can you convince me otherwise?


--kevan

Re: JIRA's under Patch Avaliable

2006-09-07 Thread Kevan Miller



On Sep 7, 2006, at 7:41 AM, Vamsavardhana Reddy wrote:

I have uploaded patches for some JIRA's and also checked Patch  
Available option.  But, I do not see these JIRA's listed under  
Patch Available.  What am I missing?


Hi Vamsi,
Are you the Assignee of the Jira's? I think you need to edit the  
Jira and assign the Jira's to Unassigned.


IIUC, the script that generates the email assumes that assigned  
jira's are being worked on by somebody...


--kevan

Re: Release Early, Release Often

2006-09-07 Thread Joe Bohn

Before we start thinking of a 1.2-alpha release we must decide what it 
is that we intend to include the final 1.2 release.  I don't think that 
we have done this yet (which is what I was getting at with my other post 
on this thread).


Once we have that content decided then we need to take a look at where 
we are at with regard to delivery of that content.   If we have the 
major functions nearly complete then we could consider cutting an alpha 
release while we continue to refine the capabilities and continue to 
deliver the more minor function of the release.  Anything short of that 
seems to me to be just exposing a nightly build.


Joe


Jason Dillon wrote:
I am thinking about an 1.2-alpha release, which does not need to pass  
any tck, but can still be downloaded by folks that want to test their  
apps on the bleeding edge (with out having to build).  While there is  
nothing major from a J2EE perspective in the alpha, a lot has  changed, 
or will change very shortly.  Here is a list with comments  of new and 
upcoming stuff:


ActiveMQ 4.1, is about to get committed.

Derby is about to get upgraded.

Log4j is about to get upgraded.

Use of concurrent util is about to get changed to backport-concurrent- 
util.


Lets not forget that we changed the build system, which mostly  impacts 
development, but also has an impact on the configuration  files, and 
plugins... new CAR m2 plugin.  I think it would be really  good to get 
an alpha out so that people can easily test and provide  feedback.


New m2 plugin to start/stop Geronimo, soon to have new deploy goals.

A bunch of bug fixes.

 * * *

I think that by releasing a 1.2-alpha, that we also start down the  path 
of changing the perception of how quickly we release.  The alpha  can 
also serve to help us get some experience using the m2 release  plugin 
so that when it comes time for a non-alpha/beta release that  we have 
confidence in the procedure... and this will give us time to  make sure 
that we have the right configurations and setup to make a  release with 
relative ease.


Also, more of a side effect, by making a new release, it helps  control 
the JIRA roadmap, right now 1.2 is filled with a bunch of  build system 
related fluff and other bits...


I think that we have enough changes (or soon to change in the next  days 
or so) to warrant an alpha.  I don't see any reason why not  to... we 
don't need to spend days/weeks to ensure the TCK passes,  because we 
don't need to run it.  It should be sufficient to vote on  an alpha and 
then cut the release, which should be easy with the  maven release 
plugin, and even easier with my gpg-sign'ing mojo to  sign and upload 
all artifacts.


I believe that having this alpha out will benefit our community,  
showing that we are going to start releasing more often, give people  a 
chance to provide feedback more often an earlier.


I certainly do not expect any production customers to use this, but I  
do expect that app developers will, so they can ready their apps for  
deployment on the platform.  We will clearly label this as an alpha  
release, and clear state that it has not been TCK certified.


I don't see any downside to cutting a release off of trunk soonish,  in 
the next week or so.


--jason


On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:



On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:

According to our STATUS file, our last feature release (1.1) was  on 
2006-06-26 which is about 2.5 months ago.  I'm not sure exactly  what 
we have in trunk right now, but I'd guess we most likely have  enough 
to do a release right now.   I'm going to spend a few hours  today 
browsing the JIRAs and SVN logs and compile a list of the  features 
we have in trunk right now. Anyways, I'll let you know  what I find 
and we can figure out what we want to do.



I'd be interested to hear more concretely what's in Geronimo trunk,  
OpenEJB 2.2, etc that's not in 1.1.1...


--kevan

Re: JIRA's under Patch Avaliable

Hi Kevan,

After uploading the patch, I have unassigned these JIRAs. Only one of the JIRA's shows under Patch Available.

VamsiOn 9/7/06, Kevan Miller [EMAIL PROTECTED] wrote:
On Sep 7, 2006, at 7:41 AM, Vamsavardhana Reddy wrote: I have uploaded patches for some JIRA's and also checked Patch Available option.But, I do not see these JIRA's listed under Patch Available.What am I missing?
Hi Vamsi,Are you the Assignee of the Jira's? I think you need to edit theJira and assign the Jira's to Unassigned.IIUC, the script that generates the email assumes that assigned
jira's are being worked on by somebody...--kevan

Re: [VOTE] 1.1.1-rc2 Release

2006-09-07 Thread Jan Bartel


First, I apologise but my newsreader can't find the initial email in this
thread, so I'm just replying to the first one I can find.

I've downloaded and tried geronimo-jetty-j2ee-1.1.1-rc2.tar.gz. I simply
followed the instructions in the RELEASE_NOTES. I can't get the 
console webapp to deploy. The log looks like jetty is missing a 
component and therefore not starting.


My environment is java 1.4.2_08 on linux.

I've tried both bin/geronimo.sh start and java -jar bin/server.jar start 
with the same results.


Here's the startup trace with -v flag (sorry it is a little long):

[EMAIL PROTECTED]:~/src/tmp/geronimo-1.1.1-rc2$ java -jar ./bin/server.jar -v
Booting Geronimo Kernel (in Java 1.4.2_08)...
13:46:35,596 DEBUG [GBeanSingleReference] Waiting to start 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=JCAWorkManager,name=DefaultWorkManager
 because no targets are running for reference ScheduledPool matching the 
patterns 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=GBean,name=ConnectorThreadPool
13:46:35,597 DEBUG [GBeanSingleReference] Waiting to start 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=JCAWorkManager,name=DefaultWorkManager
 because no targets are running for reference TransactionContextManager 
matching the patterns 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=TransactionContextManager,name=TransactionContextManager
13:46:35,597 DEBUG [GBeanSingleReference] Waiting to start 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=JCAWorkManager,name=DefaultWorkManager
 because no targets are running for reference SyncPool matching the patterns 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=GBean,name=ConnectorThreadPool
13:46:35,597 DEBUG [GBeanSingleReference] Waiting to start 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=JCAWorkManager,name=DefaultWorkManager
 because no targets are running for reference StartPool matching the patterns 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=GBean,name=ConnectorThreadPool
13:46:35,597 DEBUG [GBeanSingleReference] Waiting to start 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=TransactionContextManager,name=TransactionContextManager
 because no targets are running for reference XidImporter matching the patterns 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=TransactionManager,name=TransactionManager
13:46:35,598 DEBUG [GBeanSingleReference] Waiting to start 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=TransactionContextManager,name=TransactionContextManager
 because no targets are running for reference TransactionManager matching the 
patterns 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=TransactionManager,name=TransactionManager
13:46:35,863 DEBUG [GBeanSingleReference] Waiting to start 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=JCAWorkManager,name=DefaultWorkManager
 because no targets are running for reference ScheduledPool matching the 
patterns 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=GBean,name=ConnectorThreadPool
13:46:35,951 DEBUG [GBeanSingleReference] Waiting to start 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=JCAWorkManager,name=DefaultWorkManager
 because no targets are running for reference SyncPool matching the patterns 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=GBean,name=ConnectorThreadPool
13:46:35,951 DEBUG [GBeanSingleReference] Waiting to start 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=JCAWorkManager,name=DefaultWorkManager
 because no targets are running for reference StartPool matching the patterns 
geronimo/j2ee-server/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-server/1.1.1-rc2/car,j2eeType=GBean,name=ConnectorThreadPool
13:46:36,686 DEBUG [GBeanSingleReference] Waiting to start 
geronimo/j2ee-security/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-security/1.1.1-rc2/car,j2eeType=SecurityRealm,name=geronimo-properties-realm
 because no targets are running for reference LoginModuleConfiguration matching 
the patterns 
geronimo/j2ee-security/1.1.1-rc2/car?ServiceModule=geronimo/j2ee-security/1.1.1-rc2/car,j2eeType=LoginModuleUse,name=properties-login
13:46:36,686 DEBUG [GBeanSingleReference] Waiting to start

Re: Release Early, Release Often

2006-09-07 Thread Dave Colasurdo


Here is the wikipedia definition for Pre-Alpha, Alpha, Beta, etc..

http://en.wikipedia.org/wiki/Alpha_release

The definitions pretty much agree with my preconception of what an Alpha 
 would contain.


IMHO, trunk is not currently in an Alpha state and doesn't accurately 
reflect the majority of the software requirements that will be 
addressed in G1.2.


It seems that trunk is currently in a pre-alpha state and I believe 
making an occasional unstable/nightly build available would allow 
users/developers to get familiar with the latest and greatest functions 
in trunk without giving the false impression that G1.2 is currently in 
Alpha state.


Just my .02

-Dave-

Jason Dillon wrote:
I am thinking about an 1.2-alpha release, which does not need to pass 
any tck, but can still be downloaded by folks that want to test their 
apps on the bleeding edge (with out having to build).  While there is 
nothing major from a J2EE perspective in the alpha, a lot has changed, 
or will change very shortly.  Here is a list with comments of new and 
upcoming stuff:


ActiveMQ 4.1, is about to get committed.

Derby is about to get upgraded.

Log4j is about to get upgraded.

Use of concurrent util is about to get changed to backport-concurrent-util.

Lets not forget that we changed the build system, which mostly impacts 
development, but also has an impact on the configuration files, and 
plugins... new CAR m2 plugin.  I think it would be really good to get an 
alpha out so that people can easily test and provide feedback.


New m2 plugin to start/stop Geronimo, soon to have new deploy goals.

A bunch of bug fixes.

 * * *

I think that by releasing a 1.2-alpha, that we also start down the path 
of changing the perception of how quickly we release.  The alpha can 
also serve to help us get some experience using the m2 release plugin so 
that when it comes time for a non-alpha/beta release that we have 
confidence in the procedure... and this will give us time to make sure 
that we have the right configurations and setup to make a release with 
relative ease.


Also, more of a side effect, by making a new release, it helps control 
the JIRA roadmap, right now 1.2 is filled with a bunch of build system 
related fluff and other bits...


I think that we have enough changes (or soon to change in the next days 
or so) to warrant an alpha.  I don't see any reason why not to... we 
don't need to spend days/weeks to ensure the TCK passes, because we 
don't need to run it.  It should be sufficient to vote on an alpha and 
then cut the release, which should be easy with the maven release 
plugin, and even easier with my gpg-sign'ing mojo to sign and upload all 
artifacts.


I believe that having this alpha out will benefit our community, showing 
that we are going to start releasing more often, give people a chance to 
provide feedback more often an earlier.


I certainly do not expect any production customers to use this, but I do 
expect that app developers will, so they can ready their apps for 
deployment on the platform.  We will clearly label this as an alpha 
release, and clear state that it has not been TCK certified.


I don't see any downside to cutting a release off of trunk soonish, in 
the next week or so.


--jason


On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:



On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:

According to our STATUS file, our last feature release (1.1) was on 
2006-06-26 which is about 2.5 months ago.  I'm not sure exactly what 
we have in trunk right now, but I'd guess we most likely have enough 
to do a release right now.   I'm going to spend a few hours today 
browsing the JIRAs and SVN logs and compile a list of the features we 
have in trunk right now. Anyways, I'll let you know what I find and 
we can figure out what we want to do.


I'd be interested to hear more concretely what's in Geronimo trunk, 
OpenEJB 2.2, etc that's not in 1.1.1...


--kevan

Re: JIRA's under Patch Avaliable

Hi Kevan,

Seems like the JIRA's will be listed under Patch Available only after initiating RTC.

Thanks,
VamsiOn 9/7/06, Kevan Miller [EMAIL PROTECTED] wrote:
On Sep 7, 2006, at 7:41 AM, Vamsavardhana Reddy wrote: I have uploaded patches for some JIRA's and also checked Patch Available option.But, I do not see these JIRA's listed under Patch Available.What am I missing?
Hi Vamsi,Are you the Assignee of the Jira's? I think you need to edit theJira and assign the Jira's to Unassigned.IIUC, the script that generates the email assumes that assigned
jira's are being worked on by somebody...--kevan

Re: No need for m2 central mirror

2006-09-07 Thread Jacek Laskowski


On 9/6/06, Jason Dillon [EMAIL PROTECTED] wrote:

With the new central repo off of ibiblio, you no longer need a mirror
in settings.xml.  I recommend that everyone remove the mirror setting
and use the central mirror... and report any problems.


What's the new central repo? Thanks for heads-up!

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Importing Servicemix-3.0-M2 into eclipse: Build error

2006-09-07 Thread mwhs


Hello,

I am trying to import servicemix-3.0-M2-incubating into eclipse.

1.) I downloaded the src distribution and unpacked it into the binary
distribution's top folder
2.) I executed mvn eclipse:eclipse. Here maven complained, that it could not
find the jbi-maven-plugin artifact. I changed this into maven-jbi-plugin in
the pom.xml, which seemed to work much better.
3.) Maven then downloaded dependencies for quite a while
4.) now it complains about a missing jbi-component with the following
message:

[INFO] Building ServiceMix :: HTTP
[INFO]task-segment: [eclipse:eclipse]
[INFO]

[INFO] Preparing eclipse:eclipse
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Cannot find lifecycle mapping for packaging: 'jbi-component'. 
Component descriptor cannot be found in the component repository:
org.apache.maven.lifecycle.mapping.LifecycleMappingjbi-component.

What am I doing wrong?

Thx,
Martin


-- 
View this message in context: 
http://www.nabble.com/Importing-Servicemix-3.0-M2-into-eclipse%3A-Build-error-tf2233247.html#a6190620
Sent from the ServiceMix - Dev forum at Nabble.com.

Re: JIRA's under Patch Avaliable

Only those JIRA's that are submitted as Improvement have this option
of initiating RTC Review after which they appear under Patch
Available. All other JIRA's with or without patch will not
showup under Patch Available. Looks like the search filter for
Patch Available has problems.

VamsiOn 9/7/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
Hi Kevan,

Seems like the JIRA's will be listed under Patch Available only after initiating RTC.

Thanks,
VamsiOn 9/7/06, Kevan Miller 
[EMAIL PROTECTED] wrote:

On Sep 7, 2006, at 7:41 AM, Vamsavardhana Reddy wrote: I have uploaded patches for some JIRA's and also checked Patch Available option.But, I do not see these JIRA's listed under
 Patch Available.What am I missing?
Hi Vamsi,Are you the Assignee of the Jira's? I think you need to edit theJira and assign the Jira's to Unassigned.IIUC, the script that generates the email assumes that assigned
jira's are being worked on by somebody...--kevan

Re: [VOTE] 1.1.1-rc2 Release

2006-09-07 Thread Kevan Miller



On Sep 7, 2006, at 9:19 AM, Jan Bartel wrote:

First, I apologise but my newsreader can't find the initial email  
in this

thread, so I'm just replying to the first one I can find.

I've downloaded and tried geronimo-jetty-j2ee-1.1.1-rc2.tar.gz. I  
simply
followed the instructions in the RELEASE_NOTES. I can't get the  
console webapp to deploy. The log looks like jetty is missing a  
component and therefore not starting.


Hi Jan,
The minimal servers don't contain a console webapp. The RELEASE_NOTES  
should be updated to reflect this...


The DEBUG entries are misleading. Geronimo doesn't generate started  
log entries that would correspond to the waiting to start log  
entries. Certainly something to think about. We probably shouldn't be  
generating these DEBUG log entries at all...


The lack of any INFO log entries is a problem, also, IMO. There  
should be server starting and server started messages. Would  
prefer to address these issues in a future release...


--kevan

Re: [VOTE] 1.1.1-rc2 Release

2006-09-07 Thread Jan Bartel

Kevan, 
I've downloaded and tried geronimo-jetty-j2ee-1.1.1-rc2.tar.gz. 

Drat. Cut and paste error. Make that geronimo-jetty-minimal-1.1.1-rc2.tar.gz

The minimal servers don't contain a console webapp. The RELEASE_NOTES  
should be updated to reflect this...

Agreed.

The DEBUG entries are misleading. Geronimo doesn't generate started  
log entries that would correspond to the waiting to start log  
entries. Certainly something to think about. We probably shouldn't be  
generating these DEBUG log entries at all...

Agreed.

The lack of any INFO log entries is a problem, also, IMO. There  should 
be server starting and server started messages. Would  prefer to 
address these issues in a future release...

Agreed.

thanks
Jan

Re: Release Early, Release Often

2006-09-07 Thread Matt Hogstrom

I think Dain said he was scouring the primordial soup of trunk to determine which level of life form
would emerge. At this point if its a single cell organism then a .2 release might seem
inappropriate. If its an intergalactic space traveler that can cure cancer, solve world peace and
make a good pina colada then perhaps we should go to 3.0 :)

Dain, how are we doing with the data mining? Seem like the natives are getting
restless :-0

Dave Colasurdo wrote:

Here is the wikipedia definition for Pre-Alpha, Alpha, Beta, etc..

http://en.wikipedia.org/wiki/Alpha_release

The definitions pretty much agree with my preconception of what an Alpha
would contain.

IMHO, trunk is not currently in an Alpha state and doesn't accurately
reflect the majority of the software requirements that will be
addressed in G1.2.

It seems that trunk is currently in a pre-alpha state and I believe
making an occasional unstable/nightly build available would allow
users/developers to get familiar with the latest and greatest functions
in trunk without giving the false impression that G1.2 is currently in
Alpha state.

Just my .02

-Dave-

Jason Dillon wrote:
I am thinking about an 1.2-alpha release, which does not need to pass
any tck, but can still be downloaded by folks that want to test their
apps on the bleeding edge (with out having to build). While there is
nothing major from a J2EE perspective in the alpha, a lot has changed,
or will change very shortly. Here is a list with comments of new and
upcoming stuff:

ActiveMQ 4.1, is about to get committed.

Derby is about to get upgraded.

Log4j is about to get upgraded.

Use of concurrent util is about to get changed to
backport-concurrent-util.

Lets not forget that we changed the build system, which mostly impacts
development, but also has an impact on the configuration files, and
plugins... new CAR m2 plugin. I think it would be really good to get
an alpha out so that people can easily test and provide feedback.

New m2 plugin to start/stop Geronimo, soon to have new deploy goals.

A bunch of bug fixes.

* * *

I think that by releasing a 1.2-alpha, that we also start down the
path of changing the perception of how quickly we release. The alpha
can also serve to help us get some experience using the m2 release
plugin so that when it comes time for a non-alpha/beta release that we
have confidence in the procedure... and this will give us time to make
sure that we have the right configurations and setup to make a release
with relative ease.

Also, more of a side effect, by making a new release, it helps control
the JIRA roadmap, right now 1.2 is filled with a bunch of build system
related fluff and other bits...

I think that we have enough changes (or soon to change in the next
days or so) to warrant an alpha. I don't see any reason why not to...
we don't need to spend days/weeks to ensure the TCK passes, because we
don't need to run it. It should be sufficient to vote on an alpha and
then cut the release, which should be easy with the maven release
plugin, and even easier with my gpg-sign'ing mojo to sign and upload
all artifacts.

I believe that having this alpha out will benefit our community,
showing that we are going to start releasing more often, give people a
chance to provide feedback more often an earlier.

I certainly do not expect any production customers to use this, but I
do expect that app developers will, so they can ready their apps for
deployment on the platform. We will clearly label this as an alpha
release, and clear state that it has not been TCK certified.

I don't see any downside to cutting a release off of trunk soonish, in
the next week or so.

--jason

On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:

On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:

According to our STATUS file, our last feature release (1.1) was on
2006-06-26 which is about 2.5 months ago. I'm not sure exactly what
we have in trunk right now, but I'd guess we most likely have enough
to do a release right now. I'm going to spend a few hours today
browsing the JIRAs and SVN logs and compile a list of the features
we have in trunk right now. Anyways, I'll let you know what I find
and we can figure out what we want to do.

I'd be interested to hear more concretely what's in Geronimo trunk,
OpenEJB 2.2, etc that's not in 1.1.1...

--kevan

RE: Transaction isolation level in TranQL

2006-09-07 Thread Udovichenko, Nellya

Oh, it's clear now. Thank you very much for your answer!

Waiting for the next release impatiently. :)

Nellya.
-Original Message-
From: Matt Hogstrom [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 06, 2006 9:10 PM
To: dev@geronimo.apache.org
Subject: Re: Transaction isolation level in TranQL

I was planning on some changes to TranQL for CMP support but didn't get
them completed on time.  I 
thought it would be unfair to hold up the release because of my
delinquency so I regressed to 1.3. 
The changes should be in 1.1.2 or 1.2.

Udovichenko, Nellya wrote:
 Hello, Matt!

 I have downloaded Geronimo-1.1.1-rc2 and see TranQL version is 1.3
there instead of 1.3.1 

 I expected.

 Kevan Miller wrote that's due to there haven't been any changes to
TranQL since 1.3 

 (see topic TranQL version in Geronimo-1.1.1-rc1 yesterday).

 Does it mean the support for transaction isolation level setting would
only be 

 available in TranQL 1.4?

 Nellya.

 -Original Message-

 From: Matt Hogstrom [mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] ] 

 Sent: Monday, July 17, 2006 9:41 PM

 To: dev@geronimo.apache.org

 Subject: Re: Transaction isolation level in TranQL

 Vasily,

 It is already part of TranQL.  What we need is a change to OpenEJB to
allow the specification of 

 Isolation Level so TranQL can generate the right code.  Let me start a
new thread to see if we can 

 get this in 1.1.1.

 Matt

 Zakharov, Vasily M wrote:

 Hi, Matt,

 What are the perspectives of having the capability to specify the

 transaction isolation level in TranQL?

 I'm awaiting this feature eagerly, as it looks like a key to a

 successful SPECjAppServer2004 run...

 Recently you said

 (http://www.mail-archive.com/user@geronimo.apache.org/msg03421.html
http://www.mail-archive.com/user@geronimo.apache.org/msg03421.html )

 that this feature may be a part of TranQL 1.3.1, which is gonna be a

 part of Geronimo 1.1.1, as far as I understand. Am I right?

 Thank you!

 Vasily Zakharov

 Intel Middleware Products Division

Re: Importing Servicemix-3.0-M2 into eclipse: Build error

2006-09-07 Thread mwhs


I finally suceeded in building servicemix for eclipse using following steps:

mvn -N install 
cd tooling 
mvn -Dmaven.test.skip=true install 
cd .. 
mvn eclipse:eclipse 

Thx,
Martin


mwhs wrote:
 
 Hello,
 
 I am trying to import servicemix-3.0-M2-incubating into eclipse.
 
 1.) I downloaded the src distribution and unpacked it into the binary
 distribution's top folder
 2.) I executed mvn eclipse:eclipse. Here maven complained, that it could
 not find the jbi-maven-plugin artifact. I changed this into
 maven-jbi-plugin in the pom.xml, which seemed to work much better.
 3.) Maven then downloaded dependencies for quite a while
 4.) now it complains about a missing jbi-component with the following
 message:
 
 [INFO] Building ServiceMix :: HTTP
 [INFO]task-segment: [eclipse:eclipse]
 [INFO]
 
 [INFO] Preparing eclipse:eclipse
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Cannot find lifecycle mapping for packaging: 'jbi-component'. 
 Component descriptor cannot be found in the component repository:
 org.apache.maven.lifecycle.mapping.LifecycleMappingjbi-component.
 
 What am I doing wrong?
 
 Thx,
 Martin
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Importing-Servicemix-3.0-M2-into-eclipse%3A-Build-error-tf2233247.html#a6191676
Sent from the ServiceMix - Dev forum at Nabble.com.

components configuration

2006-09-07 Thread emicalc


Hello,
I'm using servicemix under tomcat; at this moment I have used components
(lightweight components) only configuring the applicationContext.xml under
the folder \webapps\servicemix\WEB-INF.
Now I want to know if it's possible that a component calls another component
(lightweight or not) dependently from the message that the component has
received. 
For example the component A send a message to the component B; the content
of the message is an integer; if this value is more than 100 the component B
should send a message to the component C, if the value is less than 100 the
component B should send a message to the component D.
I don't Know if this is possible with the applicationContext.xml.
Can someone help me?
Thank you,
Emilio

-- 
View this message in context: 
http://www.nabble.com/components-configuration-tf2233598.html#a6191813
Sent from the ServiceMix - Dev forum at Nabble.com.

[jira] Created: (GERONIMO-2385) server does not update any state when persistent configuration is loaded and ready to serve applications

2006-09-07 Thread Bill Dudney (JIRA)

server does not update any state when persistent configuration is loaded and 
ready to serve applications


 Key: GERONIMO-2385
 URL: http://issues.apache.org/jira/browse/GERONIMO-2385
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Reporter: Bill Dudney


see this thread

http://www.nabble.com/When-has-the-server-started--tf2205476.html

for reference

-- 
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-2385) server does not update any state when persistent configuration is loaded and ready to serve applications

2006-09-07 Thread Bill Dudney (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2385?page=all ]

Bill Dudney updated GERONIMO-2385:
--

Affects Version/s: 1.2

 server does not update any state when persistent configuration is loaded and 
 ready to serve applications
 

 Key: GERONIMO-2385
 URL: http://issues.apache.org/jira/browse/GERONIMO-2385
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Affects Versions: 1.2
Reporter: Bill Dudney

 see this thread
 http://www.nabble.com/When-has-the-server-started--tf2205476.html
 for reference

-- 
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-2386) Cleanup debug log entries created during server startup

2006-09-07 Thread Kevan Miller (JIRA)

Cleanup debug log entries created during server startup
---

 Key: GERONIMO-2386
 URL: http://issues.apache.org/jira/browse/GERONIMO-2386
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Logging
Affects Versions: 1.1.1, 1.1.2, 1.2
Reporter: Kevan Miller
Priority: Trivial
 Fix For: 1.1.2, 1.2


Multiple debug log entries are generated during server startup in the following 
form:

09:32:57,220 DEBUG [GBeanSingleReference] Waiting to start 
geronimo/jetty/1.1.1-rc2/car?ServiceModule=geronimo/jetty/1.1.1-rc2/car,j2eeType=GBean,name=JettyAJP13Connector
 because no targets are running for reference JettyContainer matching the 
patterns 
geronimo/jetty/1.1.1-rc2/car?ServiceModule=geronimo/jetty/1.1.1-rc2/car,j2eeType=GBean,name=JettyWebContainer

Seems like these debug messages should be turned off by default. Would also be 
nice if there were corresponding Started debug log entries.

-- 
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: When has the server started?

2006-09-07 Thread Bill Dudney


Hi All,

I have submitted a JIRA and patch to provide this GBean.

http://issues.apache.org/jira/browse/GERONIMO-2385

feedback as always welcome...

TTFN,

-bd-

On Sep 4, 2006, at 3:06 PM, David Jencks wrote:



On Sep 4, 2006, at 4:54 PM, Jason Dillon wrote:


On Sep 4, 2006, at 1:39 PM, David Jencks wrote:
IMO this would be a perversion of the geronimo architecture.   
What does fully started mean anyway?  If you start with say  
geronimo-jetty-minimal and add cars to turn it into a full j2ee  
server while it is running, when exactly is it started?  It  
certainly has nothing to do with the kernel.


When we thought about this last the best idea we could come up  
with is that it's fully started when all the modules listed in  
persistent configuration lists (should be persistent module  
lists) that are in the bootstrap or included recursively in those  
modules are started. Think about what happens if a module in the  
original PCL includes another PCL.


Started (or fully started) means that the server has loaded,  
initialized and started all modules in the persistent  
configuration, such that it could then start to serve  
applications... and start listening on ports, etc.  True there  
might be more modules to be loaded or configured after that, but  
the point is to tell when the server is ready to start accepting  
work.  There is a period while the server is starting, when it  
starts listening to http, but it is not ready to serve  
applications which have been configured to be deployed.

ya- that's a bug :-(


Anyways, I don't care too much what it is called... but I think  
that flag should be exposed as a simple Boolean on some common MBean.


That's a great idea!

Maybe its not the Kernel, as the kernel might be started, but the  
system might not be ready to serve my webapps or whatever.  Having  
to pull in geronimo-kernel to perform a simple remote call to  
fetch a boolean is overkill... especially since that module has  
magical logging fluff that rudely overwrites configuration.


If we had a specialized MBean/GBean that just exposed the very  
common remote functionality via JMX directly then we would be in a  
very good position to keep tools (IDE plugins, maven plugins, etc)  
working even after we change the internals around.  Such tools  
need an easy way to:


 * Detect when the server is started and ready to server applications
 * Shutdown

Probably some other things too...


yup

thanks
david jencks



--jason

[jira] Commented: (GERONIMO-2385) server does not update any state when persistent configuration is loaded and ready to serve applications

2006-09-07 Thread Vamsavardhana Reddy (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2385?page=comments#action_12433146
 ] 

Vamsavardhana Reddy commented on GERONIMO-2385:
---

Should the shutdown process start with setting the serverStarted attribute to 
false?  Or should we introduce a serverShuttingDown attribute??

 server does not update any state when persistent configuration is loaded and 
 ready to serve applications
 

 Key: GERONIMO-2385
 URL: http://issues.apache.org/jira/browse/GERONIMO-2385
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Affects Versions: 1.2
Reporter: Bill Dudney
 Attachments: GERONIMO-2385.bdudney.patch


 see this thread
 http://www.nabble.com/When-has-the-server-started--tf2205476.html
 for reference

-- 
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-2385) server does not update any state when persistent configuration is loaded and ready to serve applications

2006-09-07 Thread Bill Dudney (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2385?page=comments#action_12433148
 ] 

Bill Dudney commented on GERONIMO-2385:
---

good point, probably at the beginning of the server shutdown process it should 
switch to false

 server does not update any state when persistent configuration is loaded and 
 ready to serve applications
 

 Key: GERONIMO-2385
 URL: http://issues.apache.org/jira/browse/GERONIMO-2385
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Affects Versions: 1.2
Reporter: Bill Dudney
 Attachments: GERONIMO-2385.bdudney.patch


 see this thread
 http://www.nabble.com/When-has-the-server-started--tf2205476.html
 for reference

-- 
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-2387) Server life cycle log entries should be generated by the server

2006-09-07 Thread Kevan Miller (JIRA)

Server life cycle log entries should be generated by the server
---

 Key: GERONIMO-2387
 URL: http://issues.apache.org/jira/browse/GERONIMO-2387
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
Reporter: Kevan Miller
 Fix For: 1.1.2, 1.2


By default, geronimo should generate life cycle log entries. For example:

1) starting with environmental information
2) started
3) stopping

-- 
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-855) Add support for prefetchSize = 0

 [ https://issues.apache.org/activemq/browse/AMQ-855?page=all ]

Hiram Chirino resolved AMQ-855.
---

Resolution: Fixed

no further feedback.. assuming issue is now resolved.

 Add support for prefetchSize = 0
 

 Key: AMQ-855
 URL: https://issues.apache.org/activemq/browse/AMQ-855
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 4.0, 4.0.1, 4.0.2
 Environment: any
Reporter: Vadim Pesochinskiy
 Assigned To: Hiram Chirino
Priority: Critical
 Fix For: 4.1

 Attachments: ActiveMQMessageConsumer.patch, 
 ActiveMQMessageConsumer.patch2, PrefetchSubscription.patch, 
 region.QueueSubscription.java.patch, ZeroPrefetchConsumerTest.java.patch


 This feature would enable to support following test case:
 2 servers are processing 3 submitted jobs with following processing times 10 
 min, 1 min, 1 min. This sequence should finish in 10 minutes as one service 
 will pick up the 10 minutes job, meanwhile the other one should manage the 
 two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute 
 jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes 
 instead of 10.
 This is simplification of the real scenario where I have about 30 consumers 
 submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems:
  Messages are sitting in prefetch buffer are not available to processors, 
 which results in a lot of idle time.
  Order of processing is random. For some reason Job # 20 is processed after 
 Job # 1500. Since senders are synchronously blocked this can result in 
 time-outs.
  Some requests are real-time, i.e. there is a user waiting, so the system 
 cannot wait, so AMQ-850 does not fix this issue.

-- 
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] Resolved: (AMQ-887) Allow temp destination message bridging to be disable across demand based bridges.

 [ https://issues.apache.org/activemq/browse/AMQ-887?page=all ]

Hiram Chirino resolved AMQ-887.
---

Resolution: Fixed

Fixed in trunk rev 433673

 Allow temp destination message bridging to be disable across demand based 
 bridges.
 --

 Key: AMQ-887
 URL: https://issues.apache.org/activemq/browse/AMQ-887
 Project: ActiveMQ
  Issue Type: New Feature
Reporter: Hiram Chirino
 Assigned To: Hiram Chirino
 Fix For: 4.1




-- 
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: (AMQ-888) Licence headers missing from several source files.

 [ https://issues.apache.org/activemq/browse/AMQ-888?page=all ]

Hiram Chirino reassigned AMQ-888:
-

Assignee: james strachan  (was: Hiram Chirino)

Just a few more unaccounted files remain in the web modules..  assining to 
james to see if he can look into these.

 Licence headers missing from several source files.
 --

 Key: AMQ-888
 URL: https://issues.apache.org/activemq/browse/AMQ-888
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Hiram Chirino
 Assigned To: james strachan
 Fix For: 4.1, 4.0.2

 Attachments: findunlicensed.pl


 robert burrell donkin reported:
 {quote}
 missing license headers from some of the files i checked at random
 gives me concerns. for example:
 maven-bundle-plugin/src/main/java/org/apache/activemq/maven/BundleMojo.java
 activemq-web-demo worries me: there are a lot of files without license
 headers and some which have them were not created at the ASF (which is
 ok but gives me concerns about the rest).
 i would like to see the issue of licenses in the source tidied up
 before this release ships. i haven't gone through every file but IMO
 this needs to be done.
 {quote}

-- 
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] Resolved: (AMQ-907) Make the ActiveIO dependency and optional dependency.

 [ https://issues.apache.org/activemq/browse/AMQ-907?page=all ]

Hiram Chirino resolved AMQ-907.
---

Resolution: Fixed

done..

 Make the ActiveIO dependency and optional dependency.
 -

 Key: AMQ-907
 URL: https://issues.apache.org/activemq/browse/AMQ-907
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Reporter: Hiram Chirino
 Assigned To: Hiram Chirino
 Fix For: 4.1


 Need to move some core classes that are in activeio to activemq
 so that it is not needed to run.  Right now the only real
 functionality that it provides that is optional is the journal
 implementation.
 Everything else that is use from activeio are just abstract interfaces, and I 
 think
 those need to be moved/copied to ActiveMQ.

-- 
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-914) OutOfMemoryError

2006-09-07 Thread Daniel Aioanei (JIRA)

[ 
https://issues.apache.org/activemq/browse/AMQ-914?page=comments#action_36921 ] 

Daniel Aioanei commented on AMQ-914:


After more investigation on this issue, I determined the exact moment when the 
memory consumption jumps abruptly in a simpler scenario. It happens when a 
consumer is created for the queue with 200k+ messages, that is the third line 
below:

con = connectionFactory.createConnection();
Session s = con.createSession(true, Session.CLIENT_ACKNOWLEDGE);
MessageConsumer messageConsumer = s.createConsumer(dest);

where connectionFactory is jmsConnectionFactory below:

!--
## Transaction manager ##
--

bean id=transactionContextManager
class=org.jencks.factory.TransactionContextManagerFactoryBean 
/


 bean id=transactionSupport 
class=org.jencks.factory.XATransactionFactoryBean
   property name=useTransactionCaching value=true /
   property name=useThreadCaching value=true /
 /bean
  
bean id=poolingSupport
class=org.jencks.factory.SinglePoolFactoryBean
property name=maxSize value=50 /
property name=minSize value=0 /
property name=blockingTimeoutMilliseconds value=0 /
property name=idleTimeoutMinutes value=60 /
property name=matchOne value=true /
property name=matchAll value=true /
property name=selectOneAssumeMatch value=true /
/bean

bean id=connectionManager
class=org.jencks.factory.ConnectionManagerFactoryBean

property name=transactionSupport ref=transactionSupport /
property name=poolingSupport ref=poolingSupport /
/bean

!--
## JMS ##
--

bean id=jmsResourceAdapter
class=org.apache.activemq.ra.ActiveMQResourceAdapter
property name=serverUrl 
value=tcp://localhost:61616?wireFormat.cacheEnabled=falseamp;wireFormat.tightEncodingEnabled=falseamp;jms.useAsyncSend=true
 /
/bean

bean id=jmsManagedConnectionFactory
class=org.apache.activemq.ra.ActiveMQManagedConnectionFactory
property name=resourceAdapter ref=jmsResourceAdapter /
/bean

bean id=jmsConnectionFactory

class=org.springframework.jca.support.LocalConnectionFactoryBean
property name=managedConnectionFactory
ref=jmsManagedConnectionFactory /
property name=connectionManager ref=connectionManager /
/bean

Please see the attached snapshot of the jmx console connected to activemq.


 OutOfMemoryError
 

 Key: AMQ-914
 URL: https://issues.apache.org/activemq/browse/AMQ-914
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0.1
Reporter: Daniel Aioanei
 Attachments: activemq.xml


 I was doing some testing with a single MDP listening to a queue which had 
 about 247300 messages, with a postgres backend. ActiveMQ server was started 
 using the default activemq startup script (on Linux). In this configuration 
 the cpu normally stays mostly idle and I described this behaviour in another 
 bug report.
 Another issue came to surface when I tried to profile the client application 
 with EclipseColorer to see why a single MDP can't hog my machine. But when I 
 tried so, 4 OutOfMemoryError messages were logged by ActiveMQ server. Note 
 that I was *not* profiling the server, but the client which is a totally 
 different process.

-- 
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] Created: (AMQ-915) Failover transport does not replay all the transaction operations on failover.

Failover transport does not replay all the transaction operations on failover.
--

 Key: AMQ-915
 URL: https://issues.apache.org/activemq/browse/AMQ-915
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Hiram Chirino
 Assigned To: Hiram Chirino
 Fix For: 4.1


If transactions are being used on a connection that is using failover.. these 
is a small chance that the transaction will fail or the connection will fail 
due to a partial tx being run when the client reconnects.

I will change the failover transport to buffer up all the tx operations that 
are run against the broker and on failure, replay those operations.

-- 
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: Adding items to NameFactory

2006-09-07 Thread David Jencks



On Sep 7, 2006, at 6:49 AM, Rick McGuire wrote:

I'm going to be adding several new GBean types to openejb for ORB  
configuration as part of the Yoko work.  Each of these new GBeans  
is defined with a j2ee type to be consistent with the other openejb  
CORBA GBeans.  Right now, I'm using hard coded strings, but adding  
these types to NameFactory represents an interesting bootstrapping  
problem.  It appears I need to add these to a build first, build  
and publish that build to my repository, then build my openejb code  
that uses the new NameFactory entries, then build my Geronimo code  
that dependent on the new openejb version (ugh).


yup, ain't life fun.

I recommend copying your openejb checkout into thirdparty/openejb2  
and adding this profile to your root g. pom:


profile
idall/id

modules
moduletestsupport/module
modulemodules/module
modulethirdparty/openejb2/modules/module
modulemaven-plugins/module
moduleapplications/module
moduleconfigs/module
moduleassemblies/module
/modules
/profile


Then you can build g + o in one go with mvn -o clean install -Pall

jason, what would you think of adding this into the actual checked-in  
pom?




Is this assumption correct?  Can I go and add the new NameFactory  
entries now in anticipation of my future need so I can avoid the  
bootstrapping problem?


yes and yes

thanks
david jencks



Rick

Re: When has the server started?

2006-09-07 Thread David Jencks



On Sep 7, 2006, at 9:44 AM, Bill Dudney wrote:


Hi Jason,

I had some time to dig into this a bit and it looks to me like  
anything that does not belong to a particular J2EE app ends up here.


i.e.

MBean Name == geronimo:J2EEApplication=null,J2EEServer-geronimo,...

is common to all. Looks to me like the deployables in the config  
that don't have a J2EEApplication specified get null and thus the  
weird null entry. Changing that to something else would probably be  
tedious...


IIRC J2EEApplication=null is specified and required by jsr-77 for  
stuff from J2EE apps that aren't in an ear (standalone app clients,  
web apps, connectors, ejbs).


If it's in an ear, J2EEApplication=ear-name in some form

thanks
david jencks



TTFN,

-bd-

On Sep 3, 2006, at 6:54 AM, Jason Dillon wrote:

Somewhat related... I mentioned this before, but jconsole shows a  
weird null element in the tree... any idea why?


--jason

jconsole.tiff


On Sep 3, 2006, at 5:34 AM, Aaron Mulder wrote:

I think kernelFullyStarted is a GBean attribute on only certain  
types

of GBeans -- I believe PersistentConfigurationList GBeans.  It's set
by Daemon.java when the startup process is complete, so it's not a
kernel-level feature, but should still work for all practical
purposes.  I would think you'd be able to get the property from the
LocalAttributeManager via JMX.

Thanks,
Aaron

On 9/1/06, Jason Dillon [EMAIL PROTECTED] wrote:
What is the best way to detect when the server has started using  
JMX?


The ServerBehavior class in the deployment plugin has some code  
that

connects to JMX, then lists the configurations, and then takes he
first configuration and get the kernelFulltStarted attribute from
it... but it assumes that ConfigurationManager.listConfigurations()
returns an array of ObjectNames, which it does not.

I also peeked at the server's JMX tree via jconsole and I don't see
any attribute or operation that matches up to kernelFullyStarted.
There is also a strange null element of the tree, but I will  
leave

that for another day.

So, how can I easily check of the server has started by polling  
a JMX

attribute?

--jason

[jira] Commented: (GERONIMO-2332) RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all

2006-09-07 Thread David Jencks (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12433164
 ] 

David Jencks commented on GERONIMO-2332:


I believe that the work in this patch has actually been applied to all branches 
and trunk. anyone want to vote on it or should we just consider it rejected 
now that it's been applied :-) ?

 RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a 
 spec module so we don't need the schemas in svn at all
 

 Key: GERONIMO-2332
 URL: http://issues.apache.org/jira/browse/GERONIMO-2332
 Project: Geronimo
  Issue Type: RTC
  Security Level: public(Regular issues) 
  Components: specs
Affects Versions: 1.1.1, 1.1.2, 1.2
Reporter: David Jencks
 Assigned To: David Jencks
 Fix For: 1.1.1, 1.1.2, 1.2

 Attachments: GERONIMO-2332-1.1-openejb-v2.patch, 
 GERONIMO-2332-1.1-v2.patch, GERONIMO-2332-1.1.patch, 
 GERONIMO-2332-openejb-2.1.patch, GERONIMO-2332-trunk-v2.patch, 
 GERONIMO-2332-trunk.patch, geronimo-schema_1.4_spec-generated-src.zip, 
 geronimo-schema_1.4_spec-src.zip


 See GERONIMO-2307.  It seems that the option with the least legal exposure is 
 to not distribute and sun schema files and not have any in our svn.  This is 
 a proposed spec module that uses a m2 profile to pull the schemas from suns 
 website (where they are freely available), run xmlbeans on them, and remove 
 the copies of the schemas that xmlbeasn helpfully tries to include in the 
 output.  We can then check this stuff into svn.
 A normal non-profile build then just builds these sources into a jar.  We can 
 replace the xmlbeans step in j2ee-schema with a geronimo dependency on this 
 new spec jar.

-- 
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: [SUMMARY] Proposed Geronimo Development Processes

2006-09-07 Thread Kevan Miller


Thanks Matt and Jason.

I'll update the proposals to remove the PMC requirement from Relaxed  
RTC.


I'm also going to update to make clear that the focus of this vote is  
trunk development. Initially, it would apply to branches, also. If we  
feel that branches need special controls, we should handle by  
refining our general process. I don't wan't to get hung up fixing  
*everything*...


Any other comments?

More inline...

On Sep 6, 2006, at 7:27 PM, Jason Dillon wrote:


Thanks Kevan for the summary, I think this really helps.

More comments below inline...

On Sep 6, 2006, at 1:34 PM, Kevan Miller wrote:

1. Relaxed RTC

...

* 3 +1 votes from committers on the project (1 of these committers  
needs to be a member of the PMC) with no outstanding -1 votes.


I don't think that we need a requirement of a PMC vote here.  The  
PMC can provide enough oversight w/o a required vote.  IMO, a vote  
is a vote is a vote... I don't put any weight over a committers  
vote to a PMC members vote.  I value them both equally.  Forcing a  
PMC vote here is artificial and promotes separatism rather than unity.


Totally agree. I almost made that change, but was consciously trying  
*not* to edit the proposals as I pulled them out of the various  
discussion threads.






2. RTC with Lazy Consensus

Geronimo follows a Review-Then-Commit model with Lazy consensus.  
Patches for new function are provided by developers for review and  
comment by their peers. Feedback is conducted through JIRA  
comments. The goal of this interaction is to solicit suggestions  
from the community and incorporate their feedback as appropriate.  
A patch is accepted if:


* 3 +1 votes from committers on the project with no outstanding -1  
votes and no significant, ongoing discussion


* 72 hours pass with no outstanding -1 votes and no significant,  
ongoing discussion. A 24 hour warning should be sent to the dev list.


For the most part I like this model... but only for non-trivial  
changes, see below.


It's not bad and I think we can operate quite reasonably using this.  
However, I don't think it's necessary. I'd prefer to see the benefits  
of this approach handled by more up-front communication using CTR. By  
the time something is committed, it's not much of a surprise...






3. CTR with documentation guidelines

Geronimo follows a Commit-Then-Review model. There should be an  
emphasis of community communication. Community-based policing and  
persuasion will be used to remedy any problem areas. Guidelines  
are not strict dogma -- common sense should prevail. Community  
communication is the key, not a process. General guidelines are:


* Non-trivial changes (and certainly potentially controversial  
changes) should be announced on the dev list. This announcement  
should be well in advance of the change being committed. The  
community should be given the opportunity to understand and  
discuss the proposal.


* Concurrent with the commit of a significant change, the  
committer should document the change on the dev list. You should  
describe what you are doing, describe why you are doing it, and  
provide an overview of how you implemented it.


This feels a whole lot like common-sense for how to participate on  
an open-source project.  In most cases, I think this is also the  
best model to run under... though I do believe that RTC has some  
merit as well.


If it was up to me (which it isn't, but here is my opinion  
anyways), I would use a hybrid model, which would default to CTR  
(with emphasis on common sense and communication) and for non- 
trivial or potentially controversial changes follow the RTC with  
Lazy Consensus as described in #2 (with the addition of inclusion  
of development branches or patches, depending on the complexity).   
I actually think that this is common-sense too.


IMO... this is the best of both worlds, without being too  
overbearing on policy and process, leveraging the trust of the  
developers and fostering our community with sufficient oversight  
and freedom to allow real progress to be achieved.


I think RTC w/ lazy consensus is always available under a CTR model.  
However, I'd prefer it be self-imposed rather than expected. I  
wouldn't be upset if someone didn't follow RTC for a significant  
change. I would be upset if they failed to adequately communicate and  
discuss with the community...




 * * *

But Jason... how do I know what is non-trivial or controversial?


Jason, Perhaps it's time for a little holiday...  ;-)

--kevan

[jira] Commented: (GERONIMO-2354) Replace concurrent with backport-concurrent-util

2006-09-07 Thread David Jencks (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2354?page=comments#action_12433170
 ] 

David Jencks commented on GERONIMO-2354:


+1 I finally got time online to compile this patch :-)

I think the changes you've made to the thread pools/executors are fine.

IIRC I put the waiting list in because the tasks are generally started from a 
timer.  If we use the timer thread to execute tasks when the server is under 
heavy load I think we might get into trouble.

 Replace concurrent with backport-concurrent-util
 

 Key: GERONIMO-2354
 URL: http://issues.apache.org/jira/browse/GERONIMO-2354
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Affects Versions: 1.2
Reporter: Jason Dillon
 Attachments: GERONIMO-2354-openejb2.diff, 
 GERONIMO-2354-openejb2.diff, GERONIMO-2354.diff, GERONIMO-2354.diff


 Replace usage of concurrent classes with backport-concurrent-util.  
 Preparation for using java.util.concurrent in JDK 1.5, and reduce the need 
 for 2 sets of concurrent classes on the boot classloader.
 Sill need to include concurrent, as activeio and openejb still have some 
 dependencies upon it... but this brings us a step closer to not needing both.

-- 
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: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml

2006-09-07 Thread David Jencks

I think that the current bootstrap behavior is necessary for the  
reasons jason has stated however I think it should be named something  
else so people who just want to build g. won't be tempted to use it  
-- like

advanced-ultra-clean-build

or

bootstrap-with-new-mvn-repo

I would really like a convenient way to compile g + openejb together  
as we had with the m1 build.  I still find most of my changes affect  
both projects :-.  Jason, can you come up with a good way to do  
this?  I don't really understand your suggestion well enough to  
implement it.


thanks
david jencks



On Sep 1, 2006, at 3:54 PM, Jason Dillon wrote:


I give up trying to explain... do as you please.

--jason


On Sep 1, 2006, at 12:48 PM, anita kulshreshtha wrote:


inline..

--- Jason Dillon [EMAIL PROTECTED] wrote:


On Sep 1, 2006, at 7:42 AM, anita kulshreshtha wrote:



Anita, why do you always bring this up when there is talk about
bootstrap?


 Because when people are using bootstrap, it is not very obvious what
is going on. It is much simpler to give the 3 URLs and a simple build
command mvn. If there are build/test failures, they can look at the
default profile, and see what they are building. If for example the
openejb2 test failed, they could simply do

cd openejb2  and
mvn -Dmaven.test.skip=true

After this they can continue the build from the next step, i.e.
configs, etc.


I have explained over and over and over again that the
point of bootstrap is not to facilitate a normal build but to ensure


People only care about the normal build.



that the build works from a known state (ie. clean, fresh specs,  
from


openejb2).  Your method does not provide this level of assurance.  I


You have not given any concrete example/scenario in which my build
method does not work.



created this script because people had problems checking things out
in the right place,


Is this the main reason?


cleaning the right bits and running the right mvn


  Could you be more precise?



commands to perform the build steps that were needed to help ensure
that most everyone (except for some folks with whacky windows
machines) can make a reliable build near 100% of the time.

I'm really kinda getting tired of having to re-explain this.



To build geronimo with openejb2 add openejb2 to the default profile

in

the top level pom.xml as shown below:
   modules
modulemodules/module
modulemaven-plugins/module
moduleapplications/module
moduleopenejb2/module

---

moduleconfigs/module
moduleassemblies/module
/modules
and


No, no, no, no... no... no.  We had already talked about this weeks
ago.  Its fine that you want to build in this manner, but I am  
firmly


against putting a module into the main build that is for a directory

that the user must checkout by hand.


   I do not see any problems with that. Let us give people a  
choice by
putting these instructions on the wiki and they can decide if they  
want
to use bootstrap. BTW, it is in line with your philosophy about  
builds:

http://www.nabble.com/Re%3A-Unable-to-build-using-m2-p5074204.html





cd ..
mvn

   After the first time you can build from any directory.

Please give it a try and provide feedback, so that we can put
bootstrap to rest.


I don't have any problems with you, or anyone else making changes to

include openejb2 in their local workspace (I'd recommend putting  
that


into a profiles.xml next to the pom.xml though).  But I think that
your method is unacceptable for the project default.

Bootstrap is there for a reason... I am not crazy, I actually know
what I am doing.

At this point I believe that bootstrap is important and needs to
remain, until the items I previously listed are resolved.


   I am not asking you to remove the bootstrap, I want to give our
users a choice.

Thanks
Anita



--jason






__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[jira] Commented: (GERONIMO-2332) RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all

2006-09-07 Thread Matt Hogstrom (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12433172
 ] 

Matt Hogstrom commented on GERONIMO-2332:
-

I think this patch is complete and we can close it out :)  Do you want the 
honors David?

 RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a 
 spec module so we don't need the schemas in svn at all
 

 Key: GERONIMO-2332
 URL: http://issues.apache.org/jira/browse/GERONIMO-2332
 Project: Geronimo
  Issue Type: RTC
  Security Level: public(Regular issues) 
  Components: specs
Affects Versions: 1.1.1, 1.1.2, 1.2
Reporter: David Jencks
 Assigned To: David Jencks
 Fix For: 1.1.1, 1.1.2, 1.2

 Attachments: GERONIMO-2332-1.1-openejb-v2.patch, 
 GERONIMO-2332-1.1-v2.patch, GERONIMO-2332-1.1.patch, 
 GERONIMO-2332-openejb-2.1.patch, GERONIMO-2332-trunk-v2.patch, 
 GERONIMO-2332-trunk.patch, geronimo-schema_1.4_spec-generated-src.zip, 
 geronimo-schema_1.4_spec-src.zip


 See GERONIMO-2307.  It seems that the option with the least legal exposure is 
 to not distribute and sun schema files and not have any in our svn.  This is 
 a proposed spec module that uses a m2 profile to pull the schemas from suns 
 website (where they are freely available), run xmlbeans on them, and remove 
 the copies of the schemas that xmlbeasn helpfully tries to include in the 
 output.  We can then check this stuff into svn.
 A normal non-profile build then just builds these sources into a jar.  We can 
 replace the xmlbeans step in j2ee-schema with a geronimo dependency on this 
 new spec jar.

-- 
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: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml


On Sep 7, 2006, at 10:24 AM, David Jencks wrote:

I think that the current bootstrap behavior is necessary for the  
reasons jason has stated however I think it should be named  
something else so people who just want to build g. won't be tempted  
to use it -- like

advanced-ultra-clean-build

or

bootstrap-with-new-mvn-repo


Um, the default for bootstrap is that it will nuke your repo at the  
moment... its not the only thing that it does.  Dunno how many times  
I'm gonna have to say it before it starts to click.



I would really like a convenient way to compile g + openejb  
together as we had with the m1 build.  I still find most of my  
changes affect both projects :-.  Jason, can you come up with a  
good way to do this?  I don't really understand your suggestion  
well enough to implement it.


I think its kinda retarded that we have two split codebases here.   
Either decouple them or make them one... but keeping them split into  
two pieces is asking for pain.


Maybe now that OpenEJB is on its way to apache, then svn:externals  
can be used to pull the source into our tree.


--jason

Re: svn commit: r441162 - in /geronimo/server/trunk: ./ applications/console/geronimo-console-standard/ applications/console/geronimo-console-standard/src/main/java/org/apache/geronimo/console/jmsmana


Are you done with this?

Why is GERONIMO-2364 still open?

--jason


On Sep 7, 2006, at 11:09 AM, [EMAIL PROTECTED] wrote:


Author: chirino
Date: Thu Sep  7 11:09:36 2006
New Revision: 441162

URL: http://svn.apache.org/viewvc?view=revrev=441162
Log:
Applying patch GERONIMO-2364

Modified:
geronimo/server/trunk/applications/console/geronimo-console- 
standard/pom.xml
geronimo/server/trunk/applications/console/geronimo-console- 
standard/src/main/java/org/apache/geronimo/console/jmsmanager/ 
renderers/ViewDLQRenderer.java

geronimo/server/trunk/configs/activemq-broker/pom.xml
geronimo/server/trunk/configs/activemq-broker/src/plan/plan.xml
geronimo/server/trunk/configs/activemq/src/plan/plan.xml
geronimo/server/trunk/configs/webconsole-jetty/pom.xml
geronimo/server/trunk/configs/webconsole-tomcat/pom.xml
geronimo/server/trunk/modules/ge-activemq-rar/pom.xml
geronimo/server/trunk/modules/ge-activemq-rar/src/main/rar/META- 
INF/ra.xml

geronimo/server/trunk/modules/geronimo-activemq-gbean/pom.xml
geronimo/server/trunk/modules/geronimo-activemq-gbean/src/main/ 
java/org/apache/activemq/gbean/BrokerServiceGBeanImpl.java
geronimo/server/trunk/modules/geronimo-activemq-gbean/src/main/ 
java/org/apache/activemq/gbean/management/ActiveMQManagerGBean.java

geronimo/server/trunk/pom.xml

Modified: geronimo/server/trunk/applications/console/geronimo- 
console-standard/pom.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ 
applications/console/geronimo-console-standard/pom.xml? 
view=diffrev=441162r1=441161r2=441162
== 

--- geronimo/server/trunk/applications/console/geronimo-console- 
standard/pom.xml (original)
+++ geronimo/server/trunk/applications/console/geronimo-console- 
standard/pom.xml Thu Sep  7 11:09:36 2006

@@ -112,7 +112,7 @@
 !-- JMS dependencies --

 dependency
-groupIdactivemq/groupId
+groupIdorg.apache.activemq/groupId
 artifactIdactivemq-core/artifactId
 scopeprovided/scope
 /dependency

Modified: geronimo/server/trunk/applications/console/geronimo- 
console-standard/src/main/java/org/apache/geronimo/console/ 
jmsmanager/renderers/ViewDLQRenderer.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ 
applications/console/geronimo-console-standard/src/main/java/org/ 
apache/geronimo/console/jmsmanager/renderers/ViewDLQRenderer.java? 
view=diffrev=441162r1=441161r2=441162
== 

--- geronimo/server/trunk/applications/console/geronimo-console- 
standard/src/main/java/org/apache/geronimo/console/jmsmanager/ 
renderers/ViewDLQRenderer.java (original)
+++ geronimo/server/trunk/applications/console/geronimo-console- 
standard/src/main/java/org/apache/geronimo/console/jmsmanager/ 
renderers/ViewDLQRenderer.java Thu Sep  7 11:09:36 2006

@@ -34,7 +34,7 @@
 import javax.portlet.RenderRequest;
 import javax.portlet.RenderResponse;

-import org.activemq.service.DeadLetterPolicy;
+//import org.activemq.service.DeadLetterPolicy;
 import org.apache.geronimo.console.jmsmanager.AbstractJMSManager;
 import org.apache.geronimo.j2ee.j2eeobjectnames.NameFactory;
 import org.apache.geronimo.gbean.AbstractName;
@@ -59,6 +59,7 @@
 }

 public void setup(RenderRequest request, RenderResponse  
response) {

+   /*
 String destinationApplicationName = request
 .getParameter(destinationApplicationName);
 String destinationModuleName = request
@@ -108,6 +109,7 @@
 } catch (Exception e) {
 log.error(e.getMessage(), e);
 }
+*/
 }

 public List getDLQContents(QueueBrowser qb) {

Modified: geronimo/server/trunk/configs/activemq-broker/pom.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ 
activemq-broker/pom.xml?view=diffrev=441162r1=441161r2=441162
== 


--- geronimo/server/trunk/configs/activemq-broker/pom.xml (original)
+++ geronimo/server/trunk/configs/activemq-broker/pom.xml Thu Sep   
7 11:09:36 2006

@@ -43,40 +43,27 @@
 /dependency

 dependency
-groupIdactivemq/groupId
-artifactIdactivemq-core/artifactId
+groupIdorg.apache.geronimo.modules/groupId
+artifactIdgeronimo-activemq-gbean/artifactId
+version${pom.version}/version
+/dependency
+
+dependency
+groupIdorg.apache.geronimo.modules/groupId
+artifactIdgeronimo-activemq-gbean-management/ 
artifactId

+version${pom.version}/version
 /dependency

 dependency
-groupIdactivemq/groupId
-artifactIdactivemq-gbean-g1_1/artifactId
+groupIdorg.apache.activemq/groupId
+artifactIdactivemq-core/artifactId
 /dependency
-
+

Re: Release Early, Release Often


I agree.  Lets stop trying to feature box so much and try to time box
more.  I really don't have a problem if we get up to ver 1.14.0 in 12
months :)

If we don't release often then we can't tap our user community to help
us QA and provide feedback more often.

On 9/7/06, Jason Dillon [EMAIL PROTECTED] wrote:

Something tells me that we are gonna end up with a 6mo+ release cycle
(with additional month just to make the release)... and that if we
are lucky.

So far I'm not hearing anyone else signing the Release Early,
Release Often tune.

I'd stop thinking about 1.2 as JEE5 or whatever thing that is gonna
take a bunch of time to do... and just get some incremental work done
and push out a release.

--jason


On Sep 7, 2006, at 7:22 AM, Matt Hogstrom wrote:

 I think Dain said he was scouring the primordial soup of trunk to
 determine which level of life form would emerge.  At this point if
 its a single cell organism then a .2 release might seem
 inappropriate.  If its an intergalactic space traveler that can
 cure cancer, solve world peace and make a good pina colada then
 perhaps we should go to 3.0 :)

 Dain, how are we doing with the data mining?  Seem like the natives
 are getting restless :-0

 Dave Colasurdo wrote:
 Here is the wikipedia definition for Pre-Alpha, Alpha, Beta, etc..
 http://en.wikipedia.org/wiki/Alpha_release
 The definitions pretty much agree with my preconception of what an
 Alpha  would contain.
 IMHO, trunk is not currently in an Alpha state and doesn't
 accurately reflect the majority of the software requirements
 that will be addressed in G1.2.
 It seems that trunk is currently in a pre-alpha state and I
 believe making an occasional unstable/nightly build available
 would allow users/developers to get familiar with the latest and
 greatest functions in trunk without giving the false impression
 that G1.2 is currently in Alpha state.
 Just my .02
 -Dave-
 Jason Dillon wrote:
 I am thinking about an 1.2-alpha release, which does not need to
 pass any tck, but can still be downloaded by folks that want to
 test their apps on the bleeding edge (with out having to build).
 While there is nothing major from a J2EE perspective in the
 alpha, a lot has changed, or will change very shortly.  Here is a
 list with comments of new and upcoming stuff:

 ActiveMQ 4.1, is about to get committed.

 Derby is about to get upgraded.

 Log4j is about to get upgraded.

 Use of concurrent util is about to get changed to backport-
 concurrent-util.

 Lets not forget that we changed the build system, which mostly
 impacts development, but also has an impact on the configuration
 files, and plugins... new CAR m2 plugin.  I think it would be
 really good to get an alpha out so that people can easily test
 and provide feedback.

 New m2 plugin to start/stop Geronimo, soon to have new deploy goals.

 A bunch of bug fixes.

  * * *

 I think that by releasing a 1.2-alpha, that we also start down
 the path of changing the perception of how quickly we release.
 The alpha can also serve to help us get some experience using the
 m2 release plugin so that when it comes time for a non-alpha/beta
 release that we have confidence in the procedure... and this will
 give us time to make sure that we have the right configurations
 and setup to make a release with relative ease.

 Also, more of a side effect, by making a new release, it helps
 control the JIRA roadmap, right now 1.2 is filled with a bunch of
 build system related fluff and other bits...

 I think that we have enough changes (or soon to change in the
 next days or so) to warrant an alpha.  I don't see any reason why
 not to... we don't need to spend days/weeks to ensure the TCK
 passes, because we don't need to run it.  It should be sufficient
 to vote on an alpha and then cut the release, which should be
 easy with the maven release plugin, and even easier with my gpg-
 sign'ing mojo to sign and upload all artifacts.

 I believe that having this alpha out will benefit our community,
 showing that we are going to start releasing more often, give
 people a chance to provide feedback more often an earlier.

 I certainly do not expect any production customers to use this,
 but I do expect that app developers will, so they can ready their
 apps for deployment on the platform.  We will clearly label this
 as an alpha release, and clear state that it has not been TCK
 certified.

 I don't see any downside to cutting a release off of trunk
 soonish, in the next week or so.

 --jason


 On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:


 On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:

 According to our STATUS file, our last feature release (1.1)
 was on 2006-06-26 which is about 2.5 months ago.  I'm not sure
 exactly what we have in trunk right now, but I'd guess we most
 likely have enough to do a release right now.   I'm going to
 spend a few hours today browsing the JIRAs and SVN logs and
 compile a list of the features we have in trunk right now.

Re: Patches in RTC (Geronimo - 2006-09-07)


This list seems to just keep growing and growing.

Can we please get some PMC members to review and vote on these  
issues... some of them are trivial, but have been waiting for days to  
get some PMC love.


--jason


On Sep 7, 2006, at 8:12 AM, [EMAIL PROTECTED] wrote:


Geronimo - Thursday, September 7, 2006

  14 Patches in RTC

[GERONIMO-2382] Webservers portlet - Form field validation  
using javascript

  - Assignee: Unassigned
  - Reporter: Vamsavardhana Reddy
  - Created:  Tue Sep 05 10:28:15 PDT 2006
  - Updated:  Thu Sep 07 06:20:22 PDT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2382

[GERONIMO-2349] jta 1.1 support with container manager jpa  
support in transaction module

  - Assignee: David Jencks
  - Reporter: David Jencks
  - Created:  Wed Aug 23 13:22:37 PDT 2006
  - Updated:  Tue Sep 05 11:36:48 PDT 2006
  - Votes: 1
  1  David Blevins
  - http://issues.apache.org/jira/browse/GERONIMO-2349

[GERONIMO-2248] Applications portlets: List Parent and Child  
components against each component

  - Assignee: Unassigned
  - Reporter: Vamsavardhana Reddy
  - Created:  Sun Jul 30 08:15:34 PDT 2006
  - Updated:  Sat Aug 19 10:44:11 PDT 2006
  - Votes: 1
  1  Donald Woods
  - http://issues.apache.org/jira/browse/GERONIMO-2248

[GERONIMO-2354] Replace concurrent with backport-concurrent-util
  - Assignee: Unassigned
  - Reporter: Jason Dillon
  - Created:  Sun Aug 27 21:53:39 PDT 2006
  - Updated:  Wed Sep 06 00:16:28 PDT 2006
  - Votes: 2
  1  Dain Sundstrom
  2  Guillaume Nodet
  - http://issues.apache.org/jira/browse/GERONIMO-2354

[GERONIMO-2379] Security Realms portlet - form field validation  
using javascript

  - Assignee: Unassigned
  - Reporter: Vamsavardhana Reddy
  - Created:  Tue Sep 05 00:36:42 PDT 2006
  - Updated:  Thu Sep 07 06:24:19 PDT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2379

[GERONIMO-903] Update Log4J usage from 1.2.8 to latest  
maintenance version of 1.2.13

  - Assignee: Jason Dillon
  - Reporter: Donald Woods
  - Created:  Tue Aug 23 16:02:38 PDT 2005
  - Updated:  Thu Aug 31 23:13:51 PDT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-903

[GERONIMO-2381] DB Manager portlet - Form field validation  
using javascript

  - Assignee: Unassigned
  - Reporter: Vamsavardhana Reddy
  - Created:  Tue Sep 05 07:53:28 PDT 2006
  - Updated:  Thu Sep 07 06:23:01 PDT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2381

[GERONIMO-2365] Upgrade Derby to 10.1.3.1
  - Assignee: Jason Dillon
  - Reporter: Jason Dillon
  - Created:  Wed Aug 30 17:10:25 PDT 2006
  - Updated:  Mon Sep 04 12:09:59 PDT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2365

[GERONIMO-2332] RTC Put the generated xmlbeans files for the  
j2ee 1.4 schemas in svn in a spec module so we don't need the  
schemas in svn at all

  - Assignee: David Jencks
  - Reporter: David Jencks
  - Created:  Fri Aug 18 13:13:47 PDT 2006
  - Updated:  Fri Aug 25 18:32:52 PDT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2332

[GERONIMO-2015] Let's replace JKS to PKCS12 key store type
  - Assignee: Unassigned
  - Reporter: Nikolay Chugunov
  - Created:  Fri May 12 14:54:17 PDT 2006
  - Updated:  Thu Aug 10 10:59:06 PDT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2015

[GERONIMO-2163] WADI Integration for Jetty
  - Assignee: Gianny Damour
  - Reporter: Gianny Damour
  - Created:  Sun Jul 02 14:16:35 PDT 2006
  - Updated:  Fri Sep 01 08:33:50 PDT 2006
  - Votes: 1
  1  David Jencks
  - http://issues.apache.org/jira/browse/GERONIMO-2163

[GERONIMO-2380] Keystores portlet - Form field validation using  
javascript

  - Assignee: Unassigned
  - Reporter: Vamsavardhana Reddy
  - Created:  Tue Sep 05 06:40:58 PDT 2006
  - Updated:  Thu Sep 07 06:23:49 PDT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2380

[GERONIMO-2364] Update geronimo to use ActiveMQ 4.1.x
  - Assignee: Hiram Chirino
  - Reporter: Hiram Chirino
  - Created:  Tue Aug 29 12:21:46 PDT 2006
  - Updated:  Wed Sep 06 12:34:52 PDT 2006
  - Votes: 4
  1  Alan Cabrera
  2  Dain Sundstrom
  3  Guillaume Nodet
  4  Jason Dillon
  - http://issues.apache.org/jira/browse/GERONIMO-2364

[GERONIMO-2358] Move java ee 5 specs into specs trunk
  - Assignee: David Blevins
  - Reporter: David Blevins
  - Created:  Mon Aug 28 17:21:48 PDT 2006
  - Updated:  Mon Sep 04 15:22:43 PDT 2006
  - Votes: 2
  1  Guillaume Nodet
  2  Jeff Genender
  -

[jira] Updated: (GERONIMO-2354) Replace concurrent with backport-concurrent-util

2006-09-07 Thread Alan Cabrera (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2354?page=all ]

Alan Cabrera updated GERONIMO-2354:
---

Attachment: (was: GERONIMO-2354.diff)

 Replace concurrent with backport-concurrent-util
 

 Key: GERONIMO-2354
 URL: http://issues.apache.org/jira/browse/GERONIMO-2354
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Affects Versions: 1.2
Reporter: Jason Dillon
 Attachments: GERONIMO-2354-openejb2.diff, GERONIMO-2354.diff


 Replace usage of concurrent classes with backport-concurrent-util.  
 Preparation for using java.util.concurrent in JDK 1.5, and reduce the need 
 for 2 sets of concurrent classes on the boot classloader.
 Sill need to include concurrent, as activeio and openejb still have some 
 dependencies upon it... but this brings us a step closer to not needing both.

-- 
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-2354) Replace concurrent with backport-concurrent-util

2006-09-07 Thread Alan Cabrera (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2354?page=all ]

Alan Cabrera updated GERONIMO-2354:
---

Attachment: (was: GERONIMO-2354-openejb2.diff)

 Replace concurrent with backport-concurrent-util
 

 Key: GERONIMO-2354
 URL: http://issues.apache.org/jira/browse/GERONIMO-2354
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Affects Versions: 1.2
Reporter: Jason Dillon
 Attachments: GERONIMO-2354-openejb2.diff, GERONIMO-2354.diff


 Replace usage of concurrent classes with backport-concurrent-util.  
 Preparation for using java.util.concurrent in JDK 1.5, and reduce the need 
 for 2 sets of concurrent classes on the boot classloader.
 Sill need to include concurrent, as activeio and openejb still have some 
 dependencies upon it... but this brings us a step closer to not needing both.

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

Unit testing transactional behaviour

2006-09-07 Thread Vadim Pesochinsky


I tried to change several existing unit tests to run in transacted mode and
every one of them fails. Is there a good reason for this? This is really
bad, because there is no coverage for major parts of the functionality.
-- 
View this message in context: 
http://www.nabble.com/Unit-testing-transactional-behaviour-tf2235066.html#a6196746
Sent from the ActiveMQ - Dev forum at Nabble.com.

Re: Unit testing transactional behaviour


Please send us an example of what your doing.  We might be able to let
you know what's going wrong.

On 9/7/06, Vadim Pesochinsky [EMAIL PROTECTED] wrote:


I tried to change several existing unit tests to run in transacted mode and
every one of them fails. Is there a good reason for this? This is really
bad, because there is no coverage for major parts of the functionality.
--
View this message in context: 
http://www.nabble.com/Unit-testing-transactional-behaviour-tf2235066.html#a6196746
Sent from the ActiveMQ - Dev forum at Nabble.com.





--
Regards,
Hiram

Blog: http://hiramchirino.com

[jira] Resolved: (AMQ-886) Timing bug could cause duplicate client id exception in network code.

 [ https://issues.apache.org/activemq/browse/AMQ-886?page=all ]

Hiram Chirino resolved AMQ-886.
---

Fix Version/s: 4.0.2
   (was: 4.0.3)
   Resolution: Fixed

Applied fix to 4.0 branch rev 441189

 Timing bug could cause duplicate client id exception in network code.
 -

 Key: AMQ-886
 URL: https://issues.apache.org/activemq/browse/AMQ-886
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Hiram Chirino
 Assigned To: Hiram Chirino
 Fix For: 4.1, 4.0.2




-- 
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: SVN Repository Reorganization


Ok.

Nobody objected to the reorg.  Soo.. I'm going to start moving things
around in a little bit (in case you want to know what there are so
many scm emails flying about).

On 9/5/06, Hiram Chirino [EMAIL PROTECTED] wrote:

Hi Everybody,

The ActiveMQ project has been growing tremendously and our source tree
now has many modules that are at different stages of development.
Furthermore, we require multiple build systems and platforms to build
all our supported native clients.  I think we are getting to the point
where we need reorganize the svn repository a little so that when we
do a main ActiveMQ release, our src distro just includes the things
that are being built / tested in the main ActiveMQ build.

So.. the reorg would look something like:

/incubator/activemq/trunk/sandbox -  /incubator/activemq/sandbox
/incubator/activemq/trunk/activemq-dotnet - 
/incubator/activemq/activemq-dotnet/trunk
/incubator/activemq/trunk/activemq-cpp - 
/incubator/activemq/activemq-cpp/trunk
/incubator/activemq/trunk/cms -  /incubator/activemq/cms/trunk
/incubator/activemq/trunk/openwire-c -  /incubator/activemq/openwire-c/trunk
/incubator/activemq/trunk/openwire-cpp - 
/incubator/activemq/openwire-cpp/trunk
/incubator/activemq/trunk/amazon -  /incubator/activemq/amazon/trunk
/incubator/activemq/trunk/activeio -  /incubator/activemq/activeio/trunk
/incubator/activemq/trunk/activecluster - 
/incubator/activemq/activecluster/trunk
/incubator/activemq/trunk/activemq-jmeter - 
/incubator/activemq/activemq-jmeter/trunk
/incubator/activemq/trunk/activemq-tooling/maven-gram-plugin - 
/incubator/activemq/maven-plugins/trunk/maven-gram-plugin
/incubator/activemq/trunk/activemq-tooling/maven-bundle-plugin - 
/incubator/activemq/maven-plugins/trunk/maven-bundle-plugin
/incubator/activemq/trunk/activemq-tooling/maven-bundle-plugin - 
/incubator/activemq/maven-plugins/trunk/maven-bundle-plugin

And finally.. to keep a consistent
/incubator/activemq/${project}/trunk structure...
/incubator/activemq/trunk - /incubator/activemq/activemq/trunk
/incubator/activemq/tags - /incubator/activemq/activemq/tags
/incubator/activemq/branches - /incubator/activemq/activemq/branches

What do you guys think?  Am i missing anything that should also get
moved?  When do you think would be a good time for the re-org?

--
Regards,
Hiram

Blog: http://hiramchirino.com




--
Regards,
Hiram

Blog: http://hiramchirino.com

[jira] Commented: (GERONIMO-2354) Replace concurrent with backport-concurrent-util

2006-09-07 Thread Jason Dillon (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2354?page=comments#action_12433203
 ] 

Jason Dillon commented on GERONIMO-2354:


We are going to need to coordinate this commit with openejb... 

 Replace concurrent with backport-concurrent-util
 

 Key: GERONIMO-2354
 URL: http://issues.apache.org/jira/browse/GERONIMO-2354
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Affects Versions: 1.2
Reporter: Jason Dillon
 Attachments: GERONIMO-2354-openejb2.diff, GERONIMO-2354.diff


 Replace usage of concurrent classes with backport-concurrent-util.  
 Preparation for using java.util.concurrent in JDK 1.5, and reduce the need 
 for 2 sets of concurrent classes on the boot classloader.
 Sill need to include concurrent, as activeio and openejb still have some 
 dependencies upon it... but this brings us a step closer to not needing both.

-- 
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: Unit testing transactional behaviour

2006-09-07 Thread Vadim Pesochinsky


I take ZeroPrefetchConsumerTest, JmsTopicRedeliverTest, etc and change every
occurance of 

FROM
connection.createSession(false, ...
TO 
connection.createSession(true, ...

and every single test case fails after that


-- 
View this message in context: 
http://www.nabble.com/Unit-testing-transactional-behaviour-tf2235066.html#a6197149
Sent from the ActiveMQ - Dev forum at Nabble.com.

Re: Release Early, Release Often

2006-09-07 Thread Matt Hogstrom

How would you handle J2EE certification then? I don't know the rules around it but I want to be
careful about confusing users.

I'm all for release early and often (tried to do that with 1.1.1 but these pesky security issues and
other problems pop up). I think getting a weekly drop available will be a significant help. We
tried that in the past (I think Blevins spearheaded new feature Wednesdays).

If we got that going first (and not considering releases) I think that would be a huge help. I'm
happy to assist when 1.1.1 gets out the door.

Jason Dillon wrote:
Something tells me that we are gonna end up with a 6mo+ release cycle
(with additional month just to make the release)... and that if we are
lucky.

So far I'm not hearing anyone else signing the Release Early, Release
Often tune.

I'd stop thinking about 1.2 as JEE5 or whatever thing that is gonna take
a bunch of time to do... and just get some incremental work done and
push out a release.

--jason

On Sep 7, 2006, at 7:22 AM, Matt Hogstrom wrote:

I think Dain said he was scouring the primordial soup of trunk to
determine which level of life form would emerge. At this point if its
a single cell organism then a .2 release might seem inappropriate. If
its an intergalactic space traveler that can cure cancer, solve world
peace and make a good pina colada then perhaps we should go to 3.0 :)

Dain, how are we doing with the data mining? Seem like the natives
are getting restless :-0

Dave Colasurdo wrote:

Here is the wikipedia definition for Pre-Alpha, Alpha, Beta, etc..
http://en.wikipedia.org/wiki/Alpha_release
The definitions pretty much agree with my preconception of what an
Alpha would contain.
IMHO, trunk is not currently in an Alpha state and doesn't accurately
reflect the majority of the software requirements that will be
addressed in G1.2.
It seems that trunk is currently in a pre-alpha state and I believe
making an occasional unstable/nightly build available would allow
users/developers to get familiar with the latest and greatest
functions in trunk without giving the false impression that G1.2 is
currently in Alpha state.

Just my .02
-Dave-
Jason Dillon wrote:
I am thinking about an 1.2-alpha release, which does not need to
pass any tck, but can still be downloaded by folks that want to test
their apps on the bleeding edge (with out having to build). While
there is nothing major from a J2EE perspective in the alpha, a lot
has changed, or will change very shortly. Here is a list with
comments of new and upcoming stuff:

ActiveMQ 4.1, is about to get committed.

Derby is about to get upgraded.

Log4j is about to get upgraded.

Use of concurrent util is about to get changed to
backport-concurrent-util.

Lets not forget that we changed the build system, which mostly
impacts development, but also has an impact on the configuration
files, and plugins... new CAR m2 plugin. I think it would be really
good to get an alpha out so that people can easily test and provide
feedback.

New m2 plugin to start/stop Geronimo, soon to have new deploy goals.

A bunch of bug fixes.

* * *

I think that by releasing a 1.2-alpha, that we also start down the
path of changing the perception of how quickly we release. The
alpha can also serve to help us get some experience using the m2
release plugin so that when it comes time for a non-alpha/beta
release that we have confidence in the procedure... and this will
give us time to make sure that we have the right configurations and
setup to make a release with relative ease.

Also, more of a side effect, by making a new release, it helps
control the JIRA roadmap, right now 1.2 is filled with a bunch of
build system related fluff and other bits...

I think that we have enough changes (or soon to change in the next
days or so) to warrant an alpha. I don't see any reason why not
to... we don't need to spend days/weeks to ensure the TCK passes,
because we don't need to run it. It should be sufficient to vote on
an alpha and then cut the release, which should be easy with the
maven release plugin, and even easier with my gpg-sign'ing mojo to
sign and upload all artifacts.

I believe that having this alpha out will benefit our community,
showing that we are going to start releasing more often, give people
a chance to provide feedback more often an earlier.

I certainly do not expect any production customers to use this, but
I do expect that app developers will, so they can ready their apps
for deployment on the platform. We will clearly label this as an
alpha release, and clear state that it has not been TCK certified.

I don't see any downside to cutting a release off of trunk soonish,
in the next week or so.

--jason

On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:

On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:

According to our STATUS file, our last feature release (1.1) was
on 2006-06-26 which is about 2.5 months ago. I'm not

Re: Release Early, Release Often


Good point.. it might not even be legally possible to do none
certified releases.  I'm really hoping that we can.

Perhaps we add big J2EE Certified and NOT Certified logos next to
the releases and clear text in the README regarding the certification
status of a release.

I'm just suggesting this since I don't think release early and release
often is possible if every release has to be certified.

On 9/7/06, Matt Hogstrom [EMAIL PROTECTED] wrote:

How would you handle J2EE certification then?  I don't know the rules around it 
but I want to be
careful about confusing users.

I'm all for release early and often (tried to do that with 1.1.1 but these 
pesky security issues and
other problems pop up).  I think getting a weekly drop available will be a 
significant help.  We
tried that in the past (I think Blevins spearheaded new feature Wednesdays).

If we got that going first (and not considering releases) I think that would be 
a huge help.  I'm
happy to assist when 1.1.1 gets out the door.



Jason Dillon wrote:
 Something tells me that we are gonna end up with a 6mo+ release cycle
 (with additional month just to make the release)... and that if we are
 lucky.

 So far I'm not hearing anyone else signing the Release Early, Release
 Often tune.

 I'd stop thinking about 1.2 as JEE5 or whatever thing that is gonna take
 a bunch of time to do... and just get some incremental work done and
 push out a release.

 --jason


 On Sep 7, 2006, at 7:22 AM, Matt Hogstrom wrote:

 I think Dain said he was scouring the primordial soup of trunk to
 determine which level of life form would emerge.  At this point if its
 a single cell organism then a .2 release might seem inappropriate.  If
 its an intergalactic space traveler that can cure cancer, solve world
 peace and make a good pina colada then perhaps we should go to 3.0 :)

 Dain, how are we doing with the data mining?  Seem like the natives
 are getting restless :-0

 Dave Colasurdo wrote:
 Here is the wikipedia definition for Pre-Alpha, Alpha, Beta, etc..
 http://en.wikipedia.org/wiki/Alpha_release
 The definitions pretty much agree with my preconception of what an
 Alpha  would contain.
 IMHO, trunk is not currently in an Alpha state and doesn't accurately
 reflect the majority of the software requirements that will be
 addressed in G1.2.
 It seems that trunk is currently in a pre-alpha state and I believe
 making an occasional unstable/nightly build available would allow
 users/developers to get familiar with the latest and greatest
 functions in trunk without giving the false impression that G1.2 is
 currently in Alpha state.
 Just my .02
 -Dave-
 Jason Dillon wrote:
 I am thinking about an 1.2-alpha release, which does not need to
 pass any tck, but can still be downloaded by folks that want to test
 their apps on the bleeding edge (with out having to build).  While
 there is nothing major from a J2EE perspective in the alpha, a lot
 has changed, or will change very shortly.  Here is a list with
 comments of new and upcoming stuff:

 ActiveMQ 4.1, is about to get committed.

 Derby is about to get upgraded.

 Log4j is about to get upgraded.

 Use of concurrent util is about to get changed to
 backport-concurrent-util.

 Lets not forget that we changed the build system, which mostly
 impacts development, but also has an impact on the configuration
 files, and plugins... new CAR m2 plugin.  I think it would be really
 good to get an alpha out so that people can easily test and provide
 feedback.

 New m2 plugin to start/stop Geronimo, soon to have new deploy goals.

 A bunch of bug fixes.

  * * *

 I think that by releasing a 1.2-alpha, that we also start down the
 path of changing the perception of how quickly we release.  The
 alpha can also serve to help us get some experience using the m2
 release plugin so that when it comes time for a non-alpha/beta
 release that we have confidence in the procedure... and this will
 give us time to make sure that we have the right configurations and
 setup to make a release with relative ease.

 Also, more of a side effect, by making a new release, it helps
 control the JIRA roadmap, right now 1.2 is filled with a bunch of
 build system related fluff and other bits...

 I think that we have enough changes (or soon to change in the next
 days or so) to warrant an alpha.  I don't see any reason why not
 to... we don't need to spend days/weeks to ensure the TCK passes,
 because we don't need to run it.  It should be sufficient to vote on
 an alpha and then cut the release, which should be easy with the
 maven release plugin, and even easier with my gpg-sign'ing mojo to
 sign and upload all artifacts.

 I believe that having this alpha out will benefit our community,
 showing that we are going to start releasing more often, give people
 a chance to provide feedback more often an earlier.

 I certainly do not expect any production customers to use this, but
 I do expect that app developers will, so they can ready their apps

Re: Release Early, Release Often

2006-09-07 Thread Dain Sundstrom

I spent a long time looking through JIRA and the svn log comments and  
there are a lot of changes in trunk already.  Just to start with we  
have 290 JIRAs closed against 1.2 and there are a few big changes  
that don't have JIRAs (these were mostly my fault :).  I whipped  
together a preliminary roadmap report using swizzle, but as you will  
see many of the issues are classified incorrectly.


Anyway, here is a list of the items we have completed in trunk  
already.  Did I miss any completed work?  How do you want to proceed?


-dain



New Features (7):

  * [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http:// 
incubator.apache.org/activemq for features)

  * [NOJIRA] Add Maven 2 deployment tools
  * [GERONIMO-1133] UUID primary key generator
  * [GERONIMO-1192] Installer should create a config.xml for the  
target install
  * [GERONIMO-1259] reduce the size of the combined deployment plan:  
package deployment plans in a jar and pass this jar to the deployer
  * [GERONIMO-1573] Spring integration -- wrap our components in  
spring interfaces

  * [GERONIMO-1593] Add SMTP Authentication and STARTTLS support.
  * [GERONIMO-2071] Move Geronimo build to M2 (new 1.2 trunk)
  * [GERONIMO-2132] Move activemq gbean integration modules from  
ActiveMQ to Geronimo


Major Improvements (21):

  *[ NOJIRA] Simplify EJB container configuration
  * [GERONIMO-790] JettyModuleBuilder should use references to  
templates, not their names

  * [GERONIMO-1163] improve jmx debug console
  * [GERONIMO-1194] Installer should only install packs(features)  
selected at install time

  * [GERONIMO-1278] Upgrade to XML Beans 2.1.0 from 2.0.0
  * [GERONIMO-1335] Create issues for making the plugins run in more  
ways
  * [GERONIMO-1401] Updates to BUILDING.txt about the last changes  
to the build process
  * [GERONIMO-1434] Allow GBeans to be bound into a component's  
java:comp/env namespace
  * [GERONIMO-1527] InternetAddress does not properly implement  
address parsing.
  * [GERONIMO-1554] Installer - Move advanced features to non- 
default installer path (simplify default installation)

  * [GERONIMO-1563] [RTC] Make the JACC implementation pluggable
  * [GERONIMO-1613] Eliminate unncessary dependencies to reduce  
assemnbly footprint size

  * [GERONIMO-1647] Enabling access to session id on Tomcat
  * [GERONIMO-1651] Complete implementation of javamail MimeMessage  
and MimeUtil classes.
  * [GERONIMO-1772] Application class loader should not see server  
classes

  * [GERONIMO-1960] Reject invalid GBean references at deployment time
  * [GERONIMO-2092] Modules migration to M2
  * [GERONIMO-2152] Update for new OpenEJB 2.2
  * [GERONIMO-2224] Add a geronimo specific system property for  
controlling dom, sax, and transformer creation

  * [GERONIMO-2277] Remove TransactionContextManager
  * [GERONIMO-2300] Use jar or assembly plugin to generate classpath/ 
manifest bits for stuff in bin/*

  * [GERONIMO-2374] use junit decorators with selenium

Critical Bug Fixes (16):

  * [GERONIMO-1176] Bad resource reference is not caught at  
deployment time
  * [GERONIMO-1196] Keystore portlet: Viewing trusted certificate  
results in an error

  * [GERONIMO-1307] JMX connector doesn't shut down cleanly
  * [GERONIMO-1433] Security vulnerability of WEB-INF contents on  
windows platforms

  * [GERONIMO-1455] Start of CAR does not load and start its GBeans
  * [GERONIMO-1480] Cross context include does not set jacc  
contextID for 2nd web app. (Tomcat only)
  * [GERONIMO-1596] Repeated interface in JMS connection factory  
plan causes deployment failure

  * [GERONIMO-1599] HOWLLog throws NPE because XidFactory is missing
  * [GERONIMO-1649] Invalid deployment descriptor error when  
deploying an EJB 2.0 MDB
  * [GERONIMO-2058] Invalid gbean names in config.xml do not prevent  
server starting or module starting
  * [GERONIMO-2100] Subject can remain attached to thread on return  
from web app request, causing problems later on subsequent use of  
that thread
  * [GERONIMO-] Application errors in static initialization  
blocks during serialization of configuration during deployment  due  
to incorrect TCCL
  * [GERONIMO-2234] User can lock the default keystore without  
warning, making jetty server unusable
  * [GERONIMO-2237] Filtering of springframework.org in  
TomcatDeployer plan creates CNF Exceptions in Ears

  * [GERONIMO-2270] Redeploy broken in 1.1.1
  * [GERONIMO-2305]  
geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad

Re: [VOTE] 1.1.1-rc2 Release

2006-09-07 Thread Paul McMahan


OK thanks Matt now I understand the timing.  I copied the jacc spec,
j2ee schema, and ejb jars into my local maven repo and built the
src.tar.gz on linux and the src.zip on windows.  Started up the server
and did a quick smoke test.  Things look ok, except for deploying a
database pool which leads to the JACC error that was found in rc1 :

java.lang.IllegalArgumentException: Qualifier patterns must be present
when first URLPattern is an exact pattern
   at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98)
   at 
javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:47)

Since others aren't hitting this error when using the binary distro I
assume its happening because the jacc spec jar I copied from ~hogstrom
into my local repo is backlevel, which reading back through this
thread I see that Vamsi noticed the same thing.

IIUC that error will be cleared up as soon as the spec jars are
published, which (due to the race condition) can't happen until the
release is finalized,  so +1 from me!  :-)

Best wishes,
Paul

On 9/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote:

Grab the jar from 
http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-j2ee-jacc_1.0_spec-1.1.1-rc2.jar
  and place it in your local repo.  Don't forget to rename it to the same name 
minus the -rc2.
Since this jar is part of the release we have a bit of a race condition.

Paul McMahan wrote:
 Trying to build the src from

 http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-1.1.1-rc2-src.tar.gz
 on linux I get this error :

 +
 | geronimo and geronimo-plugins Geronimo :: Security
 | Memory: 11M/17M
 +
 DEPRECATED: the default goal should be specified in the build
 section of project.xml instead of maven.xml
 DEPRECATED: the default goal should be specified in the build
 section of project.xml instead of maven.xml

 build:end:

 Attempting to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar.
 WARNING: Failed to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar.

 BUILD FAILED
 File.. /home/pmcmahan/foo/geronimo-1.1.1-rc2-src/maven.xml
 Element... maven:reactor
 Line.. 43
 Column -1
 The build cannot continue because of the following unsatisfied dependency:
 geronimo-j2ee-jacc_1.0_spec-1.1.1.jar

 Is this just due to a timing window where the specs haven't been
 published until the release is ready?


 Trying to build the src from
http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-1.1.1-rc2-src.zip
 on windows I get this error in Geronimo::Maven Dependency Plugin:

 15:20:10,031 INFO  [PluginManager] Artifact 'C:\Documents and
 Settings\pmcmahan\
 .maven\repository\maven\jars\maven-1.0.2.jar' not found to add to classpath

 That leads to some class not found errors when compiling
 GenerateServiceXml.java.  This seems to be a result of building with
 maven1.1b3.  Downgrading to maven1.1b2 got me further, to the error I
 saw on linux described above.


 Best wishes,
 Paul


 On 9/6/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
 http://people.apache.org/~hogstrom/1.1.1-
 rc2/geronimo-j2ee-jacc_1.0_spec-1.1.1-rc2.jar is not same
 as the one that is in the binary distributions.  I have checked this
 in the
 context of GERONIMO-2376 .

  Vamsi


 On 9/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
  The changes pointed out by Bill have been incorporated (crossing my
 fingers).  I have not received
  any other comments so I'm hoping that others have looked.  Please
 review
 these items and cast your
  votes in this thread.
 
  Thanks in advance for your time and attention.
 
  Vote ends Monday morning at 0600 Eastern Time.  If there are issues in
 advance of that date a new RC
  will be spun up and a new vote started.
 
  *Source*
 
 http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-1.1.1-rc2-src.tar.gz

 
 http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-1.1.1-rc2-src.zip
 
  *Specifications*
 
 
http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-j2ee-jacc_1.0_spec-1.1.1-rc2.jar

 
 
http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-schema-j2ee_1.4-1.0-src.jar

 
 http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-schema-j2ee_1.4-1.0.jar

 
  *Distributions*
 
 
http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-jetty-j2ee-1.1.1-rc2.tar.gz

 
 
http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-jetty-j2ee-1.1.1-rc2.zip

 
 
http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-jetty-minimal-1.1.1-rc2.tar.gz

 
 
http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-jetty-minimal-1.1.1-rc2.zip

 
 
http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-tomcat-j2ee-1.1.1-rc2.tar.gz

 
 
http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-tomcat-j2ee-1.1.1-rc2.zip

 
 
http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-tomcat-minimal-1.1.1-rc2.tar.gz

 
 
http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-tomcat-minimal-1.1.1-rc2.zip

 
  *Other Items*

Re: Release Early, Release Often

2006-09-07 Thread Dain Sundstrom

For those of you interested in the unfiltered list of completed  
JIRAs, here they are :)


-dain

New Features (8):

  * [GERONIMO-1133] UUID primary key generator
  * [GERONIMO-1192] Installer should create a config.xml for the  
target install
  * [GERONIMO-1259] reduce the size of the combined deployment plan:  
package deployment plans in a jar and pass this jar to the deployer
  * [GERONIMO-1573] Spring integration -- wrap our components in  
spring interfaces

  * [GERONIMO-1593] Add SMTP Authentication and STARTTLS support.
  * [GERONIMO-2071] Move Geronimo build to M2 (new 1.2 trunk)
  * [GERONIMO-2132] Move activemq gbean integration modules from  
ActiveMQ to Geronimo

  * [GERONIMO-2148] Add javamail 1.4 to geronimo specs.

Improvements (41):

  * [GERONIMO-790] JettyModuleBuilder should use references to  
templates, not their names
  * [GERONIMO-1075] Configuration classloaders should support an  
inverse classloading delegation model.

  * [GERONIMO-1163] improve jmx debug console
  * [GERONIMO-1194] Installer should only install packs(features)  
selected at install time

  * [GERONIMO-1278] Upgrade to XML Beans 2.1.0 from 2.0.0
  * [GERONIMO-1317] Rename the new goals to more meaningful names  
with additional build properties
  * [GERONIMO-1335] Create issues for making the plugins run in more  
ways
  * [GERONIMO-1401] Updates to BUILDING.txt about the last changes  
to the build process
  * [GERONIMO-1429] Post Geronimo Schemas online (e.g. http:// 
java.sun.com/xml/ns/j2ee/)
  * [GERONIMO-1434] Allow GBeans to be bound into a component's  
java:comp/env namespace
  * [GERONIMO-1479] Add the maxPostSize and maxSavePostSize  
attributes to the Tomcat ConnectorGBean
  * [GERONIMO-1527] InternetAddress does not properly implement  
address parsing.
  * [GERONIMO-1554] Installer - Move advanced features to non- 
default installer path (simplify default installation)

  * [GERONIMO-1563] [RTC] Make the JACC implementation pluggable
  * [GERONIMO-1571] Just a suggestion to state in the source  
distributin's BUILDING.txt file that compilation requires a JDK  
compatible with version 1.4, and that 1.5 will not work.
  * [GERONIMO-1605] Display PID of started process when using  
geronimo.sh start or startup.sh
  * [GERONIMO-1606] Display message indicating Geronimo is being  
started in another window when started with geronimo.bat start or  
startup.bat
  * [GERONIMO-1607] Allow user to specify arguments to be used on  
the Windows START command issued by geronimo.bat

  * [GERONIMO-1608] Improve Geronimo script documentation
  * [GERONIMO-1613] Eliminate unncessary dependencies to reduce  
assemnbly footprint size

  * [GERONIMO-1647] Enabling access to session id on Tomcat
  * [GERONIMO-1648] Eliminate unnecessary config parent (import)  
dependencies
  * [GERONIMO-1651] Complete implementation of javamail MimeMessage  
and MimeUtil classes.

  * [GERONIMO-1664] Export / Import configurations capability
  * [GERONIMO-1705] Use AJAX to provide for a progress bar when  
downloading a JDBC jar
  * [GERONIMO-1772] Application class loader should not see server  
classes

  * [GERONIMO-1796] Improve SMTP transport debug trace output.
  * [GERONIMO-1798] Bring NNTPStore and NNTPTransport to same level  
of debugging tracing added to SMTP.

  * [GERONIMO-1881] Remove obsolete interop module
  * [GERONIMO-1960] Reject invalid GBean references at deployment time
  * [GERONIMO-2092] Modules migration to M2
  * [GERONIMO-2135] Improve the ActiveMQ GBeans
  * [GERONIMO-2147] Remove javamail-transport from Geronimo build  
and replace with javamail-provider dependency.

  * [GERONIMO-2152] Update for new OpenEJB 2.2
  * [GERONIMO-2216] Use JLine API to get password interactivly when  
using shutdown
  * [GERONIMO-2224] Add a geronimo specific system property for  
controlling dom, sax, and transformer creation

  * [GERONIMO-2277] Remove TransactionContextManager
  * [GERONIMO-2299] Unpack assemblies for easier development/testing
  * [GERONIMO-2300] Use jar or assembly plugin to generate classpath/ 
manifest bits for stuff in bin/*

  * [GERONIMO-2345] Windows Version of bootstrap
  * [GERONIMO-2374] use junit decorators with selenium

Bug Fixes (180):

  * [GERONIMO-526] Default domain not added to object names
  * [GERONIMO-592] Startup failure in Turkish language settings
  * [GERONIMO-973] Add security to /console-standard
  * [GERONIMO-1012] Tomcat integration does not set a subject in an  
unsecured web module in a secured ejb application
  * [GERONIMO-1097] (Patch) Keystore Portlet should point to the  
default keystore file instead of ssl-keystore-1
  * [GERONIMO-1165] Changing System DB pool size to 65 causes  
ActiveMQ to fail to get a connection
  * [GERONIMO-1176] Bad resource reference is not caught at  
deployment time

  * [GERONIMO-1182] Connector portlet delete challenge
  * [GERONIMO-1183] Console/Tomcat: Add/Edit Jetty HTTPS Connector  
page does not provide key password field
  *

[jira] Assigned: (GERONIMO-1983) CLI undeploy interactive mode

2006-09-07 Thread Tim McConnell (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1983?page=all ]

Tim McConnell reassigned GERONIMO-1983:
---

Assignee: Tim McConnell

 CLI undeploy interactive mode
 -

 Key: GERONIMO-1983
 URL: http://issues.apache.org/jira/browse/GERONIMO-1983
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 1.0
Reporter: Erin Mulder
 Assigned To: Tim McConnell
Priority: Minor

 It would be great if the undeploy command had an interactive mode so that if 
 you didn't give it any arguments, it would list all of the things you could 
 undeploy (a la list-modules) and you would just press the number of the one 
 you wanted.  This would be particularly helpful it showed context roots on 
 the right so that you could quickly spot the app you cared about, even in a 
 list of 25.

-- 
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: Release Early, Release Often


On 9/7/06, Dain Sundstrom [EMAIL PROTECTED] wrote:

   * [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http://
incubator.apache.org/activemq for features)


You can find a list of new features in ActiveMQ 4.0 here:
http://activemq.com/site/changes-in-40.html
and the new features in 4.1 here:
http://activemq.com/site/new-features-in-41.html

--
Regards,
Hiram

Blog: http://hiramchirino.com

JIRA Best Practices

2006-09-07 Thread Dain Sundstrom

I've started the wiki page http://cwiki.apache.org/GMOxDEV/jira.html  
where we can capture our recommendations for JIRA usage.  I added  
some guidelines for the title and classification of issues.  Having  
clean jira issue will help understand where we are in the development  
process and autogenerate nice reports using swizzle :)   I also  
personally find it much easier to write JIRAs if I have some examples  
and help with all of the options.


So what do you think?

-dain

[jira] Updated: (GERONIMO-2359) Itests for Geronimo

2006-09-07 Thread Prasad Kashyap (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2359?page=all ]

Prasad Kashyap updated GERONIMO-2359:
-

Attachment: genesis-ArtifactItem.patch
DeployToolSuport-v2.patch

Patches:
genesis-ArtifactItem.patch to be applied to genesis tree
DeployToolSupport-v2.patch to be applied to geronimo/server tree.



 Itests for Geronimo
 ---

 Key: GERONIMO-2359
 URL: http://issues.apache.org/jira/browse/GERONIMO-2359
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: buildsystem
Affects Versions: 1.2
Reporter: Prasad Kashyap
 Fix For: 1.2

 Attachments: DeployToolSuport-v2.patch, DeployToolSuport.patch, 
 genesis-ArtifactItem.patch, itests-1.0.patch


 The openejb itests which we had for a few releases now have been dead for a 
 while. Here's an effort to revive them and expand it's scope for all of 
 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

Re: Testsuite module, with basic/crude Selenium support

2006-09-07 Thread Prasad Kashyap

Please review the latest patch at
http://issues.apache.org/jira/browse/GERONIMO-2359#action_12433253

I have worked on all but one of the issues we discussed here. The
remaning issue is the one of delegating stuff to a JMXProxy.

I have issues getting my geronimo server to start. So I shall go and
chase that problem for now.
Module 18/20 org.apache.geronimo.configs/webconsole-jetty/1.2-SNAPSHOT/car
17:27:31,528 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
abstractName=org.apache.geronimo.configs/webconsole-jetty/1.2-SNAPSHOT/car?J2EEApplication=org.apache.geronimo.configs/webconsole-jetty/1.2-SNAPSHOT/car,WebModule=framework.war,j2eeType=Servlet,name=car-export-forward
java.lang.ClassNotFoundException:
org.apache.geronimo.console.servlet.ContextForwardServlet in
classloader
org.apache.geronimo.configs/webconsole-jetty_framework.war/1.2-SNAPSHOT/car
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:249)

Cheers
Prasad

On 9/6/06, Jason Dillon [EMAIL PROTECTED] wrote:

On Sep 6, 2006, at 8:03 PM, Prasad Kashyap wrote:
Here are the use case scenarios I thought of -

UC #1 : use goal in testsuites. The modules for deployment in this
execution typically comes from the testsupport project. For most
testcases we can build the modules with the plans inside them. A few
testcases that need to test a deployment with an external plan can
specify the plan in the config.

UC #2: use goal by others. The modules for deployment in this
execution may come from a repository or be specified as a non-artifact
archive. Even here, the plan, if need be, can be specified in the
config along with the modules. However what I'd eventually like to
do here is be able to deploy a list of modules.

To be able to deploy a list of modules, the #plan param needs to get
inside the #module param so that there can be a plan specified for
every module config.

None of these cases require the moduleId and defaultModuleId bits,
which was what I was hinting at. A list of modules, with optional
plan such be fine.

Sounds like that if you did want to do some selection, that it would
be over one set of modules or another... but I still don't see the
need for that.

Why do we have 'distribute' and 'undeploy'? Why not 'deploy' and
'undeploy'?

distribute and deploy are some of the options passed to the deploy
tool. The former option just installs the modules into G while the
latter installs and starts it. Now I went with distribute + start
sequence since that is what G had in the old itests. If we think we
can get rid of it and just use deploy, then I'll be glad to change it.

I'd say, call the goal deploy, and add an optional startModule flag
to indicate if distribute() or deploy() should be used.

In DistributeModuleMojo, why is #plan a String and not a File? The
plexus container will perform the equiv of your getFile() for you.

I thought about it. But eventually I wanted to move the #plan inside
the #module. So I left it as String.

You can still have a File in a helper object and Plexus will inject
it. We should create a ModuleConfig, that extends from ArtifactItem
(like AssemblyConfig) and add that field.

Any reason why we have explicitly set the TCL in getDeploymentManager
(), was the TCL that maven setup not correct?

Hmm.. Not that I know of. Must be from legacy code. But I'll reserve
judgement on it until I investigate that further.

Well, if we don't need to set it... lets not.

--jason

Re: Release Early, Release Often

ActiveMQ 4.1 is a massive upgrade (a really good thing)  from the  
previous offering in G 1.x


--jason


On Sep 7, 2006, at 2:52 PM, Hiram Chirino wrote:


On 9/7/06, Dain Sundstrom [EMAIL PROTECTED] wrote:

   * [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http://
incubator.apache.org/activemq for features)


You can find a list of new features in ActiveMQ 4.0 here:
http://activemq.com/site/changes-in-40.html
and the new features in 4.1 here:
http://activemq.com/site/new-features-in-41.html

--
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Release Early, Release Often

2006-09-07 Thread Aaron Mulder


On 9/7/06, Jason Dillon [EMAIL PROTECTED] wrote:

ActiveMQ 4.1 is a massive upgrade (a really good thing)  from the
previous offering in G 1.x


It is a good upgrade, but looking over that list, it's practically the
only big advance for a typical user, and that's assuming they care
that much about JMS.  I wish we had more big bang features for our
next 1.x release (especially EE 5 stuff -- where's the web and web
services integration?  How is OpenEJB 3 coming?  What about XBean
integration?  Retrotranslator?  Yoko?).  Also, a fair amount of
non-new-feature items on the list were included in 1.1.1...

Thanks,
Aaron


On Sep 7, 2006, at 2:52 PM, Hiram Chirino wrote:

 On 9/7/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
* [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http://
 incubator.apache.org/activemq for features)

 You can find a list of new features in ActiveMQ 4.0 here:
 http://activemq.com/site/changes-in-40.html
 and the new features in 4.1 here:
 http://activemq.com/site/new-features-in-41.html

 --
 Regards,
 Hiram

 Blog: http://hiramchirino.com

Re: Release Early, Release Often

2006-09-07 Thread Aaron Mulder


And I guess to return to the original subject -- I'd be fine release
something like this as a 1.n.m+1 release -- it has plenty to be an
advance.  But I think there's enough incompatibility with 1.1.x that
I don't think it would make a good 1.1.2.  I wish we already had a
solid 1.2 release down so we could say this is a great looking 1.2.1
release, you know?  I'm not so sure it's exciting as a 1.2 release on
its own.

But I'd be happy to call it a pre-alpha or whatever.

Thanks,
Aaron

On 9/7/06, Aaron Mulder [EMAIL PROTECTED] wrote:

On 9/7/06, Jason Dillon [EMAIL PROTECTED] wrote:
 ActiveMQ 4.1 is a massive upgrade (a really good thing)  from the
 previous offering in G 1.x

It is a good upgrade, but looking over that list, it's practically the
only big advance for a typical user, and that's assuming they care
that much about JMS.  I wish we had more big bang features for our
next 1.x release (especially EE 5 stuff -- where's the web and web
services integration?  How is OpenEJB 3 coming?  What about XBean
integration?  Retrotranslator?  Yoko?).  Also, a fair amount of
non-new-feature items on the list were included in 1.1.1...

Thanks,
 Aaron

 On Sep 7, 2006, at 2:52 PM, Hiram Chirino wrote:

  On 9/7/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
 * [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http://
  incubator.apache.org/activemq for features)
 
  You can find a list of new features in ActiveMQ 4.0 here:
  http://activemq.com/site/changes-in-40.html
  and the new features in 4.1 here:
  http://activemq.com/site/new-features-in-41.html
 
  --
  Regards,
  Hiram
 
  Blog: http://hiramchirino.com

Deployment type defects

2006-09-07 Thread Tim McConnell


Hi, I'd like to start concentrating on some of the deployment defects
since I've spent a couple days trying to thoroughly understand the use
cases and class interactions related to the CLI interface. Does this
seem like a reasonable area for me to concentrate on (i.e., to help get
my feet wet) ?? I've already assigned GERONIMO-1983 to myself but would
certainly entertain suggestions for other deployment-related defects.
Thanks

Re: Restructuring trunk, then next steps


On 9/7/06, David Jencks [EMAIL PROTECTED] wrote:


On Sep 5, 2006, at 7:28 PM, Dain Sundstrom wrote:

 BTW I do think we should rename the dirs to match the maven
 standard geronimo-foo standard.

I completely agree

 -dain

 On Sep 5, 2006, at 2:49 PM, Jason Dillon wrote:

 Fine with me.

 The tree is still in need of reorganization even after those
 modules are gone.

 --jason


 On Sep 5, 2006, at 2:42 PM, Dain Sundstrom wrote:

 Please don't get mad at me, but I'd like to move a bit slower on
 more classification inside of the server module.  I'd like to
 pull transaction and connector out to independently versioned
 modules and then see if the tree still feels crowded.

I tend to agree with this too.  One think I have thought briefly
about for years (?!) is separating the builder modules and the
runtime modules.



+1!


thanks
david jencks
big snip




--
Regards,
Hiram

Blog: http://hiramchirino.com

Re: [PROPOSAL] Modified RTC


I think we are going to need a voting matrix for this issue! lol.

I'd like see CTR on trunk / Active Branches
and, Relaxed RTC on Maintance branches.

On 9/6/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matt Hogstrom wrote:

 *** Begin Proposal ***

 Geronimo Development Process

 Geronimo follows a model similar to Review Then Commit (RTC).

Trunk, active branches, maintenance branches, and all?  Or
how would you refine it across those?
- --
#kenP-)}

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

Millennium hand and shrimp!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRP81bprNPMCpn3XdAQKDcwP8Cfqk7bh1xwF63/vgr5f7eyHj8LAHrp+X
FGlBmOE9oJ+YqoYUGqzoGpHdKPppGQKjuyy7mvR/F2L5pNBUk2mg0Uv0bLkUa8x0
N5yNbEJS66BzjZzPK9ZId4a462jhVcCZqSrDWQRiboUqSk8p7x0lRxMA+0slntUK
GrkBhlCExl0=
=6iRu
-END PGP SIGNATURE-




--
Regards,
Hiram

Blog: http://hiramchirino.com

Re: JIRA Best Practices

2006-09-07 Thread Paul McMahan


Looks good. Can we (eventually) get this information into the window
that pops up when you click the [?] icon on the JIRA creation form?
http://issues.apache.org/jira/ShowConstantsHelp.jspa?decorator=popup#IssueTypes

Paul

On 9/7/06, Dain Sundstrom [EMAIL PROTECTED] wrote:

I've started the wiki page http://cwiki.apache.org/GMOxDEV/jira.html
where we can capture our recommendations for JIRA usage.  I added
some guidelines for the title and classification of issues.  Having
clean jira issue will help understand where we are in the development
process and autogenerate nice reports using swizzle :)   I also
personally find it much easier to write JIRAs if I have some examples
and help with all of the options.

So what do you think?

-dain

Re: ActiveMQ maven-plugins release

Looking at this thread:
http://www.nabble.com/-VOTE--approve-the-m1-release-of-Trinidad%27s-Maven-plugins-tf2180114.html

It looks the trinidad just went through something similar and they
just did a mvn deploy and then voted on the binaries.

On 9/7/06, Hiram Chirino [EMAIL PROTECTED] wrote:

Dear Mentors,

I've got tag of the code that should become the 4.1-incubator release
of the activemq maven plugins. It's located here:

https://svn.apache.org/repos/asf/incubator/activemq/maven-plugins/tags/maven-plugins-4.1/

Now.. I started following the normal release procedure that I normally
take for activemq, but I realized that it might not be such a good
idea. This is mainly because maven plugins depend on some special
deployment updating of the maven-metadata xml in the deployment
repository.

And this special updating normally happens when mvn deploy is running.
So while I could provide you a binary build for you guys to inspect,
once it's approved, I would need to re-run the build to do the mvn
deploy bits. So, can we just call a vote to do a build and release
what is located the the tag listed above? I believe the the maven
project follow a similar release procedure but I'm not sure if the
incubator pmc would approve of it.

On 9/7/06, Hiram Chirino [EMAIL PROTECTED] wrote:
Hey folks.. now that the repo reorg is done.. we can do a release of
the maven plugins that our main activemq build depends on without
having to release everything.

So... I'm going to start working on cutting a release of the stuff
under https://svn.apache.org/repos/asf/incubator/activemq/maven-plugins/trunk

Let me know if I should hold off. Since they have been working well
now for while, I'm assuming they are stable enough for a release.

--
Regards,
Hiram

Blog: http://hiramchirino.com

--
Regards,
Hiram

Blog: http://hiramchirino.com

--
Regards,
Hiram

Blog: http://hiramchirino.com

Re: SVN Repository Reorganization

2006-09-07 Thread Nathan Mittler


Looks good!

On 9/7/06, Hiram Chirino [EMAIL PROTECTED] wrote:


ok. reorg done.  Let me know if you seen anything out of place.

--
Regards,
Hiram

Blog: http://hiramchirino.com



Regards,
Nate

Re: Release 3.0


+1!

On 9/7/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

I'd like to cut branch and start the
release process for ServiceMix 3.0
tomorrow.
Any objections ?

--
Cheers,
Guillaume Nodet





--
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Patches in RTC (Geronimo - 2006-09-07)