date:20060622

consumer.dispatchAsync defaults to false


 Key: AMQ-770
 URL: https://issues.apache.org/activemq/browse/AMQ-770
 Project: ActiveMQ
Type: Bug

  Components: JMS client  
Versions: 4.0, 4.0.1
Reporter: Kevin Yaussy
Priority: Minor


Seems like there was a change between 4.0-RC3 and incubator-4.0(.1) with 
regards to the default value for the destination option 
consumer.dispatchAsync.  According to the web documentation for destination 
options, as well as behavior in RC3, the default is true.  However, it looks 
like incubator-4.0(.1) defaults to false.  I have to explicitly give the 
consumer.dispatchAsync=true for a destination option, in order to get async 
dispatch in the Broker.

Is this a code bug, or documentation bug?


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

2006-06-22 Thread James Strachan


I liked Hiram's blog today

http://hiramchirino.com/2006/06/amqp-interesting-start.html

it looks way too early to be able to implement this specification in a
JMS provider yet as there's no standard way to map JMS semantics to
AMQP yet - which would prevent JMS providers from interoperating -
but I'm sure that will come along later.


On 6/21/06, Hiram Chirino [EMAIL PROTECTED] wrote:

+1 !  BTW IMO the spec is still fuzzy.  I think they need to clarify
it a bit more.  But I think it's something we should be able to
implement really easy.

On 6/20/06, Brian McCallister [EMAIL PROTECTED] wrote:
 FYI: http://www.infoq.com/news/amq

 AMQP looks to be an attempt at wire protocol specification like
 openwire or stomp.

 Probably good for us to look at, though the licensing probably needs
 to bounce through [EMAIL PROTECTED] before we do much as it is not
 immediately clear if it is okay. I probably is, but I'd love to get
 Cliff's opinion.

 -Brian



--
Regards,
Hiram

Blog: http://hiramchirino.com




--

James
---
http://radio.weblogs.com/0112098/

[jira] Created: (AMQ-771) org.apache.activemq.broker.TransportConnection::stop should not attempt to send a message over the connection.

org.apache.activemq.broker.TransportConnection::stop should not attempt to send 
a message over the connection.
--

 Key: AMQ-771
 URL: https://issues.apache.org/activemq/browse/AMQ-771
 Project: ActiveMQ
Type: Bug

  Components: Connector  
Versions: 4.0.1, 4.0
Reporter: Kevin Yaussy


Especially when using failover, there can be a problem with respect to 
TransportConnection::stop attempting to send a shutdown message over the 
connection.  If another thread is sending messages to the connection, and it 
gets stuck for some reason, such as a network freeze, the target machine 
panics, or the target process freezes for some reason, the 
TransportConnection::dispatch will eventually block, locking the 
MutextTransport object.  When the InactivityMonitor wakes up and detects that 
the connection is dead, it will go through the process of stopping the 
connection.  This goes back into TransportConnection, and calls stop, which 
attemtps to lock the MutexTransport so it can send the shutdown command.  
Now, both threads are stuck, potentially for a long time, as a box panic will 
not cleanly close the tcp connection.

I'm not sure the rationale for wanting to send a shutdown command to the other 
side of the connection, since the target has to handle the connection going 
down hard anyway.  Seems to me, if you are intending on closing the connection, 
just close it - don't try to be nice to the other side.  Especially in this 
code path, there is something wrong with the other side anyway.


-- 
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] Reopened: (AMQ-608) Change logging level of some DemandForwardingBridge log messages.

 [ https://issues.apache.org/activemq/browse/AMQ-608?page=all ]
 
Kevin Yaussy reopened AMQ-608:
--


Hiram,

Very sorry that I did not look at the 4.0.1 source until the last couple days.  
I'd like to submit patches this time (I don't have svn, but I will attach 
regular diff -u patches).

For DemandForwardingBridgeSupport, there was just one change that was left out.

For FailoverTransport, it looks like things got changed around in kind of the 
opposite direction I was looking for.  For me, I really don't care about the 
message waiting for transport to reconnect that comes out once a second 
during a send.  Seemed like that one was less meaningful than the message 
waiting  + reconnectDelay +  ms before attempting connection.  That's the 
one I would prefer to be debug, whereas the other message would be trace.

Then, additionally, I am including a logging patch for InactivityMonitor.java.  
I would like to be able to see when readCheck is going to throw 
InactivityIOException and also show the connection info.  I also don't care 
about the other debug stuff.  So, I changed the readCheck log message to be 
info and added the toString to the message.  Alternatively, I have a second 
patch that does the same thing, but turns all current debug into trace, and 
just the readCheck message to debug.  Either way is good for me.  The issue 
here is that the Broker won't show this InactivityIOException, and I'd like to 
see it (just not all the other debug stuff).  The client-side, I think, is OK 
since now the TransportListener interrupted / resumed works.  But the 
broker is silent about this and I would like to see it.

Thanks.


 Change logging level of some DemandForwardingBridge log messages.
 -

  Key: AMQ-608
  URL: https://issues.apache.org/activemq/browse/AMQ-608
  Project: ActiveMQ
 Type: Improvement

   Components: Broker
 Versions: 4.0
 Reporter: Kevin Yaussy
 Assignee: Hiram Chirino
  Fix For: 4.0.1, 4.1
  Attachments: DemandForwardingBridge.java, 
 DemandForwardingBridgeSupport.java, FailoverTransport.java, 
 FailoverTransport.java


 In DemandForwardingBridge, I'd like to be able to see subscription messages 
 (and unsubscription messages), but not bridging messages.  Both classes of 
 log messages are log.trace.  Seems like the bridging messages should remain 
 trace, as you would want to look at that when you are doing pretty detailed 
 debugging.  However, I'd like to see subscribe/unsubscribe messages all the 
 time.  If those could be either info or debug, that would allow me to turn 
 those on separately.  I realize that I can see what is currently subscribed 
 via the JMX console.  However, seeing the subscribe/unsubscribe messages will 
 allow diagnostics over time - who subscribed when type of questions.
 Mainly, I'm referring to messages logged as trace in:
 DemandForwardingBridge.serviceRemoteConsumerAdvisory
 DemandForwardingBridge.removeDemandSubscription

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

[jira] Updated: (AMQ-608) Change logging level of some DemandForwardingBridge log messages.

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

Kevin Yaussy updated AMQ-608:
-

Attachment: DemandForwardingBridgeSupport.patch
FailoverTransport.patch
InactivityMonitor.patch

Hope this is the way to attach the patches...

Kevin.

 Change logging level of some DemandForwardingBridge log messages.
 -

  Key: AMQ-608
  URL: https://issues.apache.org/activemq/browse/AMQ-608
  Project: ActiveMQ
 Type: Improvement

   Components: Broker
 Versions: 4.0
 Reporter: Kevin Yaussy
 Assignee: Hiram Chirino
  Fix For: 4.0.1, 4.1
  Attachments: DemandForwardingBridge.java, 
 DemandForwardingBridgeSupport.java, DemandForwardingBridgeSupport.patch, 
 FailoverTransport.java, FailoverTransport.java, FailoverTransport.patch, 
 InactivityMonitor.patch


 In DemandForwardingBridge, I'd like to be able to see subscription messages 
 (and unsubscription messages), but not bridging messages.  Both classes of 
 log messages are log.trace.  Seems like the bridging messages should remain 
 trace, as you would want to look at that when you are doing pretty detailed 
 debugging.  However, I'd like to see subscribe/unsubscribe messages all the 
 time.  If those could be either info or debug, that would allow me to turn 
 those on separately.  I realize that I can see what is currently subscribed 
 via the JMX console.  However, seeing the subscribe/unsubscribe messages will 
 allow diagnostics over time - who subscribed when type of questions.
 Mainly, I'm referring to messages logged as trace in:
 DemandForwardingBridge.serviceRemoteConsumerAdvisory
 DemandForwardingBridge.removeDemandSubscription

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

[jira] Updated: (AMQ-608) Change logging level of some DemandForwardingBridge log messages.

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

Kevin Yaussy updated AMQ-608:
-

Attachment: InactivityMonitor.patch2

 Change logging level of some DemandForwardingBridge log messages.
 -

  Key: AMQ-608
  URL: https://issues.apache.org/activemq/browse/AMQ-608
  Project: ActiveMQ
 Type: Improvement

   Components: Broker
 Versions: 4.0
 Reporter: Kevin Yaussy
 Assignee: Hiram Chirino
  Fix For: 4.0.1, 4.1
  Attachments: DemandForwardingBridge.java, 
 DemandForwardingBridgeSupport.java, DemandForwardingBridgeSupport.patch, 
 FailoverTransport.java, FailoverTransport.java, FailoverTransport.patch, 
 InactivityMonitor.patch, InactivityMonitor.patch2


 In DemandForwardingBridge, I'd like to be able to see subscription messages 
 (and unsubscription messages), but not bridging messages.  Both classes of 
 log messages are log.trace.  Seems like the bridging messages should remain 
 trace, as you would want to look at that when you are doing pretty detailed 
 debugging.  However, I'd like to see subscribe/unsubscribe messages all the 
 time.  If those could be either info or debug, that would allow me to turn 
 those on separately.  I realize that I can see what is currently subscribed 
 via the JMX console.  However, seeing the subscribe/unsubscribe messages will 
 allow diagnostics over time - who subscribed when type of questions.
 Mainly, I'm referring to messages logged as trace in:
 DemandForwardingBridge.serviceRemoteConsumerAdvisory
 DemandForwardingBridge.removeDemandSubscription

-- 
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-772) Build ships without activemq-web-4.0.jar

2006-06-22 Thread Matt Parker (JIRA)

Build ships without activemq-web-4.0.jar


 Key: AMQ-772
 URL: https://issues.apache.org/activemq/browse/AMQ-772
 Project: ActiveMQ
Type: Bug

Reporter: Matt Parker


Build ships without activemq-web-4.0.jar, so WAR generated by ant task 
incomplete.  I had to add this myself.  Can you please add it to the release?

-- 
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-773) Build ships without incompatitable commons-logging and log4j

2006-06-22 Thread Matt Parker (JIRA)

Build ships without incompatitable commons-logging and log4j


 Key: AMQ-773
 URL: https://issues.apache.org/activemq/browse/AMQ-773
 Project: ActiveMQ
Type: Bug

  Components: Broker  
Versions: 4.0.1
Reporter: Matt Parker
 Fix For: 4.0.2


commons-logging calls Category.log in lo4j, which is depericated in the version 
of log4j that ships in 4.0.1.

Please upgrade the commons-log to commons-logging-1.1.jar

-- 
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-774) Can't deploy RAR on weblogic 9.1

2006-06-22 Thread Matt Parker (JIRA)

Can't deploy RAR on weblogic 9.1


 Key: AMQ-774
 URL: https://issues.apache.org/activemq/browse/AMQ-774
 Project: ActiveMQ
Type: Bug

  Components: Broker  
Versions: 4.0.1
 Environment: BEA Weblogic 9.1
Reporter: Matt Parker


I've been through the doc:

http://www.activemq.org/site/how-to-deploy-activemq-ra-versionrar-to-weblogic.html

However, when I attempt to deploy the broker on Weblogic 9.1 (actually, when i 
click on activate changes), i get the following error:

weblogic.connector.exception.RAException: There are 1 nested errors: 
javax.resource.spi.ResourceAdapterInternalException: Failed to startup an 
embedded broker: file://../broker-config.xml, due to: java.io.IOException: 
Could load file factory:java.io.IOException: Could not find factory class for 
resource: META-INF/services/org/apache/activemq/broker/file at 
org.apache.activemq.ra.ActiveMQResourceAdapter.start(ActiveMQResourceAdapter.java:82)
 at weblogic.connector.security.layer.AdapterLayer.start(AdapterLayer.java:979) 
at 
weblogic.connector.common.RAInstanceManager.initialize(RAInstanceManager.java:1139)
 at 
weblogic.connector.common.RAInstanceManager.init(RAInstanceManager.java:333) 
at weblogic.connector.deploy.ConnectorModule.prepare(ConnectorModule.java:178) 
at 
weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:90)
 at 
weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:318)
 at 
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
 at 
weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:53)
 at 
weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:43)
 at 
weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:620) at 
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
 at 
weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:231) 
at 
weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:147)
 at 
weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:61)
 at 
weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:183)
 at 
weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:84)
 at 
weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:219)
 at 
weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:750)
 at 
weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1209)
 at 
weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:246)
 at 
weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:157)
 at 
weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:157)
 at 
weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12)
 at 
weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45)
 at 
weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207) at 
weblogic.work.ExecuteThread.run(ExecuteThread.java:179) Caused by: 
java.io.IOException: Could load file factory:java.io.IOException: Could not 
find factory class for resource: 
META-INF/services/org/apache/activemq/broker/file at 
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:24) 
at 
org.apache.activemq.broker.BrokerFactory.createBrokerFactoryHandler(BrokerFactory.java:42)
 at 
org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:55) at 
org.apache.activemq.ra.ActiveMQResourceAdapter.start(ActiveMQResourceAdapter.java:79)
 ... 27 more Caused by: java.io.IOException: Could not find factory class for 
resource: META-INF/services/org/apache/activemq/broker/file at 
org.apache.activeio.util.FactoryFinder.doFindFactoryProperies(FactoryFinder.java:87)
 at org.apache.activeio.util.FactoryFinder.newInstance(FactoryFinder.java:57) 
at org.apache.activeio.util.FactoryFinder.newInstance(FactoryFinder.java:46) at 
org.apache.activemq.broker.BrokerFactory.createBrokerFactoryHandler(BrokerFactory.java:40)
 ... 29 more

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

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

2006-06-22 Thread Alan D. Cabrera


I don't quite understand what you are asking.  Can you rephrase?


Regards,
Alan

Jason Dillon wrote:
Does this mean that the bulk of changes will be done on M.m branches 
and only release + minor changes done on M.m.r branches?


--jason


On Jun 21, 2006, at 6:52 PM, David Blevins wrote:


We had this whole conversation last week, lots of good discussion was
had.  I'd prefer not to have to have it again.  Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.

1.   branches/x.y would be the branch for all x.y.z releases

2.   when a release is frozen, we spin off a branch with that *exact*
 name, as in branches/x.y.z, where z starts at zero and increments
 by one.

3.   at that time branches/x.y is immediately updated to version
 x.y.(z+1)-SNAPSHOT

3.   We cut releases from the frozen branch

4.   When a release passes final tck testing and final vote, the
 frozen branch is moved to tags

We create a branch at freeze time for the following reasons:

1.  it takes *at least* one week from freeze to ship due to voting,
tck testing and potential repeats of that process (re-cut,
re-certify, re-vote).  There is no reason why work on x.y.z+1
needs to be delayed -- only 52 weeks a year.

2.  stronger guarantee no one is updating the branch once frozen

3.  less likely that people and ci systems (continuum) will checkout
and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
would need to be removed manually and may accidentally be
distributed.

4.  it is currently very difficult to roll version numbers forward,
entries here and there are often missed.  Far better to have
branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
than a few overlooked x.y.z final numbers that needed to go back
to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
back later if that process happens in the frozen branch.


Here is my +1


-- David



On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

After the branches/1.1 was moved to tags there was some question as 
to what happened to the 1.1 branch.  At that time some kind soul 
created a new branches/1.1.1.  No activity has occurred in that 
branch and given that we'll need to define the release goals of 
1.1.1 soon I'd like to propose the following.


After 1.1 is released:

* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1

When 1.1.1 enters time for release

* Move branches/1.1.1 to branches/1.1.1.0
* Change version from 1.1.1-SNAPSHOT to 1.1.1
* Create release candidate rc1
* put out for a vote
* get a successful vote with no respins :)
* move from branches/1.1.1.0 to tags/1.1.1.0

Based on all the confusion in the past I think this procedure makes 
it clear what phase were in for the release as well as avoids 
tagging and branching repeatedly.


I'm looking for lazy consensus and not a formal vote.

Matt

Re: XBean root POM

2006-06-22 Thread Guillaume Nodet

When you use the maven release plugin, maven change the scm urlto point to the tag. I will revert it to trunk asap.Cheers,Guillaume NodetOn 6/22/06, 
David Blevins [EMAIL PROTECTED] wrote:
On Jun 21, 2006, at 6:37 PM, Alan D. Cabrera wrote: IIUC, version specific informationhas snuck into elements that should be version free, e.g. scm.Here is a list of elements that should have version information removed:
 scm build...remoteRepositoryUrl distributionManagmentNot sure how this got there, it should point to trunk scm connectionscm:svn:
http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.4/connection developerConnectionscm:svn:https://${maven.username}@
svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.4/developerConnection urlhttp://svn.apache.org/repos/asf/geronimo/xbean/tags/
xbean-2.4/url /scmNo wonder Continuum is very unhappy with XBean...http://ci.gbuild.org/continuum/servlet/continuum
... it will check the code out from *exactly* where you point it to.-David

[jira] Resolved: (SM-468) Null Pointer Exception when only using XSD imports and no types element in WSDL definition

2006-06-22 Thread Guillaume Nodet (JIRA)

 [ https://issues.apache.org/activemq/browse/SM-468?page=all ]
 
Guillaume Nodet resolved SM-468:


Fix Version: 3.0
 Resolution: Fixed
  Assign To: Guillaume Nodet

Author: gnodet
Date: Wed Jun 21 23:35:16 2006
New Revision: 416269

URL: http://svn.apache.org/viewvc?rev=416269view=rev
Log:
SM-468: Null Pointer Exception when only using XSD imports and no types element 
in WSDL definition
Patch submitted by Grant McDonald, thx

Modified:

incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/HttpEndpoint.java



 Null Pointer Exception when only using XSD imports and no types element in 
 WSDL definition
 --

  Key: SM-468
  URL: https://issues.apache.org/activemq/browse/SM-468
  Project: ServiceMix
 Type: Bug

   Components: servicemix-http
 Versions: 3.0-M2
  Environment: Ubuntu Lunix 5.10, JDK 1.5.0_06-b05
 Reporter: Grant McDonald
 Assignee: Guillaume Nodet
 Priority: Trivial
  Fix For: 3.0
  Attachments: HttpEndpoint.java.patch

 Original Estimate: 15 minutes
 Remaining: 15 minutes

 The issue arises when deploying http endpoints where the WSDL definition does 
 not declare any inline types but instead imports all types from external 
 schemas.  The workaround for this is to use an emtpy types element, but 
 correspondingly the fix is trivial as well.  (see attached patch for trunk)

-- 
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: XBean root POM

2006-06-22 Thread Alan D. Cabrera





Ahh, ok. What about the other elements?


Regards,
Alan

Guillaume Nodet wrote:
When you use the maven release plugin, maven change the
scm url
to point to the tag. I will revert it to trunk asap.
  
Cheers,
Guillaume Nodet
  
  On 6/22/06, 
David Blevins [EMAIL PROTECTED]
wrote:
  
On Jun 21, 2006, at 6:37 PM, Alan D. Cabrera wrote:

 IIUC, version specific informationhas snuck into elements that
 should be version free, e.g. scm.Here is a list of
elements
 that should have version information removed:


 scm
 build...remoteRepositoryUrl
 distributionManagment


Not sure how this got there, it should point to trunk

 scm
 connectionscm:svn:
http://svn.apache.org/repos/asf/geronimo/
xbean/tags/xbean-2.4/connection
 developerConnectionscm:svn:https://${maven.username}
@
svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.4/
developerConnection
 urlhttp://svn.apache.org/repos/asf/geronimo/xbean/tags/

xbean-2.4/url
 /scm

No wonder Continuum is very unhappy with XBean...

http://ci.gbuild.org/continuum/servlet/continuum


... it will check the code out from *exactly* where you point it to.


-David

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)



