date:20060704

problem with auto-ack and messages being redelivered in Stomp clients
-

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

Versions: 4.0.1
Reporter: james strachan
 Assigned to: Hiram Chirino 
 Fix For: 4.0.2, 4.1


For discussion see  
http://www.nabble.com/Stomp-and-ActiveMessaging-does-not-remove-messages-from-Queue-tf1889402.html#a5165844



-- 
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: New refactored STOMP implementation.

2006-07-04 Thread Nathan Mittler


Hiram,
BTW, did you run the activemq-cpp cpp-unit tests against the broker with the
new stomp transport?  I took a look at your code and it looks like you still
have the request-id/response-id headers in there, so it should work fine.
Looks a lot simpler - easier to find your way around.

Nate

On 7/4/06, James Strachan  [EMAIL PROTECTED] wrote:


It all looks good to me. Given we've already hit AMQ-793 recently...

http://issues.apache.org/activemq/browse/AMQ-793

due to the flow control issues in the stomp implementation under load,
I'd say lets get rid of the old version and go with the new.

On 7/2/06, Hiram Chirino [EMAIL PROTECTED] wrote:
 Howdy STOMP developers,

 Just wantted to let you know that I spent the day doing some major
 refactoring to the STOMP server side protocol implementation in
ActiveMQ.
 The previous implementation did all the work inside a WireFormat
layer.  The
 poll model that it imposed made some things difficult to do and made the

 code just ugly.

 I refactored it so that StompWireFormat takes the STOMP frames and
produces
 StompCommand objects which are like a 1:1 mapping (Perhaps I should
rename
 that to StompFrame).  Then the stomp transport factory sets up the
 TcpTransport to be filtered by a StompTransportFilter which converts the
 StompCommand/Protocol into the ActiveMQ commands and Protocol.  Since
the
 Transport is more event based and is also aware of the transport
lifecycle,
 it should let us continue to extend and add more features to the STOMP
 protocol easier.

 I implemented this in a new package so that we can easily switch back to
the
 old implementation if needed.  Out of the box we are now using the new
 implementation.  But I'd like to get some feed back to see if it
introduced
 any new bugs or if it fixed any old bugs.  If all goes well, I'll get
rid of
 the old version soon.

 --
 Regards,
 Hiram

 Blog: http://hiramchirino.com




--

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

[jira] Resolved: (AMQ-793) problem with auto-ack and messages being redelivered in Stomp clients

 [ https://issues.apache.org/activemq/browse/AMQ-793?page=all ]
 
Hiram Chirino resolved AMQ-793:
---

Resolution: Fixed

new stomp client which fixes this has been backported to 4.0 also.

 problem with auto-ack and messages being redelivered in Stomp clients
 -

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

 Versions: 4.0.1
 Reporter: james strachan
 Assignee: Hiram Chirino
  Fix For: 4.0.2, 4.1



 For discussion see  
 http://www.nabble.com/Stomp-and-ActiveMessaging-does-not-remove-messages-from-Queue-tf1889402.html#a5165844

-- 
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-787) The UdpTransport could potentialy fail to bind on linux.. caused the UdpTransportTest to fail sometimes.

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

Hiram Chirino updated AMQ-787:
--

Fix Version: 4.0.2

 The UdpTransport could potentialy fail to bind on linux.. caused the 
 UdpTransportTest to fail sometimes.
 

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

 Versions: 4.0
 Reporter: Hiram Chirino
 Assignee: Hiram Chirino
  Fix For: 4.1, 4.0.2



 [junit] [ERROR] Test org.apache.activemq.transport.udp.UdpTransportTest FAILED

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

[jira] Commented: (AMQ-787) The UdpTransport could potentialy fail to bind on linux.. caused the UdpTransportTest to fail sometimes.

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

Hiram Chirino commented on AMQ-787:
---

Fix also applied to 4.0 branch rev 419025.

 The UdpTransport could potentialy fail to bind on linux.. caused the 
 UdpTransportTest to fail sometimes.
 

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

 Versions: 4.0
 Reporter: Hiram Chirino
 Assignee: Hiram Chirino
  Fix For: 4.1, 4.0.2



 [junit] [ERROR] Test org.apache.activemq.transport.udp.UdpTransportTest FAILED

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

[jira] Resolved: (AMQ-794) make the support of advisory messages optional (so that they can be disabled to reduce RAM and boost performance a little)

 [ https://issues.apache.org/activemq/browse/AMQ-794?page=all ]
 
james strachan resolved AMQ-794:


Resolution: Fixed

Done - you can now disable advisory support via 

broker advisorySupport=false...

or

BrokerService broker = new BrokerService();
broker.setAdvisorySupport(false);
...
broker.start();

 make the support of advisory messages optional (so that they can be disabled 
 to reduce RAM and boost performance a little)
 --

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

 Reporter: james strachan
 Assignee: james strachan
  Fix For: 4.1





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

[jira] Created: (AMQ-795) security plugin to deal with temporary queue and topics better

security plugin to deal with temporary queue and topics better
--

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

Reporter: james strachan
 Fix For: 4.1


Allow a role to be specified for read/write/admin of temporary queue and 
temporary topics

-- 
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: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)


On Jul 3, 2006, at 10:27 PM, John Sisson wrote:
IMO, a vote for a patch would be need to be restarted if the  
changes between the previous patch and the newer version of the  
patch are not trivial.  Trival meaning:


* documentation changes
* non-controversial non-semantic style changes such as fixing  
indentation and adding comments.
Trivial changes do not include code changes or changes that affect  
the operation of the build.


In general I agree with you... but I'm not sure that this should  
apply to what is going on for m2 work (or other similar types of work).


If we tried to follow this, then almost everyday the latest patch  
needs to be reapplied and re-approved by everyone.  Its been hard  
enough to get people to apply any version of the patch.  I do not  
think, for this work, that requiring folks to reapply/revalidate for  
every revision for the RTC to complete is going to be effective.


I am making significant progress on the m2 build and I really would  
rather not wait for (days, weeks) for one patch to get approved  
before continuing to work on the next steps.  I can also not really  
split up these into incremental patches.


I might have a different opinion of this entire situation if there  
were more PMC members that were actually looking at these patches...  
say one a day.  If I pump out an average of 1/2+ a patch a day, then...


After 2 days, 2 PMC would have reviewed (and lets just say were +1),  
but I have gotten further and have a new version of the patch now, so  
now they need to do it again... and probably won't until tomorrow.


After 3 days, the 3rd PMC got to the v2 patch and +1

After 4 days, another PMC + 1, but another version is out... so  
scratch the votes and start over.


The only chance in this example is for 1-2 PMC members to review  
apply each day.  If 1 on the first, then must be 2 on the second or  
visa-versa.  Given the current PMC member activity, I don't believe  
it will ever be possible (following this example) to every get  
anything approved.


 * * *

How on earth is this going to work?  In this example I was being  
optimistic about one +1 per day by a PMC member, but based on the  
current status of GERONIMO-2161 it looks more like one +1 every 2 or  
3 days.


The alternative is to slow down... make less changes, waiting the  
time for PMC members to vote on a single revision.  So, one +1 every  
2 or 3 days turns into 6 to 9 days of idle time waiting for PMC  
members to review/vote.  And since I have made 2 (almost 3 from  
todays work) significant additions to the patch, that means about 18  
to 27 days to get the *additional* changes I have made in the past  
few days voted in to be committed.


The end result is a month+ has gone by, very little progress was  
actually committed to the codebase to migrate to Maven 2.  At that  
rate, maybe by this time next year we will have something ready.  Or,  
lets say that the numbers are off... by 50% or so... well then it  
will only take more months to implement the transition to m2.


So if it takes 6mo to a year to transition to a new build system...  
how long is it going to take to actually build features that are  
users want?!  I'm not including any of the time spent so far with the  
m2 conversion... but from what I gather its already been in progress  
for several months.  This is work that should be easily completed in  
a week or so, given that there are people actively working on it.


 * * *

Maybe I have been smoking too much crack or popped one to many crazy  
pills, but this really seems like a whacked-out impossible situation...


--jason

Re: m2migration branch - thoughts?

2006-07-04 Thread Jacek Laskowski


On 7/3/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:


Because m2 work is not the only work that's going on.  Not all work has
stopped.  You are only speaking of the m2 conversion work.  There are
other efforts underway.


Again, I don't follow. If a change is applied to trunk, why shouldn't
it be done to the branch, too? Wouldn't it ensure that the branch is
up-to-date? I think I miss something obvious and you explain me
something assuming I've got all information you've got. I remember one
said in this mailing list that it's always worth to try it out in
action rather than discussing it over and over again. Although it
doesn't work in all cases, it likely will in this one.

So, did this:

$ svn copy https://svn.apache.org/repos/asf/geronimo/trunk \
 https://svn.apache.org/repos/asf/geronimo/branches/m2migration \
 -m Creating a branch for M2 migration

Committed revision 418926.

and a branch is ready at

https://svn.apache.org/repos/asf/geronimo/branches/m2migration/

I hope I didn't break anything and the only change in Geronimo repo is
the branch only ;-)

Jacek

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

m2migration branch is available

2006-07-04 Thread Jacek Laskowski


Hi,

Just created a branch - m2migration - for all our work pertaining to
the M2 migration of Geronimo build. Everybody's welcome to work on it
*without* RTC on. Revolutionary rules are enabled again! ;-)

The branch is available at
https://svn.apache.org/repos/asf/geronimo/branches/m2migration.

Once we're ready to move a part of the work done in this branch, we'll
create a patch and RTC'ed it to commit to trunk. I believe it will
help those who are reluctant to work on the branch and give a hope not
all is/will be lost ;-)

Just to be clear: anybody who wants to learn M2 tricks and help us
with the migration is welcome. Those who aren't committers can/should
count on me to commit their work (my kids are away on their vacation,
so let's do it before they come back home ;-))

Jacek

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

Re: m2migration branch - thoughts?


Who's responsible for keeping this branch in sync with trunk?

Specifically who is going to merge changes from trunk to this branch  
and/or apply patches to this branch when they are applied to trunk?


--jason


On Jul 3, 2006, at 11:29 PM, Jacek Laskowski wrote:


On 7/3/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:

Because m2 work is not the only work that's going on.  Not all  
work has

stopped.  You are only speaking of the m2 conversion work.  There are
other efforts underway.


Again, I don't follow. If a change is applied to trunk, why shouldn't
it be done to the branch, too? Wouldn't it ensure that the branch is
up-to-date? I think I miss something obvious and you explain me
something assuming I've got all information you've got. I remember one
said in this mailing list that it's always worth to try it out in
action rather than discussing it over and over again. Although it
doesn't work in all cases, it likely will in this one.

So, did this:

$ svn copy https://svn.apache.org/repos/asf/geronimo/trunk \
 https://svn.apache.org/repos/asf/geronimo/branches/m2migration \
 -m Creating a branch for M2 migration

Committed revision 418926.

and a branch is ready at

https://svn.apache.org/repos/asf/geronimo/branches/m2migration/

I hope I didn't break anything and the only change in Geronimo repo is
the branch only ;-)

Jacek

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

Re: m2migration branch - thoughts?

2006-07-04 Thread Jacek Laskowski


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

Who's responsible for keeping this branch in sync with trunk?

Specifically who is going to merge changes from trunk to this branch
and/or apply patches to this branch when they are applied to trunk?


I'd be glad to do so. In other words - it's me, but I count on you and
others. Call me the m2migration branch maintainer ;-)


--jason


Jacek

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

Re: m2migration branch - thoughts?


Brave man!  Doesn't look like much fun:

http://svnbook.red-bean.com/nightly/en/svn- 
book.html#svn.branchmerge.commonuses.wholebr


But, maybe no one will commit anything to trunk over the next days/ 
weeks/months :-P


 * * *

Does anyone know off hand if the Subversion peeps are going to be  
adding the tracking of integrations/merges anytime soon?


--jason


On Jul 4, 2006, at 12:10 AM, Jacek Laskowski wrote:


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

Who's responsible for keeping this branch in sync with trunk?

Specifically who is going to merge changes from trunk to this branch
and/or apply patches to this branch when they are applied to trunk?


I'd be glad to do so. In other words - it's me, but I count on you and
others. Call me the m2migration branch maintainer ;-)


--jason


Jacek

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

Re: m2migration branch - thoughts?


Has anyone used SVK to facilitate full branch merging at all?

--jason


On Jul 4, 2006, at 12:10 AM, Jacek Laskowski wrote:


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

Who's responsible for keeping this branch in sync with trunk?

Specifically who is going to merge changes from trunk to this branch
and/or apply patches to this branch when they are applied to trunk?


I'd be glad to do so. In other words - it's me, but I count on you and
others. Call me the m2migration branch maintainer ;-)


--jason


Jacek

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

Re: m2migration branch - thoughts?



On Jul 4, 2006, at 12:35 AM, Jason Dillon wrote:


Has anyone used SVK to facilitate full branch merging at all?


I used svk while I was working on jetspeed 2/geronimo integration.   
However, I wasn't a jetspeed committer at the time so don't know how  
well actually committing sets of versions to the svn repo works.


I found it invaluable to track my work locally and be able to merge  
in trunk changes and produce patches, but IIRC none of the patches I  
produced could be applied by patch.  So, it would probably help  
single developers but might not improve communication or enable review.


thanks
david jencks



--jason


On Jul 4, 2006, at 12:10 AM, Jacek Laskowski wrote:


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

Who's responsible for keeping this branch in sync with trunk?

Specifically who is going to merge changes from trunk to this branch
and/or apply patches to this branch when they are applied to trunk?


I'd be glad to do so. In other words - it's me, but I count on you  
and

others. Call me the m2migration branch maintainer ;-)


--jason


Jacek

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

Re: m2migration branch - thoughts?

I found it invaluable to track my work locally and be able to merge  
in trunk changes and produce patches, but IIRC none of the patches  
I produced could be applied by patch.  So, it would probably help  
single developers but might not improve communication or enable review


I would not expect it to have anything to do with communication or  
review.  Just looking for an easier way to keep development branches  
inn sync with trunk, and then when approved, make it easy to merge  
back to trunk.  SVN is not very good at making this easy and thus  
ends up being error prone (their book even warns users about it).


So, I was thinking that something like SVK might help facilitate the  
sync... but I've only played with SVK in attempts to keep a SVN repo  
synchronized with Perforce.


Seems like it might work... I'm gonna try and see.

--jason

[jira] Updated: (SM-477) servicemix-http does not reply with HTTP 202 when processing oneway SOAP messages

2006-07-04 Thread Renaud Bruyeron (JIRA)

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

Renaud Bruyeron updated SM-477:
---

Attachment: patch.txt


this patch fixes the issue above: when the exchange is Done (i.e. in-only or 
robust-in-only) we send a HTTP 202 instead of the default HTTP 200.

 servicemix-http does not reply with HTTP 202 when processing oneway SOAP 
 messages
 ---

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

   Components: servicemix-http
 Versions: 3.0-M2
  Environment: See 
 http://www.nabble.com/support-for-oneway-MEP-in-servicemix-http---tf1871975.html
 When using Axis 1.4 to post a oneway SOAP message, servicemix-http replies 
 with a HTTP 200, which the client interprets as a response. It should reply 
 with 202 which is the right reply for async oneway processing.
 I am not sure on the fix though: on what criteria should sm-http decide what 
 http code to return? is it on the MEP declared on the endpoint, or on the 
 wsdl, or both?
 Reporter: Renaud Bruyeron
  Fix For: 3.0
  Attachments: patch.txt




-- 
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: TranQL m2 build...

Attached is an updated diff with the same version numbers as  
requested.  I just used the versions from the project.xml... someone  
should double check.


Spits out:

/Users/jason/.m2/repository/org/tranql/tranql-connector/1.2-SNAPSHOT/ 
tranql-connector-1.2-SNAPSHOT.jar
/Users/jason/.m2/repository/org/tranql/tranql-connector-derby-common/ 
1.2-SNAPSHOT/tranql-connector-derby-common-1.2-SNAPSHOT.jar
/Users/jason/.m2/repository/org/tranql/tranql-core/1.3-SNAPSHOT/ 
tranql-1.3-SNAPSHOT.jar
/Users/jason/.m2/repository/org/tranql//tranql-connector-derby-client- 
local/1.2-SNAPSHOT/tranql-connector-derby-client-local-1.2-SNAPSHOT.rar
/Users/jason/.m2/repository/org/tranql//tranql-connector-derby-client- 
xa/1.2-SNAPSHOT/tranql-connector-derby-client-xa-1.2-SNAPSHOT.rar
/Users/jason/.m2/repository/org/tranql//tranql-connector-derby-embed- 
local/1.2-SNAPSHOT/tranql-connector-derby-embed-local-1.2-SNAPSHOT.rar
/Users/jason/.m2/repository/org/tranql//tranql-connector-derby-embed- 
xa/1.2-SNAPSHOT/tranql-connector-derby-embed-xa-1.2-SNAPSHOT.rar
/Users/jason/.m2/repository/org/tranql//tranql-connector-ra/1.2- 
SNAPSHOT/tranql-connector-ra-1.2-SNAPSHOT.rar