On Jun 21, 2006, at 10:53 PM, Alan D. Cabrera wrote:


David Blevins wrote:
The only thing done in a branches/x.y.z made from branches/x.y is  
the release process itself.

I don't quite understand what this means.  Sorry.


Referring to things like switching the version numbers, etc.  The  
button it up stuff.  Specifically trying to exclude thinks like  
let's fix these 20 bugs.  The only bugs fixed would be in the event  
the release candidate had an unacceptable issue and it's vote did not  
pass.  That's the spirit of it anyway.


-David


When we agree we look good enough to cut and run, we freeze, make  
the branch and put together a release candidate.  At the point of  
the freeze the release manager owns the branches/x.y.z till the  
vote passes.  That's the ideal scenario anyway.


-David

On Jun 21, 2006, at 9:40 PM, Jason Dillon wrote:

Does this mean that the bulk of changes will be done on M.m  
branches and only release + minor changes done on M.m.r branches?


--jason


On Jun 21, 2006, at 6:52 PM, David Blevins wrote:

We had this whole conversation last week, lots of good  
discussion was

had.  I'd prefer not to have to have it again.  Here is my exact
understanding of our consensus and would like to put it to a  
vote to

avoid reinterpretation of that consensus in the future.

1.   branches/x.y would be the branch for all x.y.z releases

2.   when a release is frozen, we spin off a branch with that  
*exact*
 name, as in branches/x.y.z, where z starts at zero and  
increments

 by one.

3.   at that time branches/x.y is immediately updated to version
 x.y.(z+1)-SNAPSHOT

3.   We cut releases from the frozen branch

4.   When a release passes final tck testing and final vote, the
 frozen branch is moved to tags

We create a branch at freeze time for the following reasons:

1.  it takes *at least* one week from freeze to ship due to voting,
tck testing and potential repeats of that process (re-cut,
re-certify, re-vote).  There is no reason why work on x.y.z+1
needs to be delayed -- only 52 weeks a year.

2.  stronger guarantee no one is updating the branch once frozen

3.  less likely that people and ci systems (continuum) will  
checkout
and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)  
which

would need to be removed manually and may accidentally be
distributed.

4.  it is currently very difficult to roll version numbers forward,
entries here and there are often missed.  Far better to have
branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
than a few overlooked x.y.z final numbers that needed to go  
back
to SNAPSHOT -- they never leave SNAPSHOT and need to be  
reverted

back later if that process happens in the frozen branch.


Here is my +1


-- David



On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

After the branches/1.1 was moved to tags there was some  
question as to what happened to the 1.1 branch.  At that time  
some kind soul created a new branches/1.1.1.  No activity has  
occurred in that branch and given that we'll need to define the  
release goals of 1.1.1 soon I'd like to propose the following.


After 1.1 is released:

* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1

When 1.1.1 enters time for release

* Move branches/1.1.1 to branches/1.1.1.0
* Change version from 1.1.1-SNAPSHOT to 1.1.1
* Create release candidate rc1
* put out for a vote
* get a successful vote with no respins :)
* move from branches/1.1.1.0 to tags/1.1.1.0

Based on all the confusion in the past I think this procedure  
makes it clear what phase were in for the release as well as  
avoids tagging and branching repeatedly.


I'm looking for lazy consensus and not a formal vote.

Matt

Re: XBean root POM

2006-06-22 Thread Guillaume Nodet

The distribution repos ?Well, i wanted to publish the release in a private repo so that it can be voted,and then move to public repos.I will change them back to what they were.Cheers,Guillaume Nodet
On 6/22/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:



  


Ahh, ok. What about the other elements?


Regards,
Alan

Guillaume Nodet wrote:
When you use the maven release plugin, maven change the
scm url
to point to the tag. I will revert it to trunk asap.
  
Cheers,
Guillaume Nodet
  
  On 6/22/06, 
David Blevins [EMAIL PROTECTED]
wrote:
  
On Jun 21, 2006, at 6:37 PM, Alan D. Cabrera wrote:

 IIUC, version specific informationhas snuck into elements that
 should be version free, e.g. scm.Here is a list of
elements
 that should have version information removed:


 scm
 build...remoteRepositoryUrl
 distributionManagment


Not sure how this got there, it should point to trunk

 scm
 connectionscm:svn:
http://svn.apache.org/repos/asf/geronimo/
xbean/tags/xbean-2.4/connection
 developerConnectionscm:svn:https://${maven.username}
@
svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.4/
developerConnection
 urlhttp://svn.apache.org/repos/asf/geronimo/xbean/tags/

xbean-2.4/url
 /scm

No wonder Continuum is very unhappy with XBean...

http://ci.gbuild.org/continuum/servlet/continuum


... it will check the code out from *exactly* where you point it to.


-David

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)


Okay, then +1

--jason


On Jun 21, 2006, at 10:19 PM, David Blevins wrote:

The only thing done in a branches/x.y.z made from branches/x.y is  
the release process itself.  When we agree we look good enough to  
cut and run, we freeze, make the branch and put together a release  
candidate.  At the point of the freeze the release manager owns the  
branches/x.y.z till the vote passes.  That's the ideal scenario  
anyway.


-David

On Jun 21, 2006, at 9:40 PM, Jason Dillon wrote:

Does this mean that the bulk of changes will be done on M.m  
branches and only release + minor changes done on M.m.r branches?


--jason


On Jun 21, 2006, at 6:52 PM, David Blevins wrote:

We had this whole conversation last week, lots of good discussion  
was

had.  I'd prefer not to have to have it again.  Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.

1.   branches/x.y would be the branch for all x.y.z releases

2.   when a release is frozen, we spin off a branch with that  
*exact*
 name, as in branches/x.y.z, where z starts at zero and  
increments

 by one.

3.   at that time branches/x.y is immediately updated to version
 x.y.(z+1)-SNAPSHOT

3.   We cut releases from the frozen branch

4.   When a release passes final tck testing and final vote, the
 frozen branch is moved to tags

We create a branch at freeze time for the following reasons:

1.  it takes *at least* one week from freeze to ship due to voting,
tck testing and potential repeats of that process (re-cut,
re-certify, re-vote).  There is no reason why work on x.y.z+1
needs to be delayed -- only 52 weeks a year.

2.  stronger guarantee no one is updating the branch once frozen

3.  less likely that people and ci systems (continuum) will checkout
and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)  
which

would need to be removed manually and may accidentally be
distributed.

4.  it is currently very difficult to roll version numbers forward,
entries here and there are often missed.  Far better to have
branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
than a few overlooked x.y.z final numbers that needed to go back
to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
back later if that process happens in the frozen branch.


Here is my +1


-- David



On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

After the branches/1.1 was moved to tags there was some question  
as to what happened to the 1.1 branch.  At that time some kind  
soul created a new branches/1.1.1.  No activity has occurred in  
that branch and given that we'll need to define the release  
goals of 1.1.1 soon I'd like to propose the following.


After 1.1 is released:

* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1

When 1.1.1 enters time for release

* Move branches/1.1.1 to branches/1.1.1.0
* Change version from 1.1.1-SNAPSHOT to 1.1.1
* Create release candidate rc1
* put out for a vote
* get a successful vote with no respins :)
* move from branches/1.1.1.0 to tags/1.1.1.0

Based on all the confusion in the past I think this procedure  
makes it clear what phase were in for the release as well as  
avoids tagging and branching repeatedly.


I'm looking for lazy consensus and not a formal vote.

Matt

Re: liferay


On 6/21/06, Jeff Genender [EMAIL PROTECTED] wrote:

Personal preference...but I think its better throwing an error.  Is
obsoleting a settable option?  I am not so sure I like obsoleting by
default...this could be ugly since it may be another app other than the
Welcome app that gets obsoleted.


You don't have to obsolete anything -- I said you can do that.  If
you use the obsoletes, you provide module IDs you obsolete.  So you
could specify geronimo/welcome/*/car and it would remove the welcome
app if present and not if not and you wouldn't obsolete anything else
that happened to be listening on /

Thanks,
Aaron


 As far as populating the database, you can provide a GBean that runs
 whenever a flag like initialized is false.  Every time it starts it
 can check the flag and abort if it's set.  If it's not set, it can do
 its work, and then set the flag on itself (via a roundabout kernel
 call), so it will never execute the initialization again.  Or, of
 course, just connect to the DB and only execute the initialization if
 some known Liferay table is not present.

 Thanks,
Aaron

 On 6/21/06, Paul McMahan [EMAIL PROTECTED] wrote:
 Liferay is an open source portal made available under the MIT license.
  They provide a geronimo+liferay distribution from their website,
 which is basically a zipped up geronimo/tomcat server with liferay
 already deployed. I had some problems starting a fresh install of this
 distribution due to hsql database driver issues.  Hopefully new users
 who experience this same problem will find the entry I posted in
 liferay's support forum about how to get it working:
 http://forums.liferay.com/index.php?showtopic=5348

 Liferay currently uses a snapshot of geronimo 1.1 from 5/3/2006 which
 has the new versioning functionality but as you can imagine is missing
 several important bug fixes and schema changes.  I got their WAR
 working in geronimo 1.1 after making some adjustments to its
 geronimo-web.xml.  When geronimo 1.1 is officially released I'll offer
 my assistance to help them upgrade to it.

 I also think and have heard others mention that liferay is a great
 candidate for a geronimo plugin. Adding the necessary plugin files to
 the liferay WAR is straightforward.  But there are a couple of
 interesting challenges where I would like to get your input.   First
 is that the plugin prereqs a database pool.  Some expert users will
 want to manually create and populate the database and then use the
 console to point a db pool at it before installing the liferay plugin.
  But I imagine that some developers and more casual users would like
 for geronimo to automatically create a database pool for them as part
 of the liferay plugin install process.  That way they could add a
 working portal server to their geronimo server with only a few clicks
 in the console (remember Joe's mom? ;-)

 For this latter class of users geronimo could provide a plugin that
 defines a derby datasource and automatically populates the database
 when the plugin is installed.  Does this sound like a reasonable idea?
  I thought geronimo might already provide some facility to populate
 the database and I found this dev thread from last year where its
 proposed but (I assume) not implemented yet :
 http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL 
PROTECTED]

 This idea sounds right on to me.  Are others still in favor of it?  If
 so then I would like to work on an implementation. By the way,
 liferay currently does not support derby but I have it (mostly)
 working via a patch that I'll submit to them later.

 The second interesting aspect of creating liferay plugin is that
 liferay wants to use '/' for its context root.  The problem is that
 the geronimo welcome app is already installed in the '/' context root
 and this prevents liferay from starting.  I tried moving it to a
 different context root but then hard-coded references to scripts and
 images in their html started breaking. Is there a way to make
 geronimo override a context root such that last in wins?  Or could the
 plugin metadata specify the required context root so that the console
 can warn the user about potential conflicts before installing the
 plugin? Any ideas?

 Looking forward to your feedback.

 Best wishes,
 Paul

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.


+1 To Jason's comments with Hiram's comments...

I think we should do all development of 1.1.x in branches/1.1 (with
version 1.1.N-SNAPSHOT).  But at the time we code freeze for a
release, I think we should svn copy branches/1.1 to branches/1.1.N and
finalize the version numbers there (to version 1.1.N) and make any
last-minute tweaks there and update branches/1.1 to version number
1.1.(N+1)-SNAPSHOT.  When we have a candidate for the release, then we
can svn copy branches/1.1.N to tags/1.1.N and build the release from
the tag.

Thanks,
  Aaron

On 6/21/06, Hiram Chirino [EMAIL PROTECTED] wrote:

Hi Jason,

The problem is that it can take weeks to do a geronimo release since
stuff like CTS testing is involved.  So the release work (putting the
finishing touches) needs to be done in a branch so that work can
continue on the next release.

Perhaps m2 has a way of dealing with those issues along with
re-cutting releases and such.  But since I have not done a m2 based
release yet, I'm not sure what's involved.  Could you clarify it a bit
for me?

On 6/21/06, Jason Dillon [EMAIL PROTECTED] wrote:
  Hi Jason,
 
  I agree that we should avoid branching.  But I do agree with the 1.1.1
  branch.  It's a dead-end branch in that it's only used to prepare he
  release.  Applying last minute fixes and changing version numbers.
  Since it's a dead-end branch, once the release if approved
  moving/deleting it makes sense.

 I would make those changes on the 1.1 branch (or trunk if we were
 using that codebase), then release and let Maven make the tag and
 then update the versions to the next SNAP.

 When moving to m2 we really need to follow the m2 release system,
 else the number of changes to poms is going to get out of control and
 will be very error prone.

 --jason





--
Regards,
Hiram

Blog: http://hiramchirino.com

Re: ServiceMix-3.0-M2-incubating

2006-06-22 Thread Soumadeep-Infravio


Guillaume,

The M2 binary doesn't have the optional libraries, is this intentional or a
build issue

thanks
Soumadeep

- Original Message - 
From: Guillaume Nodet [EMAIL PROTECTED]

To: servicemix-users@geronimo.apache.org;
servicemix-dev@geronimo.apache.org
Sent: Tuesday, June 20, 2006 12:44 PM
Subject: ServiceMix-3.0-M2-incubating



I have uploaded binaries for the 3.0-M2-incubating release.
The repos and site are available at
   http://people.apache.org/~gnodet/servicemix-3.0-M2-incubating

Binary distribution can be directly accessed at

http://people.apache.org/~gnodet/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/apache-servicemix/3.0-M2-incubating/apache-servicemix-3.0-M2-incubating.tar.gz

http://people.apache.org/~gnodet/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/apache-servicemix/3.0-M2-incubating/apache-servicemix-3.0-M2-incubating.zip

Please, take some time to download and test the main configuration,
components and examples (I have changed quite a few things these last
days,
so ...),
and post your feedback (and votes for PPMC members).

Cheers,
Guillaume Nodet

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)


+1, but if we cut a release from the frozen branch, we need to note
the SVN version number or something so when we move it to tags we're
absolutely sure we didn't catch an extra commit in the tag.  I'm also
fine with copying to tags, making the candidate from tags, and then
recreating the tag if another release candidate turns out to be
necessary.

Thanks,
   Aaron

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

Okay, then +1

--jason


On Jun 21, 2006, at 10:19 PM, David Blevins wrote:

 The only thing done in a branches/x.y.z made from branches/x.y is
 the release process itself.  When we agree we look good enough to
 cut and run, we freeze, make the branch and put together a release
 candidate.  At the point of the freeze the release manager owns the
 branches/x.y.z till the vote passes.  That's the ideal scenario
 anyway.

 -David

 On Jun 21, 2006, at 9:40 PM, Jason Dillon wrote:

 Does this mean that the bulk of changes will be done on M.m
 branches and only release + minor changes done on M.m.r branches?

 --jason


 On Jun 21, 2006, at 6:52 PM, David Blevins wrote:

 We had this whole conversation last week, lots of good discussion
 was
 had.  I'd prefer not to have to have it again.  Here is my exact
 understanding of our consensus and would like to put it to a vote to
 avoid reinterpretation of that consensus in the future.

 1.   branches/x.y would be the branch for all x.y.z releases

 2.   when a release is frozen, we spin off a branch with that
 *exact*
  name, as in branches/x.y.z, where z starts at zero and
 increments
  by one.

 3.   at that time branches/x.y is immediately updated to version
  x.y.(z+1)-SNAPSHOT

 3.   We cut releases from the frozen branch

 4.   When a release passes final tck testing and final vote, the
  frozen branch is moved to tags

 We create a branch at freeze time for the following reasons:

 1.  it takes *at least* one week from freeze to ship due to voting,
 tck testing and potential repeats of that process (re-cut,
 re-certify, re-vote).  There is no reason why work on x.y.z+1
 needs to be delayed -- only 52 weeks a year.

 2.  stronger guarantee no one is updating the branch once frozen

 3.  less likely that people and ci systems (continuum) will checkout
 and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)
 which
 would need to be removed manually and may accidentally be
 distributed.

 4.  it is currently very difficult to roll version numbers forward,
 entries here and there are often missed.  Far better to have
 branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
 than a few overlooked x.y.z final numbers that needed to go back
 to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
 back later if that process happens in the frozen branch.


 Here is my +1


 -- David



 On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

 After the branches/1.1 was moved to tags there was some question
 as to what happened to the 1.1 branch.  At that time some kind
 soul created a new branches/1.1.1.  No activity has occurred in
 that branch and given that we'll need to define the release
 goals of 1.1.1 soon I'd like to propose the following.

 After 1.1 is released:

 * Delete branches/1.1.1
 * Move branches/1.1.0 to tags/1.1.0
 * Copy tags/1.1.0 to branches/1.1.1
 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
 * Start working on 1.1.1

 When 1.1.1 enters time for release

 * Move branches/1.1.1 to branches/1.1.1.0
 * Change version from 1.1.1-SNAPSHOT to 1.1.1
 * Create release candidate rc1
 * put out for a vote
 * get a successful vote with no respins :)
 * move from branches/1.1.1.0 to tags/1.1.1.0

 Based on all the confusion in the past I think this procedure
 makes it clear what phase were in for the release as well as
 avoids tagging and branching repeatedly.

 I'm looking for lazy consensus and not a formal vote.

 Matt

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

2006-06-22 Thread Rick McGuire

+1 (and we need to make sure this is added to the wiki so we can 
remember it the next time a release is spun :-))


David Blevins wrote:

We had this whole conversation last week, lots of good discussion was
had.  I'd prefer not to have to have it again.  Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.

1.   branches/x.y would be the branch for all x.y.z releases

2.   when a release is frozen, we spin off a branch with that *exact*
 name, as in branches/x.y.z, where z starts at zero and increments
 by one.

3.   at that time branches/x.y is immediately updated to version
 x.y.(z+1)-SNAPSHOT

3.   We cut releases from the frozen branch

4.   When a release passes final tck testing and final vote, the
 frozen branch is moved to tags

We create a branch at freeze time for the following reasons:

1.  it takes *at least* one week from freeze to ship due to voting,
tck testing and potential repeats of that process (re-cut,
re-certify, re-vote).  There is no reason why work on x.y.z+1
needs to be delayed -- only 52 weeks a year.

2.  stronger guarantee no one is updating the branch once frozen

3.  less likely that people and ci systems (continuum) will checkout
and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
would need to be removed manually and may accidentally be
distributed.

4.  it is currently very difficult to roll version numbers forward,
entries here and there are often missed.  Far better to have
branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
than a few overlooked x.y.z final numbers that needed to go back
to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
back later if that process happens in the frozen branch.


Here is my +1


-- David



On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

After the branches/1.1 was moved to tags there was some question as 
to what happened to the 1.1 branch.  At that time some kind soul 
created a new branches/1.1.1.  No activity has occurred in that 
branch and given that we'll need to define the release goals of 1.1.1 
soon I'd like to propose the following.


After 1.1 is released:

* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1

When 1.1.1 enters time for release

* Move branches/1.1.1 to branches/1.1.1.0
* Change version from 1.1.1-SNAPSHOT to 1.1.1
* Create release candidate rc1
* put out for a vote
* get a successful vote with no respins :)
* move from branches/1.1.1.0 to tags/1.1.1.0

Based on all the confusion in the past I think this procedure makes 
it clear what phase were in for the release as well as avoids tagging 
and branching repeatedly.


I'm looking for lazy consensus and not a formal vote.

Matt

Re: [VOTE] 1.1 Release

2006-06-22 Thread David Jencks

+1 from me.

thanks
david jencks


--- Prasad Kashyap [EMAIL PROTECTED]
wrote:

 I did a sniff test of the installed product and I
 think we are good to go.
 
 +1 from me.
 
 I shall grill it some more tomorrow.
 
 Cheers
 Prasad
 
 On 6/19/06, Hernan Cunico [EMAIL PROTECTED] wrote:
 
 
  John Sisson wrote:
   Some notes in relation to documentation:
  
   * Clicking on the the Geronimo Documentation
 link on
   http://myhost:8080/ takes me to
   http://geronimo.apache.org/documentation.html
 which doesn't currently
   have any 1.1 documentation.  What are the plans
 for the 1.1 documentation?
 
  I'm planning to update the web site today so it
 will point to the new cwiki with the 1.0 and 1.1
  (inprogress) documentation
  
   * Clicking on the Additional Documentation
 link on http://myhost:8080/
   takes me to
  

http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Home
   which contains a warning that the documentation
 has moved to
   http://cwiki.apache.org/geronimo .  Are we
 planning on changing this to
   take users directly to
 http://cwiki.apache.org/geronimo ?
 
  Additional Documentation is using a redirect
 

(http://geronimo.apache.org/redirects/additionalDocumentation.html)
 to point to the Atlassian
  confluence. Fixing this redirect is part of the
 web site update.
 
  I just froze (for edit) the confluence
 installation at Atlassian so we will not have more
 adds there
  (wanted or unwanted). I've been adding labels to
 some pages on that installation to point to the new
  cwiki.apache.org/geronimo. As far as I know, we
 can not add an automatic redirect directly from a
  confluence page.
 
  Cheers!
  Hernan
 
   Other comments in-line below..
  
   I'm still kicking the tires..
  
   John
  
   Matt Hogstrom wrote:
  
   All,
  
   I have created what I hope is the final release
 of Geronimo 1.1.
   There has been a lot of work that has gone into
 this release (please
   review the RELEASE-NOTES).  Here are the final
 release candidates for
   your review.
  
   *DayTrader Application*
  

http://people.apache.org/~hogstrom/1.1-final/daytrader-ear-1.1.ear
  
   I'm working on a website and documentation to
 help folks out but the
   deliverable is the ear above.
  
   *Geronimo 1.1 Version*
  
 *Source*
  

http://people.apache.org/~hogstrom/1.1-final/geronimo-1.1_src.tar.gz
  

http://people.apache.org/~hogstrom/1.1-final/geronimo-1.1_src.zip
  
 *Full J2EE Jetty Version*
  
  

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

http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-j2ee-1.1.zip
  
 *Minimal Jetty Version*
  
  

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

http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-minimal-1.1.zip
  
  
 *Full Tomcat Version*
  
  

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

http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-j2ee-1.1.zip
  
 *Minimal Tomcat Version*
  
  

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

http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-minimal-1.1.zip
  
  
  
   *Geronimo 1.1 Source Code*
  
   FYI (in case you re-use this mail) the line
 above should read *Geronimo
   1.1 Specs*
  
  
  

http://people.apache.org/~hogstrom/1.1-final/org.apache.geronimo.specs.tar.gz
  
  
  

http://people.apache.org/~hogstrom/1.1-final/org.apache.geronimo.specs.zip
  
  
   Is there are reason why the specs distributions
 don't have a version in
   their file name? Shouldn't it be 1.0.1?
  
   Please remember that only PMC votes are binding
 but they will
   ultimately make their decision based on your
 feedback.
  
   Thanks to everyone who has spent long hours
 working on this.
  
   A special thanks to Jencks, Sisson and Miller
 who spent long days
   working on getting the final release right with
 License issues, last
   minute release note changes, etc.
  
   I look forward to a positive outcome and a
 unanimous vote by Sunday.
   Assuming all goes well by Sunday night I will
 propogate the jars to
   the mirrors on Sunday and declare the release
 official on Tuesday.
  
   Cross your fingers, grab your beverage of
 choice and let's close this
   release out.
  
   Matt

Re: Group membership protocol ...

2006-06-22 Thread James Strachan


I replied on the other thread :) basically ActiveCluster

On 6/21/06, Komandur [EMAIL PROTECTED] wrote:


Hi,

Is any group membership protocol implemented as part of ActiveMQ ?
(I have seen references to ActiveCluster, and would like to know if AMQ
 uses it for any of the configurations).

Thanks
Regards
- Sridhar

ps: I will try delete it from the Users group
--
View this message in context: 
http://www.nabble.com/Group-membership-protocol-...-t1825489.html#a4979496
Sent from the ActiveMQ - Dev forum at Nabble.com.





--

James
---
http://radio.weblogs.com/0112098/

Re: [jira] Commented: (GERONIMO-2135) Improve the ActiveMQ GBeans

2006-06-22 Thread David Jencks

This patch addresses my major concerns. I consider it
a bug fix and thus not requiring further voting beyond
my previous +1, but in case anyone disagrees, I've
applied it and tested it to the best of my abilities
and vote +1.

thanks
david jencks


--- Gianny Damour (JIRA) dev@geronimo.apache.org
wrote:

 [

http://issues.apache.org/jira/browse/GERONIMO-2135?page=comments#action_12417237
 ] 
 
 Gianny Damour commented on GERONIMO-2135:
 -
 
 I had a look to the patch and vote +1 for it. Some
 more details:
 1. is fixed.
 2. is not fixed.
 3. is partially fixed
 4. is not fixed
 5., 6. and 7. do not know
 8. is fixed. Also, it seems that we also avoid
 abstract from methods in interfaces (one occurence
 in BrokerServiceGBean).
 
 
  Improve the ActiveMQ GBeans
  ---
 
   Key: GERONIMO-2135
   URL:
 http://issues.apache.org/jira/browse/GERONIMO-2135
   Project: Geronimo
  Type: Improvement
  Security: public(Regular issues) 
Components: ActiveMQ
  Reporter: Hiram Chirino
  Assignee: Hiram Chirino
   Fix For: 1.2
   Attachments: GERONIMO-2135.patch
 
  Suggestions by David Jencks:
  I think that this gbean adaptation code should be
 in geronimo rather
  than amq.  I'm OK with applying it as is but would
 prefer some issues
  to be addressed first or, even better, 
 immediately after the
  transfer (assuming it is done with svn mv).
  1. DataSourceReference should be replaced by the
 geronimo class that
  does the same thing, ConnectionFactorySource.
  2. I think it would be preferable to get the
 module/configuration
  classloader in the constructor as a magic
 attribute and use it in
  BrokerServiceGBeanImpl.doStart rather than the
 classloader of
  BrokerServiceGBeanImpl.
  3. Same for TransportConnectorGBeanImpl.
  4. This is a question, not really an issue, about
 this code:
  +protected TransportConnector
 createBrokerConnector(String url)
  throws Exception {
  +return

brokerService.getBrokerContainer().addConnector(url);
  +}
  To me it seems like this code is combining the
 functions of factory
  object and container.  Is this necessary and
 appropriate?  I'd be
  more comfortable with
  Connector connector =
 ConnectorFactory.createConnector(url);
 

brokerService.getBrokerContainer().addConnector(connector);
  I find that the combination style typically
 creates problems whenever
  trying to extend stuff, say by wrapping the
 connector.  What do you
  think?
  5. hardcoding the protocols in
 ActiveMQManagerGBean seems like a
  temporary expedient at best.
  6. javadoc on public JMSConnector addConnector(
 ... in the manager
  gbean seems wrong... does not appear to return an
 object name.
  7. Typo and innaccuracies in the first
 package.html... this stuff is
  only going to work in geronimo, jsr77/88 is not
 enough.
  8. I'm not sure exactly what our official policy
 is but I prefer to
  remove public from methods in interfaces since
 it is the only
  choice and implied.
 
 -- 
 This message is automatically generated by JIRA.
 -
 If you think it was sent incorrectly contact one of
 the administrators:
   

http://issues.apache.org/jira/secure/Administrators.jspa
 -
 For more information on JIRA, see:
http://www.atlassian.com/software/jira

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

2006-06-22 Thread Matt Hogstrom

I think moving from branches to tags and back again is too disruptive. The reason it sits in its
own area in branches is so that it can be finalized and then copied once its done. If we have to
then we have to but this should be the rare exception that something is caught after the final vote
has been cast.

Aaron Mulder wrote:

+1, but if we cut a release from the frozen branch, we need to note
the SVN version number or something so when we move it to tags we're
absolutely sure we didn't catch an extra commit in the tag. I'm also
fine with copying to tags, making the candidate from tags, and then
recreating the tag if another release candidate turns out to be
necessary.

Thanks,
Aaron

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

Okay, then +1

--jason

On Jun 21, 2006, at 10:19 PM, David Blevins wrote:

The only thing done in a branches/x.y.z made from branches/x.y is
the release process itself. When we agree we look good enough to
cut and run, we freeze, make the branch and put together a release
candidate. At the point of the freeze the release manager owns the
branches/x.y.z till the vote passes. That's the ideal scenario
anyway.

-David

On Jun 21, 2006, at 9:40 PM, Jason Dillon wrote:

Does this mean that the bulk of changes will be done on M.m
branches and only release + minor changes done on M.m.r branches?

--jason

On Jun 21, 2006, at 6:52 PM, David Blevins wrote:

We had this whole conversation last week, lots of good discussion
was
had. I'd prefer not to have to have it again. Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.

1. branches/x.y would be the branch for all x.y.z releases

2. when a release is frozen, we spin off a branch with that
*exact*
name, as in branches/x.y.z, where z starts at zero and
increments
by one.

3. at that time branches/x.y is immediately updated to version
x.y.(z+1)-SNAPSHOT

3. We cut releases from the frozen branch

4. When a release passes final tck testing and final vote, the
frozen branch is moved to tags

We create a branch at freeze time for the following reasons:

1. it takes *at least* one week from freeze to ship due to voting,
tck testing and potential repeats of that process (re-cut,
re-certify, re-vote). There is no reason why work on x.y.z+1
needs to be delayed -- only 52 weeks a year.

2. stronger guarantee no one is updating the branch once frozen

3. less likely that people and ci systems (continuum) will checkout
and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)
which
would need to be removed manually and may accidentally be
distributed.

4. it is currently very difficult to roll version numbers forward,
entries here and there are often missed. Far better to have
branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
than a few overlooked x.y.z final numbers that needed to go back
to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
back later if that process happens in the frozen branch.

Here is my +1

-- David

On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

After the branches/1.1 was moved to tags there was some question
as to what happened to the 1.1 branch. At that time some kind
soul created a new branches/1.1.1. No activity has occurred in
that branch and given that we'll need to define the release
goals of 1.1.1 soon I'd like to propose the following.

After 1.1 is released:

* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1

When 1.1.1 enters time for release

* Move branches/1.1.1 to branches/1.1.1.0
* Change version from 1.1.1-SNAPSHOT to 1.1.1
* Create release candidate rc1
* put out for a vote
* get a successful vote with no respins :)
* move from branches/1.1.1.0 to tags/1.1.1.0

Based on all the confusion in the past I think this procedure
makes it clear what phase were in for the release as well as
avoids tagging and branching repeatedly.

I'm looking for lazy consensus and not a formal vote.

Matt

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

2006-06-22 Thread Matt Hogstrom

Thanks David, I tried to recap in the other thread and didn't receive any additional responses so
now that we have a branches/1.1.0 branches/1.1 and a branches/1.1.1 I don't think we quite nailed
it. Your summary is great and I concur.

Here is my + 1 and I'm happy to get the Wiki updated.

The remaining question is what to do with the branches that are out there. I think we should whack
what's out there (does not appear that there has been any activity) branches/1.1 and branches/1.1.1.
When the vote is complete later today and we release 1.1 I'll move branches/1.1.0 to tags/1.1.0
and then make the copy to branches/1.1 and update the versions to 1.1.1-SNAPSHOT as well as the
plugin releases.

Then I think we're open for G-Business.

David Blevins wrote:

We had this whole conversation last week, lots of good discussion was
had. I'd prefer not to have to have it again. Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.

1. branches/x.y would be the branch for all x.y.z releases

2. when a release is frozen, we spin off a branch with that *exact*
name, as in branches/x.y.z, where z starts at zero and increments
by one.

3. at that time branches/x.y is immediately updated to version
x.y.(z+1)-SNAPSHOT

3. We cut releases from the frozen branch

4. When a release passes final tck testing and final vote, the
frozen branch is moved to tags

We create a branch at freeze time for the following reasons:

2. stronger guarantee no one is updating the branch once frozen

3. less likely that people and ci systems (continuum) will checkout
and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
would need to be removed manually and may accidentally be
distributed.

Here is my +1

-- David

On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

After the branches/1.1 was moved to tags there was some question as to
what happened to the 1.1 branch. At that time some kind soul created
a new branches/1.1.1. No activity has occurred in that branch and
given that we'll need to define the release goals of 1.1.1 soon I'd
like to propose the following.

After 1.1 is released:

* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1

When 1.1.1 enters time for release

Based on all the confusion in the past I think this procedure makes it
clear what phase were in for the release as well as avoids tagging and
branching repeatedly.

I'm looking for lazy consensus and not a formal vote.

Matt

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

2006-06-22 Thread Alan D. Cabrera


David Blevins wrote:


On Jun 21, 2006, at 10:53 PM, Alan D. Cabrera wrote:


David Blevins wrote:
The only thing done in a branches/x.y.z made from branches/x.y is 
the release process itself.

I don't quite understand what this means.  Sorry.


Referring to things like switching the version numbers, etc.  The 
button it up stuff.  Specifically trying to exclude thinks like 
let's fix these 20 bugs.  The only bugs fixed would be in the event 
the release candidate had an unacceptable issue and it's vote did not 
pass.  That's the spirit of it anyway.


Thanks that clears it up for me.  Agreed.


Regards,
Alan

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

2006-06-22 Thread John Sisson


+1 to David's recap and to Matts plans below.

John
Matt Hogstrom wrote:
Thanks David,  I tried to recap in the other thread and didn't receive 
any additional responses so now that we have a branches/1.1.0 
branches/1.1 and a branches/1.1.1 I don't think we quite nailed it.  
Your summary is great and I concur.


Here is my + 1 and I'm happy to get the Wiki updated.

The remaining question is what to do with the branches that are out 
there.  I think we should whack what's out there (does not appear that 
there has been any activity) branches/1.1 and branches/1.1.1.  When 
the vote is complete later today and we release 1.1 I'll move 
branches/1.1.0 to tags/1.1.0 and then make the copy to branches/1.1 
and update the versions to 1.1.1-SNAPSHOT as well as the plugin releases.


Then I think we're open for G-Business.

David Blevins wrote:

We had this whole conversation last week, lots of good discussion was
had.  I'd prefer not to have to have it again.  Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.

1.   branches/x.y would be the branch for all x.y.z releases

2.   when a release is frozen, we spin off a branch with that *exact*
 name, as in branches/x.y.z, where z starts at zero and increments
 by one.

3.   at that time branches/x.y is immediately updated to version
 x.y.(z+1)-SNAPSHOT

3.   We cut releases from the frozen branch

4.   When a release passes final tck testing and final vote, the
 frozen branch is moved to tags

We create a branch at freeze time for the following reasons:

1.  it takes *at least* one week from freeze to ship due to voting,
tck testing and potential repeats of that process (re-cut,
re-certify, re-vote).  There is no reason why work on x.y.z+1
needs to be delayed -- only 52 weeks a year.

2.  stronger guarantee no one is updating the branch once frozen

3.  less likely that people and ci systems (continuum) will checkout
and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
would need to be removed manually and may accidentally be
distributed.

4.  it is currently very difficult to roll version numbers forward,
entries here and there are often missed.  Far better to have
branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
than a few overlooked x.y.z final numbers that needed to go back
to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
back later if that process happens in the frozen branch.


Here is my +1


-- David



On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

After the branches/1.1 was moved to tags there was some question as 
to what happened to the 1.1 branch.  At that time some kind soul 
created a new branches/1.1.1.  No activity has occurred in that 
branch and given that we'll need to define the release goals of 
1.1.1 soon I'd like to propose the following.


After 1.1 is released:

* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1

When 1.1.1 enters time for release

* Move branches/1.1.1 to branches/1.1.1.0
* Change version from 1.1.1-SNAPSHOT to 1.1.1
* Create release candidate rc1
* put out for a vote
* get a successful vote with no respins :)
* move from branches/1.1.1.0 to tags/1.1.1.0

Based on all the confusion in the past I think this procedure makes 
it clear what phase were in for the release as well as avoids 
tagging and branching repeatedly.


I'm looking for lazy consensus and not a formal vote.

Matt

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

2006-06-22 Thread Gianny Damour


+1

Gianny

David Blevins wrote:


We had this whole conversation last week, lots of good discussion was
had.  I'd prefer not to have to have it again.  Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.

1.   branches/x.y would be the branch for all x.y.z releases

2.   when a release is frozen, we spin off a branch with that *exact*
 name, as in branches/x.y.z, where z starts at zero and increments
 by one.

3.   at that time branches/x.y is immediately updated to version
 x.y.(z+1)-SNAPSHOT

3.   We cut releases from the frozen branch

4.   When a release passes final tck testing and final vote, the
 frozen branch is moved to tags

We create a branch at freeze time for the following reasons:

1.  it takes *at least* one week from freeze to ship due to voting,
tck testing and potential repeats of that process (re-cut,
re-certify, re-vote).  There is no reason why work on x.y.z+1
needs to be delayed -- only 52 weeks a year.

2.  stronger guarantee no one is updating the branch once frozen

3.  less likely that people and ci systems (continuum) will checkout
and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
would need to be removed manually and may accidentally be
distributed.

4.  it is currently very difficult to roll version numbers forward,
entries here and there are often missed.  Far better to have
branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
than a few overlooked x.y.z final numbers that needed to go back
to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
back later if that process happens in the frozen branch.


Here is my +1


--  David



On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

After the branches/1.1 was moved to tags there was some question as  
to what happened to the 1.1 branch.  At that time some kind soul  
created a new branches/1.1.1.  No activity has occurred in that  
branch and given that we'll need to define the release goals of  
1.1.1 soon I'd like to propose the following.


After 1.1 is released:

* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1

When 1.1.1 enters time for release

* Move branches/1.1.1 to branches/1.1.1.0
* Change version from 1.1.1-SNAPSHOT to 1.1.1
* Create release candidate rc1
* put out for a vote
* get a successful vote with no respins :)
* move from branches/1.1.1.0 to tags/1.1.1.0

Based on all the confusion in the past I think this procedure makes  
it clear what phase were in for the release as well as avoids  
tagging and branching repeatedly.


I'm looking for lazy consensus and not a formal vote.

Matt

[jira] Created: (GERONIMO-2141) javamail providers component referencing non-released version of activation specs.

javamail providers component referencing non-released version of activation 
specs.
--

 Key: GERONIMO-2141
 URL: http://issues.apache.org/jira/browse/GERONIMO-2141
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: mail  
Versions: 1.2
Reporter: Rick McGuire
 Assigned to: Rick McGuire 
Priority: Minor
 Fix For: 1.2


The continuum builds of the javamail component code are failing because it 
references a dependency on the 1.1 version of the activation spec.  This is 
reaching ahead to the yet unreleased 1.1 version...it still needs to be 
referencing the 1.1-SNAPSHOT version until 1.1 is officially released. 

-- 
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: (GERONIMO-2141) javamail providers component referencing non-released version of activation specs.

 [ http://issues.apache.org/jira/browse/GERONIMO-2141?page=all ]
 
Rick McGuire resolved GERONIMO-2141:


Resolution: Fixed

Committed revision 416340.

Also fixed a copyright problem with a couple of the pom.xml files. 

 javamail providers component referencing non-released version of activation 
 specs.
 --

  Key: GERONIMO-2141
  URL: http://issues.apache.org/jira/browse/GERONIMO-2141
  Project: Geronimo
 Type: Bug
 Security: public(Regular issues) 
   Components: mail
 Versions: 1.2
 Reporter: Rick McGuire
 Assignee: Rick McGuire
 Priority: Minor
  Fix For: 1.2


 The continuum builds of the javamail component code are failing because it 
 references a dependency on the 1.1 version of the activation spec.  This is 
 reaching ahead to the yet unreleased 1.1 version...it still needs to be 
 referencing the 1.1-SNAPSHOT version until 1.1 is officially released. 

-- 
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: (GERONIMODEVTOOLS-83) Build fails for plugin org.apache.geronimo.st.v11.ui

2006-06-22 Thread Sachin Patel (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83?page=all ]
 
Sachin Patel resolved GERONIMODEVTOOLS-83:
--

Resolution: Cannot Reproduce

Actually I've seen random compile errors like this once in a blue moon.  I 
think this is some type of issue with Maven, but have not investigated further.

A recompile usually fixes the problem.

 Build fails for plugin org.apache.geronimo.st.v11.ui
 

  Key: GERONIMODEVTOOLS-83
  URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83
  Project: Geronimo-Devtools
 Type: Bug

   Components: eclipse-plugin
  Environment: WinXP, Sun Java 1.4.2_12, Maven 2.0.4
 Reporter: Donald Woods
 Assignee: Sachin Patel
 Priority: Blocker


 Have not been able to build trunk Rev411643.  During the build, I'm getting 
 the following failure for plugins\org.apache.geronimo.st.v1.core
 . . .snip
 [INFO] 
 
 [INFO] Building org.apache.geronimo.st.v1.core
 [INFO]task-segment: [install]
 [INFO] 
 
 [INFO] [geronimodevtools:download {execution: install-dependencies}]
 [INFO] emf-sdo-xsd-SDK-2.1.2.zip already exists in local repository
 [INFO] JEM-SDK-1.1.0.1.zip already exists in local repository
 [INFO] GEF-SDK-3.1.1.zip already exists in local repository
 [INFO] wtp-sdk-R-1.0.2-200604280245.zip already exists in local repository
 [INFO] eclipse-SDK-3.1.2-win32.zip already exists in local repository
 [INFO] [geronimodevtools:manifestbundles {execution: install-dependencies}]
 [INFO] [geronimodevtools:install {execution: install-dependencies}]
 [INFO] org.eclipse.jdt.core : 3.1.2 already exists in local repository.
 [INFO] org.eclipse.emf.mapping.xsd2ecore : 2.1.0 already exists in local 
 repository.
 [INFO] org.eclipse.emf.common : 2.1.0 already exists in local repository.
 [INFO] org.eclipse.wst.server.core : 1.0.2.v20060406 already exists in local 
 repository.
 [INFO] org.eclipse.wst.web : 1.0.1.v200603160007 already exists in local 
 repository.
 [INFO] org.eclipse.jst.j2ee : 1.0.1.v200604191828 already exists in local 
 repository.
 [INFO] org.eclipse.core.runtime : 3.1.2 already exists in local repository.
 [INFO] org.eclipse.debug.core : 3.1.2 already exists in local repository.
 [INFO] org.eclipse.emf.ecore : 2.1.0 already exists in local repository.
 [INFO] org.eclipse.emf.mapping.xsd2ecore.editor : 2.1.0 already exists in 
 local repository.
 [INFO] org.eclipse.jdt.launching : 3.1.0 already exists in local repository.
 [INFO] org.eclipse.xsd.edit : 2.1.0 already exists in local repository.
 [INFO] org.eclipse.jst.server.core : 1.0.2.v20060402 already exists in local 
 repository.
 [INFO] org.eclipse.wst.common.project.facet.core : 1.0.1.v200603242204 
 already exists in local repository.
 [INFO] org.eclipse.emf.mapping.ui : 2.1.0 already exists in local repository.
 [INFO] org.eclipse.wst.common.frameworks : 1.0.1.v200602070050 already exists 
 in local repository.
 [INFO] org.eclipse.jst.server.generic.core : 1.0.0.v200602112126 already 
 exists in local repository.
 [INFO] org.eclipse.wst.common.modulecore : 1.0.1.v200604191828 already exists 
 in local repository.
 [INFO] org.eclipse.osgi : 3.1.2 already exists in local repository.
 [INFO] [geronimodevtools:download {execution: install-dependencies}]
 [INFO] emf-sdo-xsd-SDK-2.1.2.zip already exists in local repository
 [INFO] JEM-SDK-1.1.0.1.zip already exists in local repository
 [INFO] GEF-SDK-3.1.1.zip already exists in local repository
 [INFO] wtp-sdk-R-1.0.2-200604280245.zip already exists in local repository
 [INFO] eclipse-SDK-3.1.2-win32.zip already exists in local repository
 [INFO] [geronimodevtools:manifestbundles {execution: install-dependencies}]
 [INFO] [geronimodevtools:install {execution: install-dependencies}]
 [INFO] org.eclipse.jdt.core : 3.1.2 already exists in local repository.
 [INFO] org.eclipse.emf.mapping.xsd2ecore : 2.1.0 already exists in local 
 repository.
 [INFO] org.eclipse.emf.common : 2.1.0 already exists in local repository.
 [INFO] org.eclipse.wst.server.core : 1.0.2.v20060406 already exists in local 
 repository.
 [INFO] org.eclipse.wst.web : 1.0.1.v200603160007 already exists in local 
 repository.
 [INFO] org.eclipse.jst.j2ee : 1.0.1.v200604191828 already exists in local 
 repository.
 [INFO] org.eclipse.core.runtime : 3.1.2 already exists in local repository.
 [INFO] org.eclipse.debug.core : 3.1.2 already exists in local repository.
 [INFO] org.eclipse.emf.ecore : 2.1.0 already exists in local repository.
 [INFO] org.eclipse.emf.mapping.xsd2ecore.editor : 2.1.0 already exists in 
 local repository.
 [INFO] org.eclipse.jdt.launching : 3.1.0 already exists in local repository.
 [INFO] org.eclipse.xsd.edit : 2.1.0 already exists in local repository.
 [INFO]

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

2006-06-22 Thread David Jencks


+1 to david and alan's annotations.

Lets get it in the wiki!

thanks
david jencks

On Jun 22, 2006, at 4:06 AM, Alan D. Cabrera wrote:


+1

I think that we should mention that patches that go into

x.y.z also go into x.y and trunk
x.y also go into trunk

Last time we neglected to apply patches evenly across the board  
when fixes were checked into one branch.  This is one reason why  
the versions drifted so wildly apart.


Regards,
Alan

David Blevins wrote:

We had this whole conversation last week, lots of good discussion was
had.  I'd prefer not to have to have it again.  Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.

1.   branches/x.y would be the branch for all x.y.z releases

2.   when a release is frozen, we spin off a branch with that *exact*
 name, as in branches/x.y.z, where z starts at zero and  
increments

 by one.

3.   at that time branches/x.y is immediately updated to version
 x.y.(z+1)-SNAPSHOT

3.   We cut releases from the frozen branch

4.   When a release passes final tck testing and final vote, the
 frozen branch is moved to tags

We create a branch at freeze time for the following reasons:

1.  it takes *at least* one week from freeze to ship due to voting,
tck testing and potential repeats of that process (re-cut,
re-certify, re-vote).  There is no reason why work on x.y.z+1
needs to be delayed -- only 52 weeks a year.

2.  stronger guarantee no one is updating the branch once frozen

3.  less likely that people and ci systems (continuum) will checkout
and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)  
which

would need to be removed manually and may accidentally be
distributed.

4.  it is currently very difficult to roll version numbers forward,
entries here and there are often missed.  Far better to have
branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
than a few overlooked x.y.z final numbers that needed to go back
to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
back later if that process happens in the frozen branch.


Here is my +1


-- David



On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

After the branches/1.1 was moved to tags there was some question  
as to what happened to the 1.1 branch.  At that time some kind  
soul created a new branches/1.1.1.  No activity has occurred in  
that branch and given that we'll need to define the release goals  
of 1.1.1 soon I'd like to propose the following.


After 1.1 is released:

* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1

When 1.1.1 enters time for release

* Move branches/1.1.1 to branches/1.1.1.0
* Change version from 1.1.1-SNAPSHOT to 1.1.1
* Create release candidate rc1
* put out for a vote
* get a successful vote with no respins :)
* move from branches/1.1.1.0 to tags/1.1.1.0

Based on all the confusion in the past I think this procedure  
makes it clear what phase were in for the release as well as  
avoids tagging and branching repeatedly.


I'm looking for lazy consensus and not a formal vote.

Matt

[jira] Created: (GERONIMO-2142) EJB Refs to EJB in parent module often fail

EJB Refs to EJB in parent module often fail
---

 Key: GERONIMO-2142
 URL: http://issues.apache.org/jira/browse/GERONIMO-2142
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: deployment, OpenEJB  
Versions: 1.1
Reporter: Aaron Mulder
 Assigned to: Aaron Mulder 
 Fix For: 1.1.1


In OpenEJBReferenceBuilder:

createEJBLocalRef and createEJBRemoteRef accept a targetConfigId argument.

Then they often call getMatch or getImplicitMatch and don't use the 
targetConfigId.  As a result, the current module's ID is always used as the 
targetConfigId:

context.findGBeans(new AbstractNameQuery(context.getId(), ...

This means that the query will never match EJBs in a parent of the current 
configuration.  It should be changed to use the targetConfigId instead of the 
current module's ID.

This does not come up if a pattern element is used in the mapping, though that 
mapping strategy runs into a different 1.1 bug (ClassCastException on 
org.openejb.proxy.ProxyInfo)

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

2006-06-22 Thread Jeff Genender



Aaron Mulder wrote:
 On 6/21/06, Jeff Genender [EMAIL PROTECTED] wrote:
 Personal preference...but I think its better throwing an error.  Is
 obsoleting a settable option?  I am not so sure I like obsoleting by
 default...this could be ugly since it may be another app other than the
 Welcome app that gets obsoleted.
 
 You don't have to obsolete anything -- I said you can do that.  If
 you use the obsoletes, you provide module IDs you obsolete.  So you
 could specify geronimo/welcome/*/car and it would remove the welcome
 app if present and not if not and you wouldn't obsolete anything else
 that happened to be listening on /
 