--jason



tranql-m2-v2.diff
Description: Binary data



On Jul 3, 2006, at 10:31 PM, Jason Dillon wrote:


Not sure who to send this too... so I'm posting it here.

Attached is the start of a m2 build for TranQL.  This builds the  
core (tranql), connector and derby bits.  Had to add a separate  
connector-ra to build the rar, as the vendor bits need the jar for  
depends and I'm not sure how to make m2 build that configuration.


I set this up to all build in one cycle, using org.tranql and 2.0- 
SNAPSHOT... if you guys wanna keep the versions different for the  
vendor bits then some small changes need to be made... though IMO  
its easier to maintain the tree with one version.


Still needs the other vendors hooked up, but those should be  
relatively simple to create based on the derby poms.


Cheers,

--jason

tranql-m2.diff

Re: newbie newbie

2006-07-04 Thread James Strachan


On 7/4/06, Lalit Nagpal [EMAIL PROTECTED] wrote:

Hi,

I am a absolute new starter in the field of MOM although I worked on MQ
Series sometime back.


Welcome! :)


But totally new to ActiveMQ ... need to pick up on
ActiveMQ.
Can somebody guide me as to how to get started on this.


I'd start here
http://incubator.apache.org/activemq/getting-started.html



Specially areas of C++ like Stomp, Openwire and stuff.


For background see...
http://incubator.apache.org/activemq/stomp.html
http://incubator.apache.org/activemq/openwire.html

The C++ client is undergoing some work; we've a new C++ client just
been imported here
https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cpp/

but the current C++ client, CMS is documented here
http://incubator.apache.org/activemq/cms.html
--

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

Re: TranQL m2 build...


I looked this over and applied it.

It appears that the versions in project.xml (and now the poms) are  
lower than those expected by geronimo, e.g. tranql version is 1.3- 
SNAPSHOT but geronimo is using 1.4-SNAPSHOT, connector version is 1.2- 
SNAPSHOT but geronimo is using 1.3-SNAPSHOT.


Does anyone know what is going on and where the tranql snapshots with  
the higher numbers are from?


thanks
david jencks

On Jul 4, 2006, at 1:16 AM, Jason Dillon wrote:

Attached is an updated diff with the same version numbers as  
requested.  I just used the versions from the project.xml...  
someone should double check.


Spits out:

/Users/jason/.m2/repository/org/tranql/tranql-connector/1.2- 
SNAPSHOT/tranql-connector-1.2-SNAPSHOT.jar
/Users/jason/.m2/repository/org/tranql/tranql-connector-derby- 
common/1.2-SNAPSHOT/tranql-connector-derby-common-1.2-SNAPSHOT.jar
/Users/jason/.m2/repository/org/tranql/tranql-core/1.3-SNAPSHOT/ 
tranql-1.3-SNAPSHOT.jar
/Users/jason/.m2/repository/org/tranql//tranql-connector-derby- 
client-local/1.2-SNAPSHOT/tranql-connector-derby-client-local-1.2- 
SNAPSHOT.rar
/Users/jason/.m2/repository/org/tranql//tranql-connector-derby- 
client-xa/1.2-SNAPSHOT/tranql-connector-derby-client-xa-1.2- 
SNAPSHOT.rar
/Users/jason/.m2/repository/org/tranql//tranql-connector-derby- 
embed-local/1.2-SNAPSHOT/tranql-connector-derby-embed-local-1.2- 
SNAPSHOT.rar
/Users/jason/.m2/repository/org/tranql//tranql-connector-derby- 
embed-xa/1.2-SNAPSHOT/tranql-connector-derby-embed-xa-1.2-SNAPSHOT.rar
/Users/jason/.m2/repository/org/tranql//tranql-connector-ra/1.2- 
SNAPSHOT/tranql-connector-ra-1.2-SNAPSHOT.rar


--jason

tranql-m2-v2.diff


On Jul 3, 2006, at 10:31 PM, Jason Dillon wrote:


Not sure who to send this too... so I'm posting it here.

Attached is the start of a m2 build for TranQL.  This builds the  
core (tranql), connector and derby bits.  Had to add a separate  
connector-ra to build the rar, as the vendor bits need the jar for  
depends and I'm not sure how to make m2 build that configuration.


I set this up to all build in one cycle, using org.tranql and 2.0- 
SNAPSHOT... if you guys wanna keep the versions different for the  
vendor bits then some small changes need to be made... though IMO  
its easier to maintain the tree with one version.


Still needs the other vendors hooked up, but those should be  
relatively simple to create based on the derby poms.


Cheers,

--jason

tranql-m2.diff

Re: m2migration branch - thoughts?


On Jul 4, 2006, at 12:43 AM, David Jencks wrote:
I found it invaluable to track my work locally and be able to merge  
in trunk changes and produce patches, but IIRC none of the patches  
I produced could be applied by patch.  So, it would probably help  
single developers but might not improve communication or enable  
review.


I just re-read this... why were the patches you produced not able to  
be applied?


Did SVK generate bunk patches?

 * * *

From what I have read so far, I *think* that using SVK *might* work  
to perform the branch sync'ing.


I'm going to test it out tomorrow; something like

Create a faux-trunk and branch to test with and not taint the real  
trunk or branch:


svn cp https://svn.apache.org/repos/asf/geronimo/trunk https:// 
svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/trunk
svn cp https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/ 
trunk https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/ 
m2migration


Then I'm going to setup SVK to mirror both of these new branches...  
which I think ends up looking like:


svk cp https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/ 
trunk trunk
svk cp https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/ 
m2migration m2migration


But, I'm only going to use SVK to sync... not apply changes, so I  
will apply the GERONIMO-2161 patch to https://svn.apache.org/repos/ 
asf/geronimo/sandbox/svkmerge/m2migration and then commit with SVN


Then sync the SVK mirrors...

And then smerge m2migration to trunk with SVK (svk push).  Should  
also be able to test smerge trunk to m2migration to test how branch  
refreshing works (svk pull).


Found this email which leads me to believe that this will work:

http://rt.openfoundry.org/Foundry/Project/Forum/List.html/wws/ 
arc/svk-dev/2005-02/msg00035.html


I might ping folks in #svk on freenode too and see what they have to  
say about using SVK in this manner.


--jason

Re: TranQL m2 build...


On Jul 4, 2006, at 1:39 AM, David Jencks wrote:

I looked this over and applied it.


Cool.


It appears that the versions in project.xml (and now the poms) are  
lower than those expected by geronimo, e.g. tranql version is 1.3- 
SNAPSHOT but geronimo is using 1.4-SNAPSHOT, connector version is  
1.2-SNAPSHOT but geronimo is using 1.3-SNAPSHOT.


Does anyone know what is going on and where the tranql snapshots  
with the higher numbers are from?


When this is resolved, should get new jars pushed with the org.tranql  
groupId and then update the G and OpenEJB builds to use them.  You  
can then remove the local m1 repo cache bits in the OpenEJB build.


--jason

[jira] Updated: (GERONIMO-2164) Creating SQL- based security realm fails

2006-07-04 Thread Aaron Mulder (JIRA)

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

Aaron Mulder updated GERONIMO-2164:
---

Fix Version: 1.1.1

 Creating SQL- based security realm fails
 

  Key: GERONIMO-2164
  URL: http://issues.apache.org/jira/browse/GERONIMO-2164
  Project: Geronimo
 Type: Bug
 Security: public(Regular issues) 
   Components: console
 Versions: 1.1
  Environment: Geronimo 1.1, Jetty version, running on Sun Java 1.4.2_08
 Reporter: Markus Hanecke
  Fix For: 1.1.1


 It's not possible to create an SQL-based security realm using the console in 
 Geronimo 1.1.
 Error shown in console:
 Error: Error: Unable to initialize LoginModule: Unable to load, instantiate, 
 register driver null: null
 Error written to Geronimo logfile:
 09:49:15,142 ERROR [SecurityRealmPortlet] Unable to parse ObjectName
 javax.management.MalformedObjectNameException: Missing ':' character in 
 ObjectName
 at javax.management.ObjectName.parseDomain(ObjectName.java:417)
 at javax.management.ObjectName.parse(ObjectName.java:385)
 at javax.management.ObjectName.init(ObjectName.java:76)
 at javax.management.ObjectName.getInstance(ObjectName.java:261)
 at 
 org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet$RealmData.load(SecurityRealmPortlet.java:775)
 at 
 org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.processAction(SecurityRealmPortlet.java:167)
 at 
 org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
 at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
 at 
 org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
 at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
 at 
 org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
 at 
 org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
 at 
 org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
 at 
 org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
 at 
 org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
 at 
 org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWebApplicationHandler.java:58)
 at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
 at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
 at 
 org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
 at 
 org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
 at 
 org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
 at 
 org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
 at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
 at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
 at 
 org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
 at 
 org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
 at 
 org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
 at 
 org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
 at 
 org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
 at 
 org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWebApplicationHandler.java:58)
 at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
 at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
 at 
 org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
 at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
 at org.mortbay.http.HttpServer.service(HttpServer.java:909)
 at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
 at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
 at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
 at 
 org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
 at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
 at

Re: m2migration branch is available

2006-07-04 Thread Aaron Mulder


Jacek,

When discussing whether a branch was appropriate, I expressed a
concern that it would be difficult to merge changes from this branch
to HEAD because SVN seems to have difficulty handling multiple
revisions of add/delete/move/copy operations in a single merge (and I
understand the M2 restructuring will involve a lot of that).  I've
often had problems where something is e.g. removed and then recreated
and I try to apply and it refuses claiming that there's something in
the way.  The only way to proceed is to manually delete offending
directories and then update.  But that won't work for merging from a
branch to HEAD -- it would effectively be a revolution operation where
we would have to vote to delete HEAD and move the branch to HEAD.
Then we lose the bug fixes that have been applied to HEAD and we've
been through that before.

I'm concerned that you ignored this concern and went ahead with the
branch plan.  In fact the only response I got was that perhaps a
commercial source control system would be better.  Perhaps that means
this should have been an RTC operation so you were forced to address
my concern before taking this approach.

Thanks,
   Aaron

On 7/4/06, Jacek Laskowski [EMAIL PROTECTED] wrote:

Hi,

Just created a branch - m2migration - for all our work pertaining to
the M2 migration of Geronimo build. Everybody's welcome to work on it
*without* RTC on. Revolutionary rules are enabled again! ;-)

The branch is available at
https://svn.apache.org/repos/asf/geronimo/branches/m2migration.

Once we're ready to move a part of the work done in this branch, we'll
create a patch and RTC'ed it to commit to trunk. I believe it will
help those who are reluctant to work on the branch and give a hope not
all is/will be lost ;-)

Just to be clear: anybody who wants to learn M2 tricks and help us
with the migration is welcome. Those who aren't committers can/should
count on me to commit their work (my kids are away on their vacation,
so let's do it before they come back home ;-))

Jacek

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

Bpe integration with tomcat

2006-07-04 Thread davipo


Hi, I'm trying to integrate servicemix-bpe bpel engine into servicemix-web
and trying to deploy it under tomcat but I have many problems to insert the
wsdl files. when I try to deploy I have theese errors:

4-lug-2006 10.26.54 org.apache.servicemix.jbi.framework.ComponentMBeanImpl
setInitialRunningState
INFO: Setting running state for Component: servicemix-bpe to Started

4-lug-2006 10.26.54 org.apache.servicemix.jbi.framework.ComponentMBeanImpl
init
INFO: Initializing component: servicemix-bpe

4-lug-2006 10.26.54 org.apache.ode.bpe.util.BPEProperties lookupBoolean
AVVERTENZA: Name UUID_USE_CONNECTOR_KEY is not bound in this Context

4-lug-2006 10.26.54
org.apache.servicemix.jbi.framework.ServiceAssemblyLifeCycle stop
INFO: Stopping service assembly: bpe-demo

4-lug-2006 10.26.54 org.apache.servicemix.jbi.framework.ServiceUnitLifeCycle
init
INFO: Initializing service unit: bpe-su

Retrieving document at 'loanbroker'.
Retrieving document at 'creditagency.wsdl', relative to 'loanbroker'.
Retrieving document at 'bank.wsdl', relative to 'loanbroker'.
Retrieving document at 'creditagency.wsdl', relative to 'file:/C:/Program
Files/Apache Software Foundation/Tomcat
5.5/webapps/servicemix-web/wdir/service-assemblies/bpe-demo/version_1/sus/servicemix-bpe/bpe-su/loanbroker.wsdl'.
Retrieving document at 'bank.wsdl', relative to 'file:/C:/Program
Files/Apache Software Foundation/Tomcat
5.5/webapps/servicemix-web/wdir/service-assemblies/bpe-demo/version_1/sus/servicemix-bpe/bpe-su/loanbroker.wsdl'.

[Fatal Error] :1:1: Content is not allowed in prolog.
4-lug-2006 10.26.56
org.apache.servicemix.jbi.framework.ServiceAssemblyLifeCycle
getComponentFailure

AVVERTENZA: Could not parse result exception
org.xml.sax.SAXParseException: Content is not allowed in prolog.
at
com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
at
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown
Source)
at
org.apache.servicemix.jbi.framework.ServiceAssemblyLifeCycle.parse(ServiceAssemblyLifeCycle.java:420)
at
org.apache.servicemix.jbi.framework.ServiceAssemblyLifeCycle.getComponentFailure(ServiceAssemblyLifeCycle.java:401)
at
org.apache.servicemix.jbi.framework.ServiceAssemblyLifeCycle.stop(ServiceAssemblyLifeCycle.java:168)
at
org.apache.servicemix.jbi.framework.ServiceAssemblyLifeCycle.restore(ServiceAssemblyLifeCycle.java:329)
at
org.apache.servicemix.jbi.framework.DeploymentService.start(DeploymentService.java:96)
at
org.apache.servicemix.jbi.container.JBIContainer.start(JBIContainer.java:556)
at
org.apache.servicemix.jbi.container.SpringJBIContainer.afterPropertiesSet(SpringJBIContainer.java:78)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1059)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:363)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:275)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:320)
at
org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:134)
at
org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246)
at
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184)
at
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3729)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4187)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:904)
at
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:867)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:474)
at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at

Re: m2migration branch is available

FYI... Perforce may be commercial, but they provide free licenses for  
qualifying open source usage:


http://perforce.com/perforce/opensource-faq.html

:-)

--jason


On Jul 4, 2006, at 3:50 AM, Aaron Mulder wrote:


Jacek,

When discussing whether a branch was appropriate, I expressed a
concern that it would be difficult to merge changes from this branch
to HEAD because SVN seems to have difficulty handling multiple
revisions of add/delete/move/copy operations in a single merge (and I
understand the M2 restructuring will involve a lot of that).  I've
often had problems where something is e.g. removed and then recreated
and I try to apply and it refuses claiming that there's something in
the way.  The only way to proceed is to manually delete offending
directories and then update.  But that won't work for merging from a
branch to HEAD -- it would effectively be a revolution operation where
we would have to vote to delete HEAD and move the branch to HEAD.
Then we lose the bug fixes that have been applied to HEAD and we've
been through that before.

I'm concerned that you ignored this concern and went ahead with the
branch plan.  In fact the only response I got was that perhaps a
commercial source control system would be better.  Perhaps that means
this should have been an RTC operation so you were forced to address
my concern before taking this approach.

Thanks,
   Aaron

On 7/4/06, Jacek Laskowski [EMAIL PROTECTED] wrote:

Hi,

Just created a branch - m2migration - for all our work pertaining to
the M2 migration of Geronimo build. Everybody's welcome to work on it
*without* RTC on. Revolutionary rules are enabled again! ;-)

The branch is available at
https://svn.apache.org/repos/asf/geronimo/branches/m2migration.

Once we're ready to move a part of the work done in this branch,  
we'll