I read that you stated, It's kind of heavy-handed, but probably better
than having it install and immediately fail due to the context root
conflict.

I disagreed with that statement you made.  I don't believe anything
should supersede any application, except those that are controlled by
themselves (i.e Liferay superseding an earlier version of Liferay).


 Thanks,
 Aaron
 
  As far as populating the database, you can provide a GBean that runs
  whenever a flag like initialized is false.  Every time it starts it
  can check the flag and abort if it's set.  If it's not set, it can do
  its work, and then set the flag on itself (via a roundabout kernel
  call), so it will never execute the initialization again.  Or, of
  course, just connect to the DB and only execute the initialization if
  some known Liferay table is not present.
 
  Thanks,
 Aaron
 
  On 6/21/06, Paul McMahan [EMAIL PROTECTED] wrote:
  Liferay is an open source portal made available under the MIT license.
   They provide a geronimo+liferay distribution from their website,
  which is basically a zipped up geronimo/tomcat server with liferay
  already deployed. I had some problems starting a fresh install of this
  distribution due to hsql database driver issues.  Hopefully new users
  who experience this same problem will find the entry I posted in
  liferay's support forum about how to get it working:
  http://forums.liferay.com/index.php?showtopic=5348
 
  Liferay currently uses a snapshot of geronimo 1.1 from 5/3/2006 which
  has the new versioning functionality but as you can imagine is missing
  several important bug fixes and schema changes.  I got their WAR
  working in geronimo 1.1 after making some adjustments to its
  geronimo-web.xml.  When geronimo 1.1 is officially released I'll offer
  my assistance to help them upgrade to it.
 
  I also think and have heard others mention that liferay is a great
  candidate for a geronimo plugin. Adding the necessary plugin files to
  the liferay WAR is straightforward.  But there are a couple of
  interesting challenges where I would like to get your input.   First
  is that the plugin prereqs a database pool.  Some expert users will
  want to manually create and populate the database and then use the
  console to point a db pool at it before installing the liferay plugin.
   But I imagine that some developers and more casual users would like
  for geronimo to automatically create a database pool for them as part
  of the liferay plugin install process.  That way they could add a
  working portal server to their geronimo server with only a few clicks
  in the console (remember Joe's mom? ;-)
 
  For this latter class of users geronimo could provide a plugin that
  defines a derby datasource and automatically populates the database
  when the plugin is installed.  Does this sound like a reasonable idea?
   I thought geronimo might already provide some facility to populate
  the database and I found this dev thread from last year where its
  proposed but (I assume) not implemented yet :
 
 http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL 
 PROTECTED]

 
  This idea sounds right on to me.  Are others still in favor of it?  If
  so then I would like to work on an implementation. By the way,
  liferay currently does not support derby but I have it (mostly)
  working via a patch that I'll submit to them later.
 
  The second interesting aspect of creating liferay plugin is that
  liferay wants to use '/' for its context root.  The problem is that
  the geronimo welcome app is already installed in the '/' context root
  and this prevents liferay from starting.  I tried moving it to a
  different context root but then hard-coded references to scripts and
  images in their html started breaking. Is there a way to make
  geronimo override a context root such that last in wins?  Or could the
  plugin metadata specify the required context root so that the console
  can warn the user about potential conflicts before installing the
  plugin? Any ideas?
 
  Looking forward to your feedback.
 
  Best wishes,
  Paul

Re: liferay

2006-06-22 Thread Paul McMahan


Thanks Matt this helps a lot.  Sounds like
DirectoryInitializationGBean can get the job done, mainly due to the
fact that creating a database in derby is as easy as copying a
directory into var/derby.  I'll look into this approach for the
initial rev of the liferay database pool plugin and think longer term
about creating a more specialized GBean which can run arbitrary sql
against a database connection supplied in the plan xml.

Paul


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

Paul,

David Jencks wrote a GBean to do mostly what your looking for.  If you look in
applications/daytrader/derby you'll find how the database is predefined for 
derby.  In the DayTrader
plan built in configs/daytrader/src/plan/target/plan.xml you'll find an entry 
in the deployment plan
the copies the pre-built database into the Geronimo var directory.

Here is the XML part of the deployment plan.

   gbean name=DaytraderResources
class=org.apache.geronimo.system.util.DirectoryInitializationGBean
 !--copies daytrader derby db files into specified location--
 attribute name=prefixMETA-INF/geronimo-daytrader-derby-db/attribute
 attribute name=pathvar/derby/attribute
 reference name=ServerInfo
   nameServerInfo/name
 /reference

I think this is what your are looking for.  Does this help?

Paul McMahan wrote:
 Liferay is an open source portal made available under the MIT license.
 They provide a geronimo+liferay distribution from their website,
 which is basically a zipped up geronimo/tomcat server with liferay
 already deployed. I had some problems starting a fresh install of this
 distribution due to hsql database driver issues.  Hopefully new users
 who experience this same problem will find the entry I posted in
 liferay's support forum about how to get it working:
 http://forums.liferay.com/index.php?showtopic=5348

 Liferay currently uses a snapshot of geronimo 1.1 from 5/3/2006 which
 has the new versioning functionality but as you can imagine is missing
 several important bug fixes and schema changes.  I got their WAR
 working in geronimo 1.1 after making some adjustments to its
 geronimo-web.xml.  When geronimo 1.1 is officially released I'll offer
 my assistance to help them upgrade to it.

 I also think and have heard others mention that liferay is a great
 candidate for a geronimo plugin. Adding the necessary plugin files to
 the liferay WAR is straightforward.  But there are a couple of
 interesting challenges where I would like to get your input.   First
 is that the plugin prereqs a database pool.  Some expert users will
 want to manually create and populate the database and then use the
 console to point a db pool at it before installing the liferay plugin.
 But I imagine that some developers and more casual users would like
 for geronimo to automatically create a database pool for them as part
 of the liferay plugin install process.  That way they could add a
 working portal server to their geronimo server with only a few clicks
 in the console (remember Joe's mom? ;-)

 For this latter class of users geronimo could provide a plugin that
 defines a derby datasource and automatically populates the database
 when the plugin is installed.  Does this sound like a reasonable idea?
 I thought geronimo might already provide some facility to populate
 the database and I found this dev thread from last year where its
 proposed but (I assume) not implemented yet :
 http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL 
PROTECTED]

 This idea sounds right on to me.  Are others still in favor of it?  If
 so then I would like to work on an implementation. By the way,
 liferay currently does not support derby but I have it (mostly)
 working via a patch that I'll submit to them later.

 The second interesting aspect of creating liferay plugin is that
 liferay wants to use '/' for its context root.  The problem is that
 the geronimo welcome app is already installed in the '/' context root
 and this prevents liferay from starting.  I tried moving it to a
 different context root but then hard-coded references to scripts and
 images in their html started breaking. Is there a way to make
 geronimo override a context root such that last in wins?  Or could the
 plugin metadata specify the required context root so that the console
 can warn the user about potential conflicts before installing the
 plugin? Any ideas?

 Looking forward to your feedback.

 Best wishes,
 Paul

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

2006-06-22 Thread Hiram Chirino


On 6/22/06, Aaron Mulder [EMAIL PROTECTED] wrote:

+1 To Jason's comments with Hiram's comments...

I think we should do all development of 1.1.x in branches/1.1 (with
version 1.1.N-SNAPSHOT).  But at the time we code freeze for a
release, I think we should svn copy branches/1.1 to branches/1.1.N and
finalize the version numbers there (to version 1.1.N) and make any
last-minute tweaks there and update branches/1.1 to version number
1.1.(N+1)-SNAPSHOT.  When we have a candidate for the release, then we
can svn copy branches/1.1.N to tags/1.1.N and build the release from
the tag.


BTW: I don't think there is any harm in doing the release from the
branch if the branch is copied to the tag since the source code should
be identical between them.  I think we should perhaps avoid creating
the the tag until we KNOW that the binary is approved.



Thanks,
   Aaron

On 6/21/06, Hiram Chirino [EMAIL PROTECTED] wrote:
 Hi Jason,

 The problem is that it can take weeks to do a geronimo release since
 stuff like CTS testing is involved.  So the release work (putting the
 finishing touches) needs to be done in a branch so that work can
 continue on the next release.

 Perhaps m2 has a way of dealing with those issues along with
 re-cutting releases and such.  But since I have not done a m2 based
 release yet, I'm not sure what's involved.  Could you clarify it a bit
 for me?

 On 6/21/06, Jason Dillon [EMAIL PROTECTED] wrote:
   Hi Jason,
  
   I agree that we should avoid branching.  But I do agree with the 1.1.1
   branch.  It's a dead-end branch in that it's only used to prepare he
   release.  Applying last minute fixes and changing version numbers.
   Since it's a dead-end branch, once the release if approved
   moving/deleting it makes sense.
 
  I would make those changes on the 1.1 branch (or trunk if we were
  using that codebase), then release and let Maven make the tag and
  then update the versions to the next SNAP.
 
  When moving to m2 we really need to follow the m2 release system,
  else the number of changes to poms is going to get out of control and
  will be very error prone.
 
  --jason
 
 
 


 --
 Regards,
 Hiram

 Blog: http://hiramchirino.com





--
Regards,
Hiram

Blog: http://hiramchirino.com

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

2006-06-22 Thread Hiram Chirino


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

Thanks David,  I tried to recap in the other thread and didn't receive any 
additional responses so
now that we have a branches/1.1.0 branches/1.1 and a branches/1.1.1 I don't 
think we quite nailed
it.  Your summary is great and I concur.

Here is my + 1 and I'm happy to get the Wiki updated.

The remaining question is what to do with the branches that are out there.  I 
think we should whack
what's out there (does not appear that there has been any activity) 
branches/1.1 and branches/1.1.1.
  When the vote is complete later today and we release 1.1 I'll move 
branches/1.1.0 to tags/1.1.0
and then make the copy to branches/1.1 and update the versions to 
1.1.1-SNAPSHOT as well as the
plugin releases.


+1



Then I think we're open for G-Business.

David Blevins wrote:
 We had this whole conversation last week, lots of good discussion was
 had.  I'd prefer not to have to have it again.  Here is my exact
 understanding of our consensus and would like to put it to a vote to
 avoid reinterpretation of that consensus in the future.

 1.   branches/x.y would be the branch for all x.y.z releases

 2.   when a release is frozen, we spin off a branch with that *exact*
  name, as in branches/x.y.z, where z starts at zero and increments
  by one.

 3.   at that time branches/x.y is immediately updated to version
  x.y.(z+1)-SNAPSHOT

 3.   We cut releases from the frozen branch

 4.   When a release passes final tck testing and final vote, the
  frozen branch is moved to tags

 We create a branch at freeze time for the following reasons:

 1.  it takes *at least* one week from freeze to ship due to voting,
 tck testing and potential repeats of that process (re-cut,
 re-certify, re-vote).  There is no reason why work on x.y.z+1
 needs to be delayed -- only 52 weeks a year.

 2.  stronger guarantee no one is updating the branch once frozen

 3.  less likely that people and ci systems (continuum) will checkout
 and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
 would need to be removed manually and may accidentally be
 distributed.

 4.  it is currently very difficult to roll version numbers forward,
 entries here and there are often missed.  Far better to have
 branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
 than a few overlooked x.y.z final numbers that needed to go back
 to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
 back later if that process happens in the frozen branch.


 Here is my +1


 -- David



 On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

 After the branches/1.1 was moved to tags there was some question as to
 what happened to the 1.1 branch.  At that time some kind soul created
 a new branches/1.1.1.  No activity has occurred in that branch and
 given that we'll need to define the release goals of 1.1.1 soon I'd
 like to propose the following.

 After 1.1 is released:

 * Delete branches/1.1.1
 * Move branches/1.1.0 to tags/1.1.0
 * Copy tags/1.1.0 to branches/1.1.1
 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
 * Start working on 1.1.1

 When 1.1.1 enters time for release

 * Move branches/1.1.1 to branches/1.1.1.0
 * Change version from 1.1.1-SNAPSHOT to 1.1.1
 * Create release candidate rc1
 * put out for a vote
 * get a successful vote with no respins :)
 * move from branches/1.1.1.0 to tags/1.1.1.0

 Based on all the confusion in the past I think this procedure makes it
 clear what phase were in for the release as well as avoids tagging and
 branching repeatedly.

 I'm looking for lazy consensus and not a formal vote.

 Matt









--
Regards,
Hiram

Blog: http://hiramchirino.com

Re: [VOTE] 1.1 Release

2006-06-22 Thread anita kulshreshtha

   I played around with j2ee-tomcat-server and came away with a good
first impression. I liked the 'usage' link on Database Pools and
Security Realms page. Here is my +1.

Thanks
Anita


P.S. - The copyright notice on console--welcome says :
Copyright © 1999-2005 Apache Software Foundation
All Rights Reserved
   Most other notices use 2006.  


--- David Jencks [EMAIL PROTECTED] wrote:

 +1 from me.
 
 thanks
 david jencks
 
 
 --- Prasad Kashyap [EMAIL PROTECTED]
 wrote:
 
  I did a sniff test of the installed product and I
  think we are good to go.
  
  +1 from me.
  
  I shall grill it some more tomorrow.
  
  Cheers
  Prasad
  
  On 6/19/06, Hernan Cunico [EMAIL PROTECTED] wrote:
  
  
   John Sisson wrote:
Some notes in relation to documentation:
   
* Clicking on the the Geronimo Documentation
  link on
http://myhost:8080/ takes me to
http://geronimo.apache.org/documentation.html
  which doesn't currently
have any 1.1 documentation.  What are the plans
  for the 1.1 documentation?
  
   I'm planning to update the web site today so it
  will point to the new cwiki with the 1.0 and 1.1
   (inprogress) documentation
   
* Clicking on the Additional Documentation
  link on http://myhost:8080/
takes me to
   
 
 http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Home
which contains a warning that the documentation
  has moved to
http://cwiki.apache.org/geronimo .  Are we
  planning on changing this to
take users directly to
  http://cwiki.apache.org/geronimo ?
  
   Additional Documentation is using a redirect
  
 
 (http://geronimo.apache.org/redirects/additionalDocumentation.html)
  to point to the Atlassian
   confluence. Fixing this redirect is part of the
  web site update.
  
   I just froze (for edit) the confluence
  installation at Atlassian so we will not have more
  adds there
   (wanted or unwanted). I've been adding labels to
  some pages on that installation to point to the new
   cwiki.apache.org/geronimo. As far as I know, we
  can not add an automatic redirect directly from a
   confluence page.
  
   Cheers!
   Hernan
  
Other comments in-line below..
   
I'm still kicking the tires..
   
John
   
Matt Hogstrom wrote:
   
All,
   
I have created what I hope is the final release
  of Geronimo 1.1.
There has been a lot of work that has gone into
  this release (please
review the RELEASE-NOTES).  Here are the final
  release candidates for
your review.
   
*DayTrader Application*
   
 
 http://people.apache.org/~hogstrom/1.1-final/daytrader-ear-1.1.ear
   
I'm working on a website and documentation to
  help folks out but the
deliverable is the ear above.
   
*Geronimo 1.1 Version*
   
  *Source*
   
 
 http://people.apache.org/~hogstrom/1.1-final/geronimo-1.1_src.tar.gz
   
 
 http://people.apache.org/~hogstrom/1.1-final/geronimo-1.1_src.zip
   
  *Full J2EE Jetty Version*
   
   
 

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

http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-j2ee-1.1.zip
   
  *Minimal Jetty Version*
   
   
 

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

http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-minimal-1.1.zip
   
   
  *Full Tomcat Version*
   
   
 

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

http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-j2ee-1.1.zip
   
  *Minimal Tomcat Version*
   
   
 

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

http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-minimal-1.1.zip
   
   
   
*Geronimo 1.1 Source Code*
   
FYI (in case you re-use this mail) the line
  above should read *Geronimo
1.1 Specs*
   
   
   
 

http://people.apache.org/~hogstrom/1.1-final/org.apache.geronimo.specs.tar.gz
   
   
   
 

http://people.apache.org/~hogstrom/1.1-final/org.apache.geronimo.specs.zip
   
   
Is there are reason why the specs distributions
  don't have a version in
their file name? Shouldn't it be 1.0.1?
   
Please remember that only PMC votes are binding
  but they will
ultimately make their decision based on your
  feedback.
   
Thanks to everyone who has spent long hours
  working on this.
   
A special thanks to Jencks, Sisson and Miller
  who spent long days
working on getting the final release right with
  License issues, last
minute release note changes, etc.
   
I look forward to a positive outcome and a
  unanimous vote by Sunday.
Assuming all goes well by Sunday night I will
  propogate the jars to
the mirrors on Sunday and declare the release
  official on Tuesday.
   
Cross your fingers, grab your beverage of
  choice and let's close this
release out.
   
Matt
 
=== message truncated

Re: liferay

2006-06-22 Thread Paul McMahan


Thanks for the suggestions Aaron.  Comments inline.

On 6/21/06, Aaron Mulder [EMAIL PROTECTED] wrote:

There are two options you should be aware of for a plugin.

One is that you can declare a database pool dependency named
LiferayDatabase or whatever.  Then provide a Derby database pool
plugin with that name.  If the user creates a custom database pool
named LiferayDatabase then the Liferay plugin will map to that,
whatever it is.  If not, it will download and install the Derby
database pool.  (This only works for embedded databases like Derby
where there's no need to point it to a specific DB server, etc.)  The
simple alternative is to make the database pool a prerequisite instead
of a dependency, which would mean the user would have to create a pool
with the right name by hand before the plugin would install.  As a
side note, we're certainly open to more customized handling of
database pool dependencies, but it's not there in 1.1.


OK this sounds perfect. Before you revealed this I was planning to
create two liferay plugins -- one with the LiferayDatabase
dependency and one without  -- and then count on the user that has
manually created the db pool to pick the one without the dependency.
But IIUC I can use the technique you describe above to create a single
liferay plugin with the dependency and as long as the manually created
db pool is named correctly the plugin installer will do the right
thing.  Neat.


The other option is that a plugin can obsolete other modules or
plugins.  So the Liferay can obsolete the welcome app, meaning the
welcome app will be uninstalled when the Liferay plugin is installed.
It's kind of heavy-handed, but probably better than having it install
and immediately fail due to the context root conflict.


Brian Chan sent a note earlier that says I can in fact change
liferay's context root by adjusting some XML and a properties file.
I'll look into that but it's nice to have this feature you describe in
my back pocket.


As far as populating the database, you can provide a GBean that runs
whenever a flag like initialized is false.  Every time it starts it
can check the flag and abort if it's set.  If it's not set, it can do
its work, and then set the flag on itself (via a roundabout kernel
call), so it will never execute the initialization again.  Or, of
course, just connect to the DB and only execute the initialization if
some known Liferay table is not present.


Since I'm using derby I believe that the DirectoryInitializationGBean
Matt pointed out should do the job.  But longer term I agree that a
more specialized GBean like you describe is the right way to go.  I'll
create a JIRA for a reusable version of the specialized GBean and
maybe this item can make it into 1.2.


Thanks,
Paul

Re: [VOTE] Re: ServiceMix-3.0-M2-incubating

2006-06-22 Thread James Strachan


+1

On 6/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

Here is my +1

Cheers,
Guillaume Nodet

On 6/20/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

 I have uploaded binaries for the 3.0-M2-incubating release.
 The repos and site are available at
 http://people.apache.org/~gnodet/servicemix-3.0-M2-incubating
 http://people.apache.org/%7Egnodet/servicemix-3.0-M2-incubating

 Binary distribution can be directly accessed at

 
http://people.apache.org/~gnodet/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/apache-servicemix/3.0-M2-incubating/apache-servicemix-3.0-M2-incubating.tar.gzhttp://people.apache.org/%7Egnodet/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/apache-servicemix/3.0-M2-incubating/apache-servicemix-3.0-M2-incubating.tar.gz

 
http://people.apache.org/~gnodet/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/apache-servicemix/3.0-M2-incubating/apache-servicemix-3.0-M2-incubating.ziphttp://people.apache.org/%7Egnodet/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/apache-servicemix/3.0-M2-incubating/apache-servicemix-3.0-M2-incubating.zip

 Please, take some time to download and test the main configuration,
 components and examples (I have changed quite a few things these last days,
 so ...),
 and post your feedback (and votes for PPMC members).

 Cheers,
 Guillaume Nodet






--

James
---
http://radio.weblogs.com/0112098/

Re: [VOTE] Re: ServiceMix-3.0-M2-incubating

2006-06-22 Thread Guillaume Nodet


I have just launched a deployment of a new version which fixes a few bugs.
Will start a new vote in a few hours.

Cheers,
Guillaume Nodet

On 6/22/06, James Strachan [EMAIL PROTECTED] wrote:


+1

On 6/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
 Here is my +1

 Cheers,
 Guillaume Nodet

 On 6/20/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
 
  I have uploaded binaries for the 3.0-M2-incubating release.
  The repos and site are available at
  http://people.apache.org/~gnodet/servicemix-3.0-M2-incubating
  http://people.apache.org/%7Egnodet/servicemix-3.0-M2-incubating
 
  Binary distribution can be directly accessed at
 
 
http://people.apache.org/~gnodet/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/apache-servicemix/3.0-M2-incubating/apache-servicemix-3.0-M2-incubating.tar.gz

http://people.apache.org/%7Egnodet/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/apache-servicemix/3.0-M2-incubating/apache-servicemix-3.0-M2-incubating.tar.gz

 
 
http://people.apache.org/~gnodet/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/apache-servicemix/3.0-M2-incubating/apache-servicemix-3.0-M2-incubating.zip

http://people.apache.org/%7Egnodet/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/apache-servicemix/3.0-M2-incubating/apache-servicemix-3.0-M2-incubating.zip

 
  Please, take some time to download and test the main configuration,
  components and examples (I have changed quite a few things these last
days,
  so ...),
  and post your feedback (and votes for PPMC members).
 
  Cheers,
  Guillaume Nodet
 




--

James
---
http://radio.weblogs.com/0112098/

Re: liferay

2006-06-22 Thread Paul McMahan


Thanks for the helpful feedback Jeff.  Comments inline.

On 6/21/06, Jeff Genender [EMAIL PROTECTED] wrote:



Paul McMahan wrote:
 Liferay is an open source portal made available under the MIT license.
 They provide a geronimo+liferay distribution from their website,
 which is basically a zipped up geronimo/tomcat server with liferay
 already deployed. I had some problems starting a fresh install of this
 distribution due to hsql database driver issues.  Hopefully new users
 who experience this same problem will find the entry I posted in
 liferay's support forum about how to get it working:
 http://forums.liferay.com/index.php?showtopic=5348

I was the one who helped get the Liferay implementation running with the
Liferay guys.  I personally got it running fine on MySQL.


Nice work!  Yeah I also had no problems getting it to run on mysql. It
was the out of the box distribution which uses hsqldb that I had
problems with.  It may have been something environmental because Brian
didn't encounter any problems.  The instructions I provided in the
support forum describe how to replace the hsqldb pool with a mysql
pool.  No other changes were necessary.


 Liferay currently uses a snapshot of geronimo 1.1 from 5/3/2006 which
 has the new versioning functionality but as you can imagine is missing
 several important bug fixes and schema changes.  I got their WAR
 working in geronimo 1.1 after making some adjustments to its
 geronimo-web.xml.  When geronimo 1.1 is officially released I'll offer
 my assistance to help them upgrade to it.

Yes...we used 1.1 SNAPSHOT because it was the best available to move
forward with.  I am currently working with them to get the Enterprise
version working...hopefully next week.  If you want to join in...by all
means please do ;-)


I agree using the 1.1 SNAPSHOT makes good sense since the release of
liferay 4.0 was imminent.  To get it working in the geronimo 1.1rc I
needed to update geronimo-web.xml for the new schema -- replacing
configId with moduleId and removing the context-priority-classloader
element.  I also encountered some classloader problems due to liferay
having cglib and spring in its WEB-INF/lib directory (figuring this
out gave me a major headache :-)  I worked around that by adding them
to hidden-classes. I'm not an EJB expert but I'm definitely on board
for helping with the Enterprise version if you could use a hand.  Ping
me on IRC if you wanna discuss...


 I also think and have heard others mention that liferay is a great
 candidate for a geronimo plugin. Adding the necessary plugin files to
 the liferay WAR is straightforward.  But there are a couple of
 interesting challenges where I would like to get your input.   First
 is that the plugin prereqs a database pool.  Some expert users will
 want to manually create and populate the database and then use the
 console to point a db pool at it before installing the liferay plugin.
 But I imagine that some developers and more casual users would like
 for geronimo to automatically create a database pool for them as part
 of the liferay plugin install process.  That way they could add a
 working portal server to their geronimo server with only a few clicks
 in the console (remember Joe's mom? ;-)

When I did the professional version I placed an automagically created DB
pool...but with MySQL.  But it was proof of concept since who knows if
someone is going to be using MySQL or not or where the database would
even live.  But to offer a plugin for Derby would be great IMHO for
people to try it out...since Derby will likely live with Geronimo. But
obviously when using an enterprise class database, it made no sense to
include it since the locations may be anywhere.  It would be difficult
to provide plugins for this.


Yeah I definitely agree that this was the right approach since
production level servers will want to use an enterprise class
database.  I think that ideally the liferay plugin would automatically
set up a derby pool unless the user has already set up a pool
manually. After hearing from Aaron it sounds like the plugin
architecture handles this case quite nicely.  Subsequently, if derby
is too lightweight then it should be easy to switch to a server like
DB2.  Using the console db wizard that process seems pretty
straightforward as well.


 The second interesting aspect of creating liferay plugin is that
 liferay wants to use '/' for its context root.  The problem is that
 the geronimo welcome app is already installed in the '/' context root
 and this prevents liferay from starting.  I tried moving it to a
 different context root but then hard-coded references to scripts and
 images in their html started breaking. Is there a way to make
 geronimo override a context root such that last in wins?  Or could the
 plugin metadata specify the required context root so that the console
 can warn the user about potential conflicts before installing the
 plugin? Any ideas?

According to their documentation for

[jira] Created: (GERONIMO-2143) ENCConfigBuilder blocks outside callers

ENCConfigBuilder blocks outside callers
---

 Key: GERONIMO-2143
 URL: http://issues.apache.org/jira/browse/GERONIMO-2143
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: deployment, naming  
Versions: 1.1
Reporter: Aaron Mulder
 Assigned to: Aaron Mulder 
 Fix For: 1.1.1


ENCConfigBuilder makes strategic methods private and some methods require an 
EAR context, module ID, JNDI builder, etc. that are only relevant for EAR 
callers.  For plugins, etc. that want to create EJB/Resource/Service 
references, they need a lot of copy and paste and refactoring of code that 
should be reusable.  The ENCConfigBuilder should be fixed to be equally useful 
to internal (J2EE) and external (non-J2EE) callers.

-- 
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-2144) GBean for handling initial database population

2006-06-22 Thread Paul McMahan (JIRA)

GBean for handling initial database population
--

 Key: GERONIMO-2144
 URL: http://issues.apache.org/jira/browse/GERONIMO-2144
 Project: Geronimo
Type: New Feature
Security: public (Regular issues) 
  Components: databases  
Versions: Wish List
Reporter: Paul McMahan
Priority: Minor


Some applications like daytrader and liferay need to have a database populated 
before they can run.  It would be nice to have a GBean that could take a 
datasource and SQL as input and handling running the SQL when the application 
is started for the first time.  The GBean would need to also provide a way to 
avoid running the SQL multiple times, perhaps by allowing the deployment plan 
to specify an SQL statement that the GBean can use to determine if the database 
has already been populated.

This idea was originally proposed by David Jencks and discussed in this thread:
http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL 
PROTECTED]

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

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)