create a patch and RTC'ed it to commit to trunk. I believe it will
help those who are reluctant to work on the branch and give a hope  
not

all is/will be lost ;-)

Just to be clear: anybody who wants to learn M2 tricks and help us
with the migration is welcome. Those who aren't committers can/should
count on me to commit their work (my kids are away on their vacation,
so let's do it before they come back home ;-))

Jacek

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

Re: m2migration branch is available

2006-07-04 Thread Aaron Mulder


Are you recommending that the project switch to Perforce, or is this
just wishful thinking?

Also, one more note on the merging -- If we change the directory
layout in the branch, it will be very hard to merge any patches to
HEAD into the branch to keep them in sync since all the patch paths
will be wrong.  I don't see how this can end well.  Unless there's a
freeze in HEAD for the duration of the branch, which would mean we're
just using the branch to work around RTC.

Thanks,
   Aaron

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

FYI... Perforce may be commercial, but they provide free licenses for
qualifying open source usage:

 http://perforce.com/perforce/opensource-faq.html

:-)

--jason


On Jul 4, 2006, at 3:50 AM, Aaron Mulder wrote:

 Jacek,

 When discussing whether a branch was appropriate, I expressed a
 concern that it would be difficult to merge changes from this branch
 to HEAD because SVN seems to have difficulty handling multiple
 revisions of add/delete/move/copy operations in a single merge (and I
 understand the M2 restructuring will involve a lot of that).  I've
 often had problems where something is e.g. removed and then recreated
 and I try to apply and it refuses claiming that there's something in
 the way.  The only way to proceed is to manually delete offending
 directories and then update.  But that won't work for merging from a
 branch to HEAD -- it would effectively be a revolution operation where
 we would have to vote to delete HEAD and move the branch to HEAD.
 Then we lose the bug fixes that have been applied to HEAD and we've
 been through that before.

 I'm concerned that you ignored this concern and went ahead with the
 branch plan.  In fact the only response I got was that perhaps a
 commercial source control system would be better.  Perhaps that means
 this should have been an RTC operation so you were forced to address
 my concern before taking this approach.

 Thanks,
Aaron

 On 7/4/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
 Hi,

 Just created a branch - m2migration - for all our work pertaining to
 the M2 migration of Geronimo build. Everybody's welcome to work on it
 *without* RTC on. Revolutionary rules are enabled again! ;-)

 The branch is available at
 https://svn.apache.org/repos/asf/geronimo/branches/m2migration.

 Once we're ready to move a part of the work done in this branch,
 we'll
 create a patch and RTC'ed it to commit to trunk. I believe it will
 help those who are reluctant to work on the branch and give a hope
 not
 all is/will be lost ;-)

 Just to be clear: anybody who wants to learn M2 tricks and help us
 with the migration is welcome. Those who aren't committers can/should
 count on me to commit their work (my kids are away on their vacation,
 so let's do it before they come back home ;-))

 Jacek

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

Re: How do we build the Eclipse Plugin assembly?

2006-07-04 Thread Shiva Kumar H R

Hi Sachin,One observation: In trunk\assembly\src\main\assembly\deployable.xml file, I changed formatzip/format to formatdir/format and ran mvn -o -e assembly:assembly from the assembly directory. I got the following errors: 
---...[INFO] [assembly:assembly][INFO] 
[ERROR] BUILD ERROR[INFO] [INFO] Error creating assembly: You must set at least one file.[INFO] 
[INFO] Traceorg.apache.maven.lifecycle.LifecycleExecutionException: Error creating assembly:You must set at least one file. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java
:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke
(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode
(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375)Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating assembly: You must set at least one file.
 at org.apache.maven.plugin.assembly.AbstractAssemblyMojo.createAssembly(AbstractAssemblyMojo.java:269) at org.apache.maven.plugin.assembly.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:241)
 at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
 ... 16 moreCaused by: org.codehaus.plexus.archiver.ArchiverException: You must set at leastone file. at org.codehaus.plexus.archiver.dir.DirectoryArchiver.createArchive(DirectoryArchiver.java
:56) at org.apache.maven.plugin.assembly.AbstractAssemblyMojo.createArchive(AbstractAssemblyMojo.java:383) at org.apache.maven.plugin.assembly.AbstractAssemblyMojo.createAssembly(AbstractAssemblyMojo.java
:261) ... 19 more---Does this help?- Shiva Kumar
On 7/3/06, Shiva Kumar H R [EMAIL PROTECTED] wrote:
Hi Sachin,I too am facing the same problem as Donald during the assembly of Eclipse Plugin. I am building Revision 418691 of the trunk, using Sun JDK 1.4.2_08  Maven 2.0.4 on a WinXP sp2 machine. By the way, I am interested in contributing to Geronimo Eclipse Plugin. Last year I have done some work on Eclipse Plugin Development and I am comfortable with SWT, JFace and Plugin Development. Also, some of the work I did in Eclipse Drag and Drop got published here: 
http://www-128.ibm.com/developerworks/library/os-ecl-dragdrop/index.html
Last one week I have been browsing through the Geronimo Dev Mailing Lists, as well as JIRA, to figure out how I can contribute to the Eclipse plugin development. If you can point me to a few to-do items of immediate interest, I would be more than happy to pick them up and start working on them right away.
Thanks,Shiva Kumar On 7/1/06, Sachin Patel 
[EMAIL PROTECTED] wrote:
You have to invoke it manually as you've done.I haven't figured outhow to invoke a build+assembly in one step.As far as the file sizeskevan saw the same problem, and we couldn't figure out why.On Jun 30, 2006, at 5:15 PM, Donald Woods wrote:
 I just checked out Rev418113 of the Eclipse plugin trunk, started with a clean m2 repo and successfully got a mvn install to complete after several attempts. But, when I look in the assembly/ directory, no target/ directory
 was created.Is this expected? When I ran mvn from the assembly directory, it created a target directory, but the following zipfiles were only 22 bytes each -g-eclipse-plugin-1.1-deployable.zip

g-eclipse-plugin-1.1-updatesite.zip I'm building on WinXP with Maven 2.0.4 and

[jira] Updated: (GERONIMO-2066) Openejb migration to M2

2006-07-04 Thread Anita Kulshreshtha (JIRA)

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

Anita Kulshreshtha updated GERONIMO-2066:
-

Attachment: openejb.patch

This patch is built against rev 2721.  The code as is does not build. The patch 
adds the following - 
1. use the correct version for  specs, wadi and activecluster.
2. M1 build uses g-dependency.xml for openejb-builder. I also think it is not 
needed.
3. The xmlbeans plugin does not pack the schemas in the jar, hence added code 
to do that.

 Openejb migration to M2
 ---

  Key: GERONIMO-2066
  URL: http://issues.apache.org/jira/browse/GERONIMO-2066
  Project: Geronimo
 Type: Sub-task
 Security: public(Regular issues) 
  Environment: All
 Reporter: Anita Kulshreshtha
  Attachments: openejb.patch, openejb.patch, openejb.patch

 The attached patch provides a local openejb build for Geronimo using 
 o.a.g.modules groupId. 
 This is to ensure that the latest openejb jars are available. The results for 
 rev 2659 are below :
 Path: .
 URL: https://svn.codehaus.org/openejb/branches/v2_1/openejb2
 Repository UUID: 2b0c1533-c60b-0410-b8bd-89f67432e5c6
 Revision: 2659
 Node Kind: directory
 Schedule: normal
 Last Changed Author: gdamour
 Last Changed Rev: 2659
 Last Changed Date: 2006-05-27 08:00:16 -0400 (Sat, 27 May 2006)
 Properties Last Updated: 2006-05-26 19:05:28 -0400 (Fri, 26 May 2006)
 Todo - fix the test failures.
 
 
 APSHOT\openejb-builder-2.1-SNAPSHOT.jar
 [INFO]
 [INFO]
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO] 
 
 [INFO] OpenEJB  SUCCESS 
 [3.953s]
 [INFO] OpenEJB :: Core  SUCCESS 
 [30.515s]
 [INFO] OpenEJB :: PK Generation :: Builder  SUCCESS 
 [9.297s]
 [INFO] OpenEJB :: Builder . SUCCESS 
 [27.875s]
 [INFO] 
 
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 1 minute 12 seconds
 [INFO] Finished at: Mon May 29 08:11:40 EDT 2006
 [INFO] Final Memory: 17M/53M
 [INFO] 
 

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

2006-07-04 Thread Nathan Mittler


Hey Hiram,
Looks ok at first glance - could you send me the patch file as an
attachment?  I seem to be having problems applying the patch through copy 
paste into subclipse.

Thanks,
Nate

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


Hi Nathan,

Please review the following patch.  It allows the stomp client to accept a
variable amount of while space between frames.  I ran the integration
tests
a slightly modified amq broker where it used 3 \n between frames and also
one where no \n were used between frames.  Everything seemed to work, but
since c++ is not my forte, I'm looking for a +1 from a before I commit the
change.

Index: src/main/activemq/connector/stomp/StompCommandReader.cpp
===
--- src/main/activemq/connector/stomp/StompCommandReader.cpp(revision
418889)
+++ src/main/activemq/connector/stomp/StompCommandReader.cpp(working
copy)
@@ -70,20 +70,46 @@
void StompCommandReader::readStompCommand( StompFrame frame )
throw ( StompConnectorException )
{
-// Read the command;
-int numChars = readStompHeaderLine();
+   while( true )
+   {
+   // Clean up the mess.
+   buffer.clear();

-if( numChars = 0 )
-{
-throw StompConnectorException(
-__FILE__, __LINE__,
-StompCommandReader::readStompCommand: 
-Error on Read of Command Header );
-}
+   // Read the command;
+   readStompHeaderLine();

-// Set the command in the frame - copy the memory.
-frame.setCommand( reinterpret_castchar*(buffer[0]) );
-
+// Ignore all white space before the command.
+int offset=-1;
+for( size_t ix = 0; ix  buffer.size()-1; ++ix )
+{
+   // Find the first non space character
+   char b = buffer[ix];
+switch ( b )
+{
+   case '\n':
+   case '\t':
+   case '\r':
+   break;
+
+   default:
+   offset = ix;
+   break;
+}
+
+   if( offset != -1 )
+   {
+   break;
+   }
+}
+
+   if( offset = 0 )
+   {
+   // Set the command in the frame - copy the memory.
+   frame.setCommand(
reinterpret_castchar*(buffer[offset]) );
+   break;
+   }
+
+   }
 // Clean up the mess.
 buffer.clear();
}
@@ -224,8 +250,7 @@
 read( buffer[0], content_length );

 // Content Length read, now pop the end terminator off (\0\n).
-if(inputStream-read() != '\0' ||
-   inputStream-read() != '\n')
+if(inputStream-read() != '\0' )
 {
 throw StompConnectorException(
 __FILE__, __LINE__,
@@ -251,16 +276,6 @@
 continue;
 }

-// We read up to the first NULL, now lets pop off the
required
-// newline to complete the packet.
-if(inputStream-read() != '\n')
-{
-throw StompConnectorException(
-__FILE__, __LINE__,
-StompCommandReader::readStompBody: 
-Read Body, and no trailing newline);
-}
-
 break;  // Read null and newline we are done.
 }
 }



On 7/3/06, Nathan Mittler  [EMAIL PROTECTED] wrote:

 No problem - sorry for the confusion :)

 On 7/3/06, Hiram Chirino [EMAIL PROTECTED] wrote:
 
  Oh. That makes sense!  Sorry for the noise!
 
  On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote:
  
   Hey Hiram,
   I was actually thinking of the messages coming from the broker to
the
   client - the newer version of the broker always sends a \0\n to
denote
   the end of the frame.  I'm not sure if the CMS client is sly enough
to
   handle both cases - I think it's expecting one or the other (either
\0
   or \0\n).  I was just throwing that out there as a possible reason
 that
   the client may freeze on a read - waiting for the trailing \n that
 never
   comes.
  
  
-Original Message-
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf
Of Hiram Chirino
Sent: Monday, July 03, 2006 12:58 PM
To: activemq-dev@geronimo.apache.org
Subject: Re:
   
Hi Nathan,
   
I'm not so sure about that.  I think that AMQ should support
receiving a STOMP frame terminated by \0 without a subsequent
\n.  The STOMP spec does say that white space before a frame
should be ignored.  Anyways, if anybody can confirm that this
is not the case, then it's a bug with how we implemented STOMP in
 AMQ.
   
On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote:

 Hi Naveen,
 There are a couple of things that might be causing this.

 1) The stomp frame ending characters have changed in recent
versions
 of AMQ.  AMQ now

Re: Openejb build for Geronimo

2006-07-04 Thread anita kulshreshtha

   The openejb rev 2721 does not build as is. There are many other
versions which need to be changed. I have attached a refreshed patch to

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

Thanks
Anita

--- Jason Dillon [EMAIL PROTECTED] wrote:

 Attached is a patch that changes the TranQL versions to 1.3-SNAPSHOT 
 
 and 1.4-SNAPSHOT as well as adds the correct SCM tags (so we can  
 build from Continuum) and introduces a root pom (most of the config  
 moved from modules/pom.xml).
 
 --jason
 
  
 
 On Jul 3, 2006, at 8:02 PM, anita kulshreshtha wrote:
 
  Hi All,
  The rev 2720 of openejb at
  https://svn.codehaus.org/openejb/trunk/openejb2 is using wrong  
  versions
  of tranql and activation Spec. Here are the values from
  etc/project.properties -
 
  tranql_version=1.4-SNAPSHOT
  tranql_connector_version=1.3-SNAPSHOT
  tranql_vendors_version=1.1
  ...
  ...
  geronimo_spec_activation_version=1.1
 
 Here are the values from modules/pom.xml -
 
  geronimoSpecActivationVersion1.0/geronimoSpecActivationVersion
  
  tranqlConnectorVersion1.2-SNAPSHOT/tranqlConnectorVersion
  tranqlVendorsVersion1.1/tranqlVendorsVersion
  tranqlVersion1.3-SNAPSHOT/tranqlVersion
   Could someone please update these and add the missing
  g-dependency.xml to openejb-builder.
 
  Thanks
  Anita
 
  __
  Do You Yahoo!?
  Tired of spam?  Yahoo! Mail has the best spam protection around
  http://mail.yahoo.com
 
 


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

[jira] Updated: (GERONIMO-2066) Openejb migration to M2

2006-07-04 Thread Anita Kulshreshtha (JIRA)

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

Anita Kulshreshtha updated GERONIMO-2066:
-

Attachment: openejb.patch

This patch openejb-2.patch adds the g-dependency.xml to openejb-builder. Please 
use either openejb.patch or openejb-2.patch.

 Openejb migration to M2
 ---

  Key: GERONIMO-2066
  URL: http://issues.apache.org/jira/browse/GERONIMO-2066
  Project: Geronimo
 Type: Sub-task
 Security: public(Regular issues) 
  Environment: All
 Reporter: Anita Kulshreshtha
  Attachments: openejb.patch, openejb.patch, openejb.patch, openejb.patch

 The attached patch provides a local openejb build for Geronimo using 
 o.a.g.modules groupId. 
 This is to ensure that the latest openejb jars are available. The results for 
 rev 2659 are below :
 Path: .
 URL: https://svn.codehaus.org/openejb/branches/v2_1/openejb2
 Repository UUID: 2b0c1533-c60b-0410-b8bd-89f67432e5c6
 Revision: 2659
 Node Kind: directory
 Schedule: normal
 Last Changed Author: gdamour
 Last Changed Rev: 2659
 Last Changed Date: 2006-05-27 08:00:16 -0400 (Sat, 27 May 2006)
 Properties Last Updated: 2006-05-26 19:05:28 -0400 (Fri, 26 May 2006)
 Todo - fix the test failures.
 
 
 APSHOT\openejb-builder-2.1-SNAPSHOT.jar
 [INFO]
 [INFO]
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO] 
 
 [INFO] OpenEJB  SUCCESS 
 [3.953s]
 [INFO] OpenEJB :: Core  SUCCESS 
 [30.515s]
 [INFO] OpenEJB :: PK Generation :: Builder  SUCCESS 
 [9.297s]
 [INFO] OpenEJB :: Builder . SUCCESS 
 [27.875s]
 [INFO] 
 
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 1 minute 12 seconds
 [INFO] Finished at: Mon May 29 08:11:40 EDT 2006
 [INFO] Final Memory: 17M/53M
 [INFO] 
 

-- 
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: Openejb build for Geronimo