On Jun 22, 2006, at 2:01 AM, Rick McGuire wrote:

+1 (and we need to make sure this is added to the wiki so we can  
remember it the next time a release is spun :-))


Definitely, was waiting to see some +1s before doing that part.

Here it is:

http://cwiki.apache.org/GMOxPMGT/release-branching-process.html

-David



David Blevins wrote:

We had this whole conversation last week, lots of good discussion was
had.  I'd prefer not to have to have it again.  Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.

1.   branches/x.y would be the branch for all x.y.z releases

2.   when a release is frozen, we spin off a branch with that *exact*
 name, as in branches/x.y.z, where z starts at zero and  
increments

 by one.

3.   at that time branches/x.y is immediately updated to version
 x.y.(z+1)-SNAPSHOT

3.   We cut releases from the frozen branch

4.   When a release passes final tck testing and final vote, the
 frozen branch is moved to tags

We create a branch at freeze time for the following reasons:

1.  it takes *at least* one week from freeze to ship due to voting,
tck testing and potential repeats of that process (re-cut,
re-certify, re-vote).  There is no reason why work on x.y.z+1
needs to be delayed -- only 52 weeks a year.

2.  stronger guarantee no one is updating the branch once frozen

3.  less likely that people and ci systems (continuum) will checkout
and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)  
which

would need to be removed manually and may accidentally be
distributed.

4.  it is currently very difficult to roll version numbers forward,
entries here and there are often missed.  Far better to have
branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
than a few overlooked x.y.z final numbers that needed to go back
to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
back later if that process happens in the frozen branch.


Here is my +1


-- David



On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

After the branches/1.1 was moved to tags there was some question  
as to what happened to the 1.1 branch.  At that time some kind  
soul created a new branches/1.1.1.  No activity has occurred in  
that branch and given that we'll need to define the release goals  
of 1.1.1 soon I'd like to propose the following.


After 1.1 is released:

* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1

When 1.1.1 enters time for release

* Move branches/1.1.1 to branches/1.1.1.0
* Change version from 1.1.1-SNAPSHOT to 1.1.1
* Create release candidate rc1
* put out for a vote
* get a successful vote with no respins :)
* move from branches/1.1.1.0 to tags/1.1.1.0

Based on all the confusion in the past I think this procedure  
makes it clear what phase were in for the release as well as  
avoids tagging and branching repeatedly.


I'm looking for lazy consensus and not a formal vote.

Matt

Re: XBean root POM

2006-06-22 Thread Dain Sundstrom


Can you update the release procedure page?

http://geronimo.apache.org/xbean/release-procedure.html

-dain

On Jun 22, 2006, at 12:05 AM, Guillaume Nodet wrote:


The distribution repos  ?
Well, i wanted to publish the release in a private repo so that it  
can be voted,

and then move to public repos.
I will change them back to what they were.

Cheers,
Guillaume Nodet

On 6/22/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
Ahh, ok.  What about the other elements?


Regards,
Alan


Guillaume Nodet wrote:

When you use the maven release plugin, maven change the scm url
to point to the tag.  I will revert it to trunk asap.

Cheers,
Guillaume Nodet

On 6/22/06, David Blevins [EMAIL PROTECTED] wrote:
On Jun 21, 2006, at 6:37 PM, Alan D. Cabrera wrote:

 IIUC, version specific information  has snuck into elements that
 should be version free, e.g. scm.  Here is a list of elements
 that should have version information removed:

 scm
 build...remoteRepositoryUrl
 distributionManagment


Not sure how this got there, it should point to trunk

   scm
 connectionscm:svn: http://svn.apache.org/repos/asf/geronimo/
xbean/tags/xbean-2.4/connection
 developerConnectionscm:svn:https://${maven.username}
@ svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.4/
developerConnection
 urlhttp://svn.apache.org/repos/asf/geronimo/xbean/tags/
xbean-2.4/url
   /scm

No wonder Continuum is very unhappy with XBean...

http://ci.gbuild.org/continuum/servlet/continuum

... it will check the code out from *exactly* where you point it to.


-David

Update on Quartz plugin, Plugin features


I was not swayed by the arguments against letting people deploy Quartz
jobs as GBeans.  However, I agree that it's not appropriate for every
case.  When I document this plugin, I plan to list the use cases I'm
going for and the ones I'm not.

After a little experimentation, I've been able to configure both EJB
references and Resources references for the Quartz jobs using
dependency injection (not JNDI).  So for example, if your job declares
a setMyDatabase(DataSource foo) then you can point to a Geronimo data
source in your XML and that method will be called on your job to give
it the appropriate data source before it is executed.  EJBs should
work the same way.  I don't plan to add service references because I
think people would be unlikely to use JAX-RPC from a non-J2EE
component, but it will just require some XML surgery if people clamor
for it.

However, due to a variety of bugs in 1.1, the EJB references don't
work, and there's a fair amount of Geronimo code copied and pasted
into the plugin.  If we fix the EJB proxy bug and the EJB reference
builder bug and the ENCConfigBuilder visibility bug for 1.1.1, then
EJB references should work and the plugin code will get a lot cleaner.
I plan to look at the last two bugs, and I hear there's a patch for
the EJB proxy bug but we're waiting for Dain to review it and see if
he has a better idea.

Thanks,
   Aaron

[jira] Created: (GERONIMO-2145) NPE in Maven1Repository

NPE in Maven1Repository
---

 Key: GERONIMO-2145
 URL: http://issues.apache.org/jira/browse/GERONIMO-2145
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: kernel  
Versions: 1.1
Reporter: Aaron Mulder
 Assigned to: Aaron Mulder 
 Fix For: 1.1.1


Circa line 66: path.listFiles() returns null if it's not a directory or 
whatever.

-- 
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-2146) GBeanOverride ignores reference name when saving if artifact is not set

GBeanOverride ignores reference name when saving if artifact is not set
---

 Key: GERONIMO-2146
 URL: http://issues.apache.org/jira/browse/GERONIMO-2146
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: kernel  
Versions: 1.1
Reporter: Aaron Mulder
 Assigned to: Aaron Mulder 
 Fix For: 1.1.1


In writeXml the writing of name and module should be outside the if(artifact != 
null) block

-- 
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: Update on Quartz plugin, Plugin features

2006-06-22 Thread Jeff Genender



Aaron Mulder wrote:
 I was not swayed by the arguments against letting people deploy Quartz
 jobs as GBeans.  However, I agree that it's not appropriate for every
 case.  When I document this plugin, I plan to list the use cases I'm
 going for and the ones I'm not.
 

I don't think people had issues with deploying Jobs as Gbeans as an
*add-on* to allowing a scheduled implementation as part of a deployment.
 However, making the GBean references a requirement and thus replacing
the actual Quartz API for using jobs was the issue at hand...at least
that was my issue...the last thing we need is (YAA) Yet Another Api.
If that is not the issue, then I have no problems at all with it.

 After a little experimentation, I've been able to configure both EJB
 references and Resources references for the Quartz jobs using
 dependency injection (not JNDI).  So for example, if your job declares
 a setMyDatabase(DataSource foo) then you can point to a Geronimo data
 source in your XML and that method will be called on your job to give
 it the appropriate data source before it is executed.  EJBs should
 work the same way.  I don't plan to add service references because I
 think people would be unlikely to use JAX-RPC from a non-J2EE
 component, but it will just require some XML surgery if people clamor
 for it.
 
 However, due to a variety of bugs in 1.1, the EJB references don't
 work, and there's a fair amount of Geronimo code copied and pasted
 into the plugin.  If we fix the EJB proxy bug and the EJB reference
 builder bug and the ENCConfigBuilder visibility bug for 1.1.1, then
 EJB references should work and the plugin code will get a lot cleaner.
 I plan to look at the last two bugs, and I hear there's a patch for
 the EJB proxy bug but we're waiting for Dain to review it and see if
 he has a better idea.
 
 Thanks,
Aaron

[jira] Commented: (GERONIMO-2116) Precompile JSPs in apps. Jar classes into web-inf/lib

2006-06-22 Thread David Jencks (JIRA)

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

David Jencks commented on GERONIMO-2116:


The error I got before rebuilding the plugins was:

Embedded error: The -uriroot option must specify a pre-existing directory   

This went away after I built the jspc plugin (mojo/codehaus) and war plugin 
(apache)

 Precompile JSPs in apps. Jar classes into web-inf/lib
 -

  Key: GERONIMO-2116
  URL: http://issues.apache.org/jira/browse/GERONIMO-2116
  Project: Geronimo
 Type: Sub-task
 Security: public(Regular issues) 
   Components: web
 Versions: 1.2
 Reporter: Prasad Kashyap
 Assignee: David Jencks
  Fix For: 1.2
  Attachments: jspc.patch

 Patch precompiles jsps.
 Patch also jars classes into web-inf/lib/${project.build.finalName}.jar.
 Note: The 2.0.1 snapshot of the maven-war-plugin has not been deployed yet. 
 To test the jar functionality, you will have to build your own war plugin.

-- 
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-2147) Remove javamail-transport from Geronimo build and replace with javamail-provider dependency.

Remove javamail-transport from Geronimo build and replace with 
javamail-provider dependency. 
-

 Key: GERONIMO-2147
 URL: http://issues.apache.org/jira/browse/GERONIMO-2147
 Project: Geronimo
Type: Improvement
Security: public (Regular issues) 
  Components: mail  
Versions: 1.2
Reporter: Rick McGuire
 Assigned to: Rick McGuire 
 Fix For: 1.2


Now that the javamail-provider repository and build is available, it's time to 
replace the javamail-transport module in the Geronimo code tree with a 
dependency on the javamail_provider_1.3.1 jar file. 

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

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)


Then I think we're open for G-Business.


I love it... G-Business :-)

--jason

[jira] Updated: (GERONIMO-2147) Remove javamail-transport from Geronimo build and replace with javamail-provider dependency.

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

Rick McGuire updated GERONIMO-2147:
---

Attachment: notrans.diff

Changes to the config for removing the javamail-transport dependencies.  Also 
deletes the javamail-transport module.

 Remove javamail-transport from Geronimo build and replace with 
 javamail-provider dependency.
 

  Key: GERONIMO-2147
  URL: http://issues.apache.org/jira/browse/GERONIMO-2147
  Project: Geronimo
 Type: Improvement
 Security: public(Regular issues) 
   Components: mail
 Versions: 1.2
 Reporter: Rick McGuire
 Assignee: Rick McGuire
  Fix For: 1.2
  Attachments: notrans.diff

 Now that the javamail-provider repository and build is available, it's time 
 to replace the javamail-transport module in the Geronimo code tree with a 
 dependency on the javamail_provider_1.3.1 jar file. 

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

[RTC] Removal of the javamail-transport code.

2006-06-22 Thread Rick McGuire


Ok, on to the next phase of the javamail reorganization.  This patch

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

is to remove the javamail-transport module and replace it with 
references to the javamail-providers-1.3.1 jar file. 


Rick

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)


On Jun 22, 2006, at 3:17 AM, Matt Hogstrom wrote:

The remaining question is what to do with the branches that are out  
there.  I think we should whack what's out there (does not appear  
that there has been any activity) branches/1.1 and branches/1.1.1.   
When the vote is complete later today and we release 1.1 I'll move  
branches/1.1.0 to tags/1.1.0 and then make the copy to branches/1.1  
and update the versions to 1.1.1-SNAPSHOT as well as the plugin  
releases.


I whacked branches/1.1.1 -- that was my mess.  We're good on branches/ 
1.1, it was created from 1.1.0.  There was an update to the 1.1.0  
NOTICE.txt file which is the only thing we have to port back.


Then I think we're open for G-Business.


G-reat.

/me is getting a very Tony the Tiger vibe

-David

Apache Geronimo Knowledge Base (was: Wiki based FAQ)


Okay, here ya go:

http://cwiki.apache.org/confluence/display/GMOxKB

I did a few things...

First, I setup a geronimo team label, and labeled all of our spaces  
(so from the dashboard you can see all of the G-related spaces  
easily).  New spaces for G should also get this label added (have add  
it manually after creation).


Then I added a {font-size} user-macro to help change font sizes.

I installed the navigation plugin (which gets us {scrollbar}).

I installed the footnotes plugin, see this for an example: http:// 
cwiki.apache.org/confluence/display/GMOxKB/CLI


And I installed the plugin repository client, which makes it easier  
to manage plugin versions.  I need to know how to get the Utilities  
plugin installed into WEB-INF/lib before I can enable some of the  
other plugins, but that can wait.  If you have admin, you can see the  
repository client page here:


http://cwiki.apache.org/confluence/admin/repository/plugins.action

Just be careful, cause sometimes installing a plugin will hose the  
entire Confluence install, or need it to be bounced before it is usable.


Who is the point-man for bouncing/installing stuff for this?

 * * *

Basically there are 3 major sections (each of which could really be  
its own space if needed, when we get more content, but for now will  
work):


 FAQ - yada yada
 Topics - General KB stuff, not really FAQ
 Glossary - Definitions for terms

The way it works is that each bit of content is its own page.  That  
pages parent page is the section it is under.  The name of the page  
is the topic title, or FAQ question, or glossary term.


Each content page has at the top {scrollbar}, so that it is easy to  
navigate between all of the pages in the KB.


Sub-sections are also just pages, but with the {children:all=true}  
macro to allow easy navigation to children.  It is important to add  
that, cause the default rendering of children pages at the bottom is  
disabled.


The main indexes are dynamic, so you just have to add a page in the  
right place and presto it updates.


Use the {excerpt} macro to provide a bit more detail that will  
compliment the page title in the listing.


 * * *

Once we get the Utilities plugin installed into WEB-INF/lib, we can  
use the Zones plugin to setup dynamic templates for each of these  
sections, and then you don't have to worry about the {scrollbar} or  
{children} stuff, just add the content and the zone will render per  
the zone template.