2006-07-04 Thread anita kulshreshtha

Now we must use the org.openejb groupId in Geronimo. As of rev
418907 Geronimo is still using openejb as groupId. I will be happy to
provide a patch.

Thanks
Anita

--- anita kulshreshtha [EMAIL PROTECTED] wrote:

The openejb rev 2721 does not build as is. There are many other
 versions which need to be changed. I have attached a refreshed patch
 to
 
 http://issues.apache.org/jira/browse/GERONIMO-2066. 
 
 Thanks
 Anita
 
 --- Jason Dillon [EMAIL PROTECTED] wrote:
 
  Attached is a patch that changes the TranQL versions to
 1.3-SNAPSHOT 
  
  and 1.4-SNAPSHOT as well as adds the correct SCM tags (so we can  
  build from Continuum) and introduces a root pom (most of the config
  
  moved from modules/pom.xml).
  
  --jason
  
   
  
  On Jul 3, 2006, at 8:02 PM, anita kulshreshtha wrote:
  
   Hi All,
   The rev 2720 of openejb at
   https://svn.codehaus.org/openejb/trunk/openejb2 is using wrong  
   versions
   of tranql and activation Spec. Here are the values from
   etc/project.properties -
  
   tranql_version=1.4-SNAPSHOT
   tranql_connector_version=1.3-SNAPSHOT
   tranql_vendors_version=1.1
   ...
   ...
   geronimo_spec_activation_version=1.1
  
  Here are the values from modules/pom.xml -
  
  
 geronimoSpecActivationVersion1.0/geronimoSpecActivationVersion
   
   tranqlConnectorVersion1.2-SNAPSHOT/tranqlConnectorVersion
   tranqlVendorsVersion1.1/tranqlVendorsVersion
   tranqlVersion1.3-SNAPSHOT/tranqlVersion
Could someone please update these and add the missing
   g-dependency.xml to openejb-builder.
  
   Thanks
   Anita
  
   __
   Do You Yahoo!?
   Tired of spam?  Yahoo! Mail has the best spam protection around
   http://mail.yahoo.com
  
  
 
 
 __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around 
 http://mail.yahoo.com 
 


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

Re: handling slow consumers on non-persistent topics and AMQ-688

2006-07-04 Thread James Strachan


BTW AMQ-792 is now fixed - details here...

http://incubator.apache.org/activemq/consumer-dispatch-async.html

so the only real pending issue so far that I'm aware of for dealing
with slow consumers is AMQ-791 (spooling to disk)...

http://issues.apache.org/activemq/browse/AMQ-791

Unless folks have any other use cases or requirements?


On 7/3/06, James Strachan [EMAIL PROTECTED] wrote:

While perusing JIRA I spotted this issue again...
http://issues.apache.org/activemq/browse/AMQ-688
I know its an issue close to folks at Amazon's hearts.

Dealing with slow consumers is a fascinating problem for a messaging
system; its quite a tricky problem :). Here's some background on the
issue...
http://incubator.apache.org/activemq/slow-consumers.html

together with the currently supported features - to allow messages to
be discarded on slow consumers using a pluggable algorithm...
http://incubator.apache.org/activemq/slow-consumer-handling.html

Now for all consumers we fill up prefetch buffers as quickly as possible...
http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html

so there's always a buffer of messages per consumer. For non-durable
topics once these messages are written to a socket they are evicted
from RAM; so we already have some support for slow consumers.

I wanted to start a discussion on both AMQ-688 and to see if folks had
other requirements for handling slow consumers  to try decide what
features  stragegies we should add next in this area.

One of the first requirements folks ask for is that rather than
blocking permanently the non-persistent topic engine until RAM is
cleared, that at a certain threshhold we start spooling to disk. I've
raised a separate JIRA issue for this specific feature request...

http://issues.apache.org/activemq/browse/AMQ-791

Another issue some folks have hit in the past is that for high
performance and to minimise context switches in the broker, we tend to
use the current thread in the broker to dispatch to all the
non-durable topic consumers so a slow/blocked consumer can appear to
'block' the producer.

I've raised this issue to track that feature
http://issues.apache.org/activemq/browse/AMQ-792

I just wondered if folks had any other issues or requirements with the
whole slow consumers and non-durable topics they'd like to discuss? Is
there any requirements we won't have covered if the above two JIRAs
are fixed
--

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




--

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

[jira] Resolved: (AMQ-688) Avoid blocking producers

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

james strachan resolved AMQ-688:

Resolution: Duplicate

AFAIK this issue is now complete with the exception of issue:
http://issues.apache.org/activemq/browse/AMQ-791 which is still currently open.
So for now I'm closing this issue as a duplicate.

If there are other requirements you can think of or if the proposed AMQ-792 and
AMQ-791 issues are not sufficient then please join the discussion here...

http://www.nabble.com/handling-slow-consumers-on-non-persistent-topics-and-AMQ-688-tf1886108.html

or comment on this issue and we can always reopen it - or open another issue
etc.

Avoid blocking producers

Key: AMQ-688
URL: https://issues.apache.org/activemq/browse/AMQ-688
Project: ActiveMQ
Type: New Feature

Components: Broker
Versions: 4.0 RC2
Reporter: Christopher A. Larrieu
Assignee: Christopher A. Larrieu
Fix For: 4.1

Original Estimate: 8 weeks
Remaining: 8 weeks

Our main goal
is to avoid stalled producers by addressing the main culprit: too many
undispatched messages
in the broker's memory. Our motivation is to handle significant --though
temporary-- imbalances
between production and consumption rates.
Reaching this goal entails specific broker modifications:
1. When memory gets tight, start dropping undispatched non-persistent
messages. This is the
first-cut attempt to maintain throughput of persistent messages.
Unlike the approach documented at
http://docs.codehaus.org/display/ACTIVEMQ/Slow+Consumer+Handling,
the message dropping will only occur after the UsageManager reaches capacity.
Non-persistent
messages in dispatch lists will be dropped according to per-destination
policy. Subscriptions
can purge their own messages triggered via callback from the UsageManager.
2. Evict messages if memory remains tight, to be fetched from backing store
prior to dispatch.
ActiveMQ already supports this for persistent messages on Topics with durable
subscriptions.
If a consumer's prefetch buffer is full, the splash-over messages remain as
IndirectMessageReference
objects in the dispatch list, with the actual message body loaded from store
on demand. I
believe we can extend this approach for Queues as well.
3. Improve the efficiency with which evicted messages are loaded back into
memory.
Currently, they are loaded one at a time as needed. It would make sense to
batch-load message
sets periodically. This will require a significant shift in responsibilities
between objects,
since an IndirectMessageReference doesn't know about other instances that can
be loaded in
mass.

The goal will be to keep each subscription dispatch list stocked with a
decent number of messages
in-memory to reasonably trade-off between it's consumer's performance and
resource usage in
the broker. As with everything else, we can implement this as a strategy
class with the first
cut implementing a simple resource allocation strategy: divvy up available
memory amongst
all subscriptions and keep that memory filled with messages for dispatch. I
envision a worker
task assuming responsibility for keeping these lists filled.
4. Even with the above modifications, we still can't entirely avoid blocked
producers, so
we'd like to add client-configurable time-outs to provide a bound for the
time a producer
can remain stalled.
Maybe this should be a new attribute of ActiveMQConnection:
maxProducerFlowControlWait. Calls
to UsageManager.waitForSpace can take this quantity as an argument. Failure
to reach sufficient
space for the new message will throw an exception back up the stack and
across the wire, letting
the producer know that the message was not delivered.
5. Finally, we need to extend disk support for Topics that have only
non-durable subscribers,
otherwise their dispatch lists can fill up with persistent messages. In
order to maintain
compliance with JMS, it would be nice to provide some alternative to dropping
persistent messages.
One possible first cut is to layer this on top of a DurableTopicSubscription
by creating an
anonymous subscriber for every Topic that has only non-durable subscriptions.
When all such
subscriptions terminate, the broker can remove the anonymous subscriber.

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

[RTC] Move Daytrader plans and configs from Geronimo trunk to geronimo/daytrader

I'm happy to move the configs to the daytrader tree as well as the applications/daytrader which 
builds a derby database.


I don't see a reason for them to remain in the 1.2 tree.

DJencks...thoughts?

Re: [RTC] pluggable jacc

2006-07-04 Thread Gianny Damour


Hi,

I had a look to the patch and I think that it will take me about one 
night to review it. As I will be on holidays this Friday, only 2 nights 
left, and away from any computer for 3 weeks, I am happy to vote now if 
need be.


I do have a couple of questions, more for my education than anything else:
* why is the root security element used as a placeholder for group 
substitution in the geronimo-application schema? I would have thought 
that this placeholder would be better in the geronimo-security schema 
where the out-of-the-box/Geronimo substitution group is defined; and
* I think that SecurityBuilder should have a way to modify the 
Environment of a Web-app module and, hence, that an additional method 
should be added to do that during the createModule phase. Otherwise, I 
am not sure how additional parent modules or specific dependencies can 
be added to a Web-app module such that the GBeans added by the builder 
can run.


Also, it is worth to underline that the definition of a substitutable 
service element, which is currently replaceable by a gbean element seems 
to be a very flexible configuration mechanism.


What would be awesome is to be able to register additional 
ElementConverter with SchemaConversionUtils such that developers working 
on their home grown substitution groups do not need to change this class.


Obvisously, I am sold :)

Thanks,
Gianny

David Jencks wrote:

I think my latest patch for pluggable jacc is plausible to commit,  
see http://issues.apache.org/jira/browse/GERONIMO-1563?page=all and  
be sure to apply only the v4 patches.


I realize this is a significant amount of work, so at this time I'm  
not actually asking any PMC members to review this, but I would  
greatly appreciate it if at least 3 could spend a couple minutes  
estimating how long they think it would take them to evaluate the  
patch and when they might be able to complete evaluating it, as this  
will personally affect my plans for the next few weeks.


I think all the committers and other contributors might find this  
information useful in planning their development activities for the  
next few months.


Many thanks,
david jencks

1.2 Release Goals and Release Manager

2006-07-04 Thread Aaron Mulder


Perhaps we could have a discussion about what we're trying to
accomplish in the 1.2 release, and who the release manager is going to
be?  There were a large number of thoughts in the notes from the
JavaOne meeting, and we've discussed the schedule at least a bit, but
perhaps we need to reconsider what we think we can accomplish under
the current circumstances, and find someone who's willing to drive the
release process.

Thanks,
   Aaron

RE:

2006-07-04 Thread Timothy Bish

I took a look at the patch, it looks like it should work without impacting
anything.

-
Timothy A. Bish
[EMAIL PROTECTED]


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram
Chirino
Sent: Tuesday, July 04, 2006 9:26 AM
To: activemq-dev@geronimo.apache.org
Subject: Re:

It should be on it's way to your gmail account.

On 7/4/06, Nathan Mittler [EMAIL PROTECTED] wrote:

 Hey Hiram,
 Looks ok at first glance - could you send me the patch file as an
 attachment?  I seem to be having problems applying the patch through copy
 
 paste into subclipse.

 Thanks,
 Nate

 On 7/3/06, Hiram Chirino [EMAIL PROTECTED] wrote:
 
  Hi Nathan,
 
  Please review the following patch.  It allows the stomp client to accept
 a
  variable amount of while space between frames.  I ran the integration
  tests
  a slightly modified amq broker where it used 3 \n between frames and
 also
  one where no \n were used between frames.  Everything seemed to work,
 but
  since c++ is not my forte, I'm looking for a +1 from a before I commit
 the
  change.
 
  Index: src/main/activemq/connector/stomp/StompCommandReader.cpp
  ===
  ---
 src/main/activemq/connector/stomp/StompCommandReader.cpp(revision
  418889)
  +++ src/main/activemq/connector/stomp/StompCommandReader.cpp(working
  copy)
  @@ -70,20 +70,46 @@
  void StompCommandReader::readStompCommand( StompFrame frame )
  throw ( StompConnectorException )
  {
  -// Read the command;
  -int numChars = readStompHeaderLine();
  +   while( true )
  +   {
  +   // Clean up the mess.
  +   buffer.clear();
 
  -if( numChars = 0 )
  -{
  -throw StompConnectorException(
  -__FILE__, __LINE__,
  -StompCommandReader::readStompCommand: 
  -Error on Read of Command Header );
  -}
  +   // Read the command;
  +   readStompHeaderLine();
 
  -// Set the command in the frame - copy the memory.
  -frame.setCommand( reinterpret_castchar*(buffer[0]) );
  -
  +// Ignore all white space before the command.
  +int offset=-1;
  +for( size_t ix = 0; ix  buffer.size()-1; ++ix )
  +{
  +   // Find the first non space character
  +   char b = buffer[ix];
  +switch ( b )
  +{
  +   case '\n':
  +   case '\t':
  +   case '\r':
  +   break;
  +
  +   default:
  +   offset = ix;
  +   break;
  +}
  +
  +   if( offset != -1 )
  +   {
  +   break;
  +   }
  +}
  +
  +   if( offset = 0 )
  +   {
  +   // Set the command in the frame - copy the memory.
  +   frame.setCommand(
  reinterpret_castchar*(buffer[offset]) );
  +   break;
  +   }
  +
  +   }
   // Clean up the mess.
   buffer.clear();
  }
  @@ -224,8 +250,7 @@
   read( buffer[0], content_length );
 
   // Content Length read, now pop the end terminator off (\0\n).
  -if(inputStream-read() != '\0' ||
  -   inputStream-read() != '\n')
  +if(inputStream-read() != '\0' )
   {
   throw StompConnectorException(
   __FILE__, __LINE__,
  @@ -251,16 +276,6 @@
   continue;
   }
 
  -// We read up to the first NULL, now lets pop off the
  required
  -// newline to complete the packet.
  -if(inputStream-read() != '\n')
  -{
  -throw StompConnectorException(
  -__FILE__, __LINE__,
  -StompCommandReader::readStompBody: 
  -Read Body, and no trailing newline);
  -}
  -
   break;  // Read null and newline we are done.
   }
   }
 
 
 
  On 7/3/06, Nathan Mittler  [EMAIL PROTECTED] wrote:
  
   No problem - sorry for the confusion :)
  
   On 7/3/06, Hiram Chirino [EMAIL PROTECTED] wrote:
   
Oh. That makes sense!  Sorry for the noise!
   
On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote:

 Hey Hiram,
 I was actually thinking of the messages coming from the broker to
  the
 client - the newer version of the broker always sends a \0\n to
  denote
 the end of the frame.  I'm not sure if the CMS client is sly
 enough
  to
 handle both cases - I think it's expecting one or the other
 (either
  \0
 or \0\n).  I was just throwing that out there as a possible reason
   that
 the client may freeze on a read - waiting for the trailing \n that
   never
 comes.


  -Original Message-
  From: [EMAIL PROTECTED] [mailto: [EMAIL

Re: [RTC] pluggable jacc

2006-07-04 Thread Gianny Damour


Gianny Damour wrote:


Hi,

I had a look to the patch and I think that it will take me about one 
night to review it. As I will be on holidays this Friday, only 2 
nights left, and away from any computer for 3 weeks, I am happy to 
vote now if need be.


I do have a couple of questions, more for my education than anything 
else:
* why is the root security element used as a placeholder for group 
substitution in the geronimo-application schema? I would have thought 
that this placeholder would be better in the geronimo-security schema 
where the out-of-the-box/Geronimo substitution group is defined; and
* I think that SecurityBuilder should have a way to modify the 
Environment of a Web-app module and, hence, that an additional method 
should be added to do that during the createModule phase. Otherwise, I 
am not sure how additional parent modules or specific dependencies can 
be added to a Web-app module such that the GBeans added by the builder 
can run.


Also, it is worth to underline that the definition of a substitutable 
service element, which is currently replaceable by a gbean element 
seems to be a very flexible configuration mechanism.


What would be awesome is to be able to register additional 
ElementConverter with SchemaConversionUtils such that developers 
working on their home grown substitution groups do not need to change 
this class.


Forget this point... While trying to see how this could be done I 
discovered that it is actually already done, by XmlBeansUtil...


Thanks,
Gianny



Obvisously, I am sold :)

Thanks,
Gianny

David Jencks wrote:

I think my latest patch for pluggable jacc is plausible to commit,  
see http://issues.apache.org/jira/browse/GERONIMO-1563?page=all and  
be sure to apply only the v4 patches.


I realize this is a significant amount of work, so at this time I'm  
not actually asking any PMC members to review this, but I would  
greatly appreciate it if at least 3 could spend a couple minutes  
estimating how long they think it would take them to evaluate the  
patch and when they might be able to complete evaluating it, as this  
will personally affect my plans for the next few weeks.


I think all the committers and other contributors might find this  
information useful in planning their development activities for the  
next few months.


Many thanks,
david jencks

Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC

I do not believe the +1's need to be from PMC members but other committers. This is a snippet from
Ken's personal web page:

Consequently, acting ex officio my VP/chair of Apache Geronimo role, yesterday (Sunday, 21 May
2006) I changed the project's development model from CTR (Commit-Then-Review) to RTC
(Review-Then-Commit). This means that all code changes that aren't to documentation or specific bug
fixes must be proposed to the development list as patches, and three *[other] committers* need to
verify them and vote in favour of them before they can be applied to the code in the repository.
(This doesn't apply to the sandboxes and experimental areas, only the main lines and branches of
development.)

In Ken's original e-mail the vote required three other committers and not specifically PMC members.
Here is the original e-mail.

http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/[EMAIL
PROTECTED]

It is my understanding that the an RTC request needs 3 other committers to +1 it and does not
require the other +1's to be PMC members.

Hiram Chirino wrote:

Whoa!

I think we have been operation under a different assumption. I know I
committed a patch when 1 got 3 committer +1s... And not even 1 PMC member
looked at it. And that took over a week to garner enough votes. Imagine
how long it would take if we had to get 3 PMC +1! I think we need to clear
this up ASAP!

On 7/1/06, John Sisson [EMAIL PROTECTED] wrote:

AFAIK, it has never changed from having three binding +1 votes from the
PMC, which is why there is an issue with a bottleneck processing RTCs
due to the size of the PMC.

It may not have been clearly communicated that that is how RTC works.

See Ken's comment in
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24899.html

Also see http://www.apache.org/foundation/voting.html where it says
Only votes by PMC members are considered binding on code-modification
issues.

Made change below...

John

Alan D. Cabrera wrote:
I don't understand how things changed from an RTC needing three +1
votes from other committers to three +1 votes from a PMC member. Did
I miss an email that got sent out from the PMC?

Regards,
Alan

John Sisson wrote:
One of the issues I see with the current process we have for changes
under RTC is that it is hard to keep track of what patches are
pending RTC.

Ken suggested that we reintroduce the STATUS file as a way of keeping
track of the status of patches (
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24780.html ).
On the same thread, Dain suggested introducing a review-required
status in JIRA (
http://www.mail-archive.com/dev%40geronimo.apache.org/msg25122.html )
and is the method of tracking work that I prefer.

PROPOSAL

1. Add a review-required and review-complete statuses to JIRA. I
thought having two statuses might allow a cleaner workflow in JIRA,
but would be interested in hearing others opinions.

2. To make it easy for those reviewing and voting on the patches
(there could end up being a number of revisions of the patch before
it is accepted) the file names of the patches attached to the JIRA
should be prefixed with the JIRA issue identifier followed by an
optional text followed by a mandatory patch version number (starting
at 1).
Example patch names:

GERONIMO-1234-FixNPE-v1
GERONIMO-1234-FixNPE-v2 (second attempt at patch)
GERONIMO-3421-v1

2.1 This status should only be set by a committer (can we can get
JIRA to enforce this?) when they have tested the patch attached to
the JIRA and believe it is ready for review. 2.2 The JIRA should
contain all information about the patch. If the changes were
previously discussed on the dev list prior to the JIRA being created,
a summary of the discussions should be moved into the JIRA so that
those reviewing the patch have all the information in one place. It
would also be preferable to add links to the original discussions on
the dev list archives. The way we document changes may be subject
to change (e.g. detailed documentation placed in a linked JIRA) based
upon the outcome of the discussions in the thread [DISCUSS] Tracking
documentation tasks in JIRA ( was Re: [RTC] Clarification please from
the PMC )

2.3 Each PMC member who reviews the patch attached to the JIRA must
do the following:
* Add a JIRA comment containing the file name of the patch they
reviewed. This is so there is no confusion if there ends up being
multiple revisions of the patch when collating votes.
* In the JIRA comment add the results of their review (e.g.
comments or a vote). If a PMC member vetos the patch, they must
include a technical justification in their JIRA comments. I propose
that when there is a veto that we leave the status as
review-required, as others may still want to vote and so that the
patch remains getting daily visibility in the JIRAs Pending Review
daily email (proposed below). The committer can then

Re: FW: Apache Geronimo


Hello Milan,

Thanks for your interest in Apache Geronimo.  You can subscribe to our mailing lists and find out 
other information about Apache Geronimo at http://geronimo.apache.org.


We are currently reworking our build environment in our trunk environment (1.2-SNAPSHOT) and 
starting work on a bug release for Geronimo 1.1.1.


Please take a few minutes and look at the web site.  Are there particular areas you are interested 
in regarding Java and J2EE?


Matt

Noel J. Bergman wrote:

-Original Message-
From: milan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 27, 2006 0:42
To: general@incubator.apache.org
Subject: Apache Geronimo


My name is Milan Shrestha .Am am an IT Engineeer . I have about one year
experience working in java.

I have heard the project proposed by apache named Apache Geronimo . So I
would be thankful if I got chance to work and contribute

for your project .



Regards,

Milan Shrestha

Kathmandu

Nepal

Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)

I think in general you are correct John. Although, from what I've seen the people that are
reviewing the patches are working with the submitter and then when they're happy give they're +1. I
believe the spirit of RTC is being met through the current process. Personally I'd prefer to not
increase the bureaucracy unless there is concern that the current process is being abused.

Jason Dillon wrote:

On Jul 3, 2006, at 10:27 PM, John Sisson wrote:
IMO, a vote for a patch would be need to be restarted if the changes
between the previous patch and the newer version of the patch are not
trivial. Trival meaning:

* documentation changes
* non-controversial non-semantic style changes such as fixing
indentation and adding comments.
Trivial changes do not include code changes or changes that affect the
operation of the build.

In general I agree with you... but I'm not sure that this should apply
to what is going on for m2 work (or other similar types of work).

If we tried to follow this, then almost everyday the latest patch needs
to be reapplied and re-approved by everyone. Its been hard enough to
get people to apply any version of the patch. I do not think, for this
work, that requiring folks to reapply/revalidate for every revision for
the RTC to complete is going to be effective.

I am making significant progress on the m2 build and I really would
rather not wait for (days, weeks) for one patch to get approved before
continuing to work on the next steps. I can also not really split up
these into incremental patches.

I might have a different opinion of this entire situation if there were
more PMC members that were actually looking at these patches... say one
a day. If I pump out an average of 1/2+ a patch a day, then...

After 2 days, 2 PMC would have reviewed (and lets just say were +1), but
I have gotten further and have a new version of the patch now, so now
they need to do it again... and probably won't until tomorrow.

After 3 days, the 3rd PMC got to the v2 patch and +1

After 4 days, another PMC + 1, but another version is out... so scratch
the votes and start over.

The only chance in this example is for 1-2 PMC members to review apply
each day. If 1 on the first, then must be 2 on the second or
visa-versa. Given the current PMC member activity, I don't believe it
will ever be possible (following this example) to every get anything
approved.

* * *

How on earth is this going to work? In this example I was being
optimistic about one +1 per day by a PMC member, but based on the
current status of GERONIMO-2161 it looks more like one +1 every 2 or 3
days.

The alternative is to slow down... make less changes, waiting the time
for PMC members to vote on a single revision. So, one +1 every 2 or 3
days turns into 6 to 9 days of idle time waiting for PMC members to
review/vote. And since I have made 2 (almost 3 from todays work)
significant additions to the patch, that means about 18 to 27 days to
get the *additional* changes I have made in the past few days voted in
to be committed.

The end result is a month+ has gone by, very little progress was
actually committed to the codebase to migrate to Maven 2. At that rate,
maybe by this time next year we will have something ready. Or, lets say
that the numbers are off... by 50% or so... well then it will only take
more months to implement the transition to m2.

So if it takes 6mo to a year to transition to a new build system... how
long is it going to take to actually build features that are users
want?! I'm not including any of the time spent so far with the m2
conversion... but from what I gather its already been in progress for
several months. This is work that should be easily completed in a week
or so, given that there are people actively working on it.

* * *

Maybe I have been smoking too much crack or popped one to many crazy
pills, but this really seems like a whacked-out impossible situation...

--jason

Re: Geronimo specs pre-RTC


Alan,

This was the situation I described in an earlier e-mail about not providing a patch for an RTC.  I 
think generally describing the activities and getting the votes should be adequate.


Alan D. Cabrera wrote:
We had talked about breaking out the Geronimo specs so that they don't 
share the same root pom.   There seemed to be a consensus that this was 
a good idea.  John Sisson mentioned that we might need separate Jiras 
for each.  I think that that might be excessive given how the specs jars 
are unlikely to change.


The nature of this change is that it will not be possible to make a 
patch to reflect the changes that need to be done.  What I can do is to 
concretely express the changes that need to be made in an RTC.  Thoughts?



Regards,
Alan

Re: [RTC] Move Daytrader plans and configs from Geronimo trunk to geronimo/daytrader

2006-07-04 Thread anita kulshreshtha

   Would you still be using packaging plugin to package a car? The
daytrader was a special case in the packaging plugin because it
generated more than one artifact (in maven terminology).

Thanks
Anita


--- Matt Hogstrom [EMAIL PROTECTED] wrote:

 I'm happy to move the configs to the daytrader tree as well as the
 applications/daytrader which 
 builds a derby database.
 
 I don't see a reason for them to remain in the 1.2 tree.
 
 DJencks...thoughts?
 


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

Re: m2migration branch - thoughts?

I think the Maven 2 work is a significant project. It appears to me that RTC has worked really well
in increasing e-mail traffic on the list exponentially but I too would agree that it has not been
totally productive. Here is my assessment:

1. Everyone agrees that this work needs to be done.

2. The overall approach is generally accepted.

3. I believe that Jason and others that have been working on the conversion (not to mention the
voluminous amount of work on the part of Prasad and Anita as well as Jencks) and understand what
needs to be done.

4. Maven 1 still works in trunk and Maven 2 is broken.

I suggest that we agree that the team doing the conversion be allowed to make the changes directly
in trunk. They are not disrupting anything they are currently fixing a move to an already agreed to
build change. Rather than have RTC be the model I move that we allow them to continue to
communicate through e-mail to keep everyone up to date on the status of the migration.

My goal is not to bypass RTC but merely to acknowledge that in the case of this migration it is not
the best tool to accomplish the task.

John and Jacek since you are the active committers on the PMC perhaps you can discuss this and
provide some relief in the process.

Cheers.

Jacek Laskowski wrote:

Hi,

After having read so many emails with frustration and disgust, I think
we could get rid of these shortcomings and do the migration in a
branch - m2migration or alike. The idea of the branch would be to
loosen up the RTC rules that are bound to the trunk and let people
experimenting - do the migration without having to follow RTC,
preparing patches that don't work for everyone, but often very
temporarily until they're again fixed and improved.

Thoughts?

Jacek

[jira] Commented: (SM-481) servicemix-http provider truncates a large xml response

2006-07-04 Thread Philip Dodds (JIRA)

[ 
https://issues.apache.org/activemq/browse/SM-481?page=comments#action_36524 ] 

Philip Dodds commented on SM-481:
-

Added new test to org.apache.servicemix.http.HttpProviderTest.java which has a 
640k message on an InOut with a provider.  The test passed.

Can you confirm you are running against the subversion HEAD?

 servicemix-http provider truncates a large xml response
 ---

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

   Components: servicemix-http
  Environment: windows xp professional.  Java 1.5 
 Reporter: Pete 
 Priority: Critical
  Fix For: incubation
  Attachments: soap_response.txt


 When using servicemix-http as a provider, our provider web service returns a 
 very large xml response, this gets truncated somewhere in servicemix (I did 
 notice when debugging it went down the stax xml route) 
  
 We had the same problem when using SaajBinding, we fixed this locally by 
 extending the SaajBinding and overridng the
 onMessageExchange
 in particular just after the call() we added  response.saveChanges();  e.g.
 SOAPMessage response = connection.call(inMessage, soapEndpoint);
 response.saveChanges();  
  
 This I believe was a known issue using this particular SAAJ implementation, 
 which is why saveChanges() was added to the api.
 see 
 http://www.nabble.com/servicemix-http-provider-truncates-a-large-xml-response-tf1857975.html
  for forum post 
 Our response xml is 673148 bytes. I have attached an example of the failing 
 soap response. Note: you'll need to remove header stuff and save as xml.  The 
 response has a single xml element, where embedded (as a string) is another 
 xml document - nasty I know. 
 XML Config is
 !-- Http based client recieve/send html request/response passes message to a 
 router component--
 sm:activationSpec componentName=httpReceiver 
 service=my:httpBinding endpoint=httpReceiver
 destinationService=my:router
 sm:component
 bean 
 xmlns=http://xbean.org/schemas/spring/1.0; 
 class=org.apache.servicemix.components.http.HttpConnector
 property name=host 
 value=localhost /
 property name=port value=8912 /
 property name=marshaler
 bean class=org.apache.servicemix.components.http.HttpMarshaler 
 /
 /property
 /bean
 /sm:component
 /sm:activationSpec
 Then there is an eip router that routes to
  sm:component
 http:component
   http:endpoints
 http:endpoint service=my:search
endpoint=search
role=provider
soap=true

 soapAction=http://www.blah.com/blah;

 locationURI=http://www.blah.com:80/blah.asmx/
   /http:endpoints
 /http:component
   /sm:component

-- 
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: TranQL m2 build...

David / Jason

The version number for tranql/trunk/tranql/ was incorrect. I've corrected the version numbers for
connector and tranql to 1.3-SNAPSHOT and 1.4-SNAPSHOT accordingly.

David Jencks wrote:

I looked this over and applied it.

It appears that the versions in project.xml (and now the poms) are lower
than those expected by geronimo, e.g. tranql version is 1.3-SNAPSHOT but
geronimo is using 1.4-SNAPSHOT, connector version is 1.2-SNAPSHOT but
geronimo is using 1.3-SNAPSHOT.

Does anyone know what is going on and where the tranql snapshots with
the higher numbers are from?

thanks
david jencks

On Jul 4, 2006, at 1:16 AM, Jason Dillon wrote:

Attached is an updated diff with the same version numbers as
requested. I just used the versions from the project.xml... someone
should double check.

Spits out:

/Users/jason/.m2/repository/org/tranql/tranql-connector/1.2-SNAPSHOT/tranql-connector-1.2-SNAPSHOT.jar

/Users/jason/.m2/repository/org/tranql/tranql-connector-derby-common/1.2-SNAPSHOT/tranql-connector-derby-common-1.2-SNAPSHOT.jar

/Users/jason/.m2/repository/org/tranql/tranql-core/1.3-SNAPSHOT/tranql-1.3-SNAPSHOT.jar

/Users/jason/.m2/repository/org/tranql//tranql-connector-derby-client-local/1.2-SNAPSHOT/tranql-connector-derby-client-local-1.2-SNAPSHOT.rar

/Users/jason/.m2/repository/org/tranql//tranql-connector-derby-client-xa/1.2-SNAPSHOT/tranql-connector-derby-client-xa-1.2-SNAPSHOT.rar

/Users/jason/.m2/repository/org/tranql//tranql-connector-derby-embed-local/1.2-SNAPSHOT/tranql-connector-derby-embed-local-1.2-SNAPSHOT.rar

/Users/jason/.m2/repository/org/tranql//tranql-connector-derby-embed-xa/1.2-SNAPSHOT/tranql-connector-derby-embed-xa-1.2-SNAPSHOT.rar

/Users/jason/.m2/repository/org/tranql//tranql-connector-ra/1.2-SNAPSHOT/tranql-connector-ra-1.2-SNAPSHOT.rar

--jason

tranql-m2-v2.diff

On Jul 3, 2006, at 10:31 PM, Jason Dillon wrote:

Not sure who to send this too... so I'm posting it here.

Attached is the start of a m2 build for TranQL. This builds the core
(tranql), connector and derby bits. Had to add a separate
connector-ra to build the rar, as the vendor bits need the jar for
depends and I'm not sure how to make m2 build that configuration.

I set this up to all build in one cycle, using org.tranql and
2.0-SNAPSHOT... if you guys wanna keep the versions different for the
vendor bits then some small changes need to be made... though IMO its
easier to maintain the tree with one version.

Still needs the other vendors hooked up, but those should be
relatively simple to create based on the derby poms.

Cheers,

--jason

tranql-m2.diff

Re: m2migration branch is available

Sent a note in a related thread asking to have RTC suspended for this activity and let the work
proceed in trunk directly.

Aaron Mulder wrote:

Are you recommending that the project switch to Perforce, or is this
just wishful thinking?

Also, one more note on the merging -- If we change the directory
layout in the branch, it will be very hard to merge any patches to
HEAD into the branch to keep them in sync since all the patch paths
will be wrong. I don't see how this can end well. Unless there's a
freeze in HEAD for the duration of the branch, which would mean we're
just using the branch to work around RTC.

Thanks,
Aaron

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

FYI... Perforce may be commercial, but they provide free licenses for
qualifying open source usage:

http://perforce.com/perforce/opensource-faq.html

:-)

--jason

On Jul 4, 2006, at 3:50 AM, Aaron Mulder wrote:

Jacek,

When discussing whether a branch was appropriate, I expressed a
concern that it would be difficult to merge changes from this branch
to HEAD because SVN seems to have difficulty handling multiple
revisions of add/delete/move/copy operations in a single merge (and I
understand the M2 restructuring will involve a lot of that). I've
often had problems where something is e.g. removed and then recreated
and I try to apply and it refuses claiming that there's something in
the way. The only way to proceed is to manually delete offending
directories and then update. But that won't work for merging from a
branch to HEAD -- it would effectively be a revolution operation where
we would have to vote to delete HEAD and move the branch to HEAD.
Then we lose the bug fixes that have been applied to HEAD and we've
been through that before.

I'm concerned that you ignored this concern and went ahead with the
branch plan. In fact the only response I got was that perhaps a
commercial source control system would be better. Perhaps that means
this should have been an RTC operation so you were forced to address
my concern before taking this approach.

Thanks,
Aaron

On 7/4/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
Hi,

Just created a branch - m2migration - for all our work pertaining to
the M2 migration of Geronimo build. Everybody's welcome to work on it
*without* RTC on. Revolutionary rules are enabled again! ;-)