I have not yet set this up to auto-export, should probably do that soon.

 * * *

Comments?  Questions?  Yada yada...

--jason

Re: Apache Geronimo Knowledge Base (was: Wiki based FAQ)


Autoexport is up:

http://cwiki.apache.org/GMOxKB/index.html

--jason


On Jun 22, 2006, at 12:17 PM, Jason Dillon wrote:


Okay, here ya go:

http://cwiki.apache.org/confluence/display/GMOxKB

I did a few things...

First, I setup a geronimo team label, and labeled all of our spaces  
(so from the dashboard you can see all of the G-related spaces  
easily).  New spaces for G should also get this label added (have  
add it manually after creation).


Then I added a {font-size} user-macro to help change font sizes.

I installed the navigation plugin (which gets us {scrollbar}).

I installed the footnotes plugin, see this for an example: http:// 
cwiki.apache.org/confluence/display/GMOxKB/CLI


And I installed the plugin repository client, which makes it easier  
to manage plugin versions.  I need to know how to get the Utilities  
plugin installed into WEB-INF/lib before I can enable some of the  
other plugins, but that can wait.  If you have admin, you can see  
the repository client page here:


http://cwiki.apache.org/confluence/admin/repository/plugins.action

Just be careful, cause sometimes installing a plugin will hose the  
entire Confluence install, or need it to be bounced before it is  
usable.


Who is the point-man for bouncing/installing stuff for this?

 * * *

Basically there are 3 major sections (each of which could really be  
its own space if needed, when we get more content, but for now will  
work):


 FAQ - yada yada
 Topics - General KB stuff, not really FAQ
 Glossary - Definitions for terms

The way it works is that each bit of content is its own page.  That  
pages parent page is the section it is under.  The name of the page  
is the topic title, or FAQ question, or glossary term.


Each content page has at the top {scrollbar}, so that it is easy to  
navigate between all of the pages in the KB.


Sub-sections are also just pages, but with the {children:all=true}  
macro to allow easy navigation to children.  It is important to add  
that, cause the default rendering of children pages at the bottom  
is disabled.


The main indexes are dynamic, so you just have to add a page in the  
right place and presto it updates.


Use the {excerpt} macro to provide a bit more detail that will  
compliment the page title in the listing.


 * * *

Once we get the Utilities plugin installed into WEB-INF/lib, we can  
use the Zones plugin to setup dynamic templates for each of these  
sections, and then you don't have to worry about the {scrollbar} or  
{children} stuff, just add the content and the zone will render per  
the zone template.


I have not yet set this up to auto-export, should probably do that  
soon.


 * * *

Comments?  Questions?  Yada yada...

--jason

Re: Apache Geronimo Knowledge Base

2006-06-22 Thread Hernan Cunico

Hi Jason,
what is the long term plan for this space? could we ultimately move/merge the MoinMoin content there
once migrated?

There is this GMOxSBOX space (the SandBox) that we could remove and put the GMOxKB instead, see
cwiki.apache.org/geronimo

Let me know what you think?

Cheers!
Hernan

Jason Dillon wrote:

Okay, here ya go:

http://cwiki.apache.org/confluence/display/GMOxKB

I did a few things...

First, I setup a geronimo team label, and labeled all of our spaces (so
from the dashboard you can see all of the G-related spaces easily).
New spaces for G should also get this label added (have add it manually
after creation).

Then I added a {font-size} user-macro to help change font sizes.

I installed the navigation plugin (which gets us {scrollbar}).

I installed the footnotes plugin, see this for an example: http://
cwiki.apache.org/confluence/display/GMOxKB/CLI

And I installed the plugin repository client, which makes it easier to
manage plugin versions. I need to know how to get the Utilities plugin
installed into WEB-INF/lib before I can enable some of the other
plugins, but that can wait. If you have admin, you can see the
repository client page here:

http://cwiki.apache.org/confluence/admin/repository/plugins.action

Just be careful, cause sometimes installing a plugin will hose the
entire Confluence install, or need it to be bounced before it is usable.

Who is the point-man for bouncing/installing stuff for this?

* * *

Basically there are 3 major sections (each of which could really be its
own space if needed, when we get more content, but for now will work):

FAQ - yada yada
Topics - General KB stuff, not really FAQ
Glossary - Definitions for terms

The way it works is that each bit of content is its own page. That
pages parent page is the section it is under. The name of the page is
the topic title, or FAQ question, or glossary term.

Each content page has at the top {scrollbar}, so that it is easy to
navigate between all of the pages in the KB.

Sub-sections are also just pages, but with the {children:all=true}
macro to allow easy navigation to children. It is important to add
that, cause the default rendering of children pages at the bottom is
disabled.

The main indexes are dynamic, so you just have to add a page in the
right place and presto it updates.

Use the {excerpt} macro to provide a bit more detail that will
compliment the page title in the listing.

* * *

Once we get the Utilities plugin installed into WEB-INF/lib, we can use
the Zones plugin to setup dynamic templates for each of these sections,
and then you don't have to worry about the {scrollbar} or {children}
stuff, just add the content and the zone will render per the zone
template.

I have not yet set this up to auto-export, should probably do that soon.

* * *

Comments? Questions? Yada yada...

--jason

Re: Apache Geronimo Knowledge Base

I think that the bulk of what is in http://wiki.apache.org/geronimo/  
should move to http://cwiki.apache.org/geronimo/


I think that the KB space is really for stuff that does not fit well  
into other spaces (like docNN or geronimo), or stuff that is FAQ-like.


It looks like the moin content is current a mix of docNN, FAQ and  
project information.


I also think that we could probably merge GMOxPMGT into the geronimo  
space, but that is just a thought.


IMO, the important thing is to get the content into Confluence and  
out of moin.  Maybe start by adding them to the sandbox just to get  
them into the system, and then we can move stuff around from there.


Did you ever peek at those moin importers?

--jason


On Jun 22, 2006, at 12:55 PM, Hernan Cunico wrote:


Hi Jason,
what is the long term plan for this space? can we ultimately move  
the MoinMoin content there?
There is this GMOxSBOX space that we could get rid of and put the  
knowledge base instead, see cwiki.apache.org/geronimo


Let me know what you think

Cheers!
Hernan

Jason Dillon wrote:

Okay, here ya go:
http://cwiki.apache.org/confluence/display/GMOxKB
I did a few things...
First, I setup a geronimo team label, and labeled all of our  
spaces  (so from the dashboard you can see all of the G-related  
spaces  easily).  New spaces for G should also get this label  
added (have add  it manually after creation).

Then I added a {font-size} user-macro to help change font sizes.
I installed the navigation plugin (which gets us {scrollbar}).
I installed the footnotes plugin, see this for an example: http://  
cwiki.apache.org/confluence/display/GMOxKB/CLI
And I installed the plugin repository client, which makes it  
easier  to manage plugin versions.  I need to know how to get the  
Utilities  plugin installed into WEB-INF/lib before I can enable  
some of the  other plugins, but that can wait.  If you have admin,  
you can see the  repository client page here:
http://cwiki.apache.org/confluence/admin/repository/ 
plugins.action
Just be careful, cause sometimes installing a plugin will hose  
the  entire Confluence install, or need it to be bounced before it  
is usable.

Who is the point-man for bouncing/installing stuff for this?
 * * *
Basically there are 3 major sections (each of which could really  
be  its own space if needed, when we get more content, but for now  
will  work):

 FAQ - yada yada
 Topics - General KB stuff, not really FAQ
 Glossary - Definitions for terms
The way it works is that each bit of content is its own page.   
That  pages parent page is the section it is under.  The name of  
the page  is the topic title, or FAQ question, or glossary term.
Each content page has at the top {scrollbar}, so that it is easy  
to  navigate between all of the pages in the KB.
Sub-sections are also just pages, but with the  
{children:all=true}  macro to allow easy navigation to children.   
It is important to add  that, cause the default rendering of  
children pages at the bottom is  disabled.
The main indexes are dynamic, so you just have to add a page in  
the  right place and presto it updates.
Use the {excerpt} macro to provide a bit more detail that will   
compliment the page title in the listing.

 * * *
Once we get the Utilities plugin installed into WEB-INF/lib, we  
can  use the Zones plugin to setup dynamic templates for each of  
these  sections, and then you don't have to worry about the  
{scrollbar} or  {children} stuff, just add the content and the  
zone will render per  the zone template.
I have not yet set this up to auto-export, should probably do that  
soon.

 * * *
Comments?  Questions?  Yada yada...
--jason

Re: Apache Geronimo Knowledge Base

2006-06-22 Thread Hernan Cunico

Jason Dillon wrote:
I think that the bulk of what is in http://wiki.apache.org/geronimo/
should move to http://cwiki.apache.org/geronimo/

I think that the KB space is really for stuff that does not fit well
into other spaces (like docNN or geronimo), or stuff that is FAQ-like.

That was the original idea behind GMOxSBOX

It looks like the moin content is current a mix of docNN, FAQ and
project information.

I also think that we could probably merge GMOxPMGT into the geronimo
space, but that is just a thought.

Merging one space into another is way much easier than spliting a space in two. I would keep spaces
separated for now and then evaluate the benefit of merging. That goes for merging content directly
into the plain geronimo space.

IMO, the important thing is to get the content into Confluence and out
of moin. Maybe start by adding them to the sandbox just to get them
into the system, and then we can move stuff around from there.

That's the plan

Did you ever peek at those moin importers?

I'm looking at migration alternatives right now.

Can we make an export of the Geronimo space in Moin Moin? I don't know how to do it. If I can get
a copy of the wiki I'll be doing the migration tools testing on my machine.

Cheers!
Hernan

--jason

On Jun 22, 2006, at 12:55 PM, Hernan Cunico wrote:

Hi Jason,
what is the long term plan for this space? can we ultimately move the
MoinMoin content there?
There is this GMOxSBOX space that we could get rid of and put the
knowledge base instead, see cwiki.apache.org/geronimo

Let me know what you think

Cheers!
Hernan

Jason Dillon wrote:

Okay, here ya go:
http://cwiki.apache.org/confluence/display/GMOxKB
I did a few things...
First, I setup a geronimo team label, and labeled all of our spaces
(so from the dashboard you can see all of the G-related spaces
easily). New spaces for G should also get this label added (have
add it manually after creation).

Then I added a {font-size} user-macro to help change font sizes.
I installed the navigation plugin (which gets us {scrollbar}).
I installed the footnotes plugin, see this for an example: http://
cwiki.apache.org/confluence/display/GMOxKB/CLI
And I installed the plugin repository client, which makes it easier
to manage plugin versions. I need to know how to get the Utilities
plugin installed into WEB-INF/lib before I can enable some of the
other plugins, but that can wait. If you have admin, you can see
the repository client page here:

http://cwiki.apache.org/confluence/admin/repository/ plugins.action
Just be careful, cause sometimes installing a plugin will hose the
entire Confluence install, or need it to be bounced before it is
usable.

Who is the point-man for bouncing/installing stuff for this?
* * *
Basically there are 3 major sections (each of which could really be
its own space if needed, when we get more content, but for now will
work):

FAQ - yada yada
Topics - General KB stuff, not really FAQ
Glossary - Definitions for terms
The way it works is that each bit of content is its own page. That
pages parent page is the section it is under. The name of the page
is the topic title, or FAQ question, or glossary term.
Each content page has at the top {scrollbar}, so that it is easy to
navigate between all of the pages in the KB.
Sub-sections are also just pages, but with the {children:all=true}
macro to allow easy navigation to children. It is important to add
that, cause the default rendering of children pages at the bottom
is disabled.
The main indexes are dynamic, so you just have to add a page in the
right place and presto it updates.
Use the {excerpt} macro to provide a bit more detail that will
compliment the page title in the listing.

* * *
Once we get the Utilities plugin installed into WEB-INF/lib, we can
use the Zones plugin to setup dynamic templates for each of these
sections, and then you don't have to worry about the {scrollbar} or
{children} stuff, just add the content and the zone will render per
the zone template.
I have not yet set this up to auto-export, should probably do that
soon.

* * *
Comments? Questions? Yada yada...
--jason

Re: Apache Geronimo Knowledge Base



On Jun 22, 2006, at 1:23 PM, Jason Dillon wrote:

I also think that we could probably merge GMOxPMGT into the  
geronimo space, but that is just a thought.


+1

-David


IMO, the important thing is to get the content into Confluence and  
out of moin.  Maybe start by adding them to the sandbox just to get  
them into the system, and then we can move stuff around from there.


Did you ever peek at those moin importers?

--jason


On Jun 22, 2006, at 12:55 PM, Hernan Cunico wrote:


Hi Jason,
what is the long term plan for this space? can we ultimately move  
the MoinMoin content there?
There is this GMOxSBOX space that we could get rid of and put the  
knowledge base instead, see cwiki.apache.org/geronimo


Let me know what you think

Cheers!
Hernan

Jason Dillon wrote:

Okay, here ya go:
http://cwiki.apache.org/confluence/display/GMOxKB
I did a few things...
First, I setup a geronimo team label, and labeled all of our  
spaces  (so from the dashboard you can see all of the G-related  
spaces  easily).  New spaces for G should also get this label  
added (have add  it manually after creation).

Then I added a {font-size} user-macro to help change font sizes.
I installed the navigation plugin (which gets us {scrollbar}).
I installed the footnotes plugin, see this for an example:  
http:// cwiki.apache.org/confluence/display/GMOxKB/CLI
And I installed the plugin repository client, which makes it  
easier  to manage plugin versions.  I need to know how to get the  
Utilities  plugin installed into WEB-INF/lib before I can enable  
some of the  other plugins, but that can wait.  If you have  
admin, you can see the  repository client page here:
http://cwiki.apache.org/confluence/admin/repository/ 
plugins.action
Just be careful, cause sometimes installing a plugin will hose  
the  entire Confluence install, or need it to be bounced before  
it is usable.

Who is the point-man for bouncing/installing stuff for this?
 * * *
Basically there are 3 major sections (each of which could really  
be  its own space if needed, when we get more content, but for  
now will  work):

 FAQ - yada yada
 Topics - General KB stuff, not really FAQ
 Glossary - Definitions for terms
The way it works is that each bit of content is its own page.   
That  pages parent page is the section it is under.  The name of  
the page  is the topic title, or FAQ question, or glossary term.
Each content page has at the top {scrollbar}, so that it is easy  
to  navigate between all of the pages in the KB.
Sub-sections are also just pages, but with the  
{children:all=true}  macro to allow easy navigation to children.   
It is important to add  that, cause the default rendering of  
children pages at the bottom is  disabled.
The main indexes are dynamic, so you just have to add a page in  
the  right place and presto it updates.
Use the {excerpt} macro to provide a bit more detail that will   
compliment the page title in the listing.

 * * *
Once we get the Utilities plugin installed into WEB-INF/lib, we  
can  use the Zones plugin to setup dynamic templates for each of  
these  sections, and then you don't have to worry about the  
{scrollbar} or  {children} stuff, just add the content and the  
zone will render per  the zone template.
I have not yet set this up to auto-export, should probably do  
that soon.

 * * *
Comments?  Questions?  Yada yada...
--jason

Re: Apache Geronimo Knowledge Base

I think that the bulk of what is in http://wiki.apache.org/ 
geronimo/  should move to http://cwiki.apache.org/geronimo/
I think that the KB space is really for stuff that does not fit  
well  into other spaces (like docNN or geronimo), or stuff that is  
FAQ-like.


That was the original idea behind GMOxSBOX


Sanboxes IMO have an implicit this is not baked yet or this is  
experimental or i'm playing around.  The content in the KB however  
is just stuff that does not fit well into other more specific spaces.



It looks like the moin content is current a mix of docNN, FAQ and   
project information.
I also think that we could probably merge GMOxPMGT into the  
geronimo  space, but that is just a thought.


Merging one space into another is way much easier than spliting a  
space in two. I would keep spaces separated for now and then  
evaluate the benefit of merging. That goes for merging content  
directly into the plain geronimo space.


I think the effort is equal.  Both involve editing each page and  
changing the space and/or parent.


Thought... the added overhead of managing the spaces themselves  
starts to become a burden.  Generally I recommend keeping pages into  
a centralized space until the content warrants its own space, or the  
space is needed to avoid name collisions.




Did you ever peek at those moin importers?


I'm looking at migration alternatives right now.

Can we make an export of the Geronimo space in Moin Moin? I don't  
know how to do it. If I can get a copy of the wiki I'll be doing  
the migration tools testing on my machine.


I forget, but I think that there is a tool to pull full page dumps of  
the wiki content.  Or if you know where the files live, you can copy  
them from the text dir.


I'd start with the moinmoin.rb importer that is here:

http://confluence.atlassian.com/display/CONFEXT/MoinMoin+importer

And see what it imports into a personal Confluence install (w/ RPC  
enabled).


That will probably get the content close, then if needed we can hack  
the .rb to clean it up more, and then add any finishing touches by hand.


--jason

Re: Apache Geronimo Knowledge Base

2006-06-22 Thread Dain Sundstrom

This is awesome!  I think this framework can really let us quickly  
and easily grow the content.


On Jun 22, 2006, at 2:38 PM, Jason Dillon wrote:

I think that the bulk of what is in http://wiki.apache.org/ 
geronimo/  should move to http://cwiki.apache.org/geronimo/
I think that the KB space is really for stuff that does not fit  
well  into other spaces (like docNN or geronimo), or stuff that  
is FAQ-like.


That was the original idea behind GMOxSBOX


Sanboxes IMO have an implicit this is not baked yet or this is  
experimental or i'm playing around.  The content in the KB  
however is just stuff that does not fit well into other more  
specific spaces.


I agree.  I think we need a sandbox space for working white boards  
when having live discussions or trying to document a proposed new  
feature for the community.  I see this knowledge base as a FAQ like  
content and not a general scratch area.


-dain

[jira] Reopened: (AMQ-528) 4.0 M4 NullPointerException while shutting down