The branch is available at
https://svn.apache.org/repos/asf/geronimo/branches/m2migration.

Once we're ready to move a part of the work done in this branch,
we'll
create a patch and RTC'ed it to commit to trunk. I believe it will
help those who are reluctant to work on the branch and give a hope
not
all is/will be lost ;-)

Just to be clear: anybody who wants to learn M2 tricks and help us
with the migration is welcome. Those who aren't committers can/should
count on me to commit their work (my kids are away on their vacation,
so let's do it before they come back home ;-))

Jacek

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

Re:

2006-07-04 Thread Hiram Chirino


Thanks guys.. the patch is now applied.

On 7/4/06, Timothy Bish [EMAIL PROTECTED] wrote:


I took a look at the patch, it looks like it should work without impacting
anything.

-
Timothy A. Bish
[EMAIL PROTECTED]


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram
Chirino
Sent: Tuesday, July 04, 2006 9:26 AM
To: activemq-dev@geronimo.apache.org
Subject: Re:

It should be on it's way to your gmail account.

On 7/4/06, Nathan Mittler [EMAIL PROTECTED] wrote:

 Hey Hiram,
 Looks ok at first glance - could you send me the patch file as an
 attachment?  I seem to be having problems applying the patch through
copy
 
 paste into subclipse.

 Thanks,
 Nate

 On 7/3/06, Hiram Chirino [EMAIL PROTECTED] wrote:
 
  Hi Nathan,
 
  Please review the following patch.  It allows the stomp client to
accept
 a
  variable amount of while space between frames.  I ran the integration
  tests
  a slightly modified amq broker where it used 3 \n between frames and
 also
  one where no \n were used between frames.  Everything seemed to work,
 but
  since c++ is not my forte, I'm looking for a +1 from a before I commit
 the
  change.
 
  Index: src/main/activemq/connector/stomp/StompCommandReader.cpp
  ===
  ---
 src/main/activemq/connector/stomp/StompCommandReader.cpp(revision
  418889)
  +++
src/main/activemq/connector/stomp/StompCommandReader.cpp(working
  copy)
  @@ -70,20 +70,46 @@
  void StompCommandReader::readStompCommand( StompFrame frame )
  throw ( StompConnectorException )
  {
  -// Read the command;
  -int numChars = readStompHeaderLine();
  +   while( true )
  +   {
  +   // Clean up the mess.
  +   buffer.clear();
 
  -if( numChars = 0 )
  -{
  -throw StompConnectorException(
  -__FILE__, __LINE__,
  -StompCommandReader::readStompCommand: 
  -Error on Read of Command Header );
  -}
  +   // Read the command;
  +   readStompHeaderLine();
 
  -// Set the command in the frame - copy the memory.
  -frame.setCommand( reinterpret_castchar*(buffer[0]) );
  -
  +// Ignore all white space before the command.
  +int offset=-1;
  +for( size_t ix = 0; ix  buffer.size()-1; ++ix )
  +{
  +   // Find the first non space character
  +   char b = buffer[ix];
  +switch ( b )
  +{
  +   case '\n':
  +   case '\t':
  +   case '\r':
  +   break;
  +
  +   default:
  +   offset = ix;
  +   break;
  +}
  +
  +   if( offset != -1 )
  +   {
  +   break;
  +   }
  +}
  +
  +   if( offset = 0 )
  +   {
  +   // Set the command in the frame - copy the memory.
  +   frame.setCommand(
  reinterpret_castchar*(buffer[offset]) );
  +   break;
  +   }
  +
  +   }
   // Clean up the mess.
   buffer.clear();
  }
  @@ -224,8 +250,7 @@
   read( buffer[0], content_length );
 
   // Content Length read, now pop the end terminator off
(\0\n).
  -if(inputStream-read() != '\0' ||
  -   inputStream-read() != '\n')
  +if(inputStream-read() != '\0' )
   {
   throw StompConnectorException(
   __FILE__, __LINE__,
  @@ -251,16 +276,6 @@
   continue;
   }
 
  -// We read up to the first NULL, now lets pop off the
  required
  -// newline to complete the packet.
  -if(inputStream-read() != '\n')
  -{
  -throw StompConnectorException(
  -__FILE__, __LINE__,
  -StompCommandReader::readStompBody: 
  -Read Body, and no trailing newline);
  -}
  -
   break;  // Read null and newline we are done.
   }
   }
 
 
 
  On 7/3/06, Nathan Mittler  [EMAIL PROTECTED] wrote:
  
   No problem - sorry for the confusion :)
  
   On 7/3/06, Hiram Chirino [EMAIL PROTECTED] wrote:
   
Oh. That makes sense!  Sorry for the noise!
   
On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote:

 Hey Hiram,
 I was actually thinking of the messages coming from the broker
to
  the
 client - the newer version of the broker always sends a \0\n to
  denote
 the end of the frame.  I'm not sure if the CMS client is sly
 enough
  to
 handle both cases - I think it's expecting one or the other
 (either
  \0
 or \0\n).  I was just throwing that out there as a possible
reason
   that
 the client may freeze on a read - waiting for the trailing \n
that
   never
 comes.

Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC

2006-07-04 Thread Hiram Chirino

whew... thanks for clearing that up Matt!On 7/4/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
I do not believe the +1's need to be from PMC members but other committers.This is a snippet fromKen's personal web page:Consequently, acting ex officio my VP/chair of Apache Geronimo role, yesterday (Sunday, 21 May
2006) I changed the project's development model from CTR (Commit-Then-Review) to RTC(Review-Then-Commit). This means that all code changes that aren't to documentation or specific bugfixes must be proposed to the development list as patches, and three *[other] committers* need to
verify them and vote in favour of them before they can be applied to the code in the repository.(This doesn't apply to the sandboxes and experimental areas, only the main lines and branches ofdevelopment.)
In Ken's original e-mail the vote required three other committers and not specifically PMC members.Here is the original e-mail.
http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/[EMAIL PROTECTED]It is my understanding that the an RTC request needs 3 other committers to +1 it and does notrequire the other +1's to be PMC members.
Hiram Chirino wrote: Whoa! I think we have been operation under a different assumption.I know I committed a patch when 1 got 3 committer +1s...And not even 1 PMC member looked at it.And that took over a week to garner enough votes.Imagine
 how long it would take if we had to get 3 PMC +1!I think we need to clear this up ASAP! On 7/1/06, John Sisson [EMAIL PROTECTED] wrote:
 AFAIK, it has never changed from having three binding +1 votes from the PMC, which is why there is an issue with a bottleneck processing RTCs due to the size of the PMC.
 It may not have been clearly communicated that that is how RTC works. See Ken's comment in http://www.mail-archive.com/dev%40geronimo.apache.org/msg24899.html
 Also see http://www.apache.org/foundation/voting.html where it says Only votes by PMC members are considered binding on code-modification
 issues. Made change below... John Alan D. Cabrera wrote:  I don't understand how things changed from an RTC needing three +1
  votes from other committers to three +1 votes from a PMC member.Did  I miss an email that got sent out from the PMC?Regards,  Alan
   John Sisson wrote:  One of the issues I see with the current process we have for changes  under RTC is that it is hard to keep track of what patches are
  pending RTC.   Ken suggested that we reintroduce the STATUS file as a way of keeping  track of the status of patches (  
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24780.html ).  On the same thread, Dain suggested introducing a review-required
  status in JIRA (  http://www.mail-archive.com/dev%40geronimo.apache.org/msg25122.html )  and is the method of tracking work that I prefer.
   PROPOSAL   1. Add a review-required and review-complete statuses to JIRA. I  thought having two statuses might allow a cleaner workflow in JIRA,
  but would be interested in hearing others opinions.   2. To make it easy for those reviewing and voting on the patches  (there could end up being a number of revisions of the patch before
  it is accepted) the file names of the patches attached to the JIRA  should be prefixed with the JIRA issue identifier followed by an  optional text followed by a mandatory patch version number (starting
  at 1).  Example patch names:  GERONIMO-1234-FixNPE-v1 GERONIMO-1234-FixNPE-v2 (second attempt at patch) GERONIMO-3421-v1
   2.1 This status should only be set by a committer (can we can get  JIRA to enforce this?) when they have tested the patch attached to  the JIRA and believe it is ready for review. 
2.2 The JIRA should  contain all information about the patch.If the changes were  previously discussed on the dev list prior to the JIRA being created,  a summary of the discussions should be moved into the JIRA so that
  those reviewing the patch have all the information in one place.It  would also be preferable to add links to the original discussions on  the dev list archives.The waywe document changes may be subject
  to change (e.g. detailed documentation placed in a linked JIRA) based  upon the outcome of the discussions in the thread [DISCUSS] Tracking  documentation tasks in JIRA ( was Re: [RTC] Clarification please from
  the PMC )   2.3 Each PMC member who reviews the patch attached to the JIRA must  do the following:  * Add a JIRA comment containing the file name of the patch they
  reviewed.This is so there is no confusion if there ends up being  multiple revisions of the patch when collating votes. * In the JIRA comment add the results of their review (
e.g.  comments or a vote).If a PMC member vetos the patch, they must  include a technical justification in their JIRA comments.I propose  that when there is a veto that we leave the status as
  review-required, as others may still want to vote and so that the  patch remains getting daily visibility in the JIRAs Pending Review  daily email (proposed below).The

[jira] Created: (AMQ-794) make the support of advisory messages optional (so that they can be disabled to reduce RAM and boost performance a little)

make the support of advisory messages optional (so that they can be disabled to 
reduce RAM and boost performance a little)
--

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

Reporter: james strachan
 Assigned to: james strachan 
 Fix For: 4.1




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

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

 [ http://issues.apache.org/jira/browse/GERONIMO-2135?page=all ]
 
Hiram Chirino resolved GERONIMO-2135:
-

Resolution: Fixed

thanks for the review guys. patch is applied now.

 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: Openejb build for Geronimo


This is one of the many fixes that are included with GERONIMO-2161

--jason


On Jul 4, 2006, at 5:52 AM, anita kulshreshtha wrote:


Now we must use the org.openejb groupId in Geronimo. As of rev
418907 Geronimo is still using openejb as groupId. I will be happy to
provide a patch.

Thanks
Anita

--- anita kulshreshtha [EMAIL PROTECTED] wrote:


   The openejb rev 2721 does not build as is. There are many other
versions which need to be changed. I have attached a refreshed patch
to

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

Thanks
Anita

--- Jason Dillon [EMAIL PROTECTED] wrote:


Attached is a patch that changes the TranQL versions to

1.3-SNAPSHOT


and 1.4-SNAPSHOT as well as adds the correct SCM tags (so we can
build from Continuum) and introduces a root pom (most of the config



moved from modules/pom.xml).

--jason





On Jul 3, 2006, at 8:02 PM, anita kulshreshtha wrote:


Hi All,
The rev 2720 of openejb at
https://svn.codehaus.org/openejb/trunk/openejb2 is using wrong
versions
of tranql and activation Spec. Here are the values from
etc/project.properties -

tranql_version=1.4-SNAPSHOT
tranql_connector_version=1.3-SNAPSHOT
tranql_vendors_version=1.1
...
...
geronimo_spec_activation_version=1.1

   Here are the values from modules/pom.xml -



geronimoSpecActivationVersion1.0/geronimoSpecActivationVersion


tranqlConnectorVersion1.2-SNAPSHOT/tranqlConnectorVersion
tranqlVendorsVersion1.1/tranqlVendorsVersion
tranqlVersion1.3-SNAPSHOT/tranqlVersion
 Could someone please update these and add the missing
g-dependency.xml to openejb-builder.

Thanks
Anita

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






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




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

Re: m2migration branch is available


On Jul 4, 2006, at 4:21 AM, Aaron Mulder wrote:

Are you recommending that the project switch to Perforce, or is this
just wishful thinking?


Well... both I guess.  But given our reality its more of the later.



Also, one more note on the merging -- If we change the directory
layout in the branch, it will be very hard to merge any patches to
HEAD into the branch to keep them in sync since all the patch paths
will be wrong.  I don't see how this can end well.  Unless there's a
freeze in HEAD for the duration of the branch, which would mean we're
just using the branch to work around RTC.


The reason why I mention it over and over... is that Perforce can  
handle automating a bunch of this work.


For example, to solve the issue you mention about patches.  If you  
know the change number that the patch was done against, then you  
could create a new temporary branch based on that change number, then  
apply the patch, and then merge the private branch back into the  
trunk.  Perforce is smart enough to realize what needs to merge and  
what has been merged already since it tracks integrations.  It also  
knows what been moved and deleted and when you merge the changes will  
follow the code wherever it was moved to.


It really is an excellent tool... for highly branched and dynamic  
environments Perforce really shines.


--jason



Thanks,
   Aaron

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

FYI... Perforce may be commercial, but they provide free licenses for
qualifying open source usage:

 http://perforce.com/perforce/opensource-faq.html

:-)

--jason


On Jul 4, 2006, at 3:50 AM, Aaron Mulder wrote:

 Jacek,

 When discussing whether a branch was appropriate, I expressed a
 concern that it would be difficult to merge changes from this  
branch

 to HEAD because SVN seems to have difficulty handling multiple
 revisions of add/delete/move/copy operations in a single merge  
(and I

 understand the M2 restructuring will involve a lot of that).  I've
 often had problems where something is e.g. removed and then  
recreated
 and I try to apply and it refuses claiming that there's  
something in

 the way.  The only way to proceed is to manually delete offending
 directories and then update.  But that won't work for merging  
from a
 branch to HEAD -- it would effectively be a revolution operation  
where

 we would have to vote to delete HEAD and move the branch to HEAD.
 Then we lose the bug fixes that have been applied to HEAD and we've
 been through that before.

 I'm concerned that you ignored this concern and went ahead with the
 branch plan.  In fact the only response I got was that perhaps a
 commercial source control system would be better.  Perhaps that  
means
 this should have been an RTC operation so you were forced to  
address

 my concern before taking this approach.

 Thanks,
Aaron

 On 7/4/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
 Hi,

 Just created a branch - m2migration - for all our work  
pertaining to
 the M2 migration of Geronimo build. Everybody's welcome to work  
on it

 *without* RTC on. Revolutionary rules are enabled again! ;-)

 The branch is available at
 https://svn.apache.org/repos/asf/geronimo/branches/m2migration.

 Once we're ready to move a part of the work done in this branch,
 we'll
 create a patch and RTC'ed it to commit to trunk. I believe it will
 help those who are reluctant to work on the branch and give a hope
 not
 all is/will be lost ;-)

 Just to be clear: anybody who wants to learn M2 tricks and help us
 with the migration is welcome. Those who aren't committers can/ 