2006-06-22 Thread will gunadi (JIRA)

 [ https://issues.apache.org/activemq/browse/AMQ-528?page=all ]
 
will gunadi reopened AMQ-528:
-


Using:
-
backport-util-concurrent-2.1.jar
activemq-core-4.0.jar
activemq-ra-4.0.jar
jencks-all-1.1.3.jar

broker.xml:
---
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://activemq.org/config/1.0;
  bean 
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer/

  broker useJmx=false persistent=false

!--
persistenceAdapter
  journaledJDBC journalLogFiles=5 dataDirectory=foo/
/persistenceAdapter
--

transportConnectors
  transportConnector uri=tcp://localhost:51616/
/transportConnectors

  /broker

/beans

Exception when shutting down tomcat:


[EMAIL PROTECTED]:~/dev/env/apache-tomcat-5.5.15/bin$ ./shutdown.sh
Using CATALINA_BASE:   /home/tomcat/dev/env/apache-tomcat-5.5.15
Using CATALINA_HOME:   /home/tomcat/dev/env/apache-tomcat-5.5.15
Using CATALINA_TMPDIR: /home/tomcat/dev/env/apache-tomcat-5.5.15/temp
Using JRE_HOME:   /usr/lib/j2sdk1.5-sun
Jun 22, 2006 4:53:19 PM org.apache.coyote.http11.Http11BaseProtocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8080
[EMAIL PROTECTED]:~/dev/env/apache-tomcat-5.5.15/bin$ Jun 22, 2006 4:53:20 PM 
org.a
pache.catalina.core.StandardService stop
INFO: Stopping service Catalina
Jun 22, 2006 4:53:22 PM org.apache.coyote.http11.Http11BaseProtocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
Jun 22, 2006 4:53:22 PM org.apache.catalina.core.AprLifecycleListener lifecycleE
vent
INFO: Failed shutdown of Apache Portable Runtime
Exception in thread AcitveMQ Connection Worker: tcp://localhost/127.0.0.1:51616
 Exception in thread AcitveMQ Connection Worker: tcp://localhost/127.0.0.1:516
16 java.lang.NullPointerException
at edu.emory.mathcs.backport.java.util.concurrent.helpers.Utils$SunPerfP
rovider.nanoTime(Utils.java:223)
Exception in thread AcitveMQ Connection Worker: tcp://localhost/127.0.0.1:51616
   at edu.emory.mathcs.backport.java.util.concurrent.helpers.Utils.nanoTime
(Utils.java:103)
at edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.po
ll(LinkedBlockingQueue.java:336)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.get
Task(ThreadPoolExecutor.java:482)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor
ker.run(ThreadPoolExecutor.java:674)
Exception in thread AcitveMQ Connection Worker: tcp://localhost/127.0.0.1:51616
   at java.lang.Thread.run(Thread.java:595)
java.lang.NullPointerException
at edu.emory.mathcs.backport.java.util.concurrent.helpers.Utils$SunPerfP
rovider.nanoTime(Utils.java:223)
at edu.emory.mathcs.backport.java.util.concurrent.helpers.Utils.nanoTime
(Utils.java:103)
Exception in thread AcitveMQ Connection Worker: tcp://localhost/127.0.0.1:51616
   at edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.po
ll(LinkedBlockingQueue.java:336)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.get
Task(ThreadPoolExecutor.java:482)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor

 4.0 M4 NullPointerException while shutting down
 ---

  Key: AMQ-528
  URL: https://issues.apache.org/activemq/browse/AMQ-528
  Project: ActiveMQ
 Type: Bug

 Versions: 4.0 M4
  Environment: RedHat Linux Enterprise Server 3, Tomcat 5.5.15, MySQL 5.0.18 
 for Linux
 Reporter: Leon Hu
 Priority: Critical
  Fix For: 4.0 RC2



 Setup: 
 3 networked brokers, B1, B2, and B3, on 3 servers, connected using multicast 
 discovery. activemq.xml: 
  broker useJmx=false brokerName=B1 
   
  persistenceAdapter 
 journaledJDBC journalLogFiles=5 dataDirectory=foo 
 dataSource=#mysql-ds/ 
  /persistenceAdapter 
   
  transportConnectors 
  transportConnector uri=tcp://localhost:61616 
 discoveryUri=multicast://default/ 
  /transportConnectors 
   
  networkConnectors 
  networkConnector uri=multicast://default/ 
  /networkConnectors 
   
  /broker 
   
  bean id=mysql-ds class=org.apache.commons.dbcp.BasicDataSource 
 destroy-method=close 
property name=driverClassName value=com.mysql.jdbc.Driver/ 
property name=url 
 value=jdbc:mysql://localhost/activemq?relaxAutoCommit=true/ 
  property name=username value=activemqUser/ 
  property name=password value=activemqPwd/ 
  property name=poolPreparedStatements value=true/ 
  /bean 
 Similar for B2 and B3. 
 Two queues: Q1 and Q2. 
 Two producers, one for each queue, both producers connected to B1. 
 One Q1 cosumer connected to B1, another Q1 consumer on B2. 
 One Q2 consumer connected to B2, another Q2 consumer connected to B3. 
 Steps: 
 Start the brokers and start sending messages to the queue. 
 After a while, stop the brokers

[jira] Created: (AMQ-775) MessageAuthorizationPolicy doesn't work

2006-06-22 Thread Ning Li (JIRA)

MessageAuthorizationPolicy doesn't work
---

 Key: AMQ-775
 URL: https://issues.apache.org/activemq/browse/AMQ-775
 Project: ActiveMQ
Type: Bug

  Components: Broker  
Versions: 4.0
 Environment: windows NT 2003 server
Reporter: Ning Li


Use default config, set a MessageAuthorizationPolicy to BrokerService and start 
the broker.
There are several issues:
1) In BrokerService::startTransportConnector() method, 
connector.setMessageAuthorizationPolicy(policy); is in the wrong place, it 
should be moved to almost the very end of the method, otherwise if you use JMX, 
the ManageedTransportConnector won't have authorization policy info.
2) ManagedTransportConnector doesn't pass the auth policy to ManagedTransport, 
I think the easiest way to fix it is in AbstractConnection constructor,
adding this line:
this.messageAuthorizationPolicy = connector.getMessageAuthorizationPolicy();
and remove this line:
   answer.setMessageAuthorizationPolicy(messageAuthorizationPolicy); 
from TransportConnector::createConnection(), then it will work for both 
TransportConnection and ManagedTransportConnection
3) AbstrctConnection doesn't pass the auth policy to ConnectionContext, I think 
this can be fixed by adding this line:
  context.setMessageAuthorizationPolicy(this.getMessageAuthorizationPolicy());
to AbstractConnection::processAddConnection() method.

Now the auth policy can be reached by 
MessageAuthorizationPolicy::isAllowedToConsume(ConnectionContext context, 
Message message) method, but the real problem is message value is null, but we 
need to use it to check right, some of the right information is a property 
inside the message. 

Please take a look at the problem, thanks


-- 
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: Update on Quartz plugin, Plugin features


Update: injection of GBean references into the job works too.  So it's
only EJB references that are problematic for these purposes in 1.1.

Thanks,
   Aaron

On 6/22/06, Aaron Mulder [EMAIL PROTECTED] wrote:

I was not swayed by the arguments against letting people deploy Quartz
jobs as GBeans.  However, I agree that it's not appropriate for every
case.  When I document this plugin, I plan to list the use cases I'm
going for and the ones I'm not.

After a little experimentation, I've been able to configure both EJB
references and Resources references for the Quartz jobs using
dependency injection (not JNDI).  So for example, if your job declares
a setMyDatabase(DataSource foo) then you can point to a Geronimo data
source in your XML and that method will be called on your job to give
it the appropriate data source before it is executed.  EJBs should
work the same way.  I don't plan to add service references because I
think people would be unlikely to use JAX-RPC from a non-J2EE
component, but it will just require some XML surgery if people clamor
for it.

However, due to a variety of bugs in 1.1, the EJB references don't
work, and there's a fair amount of Geronimo code copied and pasted
into the plugin.  If we fix the EJB proxy bug and the EJB reference
builder bug and the ENCConfigBuilder visibility bug for 1.1.1, then
EJB references should work and the plugin code will get a lot cleaner.
 I plan to look at the last two bugs, and I hear there's a patch for
the EJB proxy bug but we're waiting for Dain to review it and see if
he has a better idea.

Thanks,
Aaron

Re: Update on Quartz plugin, Plugin features

2006-06-22 Thread Matt Hogstrom

Being one of the dissenters I think your approach is fine. Please take into consideration that
there may be competing implementations so the name hopefully will provide a clue as to what the
plugin does.

Thanks for the heads up.

Cheers

Matt

Aaron Mulder wrote:

I was not swayed by the arguments against letting people deploy Quartz
jobs as GBeans. However, I agree that it's not appropriate for every
case. When I document this plugin, I plan to list the use cases I'm
going for and the ones I'm not.

After a little experimentation, I've been able to configure both EJB
references and Resources references for the Quartz jobs using
dependency injection (not JNDI). So for example, if your job declares
a setMyDatabase(DataSource foo) then you can point to a Geronimo data
source in your XML and that method will be called on your job to give
it the appropriate data source before it is executed. EJBs should
work the same way. I don't plan to add service references because I
think people would be unlikely to use JAX-RPC from a non-J2EE
component, but it will just require some XML surgery if people clamor
for it.

However, due to a variety of bugs in 1.1, the EJB references don't
work, and there's a fair amount of Geronimo code copied and pasted
into the plugin. If we fix the EJB proxy bug and the EJB reference
builder bug and the ENCConfigBuilder visibility bug for 1.1.1, then
EJB references should work and the plugin code will get a lot cleaner.
I plan to look at the last two bugs, and I hear there's a patch for
the EJB proxy bug but we're waiting for Dain to review it and see if
he has a better idea.

Thanks,
Aaron

gbuild: upgraded to continuum-1.0.3

Subject says it all.  All projects moved over except XBean because  
its root pom.xml has an incorrect scm url.


-David

[jira] Reopened: (GERONIMODEVTOOLS-83) Build fails for plugin org.apache.geronimo.st.v11.ui

2006-06-22 Thread Donald Woods (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83?page=all ]
 
Donald Woods reopened GERONIMODEVTOOLS-83:
--


Tried building it at least 6 times tonight without any luck.
Tried building a clean checkout at least 3 times in a row.
Tried with a clean Maven2 repo twice.
Tried rebuilding after removing all the target dirs.
No luck.

When is the last time you have deleted your .m2 repository and try to build?  
Wondering if you have some file versions in your repo that are no longer 
available..

 Build fails for plugin org.apache.geronimo.st.v11.ui
 

  Key: GERONIMODEVTOOLS-83
  URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83
  Project: Geronimo-Devtools
 Type: Bug

   Components: eclipse-plugin
  Environment: WinXP, Sun Java 1.4.2_12, Maven 2.0.4
 Reporter: Donald Woods
 Assignee: Sachin Patel
 Priority: Blocker


 Have not been able to build trunk Rev411643.  During the build, I'm getting 
 the following failure for plugins\org.apache.geronimo.st.v1.core
 . . .snip
 [INFO] 
 
 [INFO] Building org.apache.geronimo.st.v1.core
 [INFO]task-segment: [install]
 [INFO] 
 
 [INFO] [geronimodevtools:download {execution: install-dependencies}]
 [INFO] emf-sdo-xsd-SDK-2.1.2.zip already exists in local repository
 [INFO] JEM-SDK-1.1.0.1.zip already exists in local repository
 [INFO] GEF-SDK-3.1.1.zip already exists in local repository
 [INFO] wtp-sdk-R-1.0.2-200604280245.zip already exists in local repository
 [INFO] eclipse-SDK-3.1.2-win32.zip already exists in local repository
 [INFO] [geronimodevtools:manifestbundles {execution: install-dependencies}]
 [INFO] [geronimodevtools:install {execution: install-dependencies}]
 [INFO] org.eclipse.jdt.core : 3.1.2 already exists in local repository.
 [INFO] org.eclipse.emf.mapping.xsd2ecore : 2.1.0 already exists in local 
 repository.
 [INFO] org.eclipse.emf.common : 2.1.0 already exists in local repository.
 [INFO] org.eclipse.wst.server.core : 1.0.2.v20060406 already exists in local 
 repository.
 [INFO] org.eclipse.wst.web : 1.0.1.v200603160007 already exists in local 
 repository.
 [INFO] org.eclipse.jst.j2ee : 1.0.1.v200604191828 already exists in local 
 repository.
 [INFO] org.eclipse.core.runtime : 3.1.2 already exists in local repository.
 [INFO] org.eclipse.debug.core : 3.1.2 already exists in local repository.
 [INFO] org.eclipse.emf.ecore : 2.1.0 already exists in local repository.
 [INFO] org.eclipse.emf.mapping.xsd2ecore.editor : 2.1.0 already exists in 
 local repository.
 [INFO] org.eclipse.jdt.launching : 3.1.0 already exists in local repository.
 [INFO] org.eclipse.xsd.edit : 2.1.0 already exists in local repository.
 [INFO] org.eclipse.jst.server.core : 1.0.2.v20060402 already exists in local 
 repository.
 [INFO] org.eclipse.wst.common.project.facet.core : 1.0.1.v200603242204 
 already exists in local repository.
 [INFO] org.eclipse.emf.mapping.ui : 2.1.0 already exists in local repository.
 [INFO] org.eclipse.wst.common.frameworks : 1.0.1.v200602070050 already exists 
 in local repository.
 [INFO] org.eclipse.jst.server.generic.core : 1.0.0.v200602112126 already 
 exists in local repository.
 [INFO] org.eclipse.wst.common.modulecore : 1.0.1.v200604191828 already exists 
 in local repository.
 [INFO] org.eclipse.osgi : 3.1.2 already exists in local repository.
 [INFO] [geronimodevtools:download {execution: install-dependencies}]
 [INFO] emf-sdo-xsd-SDK-2.1.2.zip already exists in local repository
 [INFO] JEM-SDK-1.1.0.1.zip already exists in local repository
 [INFO] GEF-SDK-3.1.1.zip already exists in local repository
 [INFO] wtp-sdk-R-1.0.2-200604280245.zip already exists in local repository
 [INFO] eclipse-SDK-3.1.2-win32.zip already exists in local repository
 [INFO] [geronimodevtools:manifestbundles {execution: install-dependencies}]
 [INFO] [geronimodevtools:install {execution: install-dependencies}]
 [INFO] org.eclipse.jdt.core : 3.1.2 already exists in local repository.
 [INFO] org.eclipse.emf.mapping.xsd2ecore : 2.1.0 already exists in local 
 repository.
 [INFO] org.eclipse.emf.common : 2.1.0 already exists in local repository.
 [INFO] org.eclipse.wst.server.core : 1.0.2.v20060406 already exists in local 
 repository.
 [INFO] org.eclipse.wst.web : 1.0.1.v200603160007 already exists in local 
 repository.
 [INFO] org.eclipse.jst.j2ee : 1.0.1.v200604191828 already exists in local 
 repository.
 [INFO] org.eclipse.core.runtime : 3.1.2 already exists in local repository.
 [INFO] org.eclipse.debug.core : 3.1.2 already exists in local repository.
 [INFO] org.eclipse.emf.ecore : 2.1.0 already exists in local repository.
 [INFO] org.eclipse.emf.mapping.xsd2ecore.editor : 2.1.0 already exists in 
 local repository.
 [INFO]

[jira] Created: (GERONIMODEVTOOLS-86) Stack Traces upon Publishing Errors are difficult to read

2006-06-22 Thread Neal Sanche (JIRA)

Stack Traces upon Publishing Errors are difficult to read
-

 Key: GERONIMODEVTOOLS-86
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-86
 Project: Geronimo-Devtools
Type: Improvement

  Components: eclipse-plugin  
 Environment: Windows, Eclipse Callisto RC4a.
Reporter: Neal Sanche


The stack traces produced when the eclipse plugin fails to deploy a project to 
the server appear all on one line, so that the developer has to scroll 
horizontally to find the cause of the problem. An improvement I would suggest 
would be to present the user the Message text of the exception and all of the 
CausedBy exceptions first, then rewrite the stacktrace to provide the correct 
line-breaks for the platform before displaying it to the user.

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

Re: Apache Geronimo Knowledge Base (was: Wiki based FAQ)

2006-06-22 Thread Prasad Kashyap


Cool Jason. I like it. Can we please have to/fro links from the
http://cwiki.apache.org/geronimo site to the KB.

Thanx
Prasad

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

Autoexport is up:

 http://cwiki.apache.org/GMOxKB/index.html

--jason


On Jun 22, 2006, at 12:17 PM, Jason Dillon wrote:

 Okay, here ya go:

 http://cwiki.apache.org/confluence/display/GMOxKB

 I did a few things...

 First, I setup a geronimo team label, and labeled all of our spaces
 (so from the dashboard you can see all of the G-related spaces
 easily).  New spaces for G should also get this label added (have
 add it manually after creation).

 Then I added a {font-size} user-macro to help change font sizes.

 I installed the navigation plugin (which gets us {scrollbar}).

 I installed the footnotes plugin, see this for an example: http://
 cwiki.apache.org/confluence/display/GMOxKB/CLI

 And I installed the plugin repository client, which makes it easier
 to manage plugin versions.  I need to know how to get the Utilities
 plugin installed into WEB-INF/lib before I can enable some of the
 other plugins, but that can wait.  If you have admin, you can see
 the repository client page here:

 http://cwiki.apache.org/confluence/admin/repository/plugins.action

 Just be careful, cause sometimes installing a plugin will hose the
 entire Confluence install, or need it to be bounced before it is
 usable.

 Who is the point-man for bouncing/installing stuff for this?

  * * *

 Basically there are 3 major sections (each of which could really be
 its own space if needed, when we get more content, but for now will
 work):

  FAQ - yada yada
  Topics - General KB stuff, not really FAQ
  Glossary - Definitions for terms

 The way it works is that each bit of content is its own page.  That
 pages parent page is the section it is under.  The name of the page
 is the topic title, or FAQ question, or glossary term.

 Each content page has at the top {scrollbar}, so that it is easy to
 navigate between all of the pages in the KB.

 Sub-sections are also just pages, but with the {children:all=true}
 macro to allow easy navigation to children.  It is important to add
 that, cause the default rendering of children pages at the bottom
 is disabled.

 The main indexes are dynamic, so you just have to add a page in the
 right place and presto it updates.

 Use the {excerpt} macro to provide a bit more detail that will
 compliment the page title in the listing.

  * * *

 Once we get the Utilities plugin installed into WEB-INF/lib, we can
 use the Zones plugin to setup dynamic templates for each of these
 sections, and then you don't have to worry about the {scrollbar} or
 {children} stuff, just add the content and the zone will render per
 the zone template.

 I have not yet set this up to auto-export, should probably do that
 soon.

  * * *

 Comments?  Questions?  Yada yada...

 --jason

Re: Apache Geronimo Knowledge Base (was: Wiki based FAQ)