should
 count on me to commit their work (my kids are away on their  
vacation,

 so let's do it before they come back home ;-))

 Jacek

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

Minor m2 patch for OpenEJB

Needed to change the artifactId of the modules/ pom to just  
'modules' (from 'openejb-modules).  With this change, Continuum/ 
Maven2 should create the correct SCM URLs... which means that CI can  
start building the new tree.


Still pending some configuration on where to deploy to, but will get  
to that later after the CI basic configuration is working.


Thanks,

--jason



openejb-scm2.diff
Description: Binary data

Re: Minor m2 patch for OpenEJB

Ooops... forgot about updating parent elements.  New patch attached  
will actually build ;-)


--jason



openejb-scm2-v2.diff
Description: Binary data



On Jul 4, 2006, at 1:55 PM, Jason Dillon wrote:

Needed to change the artifactId of the modules/ pom to just  
'modules' (from 'openejb-modules).  With this change, Continuum/ 
Maven2 should create the correct SCM URLs... which means that CI  
can start building the new tree.


Still pending some configuration on where to deploy to, but will  
get to that later after the CI basic configuration is working.


Thanks,

--jason

openejb-scm2.diff

CAR packaging failed


Can anyone shed some light onto why this might have happened?

Something changed in my workspace last night... but not sure what, as  
this only recently started to fail consistently w/Corba J2EE Client.


rant
This is one reason why its a massive pain to work for so many days  
with out committing... can't just diff my workspace against working  
environment of yesterday and figure this out myself... well I might  
figure it out myself, but it would be much easier actually using the  
SCM to facilitate this.

/rant

snip
[INFO]  
 


[INFO] Building Geronimo Configs :: Corba J2EE Client
[INFO]task-segment: [install]
[INFO]  
 


[INFO] [clean:clean {execution: default}]
[INFO] Deleting directory /Users/jason/ws/apache/geronimo/trunk/ 
configs/client-corba/target
[INFO] Deleting directory /Users/jason/ws/apache/geronimo/trunk/ 
configs/client-corba/target/classes
[INFO] Deleting directory /Users/jason/ws/apache/geronimo/trunk/ 
configs/client-corba/target/test-classes

[INFO] [car:dependencies]
[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:provided' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:provided' is  
invalid. It will be ignored for artifact resolution. Reason: Not a  
v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:provided' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:provided' is  
invalid. It will be ignored for artifact resolution. Reason: Not a  
v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:provided' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:provided' is  
invalid. It will be ignored for artifact resolution. Reason: Not a  
v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:compile' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile' is  
invalid. It will be ignored for artifact resolution. Reason: Not a  
v4.0.0 POM.

[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [car:package]

Packaging configuration /Users/jason/ws/apache/geronimo/trunk/ 
configs/client-corba/target/plan/plan.xml


org.apache.geronimo.kernel.config.LifecycleException: start of  
org.apache.geronimo.configs/j2ee-deployer/1.2-SNAPSHOT/car failed
at  
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfig 
uration(SimpleConfigurationManager.java:529)
at  
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfig 
uration(SimpleConfigurationManager.java:493)
at  
org.apache.geronimo.kernel.config.SimpleConfigurationManager$ 
$FastClassByCGLIB$$ce77a924.invoke(generated)

at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke 
(FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke 
(GBeanOperation.java:122)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke 
(GBeanInstance.java:817)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke 
(RawInvoker.java:57)
at  
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke 
(RawOperationInvoker.java:35)
at  
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept 
(ProxyMethodInterceptor.java:96)
at org.apache.geronimo.kernel.config.ConfigurationManager$ 
$EnhancerByCGLIB$$780a4ae2.startConfiguration(generated)
at  
org.apache.geronimo.plugin.packaging.PackageBuilder.execute 
(PackageBuilder.java:324)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)
at  
org.apache.geronimo.plugin.packaging.PackageBuilderShellMojo.executePack 
ageBuilderShell(PackageBuilderShellMojo.java:232)
at  
org.apache.geronimo.plugin.packaging.PackageBuilderShellMojo.execute 
(PackageBuilderShellMojo.java:161)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo 
(DefaultPluginManager.java:412)
at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals 
(DefaultLifecycleExecutor.java:534)
at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec 
ycle(DefaultLifecycleExecutor.java:475)
at

Re: Minor m2 patch for OpenEJB


I applied this, rev 2722
david jencks

On Jul 4, 2006, at 1:59 PM, Jason Dillon wrote:

Ooops... forgot about updating parent elements.  New patch attached  
will actually build ;-)


--jason

openejb-scm2-v2.diff


On Jul 4, 2006, at 1:55 PM, Jason Dillon wrote:

Needed to change the artifactId of the modules/ pom to just  
'modules' (from 'openejb-modules).  With this change, Continuum/ 
Maven2 should create the correct SCM URLs... which means that CI  
can start building the new tree.


Still pending some configuration on where to deploy to, but will  
get to that later after the CI basic configuration is working.


Thanks,

--jason

openejb-scm2.diff

Re: CAR packaging failed



On Jul 4, 2006, at 2:04 PM, Jason Dillon wrote:


Can anyone shed some light onto why this might have happened?

Something changed in my workspace last night... but not sure what,  
as this only recently started to fail consistently w/Corba J2EE  
Client.



to top post ...

None of the builder configs can depend on any runtime config  
because any runtime config will cause j2ee-system to start which  
would duplicate the serverInfo and a lot of other singleton gbeans.   
So, what has happened is that j2ee-deployer config must have a new  
dependency on a config that has j2ee-system in its ancestor set.  I  
think there's some way to set the log4j level for the packaging  
plugin so it will print out the classloaders and their parents which  
can be a big help in locating the exact cause of these problems, but  
that might not be available in the m2 plugin and I don't recall  
exactly how to do it.


thanks
david jencks



rant
This is one reason why its a massive pain to work for so many days  
with out committing... can't just diff my workspace against working  
environment of yesterday and figure this out myself... well I might  
figure it out myself, but it would be much easier actually using  
the SCM to facilitate this.

/rant

snip
[INFO]  
-- 
--

[INFO] Building Geronimo Configs :: Corba J2EE Client
[INFO]task-segment: [install]
[INFO]  
-- 
--

[INFO] [clean:clean {execution: default}]
[INFO] Deleting directory /Users/jason/ws/apache/geronimo/trunk/ 
configs/client-corba/target
[INFO] Deleting directory /Users/jason/ws/apache/geronimo/trunk/ 
configs/client-corba/target/classes
[INFO] Deleting directory /Users/jason/ws/apache/geronimo/trunk/ 
configs/client-corba/target/test-classes

[INFO] [car:dependencies]
[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:provided' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:provided'  
is invalid. It will be ignored for artifact resolution. Reason: Not  
a v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:provided' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:provided'  
is invalid. It will be ignored for artifact resolution. Reason: Not  
a v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:provided' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:provided'  
is invalid. It will be ignored for artifact resolution. Reason: Not  
a v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:compile' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile' is  
invalid. It will be ignored for artifact resolution. Reason: Not a  
v4.0.0 POM.

[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [car:package]

Packaging configuration /Users/jason/ws/apache/geronimo/trunk/ 
configs/client-corba/target/plan/plan.xml


org.apache.geronimo.kernel.config.LifecycleException: start of  
org.apache.geronimo.configs/j2ee-deployer/1.2-SNAPSHOT/car failed
at  
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf 
iguration(SimpleConfigurationManager.java:529)
at  
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf 
iguration(SimpleConfigurationManager.java:493)
at  
org.apache.geronimo.kernel.config.SimpleConfigurationManager$ 
$FastClassByCGLIB$$ce77a924.invoke(generated)

at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at  
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke 
(FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke 
(GBeanOperation.java:122)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke 
(GBeanInstance.java:817)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke 
(RawInvoker.java:57)
at  
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke 
(RawOperationInvoker.java:35)
at  
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept 
(ProxyMethodInterceptor.java:96)
at org.apache.geronimo.kernel.config.ConfigurationManager$ 
$EnhancerByCGLIB$$780a4ae2.startConfiguration(generated)
at  
org.apache.geronimo.plugin.packaging.PackageBuilder.execute 
(PackageBuilder.java:324)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:25)

Re: CAR packaging failed

Build-related logging in m2 is whack right now... will look into  
fixing that soon.


--jason


On Jul 4, 2006, at 3:22 PM, David Jencks wrote:



On Jul 4, 2006, at 2:04 PM, Jason Dillon wrote:


Can anyone shed some light onto why this might have happened?

Something changed in my workspace last night... but not sure what,  
as this only recently started to fail consistently w/Corba J2EE  
Client.



to top post ...

None of the builder configs can depend on any runtime config  
because any runtime config will cause j2ee-system to start which  
would duplicate the serverInfo and a lot of other singleton  
gbeans.  So, what has happened is that j2ee-deployer config must  
have a new dependency on a config that has j2ee-system in its  
ancestor set.  I think there's some way to set the log4j level for  
the packaging plugin so it will print out the classloaders and  
their parents which can be a big help in locating the exact cause  
of these problems, but that might not be available in the m2 plugin  
and I don't recall exactly how to do it.


thanks
david jencks



rant
This is one reason why its a massive pain to work for so many days  
with out committing... can't just diff my workspace against  
working environment of yesterday and figure this out myself...  
well I might figure it out myself, but it would be much easier  
actually using the SCM to facilitate this.

/rant

snip
[INFO]  
- 
---

[INFO] Building Geronimo Configs :: Corba J2EE Client
[INFO]task-segment: [install]
[INFO]  
- 
---

[INFO] [clean:clean {execution: default}]
[INFO] Deleting directory /Users/jason/ws/apache/geronimo/trunk/ 
configs/client-corba/target
[INFO] Deleting directory /Users/jason/ws/apache/geronimo/trunk/ 
configs/client-corba/target/classes
[INFO] Deleting directory /Users/jason/ws/apache/geronimo/trunk/ 
configs/client-corba/target/test-classes

[INFO] [car:dependencies]
[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:provided' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:provided'  
is invalid. It will be ignored for artifact resolution. Reason:  
Not a v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:provided' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:provided'  
is invalid. It will be ignored for artifact resolution. Reason:  
Not a v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:provided' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:provided'  
is invalid. It will be ignored for artifact resolution. Reason:  
Not a v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:compile' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile'  
is invalid. It will be ignored for artifact resolution. Reason:  
Not a v4.0.0 POM.

[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [car:package]

Packaging configuration /Users/jason/ws/apache/geronimo/trunk/ 
configs/client-corba/target/plan/plan.xml


org.apache.geronimo.kernel.config.LifecycleException: start of  
org.apache.geronimo.configs/j2ee-deployer/1.2-SNAPSHOT/car failed
at  
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon 
figuration(SimpleConfigurationManager.java:529)
at  
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon 
figuration(SimpleConfigurationManager.java:493)
at  
org.apache.geronimo.kernel.config.SimpleConfigurationManager$ 
$FastClassByCGLIB$$ce77a924.invoke(generated)

at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at  
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke 
(FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke 
(GBeanOperation.java:122)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke 
(GBeanInstance.java:817)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke 
(RawInvoker.java:57)
at  
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke 
(RawOperationInvoker.java:35)
at  
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept 
(ProxyMethodInterceptor.java:96)
at org.apache.geronimo.kernel.config.ConfigurationManager$ 
$EnhancerByCGLIB$$780a4ae2.startConfiguration(generated)
at  
org.apache.geronimo.plugin.packaging.PackageBuilder.execute 
(PackageBuilder.java:324)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native  
Method)
at

Re: [RTC] pluggable jacc



On Jul 4, 2006, at 7:03 AM, Gianny Damour wrote:


Gianny Damour wrote:


Hi,

I had a look to the patch and I think that it will take me about  
one night to review it. As I will be on holidays this Friday, only  
2 nights left, and away from any computer for 3 weeks, I am happy  
to vote now if need be.


I do have a couple of questions, more for my education than  
anything else:
* why is the root security element used as a placeholder for group  
substitution in the geronimo-application schema? I would have  
thought that this placeholder would be better in the geronimo- 
security schema where the out-of-the-box/Geronimo substitution  
group is defined;


That would work too.  I was thinking that security only applies to  
j2ee artifacts and that someone might want to run without the  
geronimo security-builder module in their system.  This might be  
unrealistic since the client deployer and openejb deployer both have  
hardcoded use of the geronimo security builder (to build default  
principals), but it ought to work for web apps.  For the analogous  
case of services/gbeans, I thought that there was no likelyhood of  
anyone trying to run without the gbean builder :-)  My arm could be  
twisted on that however :-).




and
* I think that SecurityBuilder should have a way to modify the  
Environment of a Web-app module and, hence, that an additional  
method should be added to do that during the createModule phase.  
Otherwise, I am not sure how additional parent modules or specific  
dependencies can be added to a Web-app module such that the GBeans  
added by the builder can run.


At the moment I think you'd have to include the necessary jars as  
explicit dependencies.  I agree that this functionality is needed.   
It's also needed for the web services builder.  I was hoping to get  
this much committed and then consider how many of the builder  
concepts we have can be unified into namespace driven builders: I'm  
hoping at least the web services builder can be.




Also, it is worth to underline that the definition of a  
substitutable service element, which is currently replaceable by a  
gbean element seems to be a very flexible configuration mechanism.


I'm pretty happy with this.  I'm planning to convert the login module  
builder to this style, I think we can have something that looks much  
more like the sun login module config, just written in xml, with  
little bits to point out if we want our extensions such as principal  
wrapping.




What would be awesome is to be able to register additional  
ElementConverter with SchemaConversionUtils such that developers  
working on their home grown substitution groups do not need to  
change this class.


Forget this point... While trying to see how this could be done I  
discovered that it is actually already done, by XmlBeansUtil...


Thanks for your review and your, as always, perceptive and  
interesting comments!


david jencks



Thanks,
Gianny



Obvisously, I am sold :)

Thanks,
Gianny

David Jencks wrote:

I think my latest patch for pluggable jacc is plausible to  
commit,  see http://issues.apache.org/jira/browse/GERONIMO-1563? 
page=all and  be sure to apply only the v4 patches.


I realize this is a significant amount of work, so at this time  
I'm  not actually asking any PMC members to review this, but I  
would  greatly appreciate it if at least 3 could spend a couple  
minutes  estimating how long they think it would take them to  
evaluate the  patch and when they might be able to complete  
evaluating it, as this  will personally affect my plans for the  
next few weeks.


I think all the committers and other contributors might find  
this  information useful in planning their development activities  
for the  next few months.


Many thanks,
david jencks

[jira] Commented: (GERONIMO-2153) Global JNDI

2006-07-04 Thread David Jencks (JIRA)

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

David Jencks commented on GERONIMO-2153:


I apologize for taking so long to get to reviewing this.

This has some good elements but also quite a few problems.  Here are a few 
suggestions.

1. The bindingGBeans do not need to know the name of the gbean they are getting 
something to bind into jndi from, they need a reference to it.  Similarly they 
do not need to bind a naming Reference, they can bind the object itself.  For 
instance, the connector binding gbean can do something like this:

private final ManagedConnectionFactoryWrapper managedConnectionFactoryWrapper; 
// this is the reference to the gbean that gives us the connection factory to 
bind

...

//now it's time to bind the connection factory

Object connectionFactory = managedConnectionFactoryWrapper.$getResource();
globalContext.bind(jndiName, connectionFactory);

This is also going to affect how the builders set up the binding gbeans: they 
know the name of the appropriate gbean such as managedConnectionFactoryWrapper, 
since they just created it, so they need to use that name to set the reference 
pattern in the binding gbean.  The binding gbean will then get (a proxy to) the 
real gbean that it can use as outlined above.

2. I don't see an implementation of a writable thread safe jndi Context, as 
dain pointed out you would need.

3. The zip file consists almost entirely of irrelevant files and the actual 
source files do not all appear to be in the geronimo project structure.  This 
makes it extremely hard to figure out what to look at.

4. Some of the code modifications (such as to ServiceConfigBuilder) appear to 
be test cases rather than production code.  It will be a lot easier to evaluate 
your work if you keep test cases and production code clearly separated as is 
done in typical maven projects.

5. I think you will need to redo the openejb work after dain's reintegration of 
his container rewrite.

Thanks!  Let us know if you have any questions about this.

 Global JNDI
 ---

  Key: GERONIMO-2153
  URL: http://issues.apache.org/jira/browse/GERONIMO-2153
  Project: Geronimo
 Type: New Feature
 Security: public(Regular issues) 
   Components: naming
 Versions: 1.2
 Reporter: Krishnakumar B
  Attachments: jndi-project.zip

 Implementing Global JNDI for server
 Requirements
 * Non -persistent
 * Read/Write
 * Bindings to JNDI/COS-NAMING/JAXR
 * Can bind RA,EJB,GBEAN,Any object

-- 
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: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC


Matt Hogstrom wrote:
I do not believe the +1's need to be from PMC members but other 
committers.  This is a snippet from Ken's personal web page:


Consequently, acting ex officio my VP/chair of Apache Geronimo role, 
yesterday (Sunday, 21 May 2006) I changed the project's development 
model from CTR (Commit-Then-Review) to RTC (Review-Then-Commit). This 
means that all code changes that aren't to documentation or specific 
bug fixes must be proposed to the development list as patches, and 
three *[other] committers* need to verify them and vote in favour of 
them before they can be applied to the code in the repository. (This 
doesn't apply to the sandboxes and experimental areas, only the main 
lines and branches of development.)


In Ken's original e-mail the vote required three other committers and 
not specifically PMC members.  Here is the original e-mail.


http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/[EMAIL PROTECTED] 



It is my understanding that the an RTC request needs 3 other 
committers to +1 it and does not require the other +1's to be PMC 
members.


I understand that there has been confusion due to the original message 
from Ken mentioning committers in his original message, but Ken cleared 
this up in a message on the 18th of June (since his blog entry on the 
22nd May).


Please see  
http://www.mail-archive.com/dev@geronimo.apache.org/msg24899.html


Nobody should assume anything has changed from requiring 3 binding votes 
for RTC until they hear otherwise from Ken.


I encourage those not on the PMC to also vote on RTC requests as your 
input is valuable.


John

Hiram Chirino wrote:

Whoa!

I think we have been operation under a different assumption.  I know I
committed a patch when 1 got 3 committer +1s...  And not even 1 PMC 
member
looked at it.  And that took over a week to garner enough votes.  
Imagine
how long it would take if we had to get 3 PMC +1!  I think we need to 
clear

this up ASAP!

On 7/1/06, John Sisson [EMAIL PROTECTED] wrote:


AFAIK, it has never changed from having three binding +1 votes from the
PMC, which is why there is an issue with a bottleneck processing RTCs
due to the size of the PMC.

It may not have been clearly communicated that that is how RTC works.

See Ken's comment in
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24899.html

Also see http://www.apache.org/foundation/voting.html where it says
Only votes by PMC members are considered binding on code-modification
issues.

Made change below...

John

Alan D. Cabrera wrote:
 I don't understand how things changed from an RTC needing three +1
 votes from other committers to three +1 votes from a PMC member.  Did
 I miss an email that got sent out from the PMC?


 Regards,
 Alan

 John Sisson wrote:
 One of the issues I see with the current process we have for changes
 under RTC is that it is hard to keep track of what patches are
 pending RTC.

 Ken suggested that we reintroduce the STATUS file as a way of 
keeping

 track of the status of patches (
 
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24780.html ).

 On the same thread, Dain suggested introducing a review-required
 status in JIRA (
 
http://www.mail-archive.com/dev%40geronimo.apache.org/msg25122.html )

 and is the method of tracking work that I prefer.

 PROPOSAL

 1. Add a review-required and review-complete statuses to JIRA. I
 thought having two statuses might allow a cleaner workflow in JIRA,
 but would be interested in hearing others opinions.

 2. To make it easy for those reviewing and voting on the patches
 (there could end up being a number of revisions of the patch before
 it is accepted) the file names of the patches attached to the JIRA
 should be prefixed with the JIRA issue identifier followed by an
 optional text followed by a mandatory patch version number (starting
 at 1).
 Example patch names:

GERONIMO-1234-FixNPE-v1
GERONIMO-1234-FixNPE-v2 (second attempt at patch)
GERONIMO-3421-v1

 2.1 This status should only be set by a committer (can we can get
 JIRA to enforce this?) when they have tested the patch attached to
 the JIRA and believe it is ready for review. 2.2 The JIRA should
 contain all information about the patch.  If the changes were
 previously discussed on the dev list prior to the JIRA being 
created,

 a summary of the discussions should be moved into the JIRA so that
 those reviewing the patch have all the information in one place.  It
 would also be preferable to add links to the original discussions on
 the dev list archives.  The way  we document changes may be subject
 to change (e.g. detailed documentation placed in a linked JIRA) 
based
 upon the outcome of the discussions in the thread [DISCUSS] 
Tracking
 documentation tasks in JIRA ( was Re: [RTC] Clarification please 
from

 the PMC )

 2.3 Each PMC member who reviews the patch attached to the JIRA must
 do the following:
 * Add a JIRA comment containing the file name of the patch they

Re: [VOTE] Sponsor OpenEJB to become sub-project of Geronimo


Alan,

What type of concerns do they have regarding its close association with 
Geronimo?


Regards,
John

Alan D. Cabrera wrote:
I also am leaning towards the idea that it's good for OpenEJB to be 
separate from Geronimo.  Whenever I talk w/ users of OpenEJB, they are 
always concerned about its close association w/ Geronimo.  However, it 
is my understanding that Dain is working hard on decoupling OpenEJB's 
strong reliance on Geronimo code.



Regards,
Alan

Mohammed Nour wrote:

Hi All...
 
+1, but I have a question. Isn't it better to have OEJB as a separate 
project, as we have the intention to make it independent from 
Geronimo, as to have it work inside or outside Geronimo?


 
On 12/3/05, *David Blevins* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


The OpenEJB committers have discussed it and voted to be become a
Geronimo sub-project.  The incubator proposl is here:

http://wiki.apache.org/incubator/OpenEjbProposal

Please vote if you'd like Geronimo to be the sponsor of OpenEJB
during incubation

[ ] +1 = I support the move to sponsor OpenEJB during incubation
as a
sub-project of Geronimo
[ ] +0 = I don't mind either way
[ ] -1 = I don't support this move because: ___

+1 from me

--
David

Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC



On Jul 4, 2006, at 4:54 PM, John Sisson wrote:


Matt Hogstrom wrote:
I do not believe the +1's need to be from PMC members but other  
committers.  This is a snippet from Ken's personal web page:


Consequently, acting ex officio my VP/chair of Apache Geronimo  
role, yesterday (Sunday, 21 May 2006) I changed the project's  
development model from CTR (Commit-Then-Review) to RTC (Review- 
Then-Commit). This means that all code changes that aren't to  
documentation or specific bug fixes must be proposed to the  
development list as patches, and three *[other] committers* need  
to verify them and vote in favour of them before they can be  
applied to the code in the repository. (This doesn't apply to the  
sandboxes and experimental areas, only the main lines and branches  
of development.)


In Ken's original e-mail the vote required three other committers  
and not specifically PMC members.  Here is the original e-mail.


http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/% 
[EMAIL PROTECTED]


It is my understanding that the an RTC request needs 3 other  
committers to +1 it and does not require the other +1's to be PMC  
members.


I understand that there has been confusion due to the original  
message from Ken mentioning committers in his original message, but  
Ken cleared this up in a message on the 18th of June (since his  
blog entry on the 22nd May).


Please see  http://www.mail-archive.com/dev@geronimo.apache.org/ 
msg24899.html


Nobody should assume anything has changed from requiring 3 binding  
votes for RTC until they hear otherwise from Ken.


I do not think that Ken is providing sufficient communication to the  
dev list.  As matt pointed out, the original edict to the dev list  
and ken's blog entry clearly and unequivocally stated that committer  
votes were binding for commit decisions.  Sometime later ken appears  
to have commmented on this policy with an interpretation that is  
radically different from the original very clear statement with an  
comment deep in a thread.  Personally I find that rather ambiguous.   
I think that if Ken has any interest in having clear rules that he  
has an obligation to clearly state changes to them either in the  
thread in which the rules are originally promulgated or in a separate  
thread but in any case clearly indicating what has changed.


Not to insult any pmc members, but it appears that this is an issue  
on which the PMC has absolutely no input.  As such, it is difficult  
for me to trust comments on this issue from anyone other than Ken.


thanks
david jencks



I encourage those not on the PMC to also vote on RTC requests as  
your input is valuable.


John

Hiram Chirino wrote:

Whoa!

I think we have been operation under a different assumption.  I  
know I
committed a patch when 1 got 3 committer +1s...  And not even 1  
PMC member
looked at it.  And that took over a week to garner enough votes.   
Imagine
how long it would take if we had to get 3 PMC +1!  I think we  
need to clear

this up ASAP!

On 7/1/06, John Sisson [EMAIL PROTECTED] wrote:


AFAIK, it has never changed from having three binding +1 votes  
from the
PMC, which is why there is an issue with a bottleneck processing  
RTCs

due to the size of the PMC.

It may not have been clearly communicated that that is how RTC  
works.


See Ken's comment in
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24899.html

Also see http://www.apache.org/foundation/voting.html where it says
Only votes by PMC members are considered binding on code- 
modification

issues.

Made change below...

John

Alan D. Cabrera wrote:
 I don't understand how things changed from an RTC needing  
three +1
 votes from other committers to three +1 votes from a PMC  
member.  Did

 I miss an email that got sent out from the PMC?


 Regards,
 Alan

 John Sisson wrote:
 One of the issues I see with the current process we have for  
changes

 under RTC is that it is hard to keep track of what patches are
 pending RTC.

 Ken suggested that we reintroduce the STATUS file as a way of  
keeping

 track of the status of patches (
 http://www.mail-archive.com/dev%40geronimo.apache.org/ 
msg24780.html ).
 On the same thread, Dain suggested introducing a review- 
required

 status in JIRA (
 http://www.mail-archive.com/dev%40geronimo.apache.org/ 
msg25122.html )

 and is the method of tracking work that I prefer.

 PROPOSAL

 1. Add a review-required and review-complete statuses to  
JIRA. I
 thought having two statuses might allow a cleaner workflow in  
JIRA,

 but would be interested in hearing others opinions.

 2. To make it easy for those reviewing and voting on the patches
 (there could end up being a number of revisions of the patch  
before
 it is accepted) the file names of the patches attached to the  
JIRA

 should be prefixed with the JIRA issue identifier followed by an
 optional text followed by a mandatory patch version number  
(starting

 at 1).
 Example patch names:

Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC


David,

I will ensure this gets followed up by Ken.  CCing the PMC.

Regards,
John

David Jencks wrote:


On Jul 4, 2006, at 4:54 PM, John Sisson wrote:


Matt Hogstrom wrote:
I do not believe the +1's need to be from PMC members but other 
committers.  This is a snippet from Ken's personal web page:


Consequently, acting ex officio my VP/chair of Apache Geronimo 
role, yesterday (Sunday, 21 May 2006) I changed the project's 
development model from CTR (Commit-Then-Review) to RTC 
(Review-Then-Commit). This means that all code changes that aren't 
to documentation or specific bug fixes must be proposed to the 
development list as patches, and three *[other] committers* need to 
verify them and vote in favour of them before they can be applied to 
the code in the repository. (This doesn't apply to the sandboxes and 
experimental areas, only the main lines and branches of development.)


In Ken's original e-mail the vote required three other committers 
and not specifically PMC members.  Here is the original e-mail.


http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/[EMAIL PROTECTED] 



It is my understanding that the an RTC request needs 3 other 
committers to +1 it and does not require the other +1's to be PMC 
members.


I understand that there has been confusion due to the original 
message from Ken mentioning committers in his original message, but 
Ken cleared this up in a message on the 18th of June (since his blog 
entry on the 22nd May).


Please see  
http://www.mail-archive.com/dev@geronimo.apache.org/msg24899.html


Nobody should assume anything has changed from requiring 3 binding 
votes for RTC until they hear otherwise from Ken.


I do not think that Ken is providing sufficient communication to the 
dev list.  As matt pointed out, the original edict to the dev list and 
ken's blog entry clearly and unequivocally stated that committer votes 
were binding for commit decisions.  Sometime later ken appears to have 
commmented on this policy with an interpretation that is radically 
different from the original very clear statement with an comment deep 
in a thread.  Personally I find that rather ambiguous.  I think that 
if Ken has any interest in having clear rules that he has an 
obligation to clearly state changes to them either in the thread in 
which the rules are originally promulgated or in a separate thread but 
in any case clearly indicating what has changed.


Not to insult any pmc members, but it appears that this is an issue on 
which the PMC has absolutely no input.  As such, it is difficult for 
me to trust comments on this issue from anyone other than Ken.


thanks
david jencks



I encourage those not on the PMC to also vote on RTC requests as your 
input is valuable.


John

Hiram Chirino wrote:

Whoa!

I think we have been operation under a different assumption.  I know I
committed a patch when 1 got 3 committer +1s...  And not even 1 PMC 
member
looked at it.  And that took over a week to garner enough votes.  
Imagine
how long it would take if we had to get 3 PMC +1!  I think we need 
to clear

this up ASAP!

On 7/1/06, John Sisson [EMAIL PROTECTED] wrote:


AFAIK, it has never changed from having three binding +1 votes 
from the

PMC, which is why there is an issue with a bottleneck processing RTCs
due to the size of the PMC.

It may not have been clearly communicated that that is how RTC works.

See Ken's comment in
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24899.html

Also see http://www.apache.org/foundation/voting.html where it says
Only votes by PMC members are considered binding on 
code-modification

issues.

Made change below...

John

Alan D. Cabrera wrote:
 I don't understand how things changed from an RTC needing three +1
 votes from other committers to three +1 votes from a PMC 
member.  Did

 I miss an email that got sent out from the PMC?


 Regards,
 Alan

 John Sisson wrote:
 One of the issues I see with the current process we have for 
changes

 under RTC is that it is hard to keep track of what patches are
 pending RTC.

 Ken suggested that we reintroduce the STATUS file as a way of 
keeping

 track of the status of patches (
 
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24780.html 
).

 On the same thread, Dain suggested introducing a review-required
 status in JIRA (
 
http://www.mail-archive.com/dev%40geronimo.apache.org/msg25122.html )

 and is the method of tracking work that I prefer.

 PROPOSAL

 1. Add a review-required and review-complete statuses to 
JIRA. I
 thought having two statuses might allow a cleaner workflow in 
JIRA,

 but would be interested in hearing others opinions.

 2. To make it easy for those reviewing and voting on the patches
 (there could end up being a number of revisions of the patch 
before

 it is accepted) the file names of the patches attached to the JIRA
 should be prefixed with the JIRA issue identifier followed by an
 optional text followed by a mandatory patch version

Re: m2migration branch - thoughts?


Matt Hogstrom wrote:
I think the Maven 2 work is a significant project.  It appears to me 
that RTC has worked really well in increasing e-mail traffic on the 
list exponentially but I too would agree that it has not been totally 
productive.  Here is my assessment:


1. Everyone agrees that this work needs to be done.

2. The overall approach is generally accepted.

3. I believe that Jason and others that have been working on the 
conversion (not to mention the voluminous amount of work on the part 
of Prasad and Anita as well as Jencks) and understand what needs to be 
done.


4. Maven 1 still works in trunk and Maven 2 is broken.

I suggest that we agree that the team doing the conversion be allowed 
to make the changes directly in trunk.  They are not disrupting 
anything they are currently fixing a move to an already agreed to 
build change.  Rather than have RTC be the model I move that we allow 
them to continue to communicate through e-mail to keep everyone up to 
date on the status of the migration.


My goal is not to bypass RTC but merely to acknowledge that in the 
case of this migration it is not the best tool to accomplish the task.


John and Jacek since you are the active committers on the PMC perhaps 
you can discuss this and provide some relief in the process.



Will follow up with the PMC.

Regards,
John

Cheers.

Jacek Laskowski wrote:

Hi,

After having read so many emails with frustration and disgust, I think
we could get rid of these shortcomings and do the migration in a
branch - m2migration or alike. The idea of the branch would be to
loosen up the RTC rules that are bound to the trunk and let people
experimenting - do the migration without having to follow RTC,
preparing patches that don't work for everyone, but often very
temporarily until they're again fixed and improved.

Thoughts?

Jacek

Re: m2migration branch is available