date:20070321


On 3/21/07, Nirav [EMAIL PROTECTED] wrote:



Truly Helpful,

Thanks.

I think I can get one more solution from you.

You can have an overview of my project by clicking below link...

http://forum.java.sun.com/thread.jspa?forumID=512threadID=5132641

Now my problem is after time span like 4-5 hours my NMR stops accepting
uncompressed messages.



You should check that:
 * the seda queues are empty
 * delivery channels are empty
 * check if threads are waiting for something
All these checks can be done from a JMX console.
One usual problem is when a hand written component does not comply
with the JBI Meps and forget to send an exchange back with a DONE
status for example.
If you see that threads are all waiting for a resource, please post
the thread dump (Ctrl+Break / kill -3).

So, I can say like after uncompression nothing will happen!


Even I am not getting any error message!
--
View this message in context:
http://www.nabble.com/Attachment-in-form-of-byte---tf3146867s12049.html#a9590762
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.





--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Own implemented XAResource unable to register with Geronimo Transaction Manager

2007-03-21 Thread sanjoy_m


Hi All,

I have written one simple class (XAListResource.java) which implements
javax.transaction.xa.XAResource. Now I want to register it with the Geronimo
transaction manager so that this XA resource can take part in global
transaction. But I am unable to do that.

Anybody who know the answer please reply with your help. 

Thanks  Regards,

Sanjoy 
-- 
View this message in context: 
http://www.nabble.com/Own-implemented-XAResource-unable-to-register-with-Geronimo-Transaction-Manager-tf3439935s134.html#a9591617
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.

Re: correlation id with tracing

2007-03-21 Thread Thomas TERMIN

Guillaume,

I extended component support so that we have the four methods with the
MessageExchange parameter to get and set the correlation id.

public InOnly createInOnlyExchange(MessageExchange beforeExchange)
public InOptionalOut createInOptionalOutExchange(MessageExchange
beforeExchange)
public InOut createInOutExchange(MessageExchange beforeExchange)
public RobustInOnly createRobustInOnlyExchange(MessageExchange
beforeExchange)

this are the corresponding methods to the four methods without
parameters to create a new excahnge.

Do you want to create corresponding methods to the other methods like

public InOut createInOutExchange(QName service, QName interfaceName,
QName operation)

Cheers,
Thomas

Thomas TERMIN wrote:
 Is there a JIRA for that ?
 No not yet. I will create one. Do you want to implement this or should I
 do it?
 
 
 On 3/7/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
 Guillaume Nodet wrote:
 However, it might be possible to enhance the ComponentSupport
 or another class to support the correlation id automatically.
 This would make all lightweight components to support that.
 We could extend ComponentSupport with methods to create the new
 exchanges and this methods could put the correlation id automatically in
 the new excahnge. So if you would use ComponentSupport to create the
 exchange the correlationId will be propagated. The advantage is that you
 don't have to use this functions and it would be backward compatible.

 What do you think?


 On 1/23/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
 I don't think so, as the container (or the ecxhange factory) has no
 way
 to know which jbi exchange is currently handled by the component.
 And you can not use a thread local, has the component may delegate
 the exhcange processing to another thread.
 That's the reason why it has been implemented in servicemix-common.
 Do you see something else ?

 On 1/23/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
 A question again. If I have a lw component which opens a new message
 exchange the correlation id has to be propageted in the component
 itself. Would it be better or is it possible to do this automaticaly
 in
 the exchange factory?

 Cheers,
 Thomas

 Guillaume Nodet wrote:
 The way it works now is that
 all components using servicemix-common that create an exchange
 as part of the processing of a received exchange, will
 automatically
 put the correlationId in the new exchange properties.
 The correlationId is equal to correlationId of the input exchange,
 or the
 input exchange id if no correlation id is set.

 So if an endpoint A sends a JBI exchange to enpoint B, and
 endpoint
 B
 sends a jbi exchange to endpoint C while processing the exchange,
 both exchange will have the same correlationId.

 If we write a MessageExchange event listener, we should be able to
 retrieve all these informations.  Note that the flow can be
 retrieved
 with the same logic used in the DotViewFlowListener instead.

 Just copy the DotViewFlowListener and change the drawing
 logic.  What tool are will you use to draw the flow ?  The output
 of the DotViewFlowListener is not very impressive, so any
 improvement would be welcome.

 On 1/10/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
 How is this intended to work? I want to implement a tracing tool
 or
 whatever to see the flows between the components.

 Cheers

 Guillaume Nodet wrote:
 No one leverage the correlation ids, but i it could / should
 be done.  What kind of informations are you looking for ?

 On 1/10/07, Thomas TERMIN [EMAIL PROTECTED]
 wrote:
 Hello,

 How can I enable tracing in servicemix with the new
 correlation id
 mechanism. How do I have to use this? (I don't want to use the
 DotViewFlowListener)

 Cheers,
 Thomas






 --
 Cheers,
 Guillaume Nodet
 
 Architect, LogicBlaze (http://www.logicblaze.com/)
 Blog: http://gnodet.blogspot.com/



 -- 
 Thomas Termin
 ___
 blue elephant systems GmbH
 Wollgrasweg 49
 D-70599 Stuttgart

 Tel:  (+49) 0711 - 45 10 17 676
 Fax:  (+49) 0711 - 45 10 17 573
 WWW:  http://www.blue-elephant-systems.com
 Email  :  [EMAIL PROTECTED]

 blue elephant systems GmbH
 Firmensitz  : Wollgrasweg 49, D-70599 Stuttgart
 Registergericht : Amtsgericht Stuttgart, HRB 24106
 Geschäftsführer : Holger Dietrich, Thomas Gentsch, Joachim Hoernle



 
 


-- 
Thomas Termin
___
blue elephant systems GmbH
Wollgrasweg 49
D-70599 Stuttgart

Tel:  (+49) 0711 - 45 10 17 676
Fax:  (+49) 0711 - 45 10 17 573
WWW:  http://www.blue-elephant-systems.com
Email  :  [EMAIL PROTECTED]

blue elephant systems GmbH
Firmensitz  : Wollgrasweg 49, D-70599 Stuttgart
Registergericht : Amtsgericht Stuttgart, HRB 24106
Geschäftsführer : Holger Dietrich, Thomas Gentsch, Joachim Hoernle

Re: correlation id with tracing


On 3/21/07, Thomas TERMIN [EMAIL PROTECTED] wrote:


Guillaume,

I extended component support so that we have the four methods with the
MessageExchange parameter to get and set the correlation id.

public InOnly createInOnlyExchange(MessageExchange beforeExchange)
public InOptionalOut createInOptionalOutExchange(MessageExchange
beforeExchange)
public InOut createInOutExchange(MessageExchange beforeExchange)
public RobustInOnly createRobustInOnlyExchange(MessageExchange
beforeExchange)

this are the corresponding methods to the four methods without
parameters to create a new excahnge.



Cool, thx :-)

Do you want to create corresponding methods to the other methods like


public InOut createInOutExchange(QName service, QName interfaceName,
QName operation)



What about adding a helper method to progate / create the correlation id.

 public void propagateCorrelationId(MessageExchange source, MessageExchange
dest);

This method could be used by the four methods you've written, and could be
called
if the component use other methods.

Hopefully your account will be created soon.  I have sent a reminder, but I
can't do much :-(

Cheers,

Thomas

Thomas TERMIN wrote:
 Is there a JIRA for that ?
 No not yet. I will create one. Do you want to implement this or should I
 do it?


 On 3/7/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
 Guillaume Nodet wrote:
 However, it might be possible to enhance the ComponentSupport
 or another class to support the correlation id automatically.
 This would make all lightweight components to support that.
 We could extend ComponentSupport with methods to create the new
 exchanges and this methods could put the correlation id automatically
in
 the new excahnge. So if you would use ComponentSupport to create the
 exchange the correlationId will be propagated. The advantage is that
you
 don't have to use this functions and it would be backward compatible.

 What do you think?


 On 1/23/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
 I don't think so, as the container (or the ecxhange factory) has no
 way
 to know which jbi exchange is currently handled by the component.
 And you can not use a thread local, has the component may delegate
 the exhcange processing to another thread.
 That's the reason why it has been implemented in servicemix-common.
 Do you see something else ?

 On 1/23/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
 A question again. If I have a lw component which opens a new
message
 exchange the correlation id has to be propageted in the component
 itself. Would it be better or is it possible to do this
automaticaly
 in
 the exchange factory?

 Cheers,
 Thomas

 Guillaume Nodet wrote:
 The way it works now is that
 all components using servicemix-common that create an exchange
 as part of the processing of a received exchange, will
 automatically
 put the correlationId in the new exchange properties.
 The correlationId is equal to correlationId of the input exchange,
 or the
 input exchange id if no correlation id is set.

 So if an endpoint A sends a JBI exchange to enpoint B, and
 endpoint
 B
 sends a jbi exchange to endpoint C while processing the exchange,
 both exchange will have the same correlationId.

 If we write a MessageExchange event listener, we should be able to
 retrieve all these informations.  Note that the flow can be
 retrieved
 with the same logic used in the DotViewFlowListener instead.

 Just copy the DotViewFlowListener and change the drawing
 logic.  What tool are will you use to draw the flow ?  The output
 of the DotViewFlowListener is not very impressive, so any
 improvement would be welcome.

 On 1/10/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
 How is this intended to work? I want to implement a tracing tool
 or
 whatever to see the flows between the components.

 Cheers

 Guillaume Nodet wrote:
 No one leverage the correlation ids, but i it could / should
 be done.  What kind of informations are you looking for ?

 On 1/10/07, Thomas TERMIN [EMAIL PROTECTED]
 wrote:
 Hello,

 How can I enable tracing in servicemix with the new
 correlation id
 mechanism. How do I have to use this? (I don't want to use the
 DotViewFlowListener)

 Cheers,
 Thomas






 --
 Cheers,
 Guillaume Nodet
 
 Architect, LogicBlaze (http://www.logicblaze.com/)
 Blog: http://gnodet.blogspot.com/



 --
 Thomas Termin
 ___
 blue elephant systems GmbH
 Wollgrasweg 49
 D-70599 Stuttgart

 Tel:  (+49) 0711 - 45 10 17 676
 Fax:  (+49) 0711 - 45 10 17 573
 WWW:  http://www.blue-elephant-systems.com
 Email  :  [EMAIL PROTECTED]

 blue elephant systems GmbH
 Firmensitz  : Wollgrasweg 49, D-70599 Stuttgart
 Registergericht : Amtsgericht Stuttgart, HRB 24106
 Geschäftsführer : Holger Dietrich, Thomas Gentsch, Joachim Hoernle







--
Thomas Termin
___
blue elephant systems GmbH
Wollgrasweg 49
D-70599 Stuttgart

Tel:  (+49) 0711 - 45 10 17 676
Fax:  (+49) 0711 - 45 10 17 573

Re: [jira] Closed: (GERONIMO-2638) Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of JarFile

2007-03-21 Thread Tim McConnell


Hi Sachin, is this a duplicate of GERONIMO-1526 ??

Thanks,
Tim McConnell


Sachin Patel (JIRA) wrote:

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sachin Patel closed GERONIMO-2638.
--

Resolution: Later

After reflecting on this solution, it does not fit in nicely with the current 
architecture and will need to investigate alternate solutions.


Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of 
JarFile
---

Key: GERONIMO-2638
URL: https://issues.apache.org/jira/browse/GERONIMO-2638
Project: Geronimo
 Issue Type: RTC
 Security Level: public(Regular issues) 
 Components: deployment

   Affects Versions: 2.0-M1
   Reporter: Sachin Patel
Assigned To: Sachin Patel
Fix For: 2.0-M3

Attachments: GERONIMO-1526-v1.2.patch, GERONIMO-1526-v1.2.patch2

Re: [jira] Closed: (GERONIMO-2638) Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of JarFile

2007-03-21 Thread Sachin Patel


yes it is.

-sachin


On Mar 21, 2007, at 9:07 AM, Tim McConnell wrote:


Hi Sachin, is this a duplicate of GERONIMO-1526 ??

Thanks,
Tim McConnell


Sachin Patel (JIRA) wrote:
 [ https://issues.apache.org/jira/browse/GERONIMO-2638? 
page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sachin Patel closed GERONIMO-2638.
--
Resolution: Later
After reflecting on this solution, it does not fit in nicely with  
the current architecture and will need to investigate alternate  
solutions.
Improve ModuleBuilder and ConfigurationBuilder interfaces to  
replace use of JarFile
 
---


Key: GERONIMO-2638
URL: https://issues.apache.org/jira/browse/ 
GERONIMO-2638

Project: Geronimo
 Issue Type: RTC
 Security Level: public(Regular issues)  Components:  
deployment

   Affects Versions: 2.0-M1
   Reporter: Sachin Patel
Assigned To: Sachin Patel
Fix For: 2.0-M3

Attachments: GERONIMO-1526-v1.2.patch, GERONIMO-1526- 
v1.2.patch2

Re: Build Failure Rev: 520756

2007-03-21 Thread Davanum Srinivas


oops...looks like you did that already. let me check.

-- dims

On 3/21/07, Davanum Srinivas [EMAIL PROTECTED] wrote:

Rakesh,

Do you mind nuking your .m2/repository/org/apache/axis2 and running a
fresh online build?

thanks,
dims

On 3/21/07, Rakesh Midha [EMAIL PROTECTED] wrote:
 Hello

 I am getting build failure in geronimo-axis2 module with latest trunk. I
 cleaned my repo as well as did a clean checkout and build, but still stuck
 with same problem. Any idea what is wrong?

 Here is trace. The messages doesn't make any sense.


 [INFO]
 
 [ERROR] BUILD FAILURE
 [INFO]
 
 [INFO] Compilation failure

 Failure executing javac, but could not parse the error:
 C:\Documents and
 Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
 
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Endpoi
 ntDescription.java):64: class EndpointDescription is public, should be
 declared
 in a file named EndpointDescription.java
 (source unavailable)
 C:\Documents and
 Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
 
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Servic
 eDescription.java):48: class ServiceDescription is public, should be
 declared in
  a file named ServiceDescription.java
 (source unavailable)
 C:\Documents and
 Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
 
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Endpoi
 ntInterfaceDescription.java):53: class EndpointInterfaceDescription is
 public, s
 hould be declared in a file named
 EndpointInterfaceDescription.java
 (source unavailable)
 C:\Documents and
 Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
 a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar
 (org/apache/axis2/jaxws/description/Servic
 eRuntimeDescription.java):29: class ServiceRuntimeDescription is public,
 should
 be declared in a file named ServiceRuntimeDescription.java
 (source unavailable)
 C:\Documents and
 Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
 
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Operat
 ionDescription.java):58: class OperationDescription is public, should be
 declare
 d in a file named OperationDescription.java
 (source unavailable)
 C:\Documents and
 Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
 
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/FaultD
 escription.java):49: class FaultDescription is public, should be declared in
 a f
 ile named FaultDescription.java
 (source unavailable)
 C:\Documents and
 Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
 
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Parame
 terDescription.java):51: class ParameterDescription is public, should be
 declare
 d in a file named ParameterDescription.java
 (source unavailable)
 C:\Documents and
 Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
 
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Operat
 ionRuntimeDescription.java):30: class OperationRuntimeDescription is public,
 sho
 uld be declared in a file named
 OperationRuntimeDescription.java
 (source unavailable)
 8 errors


 [INFO]
 
 [INFO] For more information, run Maven with the -e switch
 [INFO]
 
 [INFO] Total time: 4 minutes 8 seconds
 [INFO] Finished at: Wed Mar 21 18:15:02 IST 2007
 [INFO] Final Memory: 76M/254M
 [INFO]
 

 Thanks
 Rakesh



--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers




--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers

Re: correlation id with tracing

2007-03-21 Thread Thomas TERMIN

 I extended component support so that we have the four methods with the
 MessageExchange parameter to get and set the correlation id.

 public InOnly createInOnlyExchange(MessageExchange beforeExchange)
 public InOptionalOut createInOptionalOutExchange(MessageExchange
 beforeExchange)
 public InOut createInOutExchange(MessageExchange beforeExchange)
 public RobustInOnly createRobustInOnlyExchange(MessageExchange
 beforeExchange)

 this are the corresponding methods to the four methods without
 parameters to create a new excahnge.
 
 
 Cool, thx :-)
 
 Do you want to create corresponding methods to the other methods like

 public InOut createInOutExchange(QName service, QName interfaceName,
 QName operation)
 
 
 What about adding a helper method to progate / create the correlation id.
create correlation id means (if correlation id == null) get the exchange
id from the source exchange, right?
 
  public void propagateCorrelationId(MessageExchange source, MessageExchange
 dest);
 
 This method could be used by the four methods you've written, and could be
 called
 if the component use other methods.
 
 Hopefully your account will be created soon.  I have sent a reminder, but I
 can't do much :-(
 
 Cheers,
 Thomas

 Thomas TERMIN wrote:
  Is there a JIRA for that ?
  No not yet. I will create one. Do you want to implement this or
 should I
  do it?
 
 
  On 3/7/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
  Guillaume Nodet wrote:
  However, it might be possible to enhance the ComponentSupport
  or another class to support the correlation id automatically.
  This would make all lightweight components to support that.
  We could extend ComponentSupport with methods to create the new
  exchanges and this methods could put the correlation id automatically
 in
  the new excahnge. So if you would use ComponentSupport to create the
  exchange the correlationId will be propagated. The advantage is that
 you
  don't have to use this functions and it would be backward compatible.
 
  What do you think?
 
 
  On 1/23/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
  I don't think so, as the container (or the ecxhange factory) has no
  way
  to know which jbi exchange is currently handled by the component.
  And you can not use a thread local, has the component may delegate
  the exhcange processing to another thread.
  That's the reason why it has been implemented in servicemix-common.
  Do you see something else ?
 
  On 1/23/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
  A question again. If I have a lw component which opens a new
 message
  exchange the correlation id has to be propageted in the component
  itself. Would it be better or is it possible to do this
 automaticaly
  in
  the exchange factory?
 
  Cheers,
  Thomas
 
  Guillaume Nodet wrote:
  The way it works now is that
  all components using servicemix-common that create an exchange
  as part of the processing of a received exchange, will
  automatically
  put the correlationId in the new exchange properties.
  The correlationId is equal to correlationId of the input
 exchange,
  or the
  input exchange id if no correlation id is set.
 
  So if an endpoint A sends a JBI exchange to enpoint B, and
  endpoint
  B
  sends a jbi exchange to endpoint C while processing the exchange,
  both exchange will have the same correlationId.
 
  If we write a MessageExchange event listener, we should be
 able to
  retrieve all these informations.  Note that the flow can be
  retrieved
  with the same logic used in the DotViewFlowListener instead.
 
  Just copy the DotViewFlowListener and change the drawing
  logic.  What tool are will you use to draw the flow ?  The output
  of the DotViewFlowListener is not very impressive, so any
  improvement would be welcome.
 
  On 1/10/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
  How is this intended to work? I want to implement a tracing tool
  or
  whatever to see the flows between the components.
 
  Cheers
 
  Guillaume Nodet wrote:
  No one leverage the correlation ids, but i it could / should
  be done.  What kind of informations are you looking for ?
 
  On 1/10/07, Thomas TERMIN [EMAIL PROTECTED]
  wrote:
  Hello,
 
  How can I enable tracing in servicemix with the new
  correlation id
  mechanism. How do I have to use this? (I don't want to use the
  DotViewFlowListener)
 
  Cheers,
  Thomas
 
 
 
 
 
 
  --
  Cheers,
  Guillaume Nodet
  
  Architect, LogicBlaze (http://www.logicblaze.com/)
  Blog: http://gnodet.blogspot.com/
 
 
 
  --
  Thomas Termin
  ___
  blue elephant systems GmbH
  Wollgrasweg 49
  D-70599 Stuttgart
 
  Tel:  (+49) 0711 - 45 10 17 676
  Fax:  (+49) 0711 - 45 10 17 573
  WWW:  http://www.blue-elephant-systems.com
  Email  :  [EMAIL PROTECTED]
 
  blue elephant systems GmbH
  Firmensitz  : Wollgrasweg 49, D-70599 Stuttgart
  Registergericht : Amtsgericht Stuttgart, HRB 24106
  Geschäftsführer : Holger Dietrich, Thomas Gentsch, Joachim

Re: [Discussion] Geronimo web site update

2007-03-21 Thread Hernan Cunico


Ok, GMOxMoinMoin is gone for good!!!

Cheers!
Hernan

Hernan Cunico wrote:
For the record, I'm getting an exception while trying to delete that 
space. Created a JIRA (INFRA-1170) with this issue.


Cheers!
Hernan

Hernan Cunico wrote:

Not really, we can nuke it. I'll make a XML bkp and delete it.

We have a tar ball backup in the sandbox for sentimental reasons.

Cheers!
Hernan


Jason Dillon wrote:

Do we still need this space?

 http://cwiki.apache.org/confluence/display/GMOxMoinMoin/Home

--jason


On Feb 19, 2007, at 4:35 PM, Hernan Cunico wrote:

you mean the shaded frame box? I think the difficult part will be 
the resizing in the css. Creating the graphics should be pretty simple.


Cheers!
Hernan

Jason Dillon wrote:
Can you find out where the ActiveMQ folks got that sexy box image 
from?  I'd *love* to have a nice box like that (g-styled of course) 
for our page too :-)

--jason
On Feb 19, 2007, at 4:05 PM, Hernan Cunico wrote:

Hey Jason,
I'm trying to catch up with the News/blog-posts on GMOxSITE as 
part of the web site update. I created a few tests (added News) 
but these posts take forever to show up. Any suggestions?


Anyway, do you have any idea how could we port the *News* we have 
on the live site?


Cheers!
Hernan

Jason Dillon wrote:

On Feb 15, 2007, at 9:17 AM, Hernan Cunico wrote:

Folks,
after lots of separated discussions on different threads it is 
clear the spirit for moving the authoring of our web site over 
Confluence. Let's bring to this thread all the ideas and 
discussion.


Proposal:
The idea is to use Confluence as the authoring tool for 
Geronimo's web site. To achieve this we will use the autoexport 
plugin already installed and in use on the cwiki.apache.org.
With the autoexport plugin we can customize the generated HTML 
look and feel by using templates. The current POC can be viewed 
at http://cwiki.apache.org/GMOxSITE (thx Jason D.)


Some suggestions (mine ;-)  )

- Avoid JIRA references/direct imports, if JIRA is down or 
running slow it will affect the main web site.
Eh... maybe... though JIRA should not be down or slow.  These are 
also static pages, which only pull images off of the JIRA webapp, 
but we could remove the icon from the rendering.  I personally 
think its useful to show some JIRA activity on some page on the 
website.  Shows that we are still moving even if the website 
content isn't.
- Remove edit/print/export links from the generated site. Only 
Geronimo committers will have edit access

Fine w/me.
- Update the template LF. Why not? It is a good opportunity to 
do it !!!
Ya, probably some changes to be made... I like the Cayenne site a 
lot... clean, simple... nice popup menus.
- Need to define how to integrate the other subprojects web 
sites (consider confluence spaces too).
Aye, we need a basic theme that works for the main site, 
documentation sites and sub-project sites.

- pls chime in!!!

I volunteer to start updating the content (matching with what we 
already have on the live site), unless somebody else wants to go 
it!

I will also look at some alternative templates.

I really would like to see this happen... so I can lend a hand.
--jason

Re: correlation id with tracing


Yeah, for example. I don't think the way the correlation Id is created
is very important.

See
http://fisheye6.cenqua.com/browse/servicemix/trunk/common/servicemix-common/src/main/java/org/apache/servicemix/common/AsyncBaseLifeCycle.java?r=515741#l526
for the code in use in servicemix-common.


On 3/21/07, Thomas TERMIN [EMAIL PROTECTED] wrote:


 I extended component support so that we have the four methods with the
 MessageExchange parameter to get and set the correlation id.

 public InOnly createInOnlyExchange(MessageExchange beforeExchange)
 public InOptionalOut createInOptionalOutExchange(MessageExchange
 beforeExchange)
 public InOut createInOutExchange(MessageExchange beforeExchange)
 public RobustInOnly createRobustInOnlyExchange(MessageExchange
 beforeExchange)

 this are the corresponding methods to the four methods without
 parameters to create a new excahnge.


 Cool, thx :-)

 Do you want to create corresponding methods to the other methods like

 public InOut createInOutExchange(QName service, QName interfaceName,
 QName operation)


 What about adding a helper method to progate / create the correlation
id.
create correlation id means (if correlation id == null) get the exchange
id from the source exchange, right?

  public void propagateCorrelationId(MessageExchange source,
MessageExchange
 dest);

 This method could be used by the four methods you've written, and could
be
 called
 if the component use other methods.

 Hopefully your account will be created soon.  I have sent a reminder,
but I
 can't do much :-(

 Cheers,
 Thomas

 Thomas TERMIN wrote:
  Is there a JIRA for that ?
  No not yet. I will create one. Do you want to implement this or
 should I
  do it?
 
 
  On 3/7/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
  Guillaume Nodet wrote:
  However, it might be possible to enhance the ComponentSupport
  or another class to support the correlation id automatically.
  This would make all lightweight components to support that.
  We could extend ComponentSupport with methods to create the new
  exchanges and this methods could put the correlation id
automatically
 in
  the new excahnge. So if you would use ComponentSupport to create
the
  exchange the correlationId will be propagated. The advantage is
that
 you
  don't have to use this functions and it would be backward
compatible.
 
  What do you think?
 
 
  On 1/23/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
  I don't think so, as the container (or the ecxhange factory) has
no
  way
  to know which jbi exchange is currently handled by the component.
  And you can not use a thread local, has the component may
delegate
  the exhcange processing to another thread.
  That's the reason why it has been implemented in
servicemix-common.
  Do you see something else ?
 
  On 1/23/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
  A question again. If I have a lw component which opens a new
 message
  exchange the correlation id has to be propageted in the
component
  itself. Would it be better or is it possible to do this
 automaticaly
  in
  the exchange factory?
 
  Cheers,
  Thomas
 
  Guillaume Nodet wrote:
  The way it works now is that
  all components using servicemix-common that create an exchange
  as part of the processing of a received exchange, will
  automatically
  put the correlationId in the new exchange properties.
  The correlationId is equal to correlationId of the input
 exchange,
  or the
  input exchange id if no correlation id is set.
 
  So if an endpoint A sends a JBI exchange to enpoint B, and
  endpoint
  B
  sends a jbi exchange to endpoint C while processing the
exchange,
  both exchange will have the same correlationId.
 
  If we write a MessageExchange event listener, we should be
 able to
  retrieve all these informations.  Note that the flow can be
  retrieved
  with the same logic used in the DotViewFlowListener instead.
 
  Just copy the DotViewFlowListener and change the drawing
  logic.  What tool are will you use to draw the flow ?  The
output
  of the DotViewFlowListener is not very impressive, so any
  improvement would be welcome.
 
  On 1/10/07, Thomas TERMIN [EMAIL PROTECTED]
wrote:
  How is this intended to work? I want to implement a tracing
tool
  or
  whatever to see the flows between the components.
 
  Cheers
 
  Guillaume Nodet wrote:
  No one leverage the correlation ids, but i it could / should
  be done.  What kind of informations are you looking for ?
 
  On 1/10/07, Thomas TERMIN [EMAIL PROTECTED]
  wrote:
  Hello,
 
  How can I enable tracing in servicemix with the new
  correlation id
  mechanism. How do I have to use this? (I don't want to use
the
  DotViewFlowListener)
 
  Cheers,
  Thomas
 
 
 
 
 
 
  --
  Cheers,
  Guillaume Nodet
  
  Architect, LogicBlaze (http://www.logicblaze.com/)
  Blog: http://gnodet.blogspot.com/
 
 
 
  --
  Thomas Termin
  ___
  blue elephant systems GmbH
  Wollgrasweg 49
  D-70599 Stuttgart
 
  Tel:

[jira] Resolved: (SM-890) Security Subject can not be propagated in servicemix-jsr181 when using the jsr181 proxies

2007-03-21 Thread Guillaume Nodet (JIRA)


 [ 
https://issues.apache.org/activemq/browse/SM-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved SM-890.


Resolution: Fixed
  Assignee: Guillaume Nodet

URL: http://svn.apache.org/viewvc?view=revrev=520903
URL: http://svn.apache.org/viewvc?view=revrev=520904


 Security Subject can not be propagated in servicemix-jsr181 when using the 
 jsr181 proxies
 -

 Key: SM-890
 URL: https://issues.apache.org/activemq/browse/SM-890
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-jsr181
Affects Versions: 3.1
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 3.1.1, 3.2




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Confluence user groups

2007-03-21 Thread Hernan Cunico


I created a geronimo-committers group in Confluence and go figure, added all 
the Geronimo committers to it ;-). (I also created some accounts in some cases)

This group is replacing the old geronimo-admins group and has full admin 
access to the following spaces:

Apache Geronimo Documentation
Apache Geronimo v2.0
Apache Geronimo v1.2
Apache Geronimo v1.1
Apache Geronimo v1.0
Apache Geronimo Development
Apache Geronimo Project Management
Apache Geronimo Knowledge Base
Apache Geronimo Samples
Apache Geronimo SandBox
Apache Geronimo

GBuild is the only space still holding on the geronimo-admins group. If nobody objects I will replace 
geronimo-admins group with geronimo-committers in this space too and then remove the 
geronimo-admins group.

Cheers!
Hernan

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)


+1


Regards,
Alan

On Mar 20, 2007, at 8:16 PM, Jason Dillon wrote:

Looks like xbean-naming is still compiling for 1.4.  Is there any  
specific reason for this?  Can we switch all of xbean to compile  
for 1.5... and if you need 1.4 compat, then use the retrotranslator- 
maven-plugin's translate-project goal to make jdk14 artifacts?


--jason


On Mar 20, 2007, at 5:14 AM, David Jencks wrote:


geronimo-naming jar

I think you'll find you need to update xbean-naming.

thanks
david jencks
On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

The server/trunk build is picking this up in configs/rmi- 
naming... but from where?


Need to update this to use java.util.concurrent... its using  
backport-concurrent-util at the moment.


--jason

Re: Build Failure Rev: 520756

2007-03-21 Thread Davanum Srinivas


FYI, Fresh svn (520891) worked fine after nuking
~/.m2/repository/org/apache/axis2

-- dims

On 3/21/07, Davanum Srinivas [EMAIL PROTECTED] wrote:

oops...looks like you did that already. let me check.

-- dims

On 3/21/07, Davanum Srinivas [EMAIL PROTECTED] wrote:
 Rakesh,

 Do you mind nuking your .m2/repository/org/apache/axis2 and running a
 fresh online build?

 thanks,
 dims

 On 3/21/07, Rakesh Midha [EMAIL PROTECTED] wrote:
  Hello
 
  I am getting build failure in geronimo-axis2 module with latest trunk. I
  cleaned my repo as well as did a clean checkout and build, but still stuck
  with same problem. Any idea what is wrong?
 
  Here is trace. The messages doesn't make any sense.
 
 
  [INFO]
  
  [ERROR] BUILD FAILURE
  [INFO]
  
  [INFO] Compilation failure
 
  Failure executing javac, but could not parse the error:
  C:\Documents and
  Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
  
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Endpoi
  ntDescription.java):64: class EndpointDescription is public, should be
  declared
  in a file named EndpointDescription.java
  (source unavailable)
  C:\Documents and
  Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
  
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Servic
  eDescription.java):48: class ServiceDescription is public, should be
  declared in
   a file named ServiceDescription.java
  (source unavailable)
  C:\Documents and
  Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
  
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Endpoi
  ntInterfaceDescription.java):53: class EndpointInterfaceDescription is
  public, s
  hould be declared in a file named
  EndpointInterfaceDescription.java
  (source unavailable)
  C:\Documents and
  Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
  a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar
  (org/apache/axis2/jaxws/description/Servic
  eRuntimeDescription.java):29: class ServiceRuntimeDescription is public,
  should
  be declared in a file named ServiceRuntimeDescription.java
  (source unavailable)
  C:\Documents and
  Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
  
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Operat
  ionDescription.java):58: class OperationDescription is public, should be
  declare
  d in a file named OperationDescription.java
  (source unavailable)
  C:\Documents and
  Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
  
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/FaultD
  escription.java):49: class FaultDescription is public, should be declared in
  a f
  ile named FaultDescription.java
  (source unavailable)
  C:\Documents and
  Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
  
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Parame
  terDescription.java):51: class ParameterDescription is public, should be
  declare
  d in a file named ParameterDescription.java
  (source unavailable)
  C:\Documents and
  Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
  
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Operat
  ionRuntimeDescription.java):30: class OperationRuntimeDescription is public,
  sho
  uld be declared in a file named
  OperationRuntimeDescription.java
  (source unavailable)
  8 errors
 
 
  [INFO]
  
  [INFO] For more information, run Maven with the -e switch
  [INFO]
  
  [INFO] Total time: 4 minutes 8 seconds
  [INFO] Finished at: Wed Mar 21 18:15:02 IST 2007
  [INFO] Final Memory: 76M/254M
  [INFO]
  
 
  Thanks
  Rakesh
 


 --
 Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers



--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers




--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers

[jira] Commented: (GERONIMO-2965) TLDs can contain listener declarations that need to hook into injection framework.

2007-03-21 Thread David Jencks (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482798
 ] 

David Jencks commented on GERONIMO-2965:


Looking even more closely at the jsp 2.1 spec section 7.1.11 we discover we 
have to look for all the tags too so the jsp engine can do its lifecycle magic 
on them too.  Just adding these to the classfinder should be sufficient.

 TLDs can contain listener declarations that need to hook into injection 
 framework.
 --

 Key: GERONIMO-2965
 URL: https://issues.apache.org/jira/browse/GERONIMO-2965
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Jetty
Affects Versions: 2.0-M3
Reporter: David Jencks
 Assigned To: Tim McConnell
 Fix For: 2.0-beta1

 Attachments: GERONIMO-2965-1.patch, GERONIMO-2965-2.patch


 It turns out that tld files can also contain listener specifications and 
 these listeners need to be scanned for annotations and injections.  I think 
 this is specific to jsp stuff so I'm inclined to make a jsp module builder 
 extension to handle this like the myfaces one.
 I don't think we've gotten far enough with tomcat to know if there's a 
 similar problem there.  A MBE ought to work for both if necessary.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DAYTRADER-37) UpdateProfile button on Account page does not work

2007-03-21 Thread Christopher James Blythe (JIRA)

UpdateProfile button on Account page does not work
--

 Key: DAYTRADER-37
 URL: https://issues.apache.org/jira/browse/DAYTRADER-37
 Project: DayTrader
  Issue Type: Bug
  Components: Web Tier
Affects Versions: 1.2, 2.0
Reporter: Christopher James Blythe
 Assigned To: Christopher James Blythe
Priority: Minor


The UpdateProfile button does not submit account profile changes to the server. 
After looking at the JSP, form tags are missing and need to be added. Already 
have a patch and will be committing shortly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DAYTRADER-37) UpdateProfile button on Account page does not work

2007-03-21 Thread Christopher James Blythe (JIRA)


 [ 
https://issues.apache.org/jira/browse/DAYTRADER-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher James Blythe closed DAYTRADER-37.
-

   Resolution: Fixed
Fix Version/s: 2.0
   1.2

Committed fix to both branches/1.2 and trunk (excluded branches/old2_0Trunk)

 UpdateProfile button on Account page does not work
 --

 Key: DAYTRADER-37
 URL: https://issues.apache.org/jira/browse/DAYTRADER-37
 Project: DayTrader
  Issue Type: Bug
  Components: Web Tier
Affects Versions: 1.2, 2.0
Reporter: Christopher James Blythe
 Assigned To: Christopher James Blythe
Priority: Minor
 Fix For: 1.2, 2.0


 The UpdateProfile button does not submit account profile changes to the 
 server. After looking at the JSP, form tags are missing and need to be 
 added. Already have a patch and will be committing shortly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3001) Geronimo needs to inject into the openejb3 system context the server ORB and HandleDelegate instances.

2007-03-21 Thread Rick McGuire (JIRA)

Geronimo needs to inject into the openejb3 system context the server ORB and 
HandleDelegate instances.
--

 Key: GERONIMO-3001
 URL: https://issues.apache.org/jira/browse/GERONIMO-3001
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: CORBA
Affects Versions: 2.0-M3
Reporter: Rick McGuire
 Assigned To: Rick McGuire
 Fix For: 2.0-beta1


In order for ejbs to resolve java:comp/ORB and java:comp/HandleDelegate 
information, Geronimo needs to provide the EJB system with the configured ORB 
and delegate information to set in its jndi tree. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3002) Error processing @WebServiceRefs annotation

2007-03-21 Thread Jarek Gawor (JIRA)

Error processing @WebServiceRefs annotation
---

 Key: GERONIMO-3002
 URL: https://issues.apache.org/jira/browse/GERONIMO-3002
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Reporter: Jarek Gawor


I'm getting the following exception when @WebServiceRefs(..) annotation is 
specified at class level:

Caused by: java.lang.IllegalArgumentException: You must supply exactly one of Me
thod, Field
at org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelper.getIn
jectionJavaType(AnnotationHelper.java:46)
at org.apache.geronimo.j2ee.deployment.annotation.WebServiceRefAnnotatio
nHelper.addWebServiceRef(WebServiceRefAnnotationHelper.java:249)
at org.apache.geronimo.j2ee.deployment.annotation.WebServiceRefAnnotatio
nHelper.processWebServiceRefs(WebServiceRefAnnotationHelper.java:159)
at org.apache.geronimo.j2ee.deployment.annotation.WebServiceRefAnnotatio
nHelper.processAnnotations(WebServiceRefAnnotationHelper.java:85)

My understanding is that for the *s annotations the deployment descriptor is 
updated however the values are not injected at runtime. Therefore, the 
injectionTarget element in xml should not be generated for such annotations.




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GERONIMO-3002) Error processing @WebServiceRefs annotation

2007-03-21 Thread Tim McConnell (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim McConnell reassigned GERONIMO-3002:
---

Assignee: Tim McConnell

 Error processing @WebServiceRefs annotation
 ---

 Key: GERONIMO-3002
 URL: https://issues.apache.org/jira/browse/GERONIMO-3002
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Reporter: Jarek Gawor
 Assigned To: Tim McConnell

 I'm getting the following exception when @WebServiceRefs(..) annotation is 
 specified at class level:
 Caused by: java.lang.IllegalArgumentException: You must supply exactly one of 
 Me
 thod, Field
 at 
 org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelper.getIn
 jectionJavaType(AnnotationHelper.java:46)
 at 
 org.apache.geronimo.j2ee.deployment.annotation.WebServiceRefAnnotatio
 nHelper.addWebServiceRef(WebServiceRefAnnotationHelper.java:249)
 at 
 org.apache.geronimo.j2ee.deployment.annotation.WebServiceRefAnnotatio
 nHelper.processWebServiceRefs(WebServiceRefAnnotationHelper.java:159)
 at 
 org.apache.geronimo.j2ee.deployment.annotation.WebServiceRefAnnotatio
 nHelper.processAnnotations(WebServiceRefAnnotationHelper.java:85)
 My understanding is that for the *s annotations the deployment descriptor is 
 updated however the values are not injected at runtime. Therefore, the 
 injectionTarget element in xml should not be generated for such annotations.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)

2007-03-21 Thread David Jencks


+1 to 1.5 only
+0 to publishing retro-jars

david jencks

On Mar 20, 2007, at 11:16 PM, Jason Dillon wrote:

Looks like xbean-naming is still compiling for 1.4.  Is there any  
specific reason for this?  Can we switch all of xbean to compile  
for 1.5... and if you need 1.4 compat, then use the retrotranslator- 
maven-plugin's translate-project goal to make jdk14 artifacts?


--jason


On Mar 20, 2007, at 5:14 AM, David Jencks wrote:


geronimo-naming jar

I think you'll find you need to update xbean-naming.

thanks
david jencks
On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

The server/trunk build is picking this up in configs/rmi- 
naming... but from where?


Need to update this to use java.util.concurrent... its using  
backport-concurrent-util at the moment.


--jason

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)


-1 (not a veto but a cancelable vote) on publishing retro-jars.


Regards,
Alan

On Mar 21, 2007, at 9:55 AM, David Jencks wrote:


+1 to 1.5 only
+0 to publishing retro-jars

david jencks

On Mar 20, 2007, at 11:16 PM, Jason Dillon wrote:

Looks like xbean-naming is still compiling for 1.4.  Is there any  
specific reason for this?  Can we switch all of xbean to compile  
for 1.5... and if you need 1.4 compat, then use the  
retrotranslator-maven-plugin's translate-project goal to make  
jdk14 artifacts?


--jason


On Mar 20, 2007, at 5:14 AM, David Jencks wrote:


geronimo-naming jar

I think you'll find you need to update xbean-naming.

thanks
david jencks
On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

The server/trunk build is picking this up in configs/rmi- 
naming... but from where?


Need to update this to use java.util.concurrent... its using  
backport-concurrent-util at the moment.


--jason

[jira] Updated: (GERONIMO-2965) TLDs can contain listener declarations that need to hook into injection framework.

2007-03-21 Thread Tim McConnell (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim McConnell updated GERONIMO-2965:


Attachment: GERONIMO-2965-3.patch

Support added for tag classes and DTD 1.1 versions of the TLD files. The 
previous patch only supported DTD 1.2 versions. 

 TLDs can contain listener declarations that need to hook into injection 
 framework.
 --

 Key: GERONIMO-2965
 URL: https://issues.apache.org/jira/browse/GERONIMO-2965
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Jetty
Affects Versions: 2.0-M3
Reporter: David Jencks
 Assigned To: Tim McConnell
 Fix For: 2.0-beta1

 Attachments: GERONIMO-2965-1.patch, GERONIMO-2965-2.patch, 
 GERONIMO-2965-3.patch


 It turns out that tld files can also contain listener specifications and 
 these listeners need to be scanned for annotations and injections.  I think 
 this is specific to jsp stuff so I'm inclined to make a jsp module builder 
 extension to handle this like the myfaces one.
 I don't think we've gotten far enough with tomcat to know if there's a 
 similar problem there.  A MBE ought to work for both if necessary.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)


Why are you both reluctant to publish retrotranslated jars ?

On 3/21/07, Alan D. Cabrera [EMAIL PROTECTED] wrote:


-1 (not a veto but a cancelable vote) on publishing retro-jars.


Regards,
Alan

On Mar 21, 2007, at 9:55 AM, David Jencks wrote:

 +1 to 1.5 only
 +0 to publishing retro-jars

 david jencks

 On Mar 20, 2007, at 11:16 PM, Jason Dillon wrote:

 Looks like xbean-naming is still compiling for 1.4.  Is there any
 specific reason for this?  Can we switch all of xbean to compile
 for 1.5... and if you need 1.4 compat, then use the
 retrotranslator-maven-plugin's translate-project goal to make
 jdk14 artifacts?

 --jason


 On Mar 20, 2007, at 5:14 AM, David Jencks wrote:

 geronimo-naming jar

 I think you'll find you need to update xbean-naming.

 thanks
 david jencks
 On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

 The server/trunk build is picking this up in configs/rmi-
 naming... but from where?

 Need to update this to use java.util.concurrent... its using
 backport-concurrent-util at the moment.

 --jason









--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)

BTW, with the latest retrotranslator-maven-plugin, the translate- 
project goal makes translation and install/publish transparent,  
defaulting to using jdk14 for the classifier for the translated bits.


I'm also not sure why folks are anti publishing these jars... they  
are there to support folks who are using JDK 1.4.  I suppose if users  
want they can retrotranslate themselves... but thats more work.   
Perhaps if folks are still -1 on this, once people start to ask for  
this they will reconsider?  I dunno... seems harmless to  
retrotranslate them IMO.  Not like xbean has 200 modules like G does.


--jason


On Mar 21, 2007, at 10:27 AM, Guillaume Nodet wrote:


Why are you both reluctant to publish retrotranslated jars ?

On 3/21/07, Alan D. Cabrera [EMAIL PROTECTED] wrote:


-1 (not a veto but a cancelable vote) on publishing retro-jars.


Regards,
Alan

On Mar 21, 2007, at 9:55 AM, David Jencks wrote:

 +1 to 1.5 only
 +0 to publishing retro-jars

 david jencks

 On Mar 20, 2007, at 11:16 PM, Jason Dillon wrote:

 Looks like xbean-naming is still compiling for 1.4.  Is there any
 specific reason for this?  Can we switch all of xbean to compile
 for 1.5... and if you need 1.4 compat, then use the
 retrotranslator-maven-plugin's translate-project goal to make
 jdk14 artifacts?

 --jason


 On Mar 20, 2007, at 5:14 AM, David Jencks wrote:

 geronimo-naming jar

 I think you'll find you need to update xbean-naming.

 thanks
 david jencks
 On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

 The server/trunk build is picking this up in configs/rmi-
 naming... but from where?

 Need to update this to use java.util.concurrent... its using
 backport-concurrent-util at the moment.

 --jason









--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: Build Failure Rev: 520756

2007-03-21 Thread Prasad Kashyap


I have had successful builds of 520810 and 520890 too. See
geronimo-scm mailing list.

All builds are done by completely wiping out the tree and the repo and
then doing a fresh checkout.

Cheers
Prasad

On 3/21/07, Davanum Srinivas [EMAIL PROTECTED] wrote:

FYI, Fresh svn (520891) worked fine after nuking
~/.m2/repository/org/apache/axis2

-- dims

On 3/21/07, Davanum Srinivas [EMAIL PROTECTED] wrote:
 oops...looks like you did that already. let me check.

 -- dims

 On 3/21/07, Davanum Srinivas [EMAIL PROTECTED] wrote:
  Rakesh,
 
  Do you mind nuking your .m2/repository/org/apache/axis2 and running a
  fresh online build?
 
  thanks,
  dims
 
  On 3/21/07, Rakesh Midha [EMAIL PROTECTED] wrote:
   Hello
  
   I am getting build failure in geronimo-axis2 module with latest trunk. I
   cleaned my repo as well as did a clean checkout and build, but still stuck
   with same problem. Any idea what is wrong?
  
   Here is trace. The messages doesn't make any sense.
  
  
   [INFO]
   
   [ERROR] BUILD FAILURE
   [INFO]
   
   [INFO] Compilation failure
  
   Failure executing javac, but could not parse the error:
   C:\Documents and
   Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
   
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Endpoi
   ntDescription.java):64: class EndpointDescription is public, should be
   declared
   in a file named EndpointDescription.java
   (source unavailable)
   C:\Documents and
   Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
   
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Servic
   eDescription.java):48: class ServiceDescription is public, should be
   declared in
a file named ServiceDescription.java
   (source unavailable)
   C:\Documents and
   Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
   
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Endpoi
   ntInterfaceDescription.java):53: class EndpointInterfaceDescription is
   public, s
   hould be declared in a file named
   EndpointInterfaceDescription.java
   (source unavailable)
   C:\Documents and
   Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
   a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar
   (org/apache/axis2/jaxws/description/Servic
   eRuntimeDescription.java):29: class ServiceRuntimeDescription is public,
   should
   be declared in a file named ServiceRuntimeDescription.java
   (source unavailable)
   C:\Documents and
   Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
   
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Operat
   ionDescription.java):58: class OperationDescription is public, should be
   declare
   d in a file named OperationDescription.java
   (source unavailable)
   C:\Documents and
   Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
   
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/FaultD
   escription.java):49: class FaultDescription is public, should be declared 
in
   a f
   ile named FaultDescription.java
   (source unavailable)
   C:\Documents and
   Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
   
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Parame
   terDescription.java):51: class ParameterDescription is public, should be
   declare
   d in a file named ParameterDescription.java
   (source unavailable)
   C:\Documents and
   Settings\libadmin\.m2\repository\org\apache\axis2\axis2-metadat
   
a\SNAPSHOT\axis2-metadata-SNAPSHOT.jar(org/apache/axis2/jaxws/description/Operat
   ionRuntimeDescription.java):30: class OperationRuntimeDescription is 
public,
   sho
   uld be declared in a file named
   OperationRuntimeDescription.java
   (source unavailable)
   8 errors
  
  
   [INFO]
   
   [INFO] For more information, run Maven with the -e switch
   [INFO]
   
   [INFO] Total time: 4 minutes 8 seconds
   [INFO] Finished at: Wed Mar 21 18:15:02 IST 2007
   [INFO] Final Memory: 76M/254M
   [INFO]
   
  
   Thanks
   Rakesh
  
 
 
  --
  Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
 


 --
 Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers



--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers

Re: [jira] Closed: (GERONIMO-2638) Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of JarFile

2007-03-21 Thread Tim McConnell

Hi Sachin, I shall miss good ole G-1526. I learned a LOT from you about the 
Geronimo module/configuration builders working on that JIRA. So from solely a 
self-serving point of view it was a good place for me to start !!


Thanks,
Tim McConnell


Sachin Patel wrote:

yes it is.

-sachin


On Mar 21, 2007, at 9:07 AM, Tim McConnell wrote:


Hi Sachin, is this a duplicate of GERONIMO-1526 ??

Thanks,
Tim McConnell


Sachin Patel (JIRA) wrote:
 [ 
https://issues.apache.org/jira/browse/GERONIMO-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
]

Sachin Patel closed GERONIMO-2638.
--
Resolution: Later
After reflecting on this solution, it does not fit in nicely with the 
current architecture and will need to investigate alternate solutions.
Improve ModuleBuilder and ConfigurationBuilder interfaces to replace 
use of JarFile
--- 



Key: GERONIMO-2638
URL: 
https://issues.apache.org/jira/browse/GERONIMO-2638

Project: Geronimo
 Issue Type: RTC
 Security Level: public(Regular issues)  Components: 
deployment

   Affects Versions: 2.0-M1
   Reporter: Sachin Patel
Assigned To: Sachin Patel
Fix For: 2.0-M3

Attachments: GERONIMO-1526-v1.2.patch, 
GERONIMO-1526-v1.2.patch2

Re: [VOTE] J2G Conversion tool acceptance

2007-03-21 Thread Paul McMahan


Jeffery,  after filing the IP clearance form I checked J2G into the
sandbox.  At the time I was thinking it would be OK to include this
file
  https://svn.apache.org/repos/asf/geronimo/sandbox/j2g/COPYRIGHT.txt
But then later someone pointed out that this file could potentially be
an issue.   Could you do us a favor and reattach the zip to the JIRA
with that COPYRIGHT.txt file removed?

Best wishes,
Paul

On 2/8/07, Jeffrey Faelnar [EMAIL PROTECTED] wrote:

Hi Paul,

We're in the process of getting the codebase cleaned up, refactored, and
adding maven support. However, I will need your assistance with the
ip-clearance form. Thanks.

-Jeff


 On 2/8/07, Paul McMahan [EMAIL PROTECTED] wrote:
 IIUC we're at step 3 of this process right now -- contributor replaces
 copyright statements with the standard apache header.  Adding maven
 support and changing the package names from com.ibm.* to org.apache.*
 would  be very useful as well if that's possible.  I can help with
 step 4 - submitting the ip clearance form and checking in to
 geronimo/sandbox.  Once in sandbox we should discuss how/when it can
 be updated to support geronimo 1.2  2.0 and merged with the devtools
 subproject.

 Best wishes,
 Paul

 On 2/1/07, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
  Here's the process :
 
  1) Contributor offers code
 
  2) Project decides to accept or reject code.  Formally, this is the
  PMC, but everyone should chime in.
 
  3) Contributor provides CCLA, cleans up code to remove copyright
  statements, and puts the standard apache file header in place.
 
  4) Project accepts code contribution and registers the code
  contribution w/ the incubator with an ip_clearance form :
 
 
http://svn.apache.org/viewvc/incubator/public/trunk/site-author/
  ip-clearance/
 
  5) Happy users convert their JBoss apps to Geronimo.
 
  There's no need for the creation of a podling for accepting code into
  an existing project, unless you wanted to bring in people and create
  a community around it.  We simply need to file an ip-clearance form
  w/ the incubator that notes that we did the due diligence in
  accepting the code.
 
  geir
 
 
 
  On Jan 31, 2007, at 10:10 AM, Filip Hanik - Dev Lists wrote:
 
   This is the formal vote to accept the J2G codebase and bring it
   through incubation (see
http://marc.theaimsgroup.com/?l=geronimo-
   devm=116906208022256w=2)
   The final destination is to be part of the geronimo devtool
   subproject.
   (see http://marc.theaimsgroup.com/?l=geronimo-
   devm=116958894929809w=2)
  
   The code donation is located at:
   https://issues.apache.org/jira/browse/GERONIMO-2743
  
   [ ] +1 lets bring it in, this is great
   [ ]  0 do what ever you want, not my cup of tea
   [ ] -1 keep it out of our sight, I have a good reason
  
   Optional
   [ ] I'm willing to mentor this project while it is in incubation
   [ ] I'm willing to champion the effort while it is in incubation
  
   Committers' votes are binding, all other votes will be duly noted
  
   Best regards
   Filip

Re: Confluence user groups

2007-03-21 Thread Hernan Cunico


We are not adding responsibility, if you were able to add, edit, delete files 
in SVN being a Geronimo committer you should still be able to do the same in 
Confluence.
This user group has space admin privs to only Geronimo related spaces, it's 
our responsibility as committers to know and communicate what we do on these spaces.

Either way, good call to refresh our memory ;-)

Cheers!
Hernan

Jason Dillon wrote:

With great power comes great responsibility... please be-careful ;-)

--jason


On Mar 21, 2007, at 8:00 AM, Hernan Cunico wrote:

I created a geronimo-committers group in Confluence and go figure, 
added all the Geronimo committers to it ;-). (I also created some 
accounts in some cases)


This group is replacing the old geronimo-admins group and has full 
admin access to the following spaces:


Apache Geronimo Documentation
Apache Geronimo v2.0
Apache Geronimo v1.2
Apache Geronimo v1.1
Apache Geronimo v1.0
Apache Geronimo Development
Apache Geronimo Project Management
Apache Geronimo Knowledge Base
Apache Geronimo Samples
Apache Geronimo SandBox
Apache Geronimo

GBuild is the only space still holding on the geronimo-admins group. 
If nobody objects I will replace geronimo-admins group with 
geronimo-committers in this space too and then remove the 
geronimo-admins group.


Cheers!
Hernan

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)

2007-03-21 Thread David Jencks

I'm fine (down?) with it as long as it doesn't create build problems  
and I don't have to set it up.  I voted +0, not -0.


thanks
david jencks

On Mar 21, 2007, at 1:47 PM, Jason Dillon wrote:

BTW, with the latest retrotranslator-maven-plugin, the translate- 
project goal makes translation and install/publish transparent,  
defaulting to using jdk14 for the classifier for the translated bits.


I'm also not sure why folks are anti publishing these jars... they  
are there to support folks who are using JDK 1.4.  I suppose if  
users want they can retrotranslate themselves... but thats more  
work.  Perhaps if folks are still -1 on this, once people start to  
ask for this they will reconsider?  I dunno... seems harmless to  
retrotranslate them IMO.  Not like xbean has 200 modules like G does.


--jason


On Mar 21, 2007, at 10:27 AM, Guillaume Nodet wrote:


Why are you both reluctant to publish retrotranslated jars ?

On 3/21/07, Alan D. Cabrera [EMAIL PROTECTED] wrote:


-1 (not a veto but a cancelable vote) on publishing retro-jars.


Regards,
Alan

On Mar 21, 2007, at 9:55 AM, David Jencks wrote:

 +1 to 1.5 only
 +0 to publishing retro-jars

 david jencks

 On Mar 20, 2007, at 11:16 PM, Jason Dillon wrote:

 Looks like xbean-naming is still compiling for 1.4.  Is there any
 specific reason for this?  Can we switch all of xbean to compile
 for 1.5... and if you need 1.4 compat, then use the
 retrotranslator-maven-plugin's translate-project goal to make
 jdk14 artifacts?

 --jason


 On Mar 20, 2007, at 5:14 AM, David Jencks wrote:

 geronimo-naming jar

 I think you'll find you need to update xbean-naming.

 thanks
 david jencks
 On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

 The server/trunk build is picking this up in configs/rmi-
 naming... but from where?

 Need to update this to use java.util.concurrent... its using
 backport-concurrent-util at the moment.

 --jason









--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)

Retrotranslator is relatively new and we would only be doubling our  
testing and it's more stuff to check when we make release  
distributions.  Also, how would our retro jars fit into the maven  
repository scheme of things?



Regards,
Alan

On Mar 21, 2007, at 10:27 AM, Guillaume Nodet wrote:


Why are you both reluctant to publish retrotranslated jars ?

On 3/21/07, Alan D. Cabrera [EMAIL PROTECTED] wrote:


-1 (not a veto but a cancelable vote) on publishing retro-jars.


Regards,
Alan

On Mar 21, 2007, at 9:55 AM, David Jencks wrote:

 +1 to 1.5 only
 +0 to publishing retro-jars

 david jencks

 On Mar 20, 2007, at 11:16 PM, Jason Dillon wrote:

 Looks like xbean-naming is still compiling for 1.4.  Is there any
 specific reason for this?  Can we switch all of xbean to compile
 for 1.5... and if you need 1.4 compat, then use the
 retrotranslator-maven-plugin's translate-project goal to make
 jdk14 artifacts?

 --jason


 On Mar 20, 2007, at 5:14 AM, David Jencks wrote:

 geronimo-naming jar

 I think you'll find you need to update xbean-naming.

 thanks
 david jencks
 On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

 The server/trunk build is picking this up in configs/rmi-
 naming... but from where?

 Need to update this to use java.util.concurrent... its using
 backport-concurrent-util at the moment.

 --jason









--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: Confluence user groups


With great power comes great responsibility... please be-careful ;-)

--jason


On Mar 21, 2007, at 8:00 AM, Hernan Cunico wrote:

I created a geronimo-committers group in Confluence and go  
figure, added all the Geronimo committers to it ;-). (I also  
created some accounts in some cases)


This group is replacing the old geronimo-admins group and has  
full admin access to the following spaces:


Apache Geronimo Documentation
Apache Geronimo v2.0
Apache Geronimo v1.2
Apache Geronimo v1.1
Apache Geronimo v1.0
Apache Geronimo Development
Apache Geronimo Project Management
Apache Geronimo Knowledge Base
Apache Geronimo Samples
Apache Geronimo SandBox
Apache Geronimo

GBuild is the only space still holding on the geronimo-admins  
group. If nobody objects I will replace geronimo-admins group  
with geronimo-committers in this space too and then remove the  
geronimo-admins group.


Cheers!
Hernan

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)

Retrotranslator has been around for a few years AFAIK.  Not sure it  
will double your testing efforts... though if you wanted to run  
integration tests on JDK 1.5 and 1.4 then ya, it would double those.


What additional stuff is there to check for the release?  AFAIK the  
jars contain the same legal bits as non-retro jars.  So someone would  
have to check that once, and then could forget... though there is a  
goal to ensure artifacts have legal muck in them automatically, which  
server is using in the default build.


Retro jars will live next to non-retro jars with a jdk14  
classifier, everything else should be the same.


--jason


On Mar 21, 2007, at 11:38 AM, Alan D. Cabrera wrote:

Retrotranslator is relatively new and we would only be doubling our  
testing and it's more stuff to check when we make release  
distributions.  Also, how would our retro jars fit into the maven  
repository scheme of things?



Regards,
Alan

On Mar 21, 2007, at 10:27 AM, Guillaume Nodet wrote:


Why are you both reluctant to publish retrotranslated jars ?

On 3/21/07, Alan D. Cabrera [EMAIL PROTECTED] wrote:


-1 (not a veto but a cancelable vote) on publishing retro-jars.


Regards,
Alan

On Mar 21, 2007, at 9:55 AM, David Jencks wrote:

 +1 to 1.5 only
 +0 to publishing retro-jars

 david jencks

 On Mar 20, 2007, at 11:16 PM, Jason Dillon wrote:

 Looks like xbean-naming is still compiling for 1.4.  Is there any
 specific reason for this?  Can we switch all of xbean to compile
 for 1.5... and if you need 1.4 compat, then use the
 retrotranslator-maven-plugin's translate-project goal to make
 jdk14 artifacts?

 --jason


 On Mar 20, 2007, at 5:14 AM, David Jencks wrote:

 geronimo-naming jar

 I think you'll find you need to update xbean-naming.

 thanks
 david jencks
 On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

 The server/trunk build is picking this up in configs/rmi-
 naming... but from where?

 Need to update this to use java.util.concurrent... its using
 backport-concurrent-util at the moment.

 --jason









--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: Confluence user groups

Yes, I know... though admin includes the ability to empty the trash,  
to alter perms of the spaces, update space info, remove the space,  
etc... which is what I want folks to be careful about.  So there is  
some added responsibility... to make sure that we keep the  
permissions intact and inline with our policies.


Anyways, I just sent this as a little reminder to folks... I don't  
expect anything major to happen... though accidents can happen.


--jason


On Mar 21, 2007, at 11:11 AM, Hernan Cunico wrote:

We are not adding responsibility, if you were able to add, edit,  
delete files in SVN being a Geronimo committer you should still be  
able to do the same in Confluence.
This user group has space admin privs to only Geronimo related  
spaces, it's our responsibility as committers to know and  
communicate what we do on these spaces.


Either way, good call to refresh our memory ;-)

Cheers!
Hernan

Jason Dillon wrote:

With great power comes great responsibility... please be-careful ;-)
--jason
On Mar 21, 2007, at 8:00 AM, Hernan Cunico wrote:
I created a geronimo-committers group in Confluence and go  
figure, added all the Geronimo committers to it ;-). (I also  
created some accounts in some cases)


This group is replacing the old geronimo-admins group and has  
full admin access to the following spaces:


Apache Geronimo Documentation
Apache Geronimo v2.0
Apache Geronimo v1.2
Apache Geronimo v1.1
Apache Geronimo v1.0
Apache Geronimo Development
Apache Geronimo Project Management
Apache Geronimo Knowledge Base
Apache Geronimo Samples
Apache Geronimo SandBox
Apache Geronimo

GBuild is the only space still holding on the geronimo-admins  
group. If nobody objects I will replace geronimo-admins group  
with geronimo-committers in this space too and then remove the  
geronimo-admins group.


Cheers!
Hernan

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)

Should not cause any build problems that I am aware of.  If anything  
does come up I will fix it ;-)


Either way... I don't really care... I want JDK 1.5 anyways, 1.4 and  
retro muck is just for any folks who consume xbean that can't use JDK  
1.5.


Shall I look into what changes are required?  Though I have commit  
here if you guys wanna see a patch first I can can make one...


--jason


On Mar 21, 2007, at 11:11 AM, David Jencks wrote:

I'm fine (down?) with it as long as it doesn't create build  
problems and I don't have to set it up.  I voted +0, not -0.


thanks
david jencks

On Mar 21, 2007, at 1:47 PM, Jason Dillon wrote:

BTW, with the latest retrotranslator-maven-plugin, the translate- 
project goal makes translation and install/publish transparent,  
defaulting to using jdk14 for the classifier for the translated bits.


I'm also not sure why folks are anti publishing these jars... they  
are there to support folks who are using JDK 1.4.  I suppose if  
users want they can retrotranslate themselves... but thats more  
work.  Perhaps if folks are still -1 on this, once people start to  
ask for this they will reconsider?  I dunno... seems harmless to  
retrotranslate them IMO.  Not like xbean has 200 modules like G does.


--jason


On Mar 21, 2007, at 10:27 AM, Guillaume Nodet wrote:


Why are you both reluctant to publish retrotranslated jars ?

On 3/21/07, Alan D. Cabrera [EMAIL PROTECTED] wrote:


-1 (not a veto but a cancelable vote) on publishing retro-jars.


Regards,
Alan

On Mar 21, 2007, at 9:55 AM, David Jencks wrote:

 +1 to 1.5 only
 +0 to publishing retro-jars

 david jencks

 On Mar 20, 2007, at 11:16 PM, Jason Dillon wrote:

 Looks like xbean-naming is still compiling for 1.4.  Is there  
any

 specific reason for this?  Can we switch all of xbean to compile
 for 1.5... and if you need 1.4 compat, then use the
 retrotranslator-maven-plugin's translate-project goal to make
 jdk14 artifacts?

 --jason


 On Mar 20, 2007, at 5:14 AM, David Jencks wrote:

 geronimo-naming jar

 I think you'll find you need to update xbean-naming.

 thanks
 david jencks
 On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

 The server/trunk build is picking this up in configs/rmi-
 naming... but from where?

 Need to update this to use java.util.concurrent... its using
 backport-concurrent-util at the moment.

 --jason









--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

[jira] Reopened: (GERONIMO-2743) [Code donation] J2G Conversion tool

2007-03-21 Thread Paul McMahan (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul McMahan reopened GERONIMO-2743:



reopening the issue so the contributor can attach a zip with the COPYRIGHT.txt 
removed

 [Code donation] J2G Conversion tool
 ---

 Key: GERONIMO-2743
 URL: https://issues.apache.org/jira/browse/GERONIMO-2743
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
Affects Versions: 1.1.x
 Environment: MS Windows XP SP2 (although Java based should work on 
 any OS supporting Java)
Reporter: Filip Hanik
 Assigned To: Paul McMahan
Priority: Minor
 Attachments: CCLA.tif, Covalent-J2G-Tool.pdf, 
 J2G-Migration-v2_src_1.0.0.zip, J2G-Migration_2.0.0_src_20070220-1501.zip, 
 J2G-Migration_2.0.0_src_20070302-1501.zip


 IBM has together with in a joint effort with Covalent developed a JBoss to 
 Geronimo conversion tool. This tool is used when converting applications from 
 JBoss to Geronimo, and automatically converts the configuration file from one 
 app server to the other.
 We feel that this piece of software adds value to Geronimo and users adopting 
 Geronimo and would like to see this effort continue as part of the Geronimo 
 project, a plugin or a sub project of Geronimo.
 The initial donation is for version 1.0 of this tool, and while a 1.1 is in 
 the making to improve 1.0, 1.1 is not yet complete but will be donated as 
 soon as the community feels that this tool belongs at the ASF, more 
 specifically within the Geronimo project.
 If you'd think this tool is valuable, but believe it should go through 
 incubation, we would hope that a Geronimo committer would step up and 
 champion this effort.
 The tool, including IBM's CCLA, can be found at 
 http://people.apache.org/~fhanik/j2g/j2g.html (Covalent will file the CCLA 
 upon request) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3003) Encrypt password strings in deployment plans

2007-03-21 Thread Aman Nanner (JIRA)

Encrypt password strings in deployment plans


 Key: GERONIMO-3003
 URL: https://issues.apache.org/jira/browse/GERONIMO-3003
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Priority: Minor
 Fix For: Wish List


Geronimo currently has a feature where password strings in the config.xml get 
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}.  This 
encryption is performed in the 
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.

It would be desirable to have the same encryption applied to the password 
strings in deployment plans (e.g. datasource or JMS deployment plans within an 
EAR).  Even though the plans are only used during the deployment process, and 
not at runtime, the plans are left with plaintext password strings sitting in 
them.  It would be nice if the deployment process could internally encrypt the 
strings and then write back out the deployment plan to the file system.  Also, 
this means that the deployment process will require the ability to decrypt 
strings that are already in encrypted format in the plan (in the case of 
redeployment, for example).

More discussion of this feature can be found in the following mailing list 
thread:

http://www.mail-archive.com/user@geronimo.apache.org/msg05859.html

I would suggest that an appropriate spot to perform the encryption is in the 
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in the 
following code just before the file is written to a temporary file:



if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path, 
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor 
dd url:  + gerModule.getAltDd().getStringValue(), e);
}



However, somebody more familiar with the design might be able to suggest a 
better solution.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)

Yeah, this is what I was thinking too.  I'm still -1 but I can easily  
be outvoted.



Regards,
Alan

On Mar 21, 2007, at 11:46 AM, Jason Dillon wrote:

Retrotranslator has been around for a few years AFAIK.  Not sure it  
will double your testing efforts... though if you wanted to run  
integration tests on JDK 1.5 and 1.4 then ya, it would double those.


What additional stuff is there to check for the release?  AFAIK the  
jars contain the same legal bits as non-retro jars.  So someone  
would have to check that once, and then could forget... though  
there is a goal to ensure artifacts have legal muck in them  
automatically, which server is using in the default build.


Retro jars will live next to non-retro jars with a jdk14  
classifier, everything else should be the same.


--jason


On Mar 21, 2007, at 11:38 AM, Alan D. Cabrera wrote:

Retrotranslator is relatively new and we would only be doubling  
our testing and it's more stuff to check when we make release  
distributions.  Also, how would our retro jars fit into the maven  
repository scheme of things?



Regards,
Alan

On Mar 21, 2007, at 10:27 AM, Guillaume Nodet wrote:


Why are you both reluctant to publish retrotranslated jars ?

On 3/21/07, Alan D. Cabrera [EMAIL PROTECTED] wrote:


-1 (not a veto but a cancelable vote) on publishing retro-jars.


Regards,
Alan

On Mar 21, 2007, at 9:55 AM, David Jencks wrote:

 +1 to 1.5 only
 +0 to publishing retro-jars

 david jencks

 On Mar 20, 2007, at 11:16 PM, Jason Dillon wrote:

 Looks like xbean-naming is still compiling for 1.4.  Is there  
any

 specific reason for this?  Can we switch all of xbean to compile
 for 1.5... and if you need 1.4 compat, then use the
 retrotranslator-maven-plugin's translate-project goal to make
 jdk14 artifacts?

 --jason


 On Mar 20, 2007, at 5:14 AM, David Jencks wrote:

 geronimo-naming jar

 I think you'll find you need to update xbean-naming.

 thanks
 david jencks
 On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

 The server/trunk build is picking this up in configs/rmi-
 naming... but from where?

 Need to update this to use java.util.concurrent... its using
 backport-concurrent-util at the moment.

 --jason









--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

[jira] Updated: (GERONIMO-2743) [Code donation] J2G Conversion tool

2007-03-21 Thread Jeffrey Faelnar (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeffrey Faelnar updated GERONIMO-2743:
--

Attachment: J2G-Migration_2.0.0_src_20070321-1501.zip

COPYRIGHT.txt file removed.

 [Code donation] J2G Conversion tool
 ---

 Key: GERONIMO-2743
 URL: https://issues.apache.org/jira/browse/GERONIMO-2743
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
Affects Versions: 1.1.x
 Environment: MS Windows XP SP2 (although Java based should work on 
 any OS supporting Java)
Reporter: Filip Hanik
 Assigned To: Paul McMahan
Priority: Minor
 Attachments: CCLA.tif, Covalent-J2G-Tool.pdf, 
 J2G-Migration-v2_src_1.0.0.zip, J2G-Migration_2.0.0_src_20070220-1501.zip, 
 J2G-Migration_2.0.0_src_20070302-1501.zip, 
 J2G-Migration_2.0.0_src_20070321-1501.zip


 IBM has together with in a joint effort with Covalent developed a JBoss to 
 Geronimo conversion tool. This tool is used when converting applications from 
 JBoss to Geronimo, and automatically converts the configuration file from one 
 app server to the other.
 We feel that this piece of software adds value to Geronimo and users adopting 
 Geronimo and would like to see this effort continue as part of the Geronimo 
 project, a plugin or a sub project of Geronimo.
 The initial donation is for version 1.0 of this tool, and while a 1.1 is in 
 the making to improve 1.0, 1.1 is not yet complete but will be donated as 
 soon as the community feels that this tool belongs at the ASF, more 
 specifically within the Geronimo project.
 If you'd think this tool is valuable, but believe it should go through 
 incubation, we would hope that a Geronimo committer would step up and 
 champion this effort.
 The tool, including IBM's CCLA, can be found at 
 http://people.apache.org/~fhanik/j2g/j2g.html (Covalent will file the CCLA 
 upon request) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] J2G Conversion tool acceptance

2007-03-21 Thread Jeffrey Faelnar


Paul,

I updated the bundle, removing the COPYRIGHT.txt file, and reattached the
zip to JIRA. Thanks.

On 3/21/07, Paul McMahan [EMAIL PROTECTED] wrote:


Jeffery,  after filing the IP clearance form I checked J2G into the
sandbox.  At the time I was thinking it would be OK to include this
file
   https://svn.apache.org/repos/asf/geronimo/sandbox/j2g/COPYRIGHT.txt
But then later someone pointed out that this file could potentially be
an issue.   Could you do us a favor and reattach the zip to the JIRA
with that COPYRIGHT.txt file removed?

Best wishes,
Paul

On 2/8/07, Jeffrey Faelnar [EMAIL PROTECTED] wrote:
 Hi Paul,

 We're in the process of getting the codebase cleaned up, refactored, and
 adding maven support. However, I will need your assistance with the
 ip-clearance form. Thanks.

 -Jeff


  On 2/8/07, Paul McMahan [EMAIL PROTECTED] wrote:
  IIUC we're at step 3 of this process right now -- contributor replaces
  copyright statements with the standard apache header.  Adding maven
  support and changing the package names from com.ibm.* to org.apache.*
  would  be very useful as well if that's possible.  I can help with
  step 4 - submitting the ip clearance form and checking in to
  geronimo/sandbox.  Once in sandbox we should discuss how/when it can
  be updated to support geronimo 1.2  2.0 and merged with the devtools
  subproject.
 
  Best wishes,
  Paul
 
  On 2/1/07, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
   Here's the process :
  
   1) Contributor offers code
  
   2) Project decides to accept or reject code.  Formally, this is the
   PMC, but everyone should chime in.
  
   3) Contributor provides CCLA, cleans up code to remove copyright
   statements, and puts the standard apache file header in place.
  
   4) Project accepts code contribution and registers the code
   contribution w/ the incubator with an ip_clearance form :
  
  
 http://svn.apache.org/viewvc/incubator/public/trunk/site-author/
   ip-clearance/
  
   5) Happy users convert their JBoss apps to Geronimo.
  
   There's no need for the creation of a podling for accepting code
into
   an existing project, unless you wanted to bring in people and create
   a community around it.  We simply need to file an ip-clearance form
   w/ the incubator that notes that we did the due diligence in
   accepting the code.
  
   geir
  
  
  
   On Jan 31, 2007, at 10:10 AM, Filip Hanik - Dev Lists wrote:
  
This is the formal vote to accept the J2G codebase and bring it
through incubation (see
 http://marc.theaimsgroup.com/?l=geronimo-
devm=116906208022256w=2)
The final destination is to be part of the geronimo devtool
subproject.
(see http://marc.theaimsgroup.com/?l=geronimo-
devm=116958894929809w=2)
   
The code donation is located at:
https://issues.apache.org/jira/browse/GERONIMO-2743
   
[ ] +1 lets bring it in, this is great
[ ]  0 do what ever you want, not my cup of tea
[ ] -1 keep it out of our sight, I have a good reason
   
Optional
[ ] I'm willing to mentor this project while it is in incubation
[ ] I'm willing to champion the effort while it is in incubation
   
Committers' votes are binding, all other votes will be duly noted
   
Best regards
Filip

Re: [VOTE] J2G Conversion tool acceptance

2007-03-21 Thread Paul McMahan


Thanks Jeffrey!

Best wishes,
Paul

On 3/21/07, Jeffrey Faelnar [EMAIL PROTECTED] wrote:

Paul,

I updated the bundle, removing the COPYRIGHT.txt file, and reattached the
zip to JIRA. Thanks.


On 3/21/07, Paul McMahan  [EMAIL PROTECTED] wrote:
 Jeffery,  after filing the IP clearance form I checked J2G into the
 sandbox.  At the time I was thinking it would be OK to include this
 file

https://svn.apache.org/repos/asf/geronimo/sandbox/j2g/COPYRIGHT.txt
 But then later someone pointed out that this file could potentially be
 an issue.   Could you do us a favor and reattach the zip to the JIRA
 with that COPYRIGHT.txt file removed?

 Best wishes,
 Paul

 On 2/8/07, Jeffrey Faelnar [EMAIL PROTECTED] wrote:
  Hi Paul,
 
  We're in the process of getting the codebase cleaned up, refactored, and
  adding maven support. However, I will need your assistance with the
  ip-clearance form. Thanks.
 
  -Jeff
 
 
   On 2/8/07, Paul McMahan [EMAIL PROTECTED] wrote:
   IIUC we're at step 3 of this process right now -- contributor replaces
   copyright statements with the standard apache header.  Adding maven
   support and changing the package names from com.ibm.* to org.apache.*
   would  be very useful as well if that's possible.  I can help with
   step 4 - submitting the ip clearance form and checking in to
   geronimo/sandbox.  Once in sandbox we should discuss how/when it can
   be updated to support geronimo 1.2  2.0 and merged with the devtools
   subproject.
  
   Best wishes,
   Paul
  
   On 2/1/07, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Here's the process :
   
1) Contributor offers code
   
2) Project decides to accept or reject code.  Formally, this is the
PMC, but everyone should chime in.
   
3) Contributor provides CCLA, cleans up code to remove copyright
statements, and puts the standard apache file header in place.
   
4) Project accepts code contribution and registers the code
contribution w/ the incubator with an ip_clearance form :
   
   
 
http://svn.apache.org/viewvc/incubator/public/trunk/site-author/
ip-clearance/
   
5) Happy users convert their JBoss apps to Geronimo.
   
There's no need for the creation of a podling for accepting code
into
an existing project, unless you wanted to bring in people and create
a community around it.  We simply need to file an ip-clearance form
w/ the incubator that notes that we did the due diligence in
accepting the code.
   
geir
   
   
   
On Jan 31, 2007, at 10:10 AM, Filip Hanik - Dev Lists wrote:
   
 This is the formal vote to accept the J2G codebase and bring it
 through incubation (see
  http://marc.theaimsgroup.com/?l=geronimo-
 devm=116906208022256w=2)
 The final destination is to be part of the geronimo devtool
 subproject.
 (see http://marc.theaimsgroup.com/?l=geronimo-
 devm=116958894929809w=2)

 The code donation is located at:

https://issues.apache.org/jira/browse/GERONIMO-2743

 [ ] +1 lets bring it in, this is great
 [ ]  0 do what ever you want, not my cup of tea
 [ ] -1 keep it out of our sight, I have a good reason

 Optional
 [ ] I'm willing to mentor this project while it is in incubation
 [ ] I'm willing to champion the effort while it is in incubation

 Committers' votes are binding, all other votes will be duly noted

 Best regards
 Filip

[jira] Closed: (GERONIMO-2743) [Code donation] J2G Conversion tool

2007-03-21 Thread Paul McMahan (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul McMahan closed GERONIMO-2743.
--

Resolution: Fixed

Thanks for the updated attachment.  I ended up just removing the IBM 
Confidential line from the COPYRIGHT.txt instead of deleting the file, which I 
think was fine to do now that you have provided an additional attachment that 
does not contain the file at all.

 [Code donation] J2G Conversion tool
 ---

 Key: GERONIMO-2743
 URL: https://issues.apache.org/jira/browse/GERONIMO-2743
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
Affects Versions: 1.1.x
 Environment: MS Windows XP SP2 (although Java based should work on 
 any OS supporting Java)
Reporter: Filip Hanik
 Assigned To: Paul McMahan
Priority: Minor
 Attachments: CCLA.tif, Covalent-J2G-Tool.pdf, 
 J2G-Migration-v2_src_1.0.0.zip, J2G-Migration_2.0.0_src_20070220-1501.zip, 
 J2G-Migration_2.0.0_src_20070302-1501.zip, 
 J2G-Migration_2.0.0_src_20070321-1501.zip


 IBM has together with in a joint effort with Covalent developed a JBoss to 
 Geronimo conversion tool. This tool is used when converting applications from 
 JBoss to Geronimo, and automatically converts the configuration file from one 
 app server to the other.
 We feel that this piece of software adds value to Geronimo and users adopting 
 Geronimo and would like to see this effort continue as part of the Geronimo 
 project, a plugin or a sub project of Geronimo.
 The initial donation is for version 1.0 of this tool, and while a 1.1 is in 
 the making to improve 1.0, 1.1 is not yet complete but will be donated as 
 soon as the community feels that this tool belongs at the ASF, more 
 specifically within the Geronimo project.
 If you'd think this tool is valuable, but believe it should go through 
 incubation, we would hope that a Geronimo committer would step up and 
 champion this effort.
 The tool, including IBM's CCLA, can be found at 
 http://people.apache.org/~fhanik/j2g/j2g.html (Covalent will file the CCLA 
 upon request) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)


Does Geronimo 1.2 uses xbean ?

On 3/21/07, Jason Dillon [EMAIL PROTECTED] wrote:


Looks like xbean-naming is still compiling for 1.4.  Is there any
specific reason for this?  Can we switch all of xbean to compile for
1.5... and if you need 1.4 compat, then use the retrotranslator-maven-
plugin's translate-project goal to make jdk14 artifacts?

--jason


On Mar 20, 2007, at 5:14 AM, David Jencks wrote:

 geronimo-naming jar

 I think you'll find you need to update xbean-naming.

 thanks
 david jencks
 On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

 The server/trunk build is picking this up in configs/rmi-naming...
 but from where?

 Need to update this to use java.util.concurrent... its using
 backport-concurrent-util at the moment.

 --jason






--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)

2007-03-21 Thread David Jencks



On Mar 21, 2007, at 5:07 PM, Guillaume Nodet wrote:


Does Geronimo 1.2 uses xbean ?

yes, but not 3.0-SNAPSHOT

thanks
david jencks



On 3/21/07, Jason Dillon [EMAIL PROTECTED] wrote:


Looks like xbean-naming is still compiling for 1.4.  Is there any
specific reason for this?  Can we switch all of xbean to compile for
1.5... and if you need 1.4 compat, then use the retrotranslator- 
maven-

plugin's translate-project goal to make jdk14 artifacts?

--jason


On Mar 20, 2007, at 5:14 AM, David Jencks wrote:

 geronimo-naming jar

 I think you'll find you need to update xbean-naming.

 thanks
 david jencks
 On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

 The server/trunk build is picking this up in configs/rmi-naming...
 but from where?

 Need to update this to use java.util.concurrent... its using
 backport-concurrent-util at the moment.

 --jason






--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)

And we are not going to be changing many deps for G 1.2... its almost  
ready to go... if we leave it alone maybe it will still be ready once  
AMQ and OpenEJB are ready too ;-)


--jason


On Mar 21, 2007, at 2:13 PM, David Jencks wrote:



On Mar 21, 2007, at 5:07 PM, Guillaume Nodet wrote:


Does Geronimo 1.2 uses xbean ?

yes, but not 3.0-SNAPSHOT

thanks
david jencks



On 3/21/07, Jason Dillon [EMAIL PROTECTED] wrote:


Looks like xbean-naming is still compiling for 1.4.  Is there any
specific reason for this?  Can we switch all of xbean to compile for
1.5... and if you need 1.4 compat, then use the retrotranslator- 
maven-

plugin's translate-project goal to make jdk14 artifacts?

--jason


On Mar 20, 2007, at 5:14 AM, David Jencks wrote:

 geronimo-naming jar

 I think you'll find you need to update xbean-naming.

 thanks
 david jencks
 On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

 The server/trunk build is picking this up in configs/rmi- 
naming...

 but from where?

 Need to update this to use java.util.concurrent... its using
 backport-concurrent-util at the moment.

 --jason






--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

xbean-log4j

The current trunk has this module, but there is no src tree for it...  
is this missing code or should the module config be removed?


--jason

Errors in xbean-finder...

I commented out the xbean-log4j module and ran a build, its choking  
on some errors in xbean-finder:


snip
---
T E S T S
---
Running org.apache.xbean.finder.ClassFinderTest
Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed:  
80.558 sec  FAILURE!

Running org.apache.xbean.finder.ResourceFinderTest
Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:  
0.156 sec


Results :

Tests in error:
  testFindAnnotatedPackages(org.apache.xbean.finder.ClassFinderTest)
  testFindAnnotatedClasses(org.apache.xbean.finder.ClassFinderTest)
  testFindAnnotatedMethods(org.apache.xbean.finder.ClassFinderTest)
  testFindAnnotatedConstructors 
(org.apache.xbean.finder.ClassFinderTest)

  testFindAnnotatedFields(org.apache.xbean.finder.ClassFinderTest)
  testClassListConstructor(org.apache.xbean.finder.ClassFinderTest)

Tests run: 28, Failures: 0, Errors: 6, Skipped: 0
/snip

All of these are dying because of:

snip
 
---

Test set: org.apache.xbean.finder.ClassFinderTest
 
---
Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed:  
80.557 sec  FAILURE!
testFindAnnotatedPackages(org.apache.xbean.finder.ClassFinderTest)   
Time elapsed: 14.046 sec   ERROR!

java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space

testFindAnnotatedClasses(org.apache.xbean.finder.ClassFinderTest)   
Time elapsed: 13.205 sec   ERROR!

java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space

testFindAnnotatedMethods(org.apache.xbean.finder.ClassFinderTest)   
Time elapsed: 12.802 sec   ERROR!

java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space

testFindAnnotatedConstructors 
(org.apache.xbean.finder.ClassFinderTest)  Time elapsed: 13.557 sec   
 ERROR!

java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space

testFindAnnotatedFields(org.apache.xbean.finder.ClassFinderTest)   
Time elapsed: 13.453 sec   ERROR!

java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space

testClassListConstructor(org.apache.xbean.finder.ClassFinderTest)   
Time elapsed: 13.413 sec   ERROR!

java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
/snip

I'm currently using these options for mvn:

MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=128m

Does xbean need more than half a gig of heap to build?

--jason

[jira] Created: (XBEAN-85) Make xbean require Java 1.5, remove backport-util-concurrent

2007-03-21 Thread Jason Dillon (JIRA)

Make xbean require Java 1.5, remove backport-util-concurrent


 Key: XBEAN-85
 URL: https://issues.apache.org/jira/browse/XBEAN-85
 Project: XBean
  Issue Type: Improvement
Affects Versions: 3.0
Reporter: Jason Dillon
 Assigned To: Jason Dillon




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (XBEAN-85) Make xbean require Java 1.5, remove backport-util-concurrent

2007-03-21 Thread Jason Dillon (JIRA)


 [ 
https://issues.apache.org/jira/browse/XBEAN-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated XBEAN-85:
--

Attachment: XBEAN-85.diff

Attached patch:

Makes the build use Java 1.5 by default.

Removes usage of backport-util-concurrent.  No code changes required (short of 
import updates).

Tidy up some java 1.5 related bits in the poms.

Comments the xbean-log4j module which is missing (perhaps this should just be 
removed).

Makes xbean-finder skip tests for the moment, cause it fails with OOME.

Adds legal muck to xbean-tiger.

Adds version property for modules to reference, and uses the projects version 
of the maven-xbean-plugin (the one we are building).

 * * *

There are some other build related changes which should eventually be made to 
clean things up, but I tried to leave them alone for this patch/review.

 Make xbean require Java 1.5, remove backport-util-concurrent
 

 Key: XBEAN-85
 URL: https://issues.apache.org/jira/browse/XBEAN-85
 Project: XBean
  Issue Type: Improvement
Affects Versions: 3.0
Reporter: Jason Dillon
 Assigned To: Jason Dillon
 Attachments: XBEAN-85.diff




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: XBean and Java 1.5 (was Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean)


Patch here for review:

http://issues.apache.org/jira/browse/XBEAN-85

This does not include retrotranslator stuff... though if we wanted to  
add that it would consist of adding this to top-level pom in project/ 
build/plugins:


8
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdretrotranslator-maven-plugin/artifactId
executions
execution
goals
goaltranslate-project/goal
/goals
configuration
classifierjdk14/classifier
attachtrue/attach
/configuration
/execution
/executions
/plugin
8

Lemme know if you guys are cool with this, and I will apply it...  
though I'd like to know why the xbean-finder tests are throwing OOME  
too... as well as why xbean-log4j was included in modules, but  
missing in src.


Cheers,

--jason


On Mar 21, 2007, at 1:30 AM, James Strachan wrote:


+1

On 3/21/07, Guillaume Nodet [EMAIL PROTECTED] wrote:

+1

On 3/21/07, Jason Dillon [EMAIL PROTECTED] wrote:

 Looks like xbean-naming is still compiling for 1.4.  Is there any
 specific reason for this?  Can we switch all of xbean to compile  
for
 1.5... and if you need 1.4 compat, then use the retrotranslator- 
maven-

 plugin's translate-project goal to make jdk14 artifacts?

 --jason


 On Mar 20, 2007, at 5:14 AM, David Jencks wrote:

  geronimo-naming jar
 
  I think you'll find you need to update xbean-naming.
 
  thanks
  david jencks
  On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:
 
  The server/trunk build is picking this up in configs/rmi- 
naming...

  but from where?
 
  Need to update this to use java.util.concurrent... its using
  backport-concurrent-util at the moment.
 
  --jason
 




--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/




--

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

XBEAN Jira project and wiki-style fields

I just noticed that the XBEAN Jira project isn't setup to use wiki- 
style rendering for content fields.  I'm going to enable this...  
unless someone objects?


--jason

Re: What javamail stuff is needed for G 1.2?


Sweet, one down... 2 to go... :-)

--jason


On Mar 21, 2007, at 2:25 AM, Rick McGuire wrote:


Jason Dillon wrote:
Did you ever get this resolved?  I don't recall seeing any  
javamail changes to 1.2 recently... is this still pending?
It's all done.  It only required a dependency change, updated by  
this Jira


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

Rick



--jason


On Mar 16, 2007, at 3:36 AM, Rick McGuire wrote:

And dblevins still has not deployed the new javamail spec jar as  
he promised he'd do on Wednesday.  I'll see if I can take care of  
that too when I figure out how to do the provider jar.


Rick

Jason Dillon wrote:

Rick this is mainly aimed at you...

What javamail stuff is needed for G 1.2?

Can we get that wrapped up in the next week?

--jason

Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean

Minor, but related... this stuff should probably be in  
org.apache.geronimo.naming.gjndi to be consistent with the general  
module to package structure.


--jason


On Mar 20, 2007, at 5:14 AM, David Jencks wrote:


geronimo-naming jar

I think you'll find you need to update xbean-naming.

thanks
david jencks
On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

The server/trunk build is picking this up in configs/rmi-naming...  
but from where?


Need to update this to use java.util.concurrent... its using  
backport-concurrent-util at the moment.


--jason

[jira] Updated: (GERONIMO-3002) Error processing @WebServiceRefs annotation

2007-03-21 Thread Tim McConnell (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim McConnell updated GERONIMO-3002:


Attachment: GERONIMO-3002.patch

Problem duplicated and resolved using a modified testcase (GreeterImpl.java) 
from the webservices-testsuite. The patch simply enforces the specification 
that Class-level annotations for @WebServiceRef (and @HandlerChain) annotations 
cannot specify injection target(s). 

 Error processing @WebServiceRefs annotation
 ---

 Key: GERONIMO-3002
 URL: https://issues.apache.org/jira/browse/GERONIMO-3002
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Reporter: Jarek Gawor
 Assigned To: Tim McConnell
 Attachments: GERONIMO-3002.patch


 I'm getting the following exception when @WebServiceRefs(..) annotation is 
 specified at class level:
 Caused by: java.lang.IllegalArgumentException: You must supply exactly one of 
 Me
 thod, Field
 at 
 org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelper.getIn
 jectionJavaType(AnnotationHelper.java:46)
 at 
 org.apache.geronimo.j2ee.deployment.annotation.WebServiceRefAnnotatio
 nHelper.addWebServiceRef(WebServiceRefAnnotationHelper.java:249)
 at 
 org.apache.geronimo.j2ee.deployment.annotation.WebServiceRefAnnotatio
 nHelper.processWebServiceRefs(WebServiceRefAnnotationHelper.java:159)
 at 
 org.apache.geronimo.j2ee.deployment.annotation.WebServiceRefAnnotatio
 nHelper.processAnnotations(WebServiceRefAnnotationHelper.java:85)
 My understanding is that for the *s annotations the deployment descriptor is 
 updated however the values are not injected at runtime. Therefore, the 
 injectionTarget element in xml should not be generated for such annotations.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SM-892) ManagementContext.shutdown() calls wrong method to unregister MBeans

2007-03-21 Thread David Potter (JIRA)

ManagementContext.shutdown() calls wrong method to unregister MBeans


 Key: SM-892
 URL: https://issues.apache.org/activemq/browse/SM-892
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-core
Affects Versions: 3.1
 Environment: All
Reporter: David Potter
Priority: Minor


The problem code is:
Object[] beans = beanMap.keySet().toArray();
for (int i = 0; i  beans.length; i++) {
try {
unregisterMBean(beans[i]);
} catch (Exception e) {
log.debug(Could not unregister mbean, e);
}
}

The object[] will contain the keys - these is an array of ObjectName but they 
are typed as Object

There are two unregisterMBean methods unregisterMBean(Object bean) and 
unregisterMBean(ObjectName name).

The code will now call unregisterMBean(Object bean) when we want it to call 
unregisterMBean(ObjectName name). this will result in no beans being 
unregisters from this method.

The fix is, I think, to cast bean[i] to an ObjectName in the method call. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMODEVTOOLS-137) Deployment plan editor does not display

2007-03-21 Thread Ivan Biddles (JIRA)

Deployment plan editor does not display
---

 Key: GERONIMODEVTOOLS-137
 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-137
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
 Environment: Eclipse 3.2.2 with JDK 1.6.0 or JDK 1.5.0_11.running 
Windows XP SP2.
Plugin is the March 14th 2007 version.
Reporter: Ivan Biddles


I am running the 14-March daily build of the Geronimo Eclipse plug-in.

I am unable to open the Geronimo Deployment Plan Editor.

I have included the messages I get from the Eclipse startup as they may be 
relevant.

This happens whether I run Eclipse 3.2.2 with JDK 1.6.0 or with JDK 1.5.0_11.
I am running Windows XP SP2.

=
JDK 1.6.0
=

!SESSION 2007-03-21 10:42:27.562 ---
eclipse.buildId=M20070212-1330
java.version=1.6.0
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments:  -os win32 -ws win32 -arch x86 -clean -debug

!ENTRY org.eclipse.emf.ecore 2 0 2007-03-21 10:42:38.359
!MESSAGE Both 'org.apache.geronimo.deployment.model' and 
'org.apache.geronimo.v11.deployment.model' register an extension parser for 
'deployment'

!ENTRY org.eclipse.emf.ecore 2 0 2007-03-21 10:42:38.359
!MESSAGE Both 'org.apache.geronimo.deployment.model' and 
'org.apache.geronimo.v11.deployment.model' register an extension parser for 
'naming'

!ENTRY org.eclipse.emf.ecore 2 0 2007-03-21 10:42:38.359
!MESSAGE Both 'org.apache.geronimo.deployment.model' and 
'org.apache.geronimo.v11.deployment.model' register an extension parser for 
'web'


JDK 1.5.0_11


!SESSION 2007-03-21 10:46:15.625 ---
eclipse.buildId=M20070212-1330
java.version=1.5.0_11
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments:  -os win32 -ws win32 -arch x86 -clean -debug

!ENTRY org.eclipse.emf.ecore 2 0 2007-03-21 10:46:22.421
!MESSAGE Both 'org.apache.geronimo.deployment.model' and 
'org.apache.geronimo.v11.deployment.model' register an extension parser for 
'deployment'

!ENTRY org.eclipse.emf.ecore 2 0 2007-03-21 10:46:22.421
!MESSAGE Both 'org.apache.geronimo.deployment.model' and 
'org.apache.geronimo.v11.deployment.model' register an extension parser for 
'naming'

!ENTRY org.eclipse.emf.ecore 2 0 2007-03-21 10:46:22.421
!MESSAGE Both 'org.apache.geronimo.deployment.model' and 
'org.apache.geronimo.v11.deployment.model' register an extension parser for 
'web'

===
When I try to open the Geronimo Deployment Plan Editor, I get:
===

!ENTRY org.eclipse.jface 4 2 2007-03-21 10:50:02.187
!MESSAGE Problems occurred when invoking code from plug-in: org.eclipse.jface.
!STACK 0
java.lang.NoClassDefFoundError: org/eclipse/core/resources/IFile
at 
org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.getLoader(SharedDeploymentPlanEditor.java:94)
at 
org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.loadDeploymentPlan(SharedDeploymentPlanEditor.java:86)
at 
org.apache.geronimo.st.ui.editors.AbstractGeronimoDeploymentPlanEditor.init(AbstractGeronimoDeploymentPlanEditor.java:181)
at 
org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:842)
at 
org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:583)
at 
org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:372)
at 
org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:566)
at 
org.eclipse.ui.internal.EditorReference.getEditor(EditorReference.java:214)
at 
org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2595)
at 
org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2528)
at 
org.eclipse.ui.internal.WorkbenchPage.access$10(WorkbenchPage.java:2520)
at org.eclipse.ui.internal.WorkbenchPage$9.run(WorkbenchPage.java:2505)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
at 
org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2500)
at 
org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2485)
at org.eclipse.ui.ide.IDE.openEditor(IDE.java:388)
at org.eclipse.ui.ide.IDE.openEditor(IDE.java:350)
at 
org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:275)
at 
org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:139)
at 
org.eclipse.jdt.internal.ui.actions.OpenActionUtil.open(OpenActionUtil.java:49)
at

RE: Websphere 6.1 and MBean registration issue

2007-03-21 Thread David Potter

I have been looking at the code and have a possible solution.

Assumptions
- All mBean registration and unregistration is done via the
ManagementContext class.

Fix
- When we register a bean we create a wrapper object to hold the bean (as
is done now) and the 'real name'and this is placed in the beanmap
ObjectInstance registeredBean =
mbeanServerContext.getMBeanServer().registerMBean(mbean, name);
beanMap.put(name, new
RegesteredBean(registeredBean.getObjectName(), resource));

- We adjust the unregister/shutdown methods to the the ObjectName from the
RegesteredBean object.
RegesteredBean rb = (RegesteredBean)beanMap.get(objName);
ComponentMBeanImpl mbean = (ComponentMBeanImpl) rb.bean;

- We remove the method unregisterMBean from MBeanServerContext [this is to
enforce the assumption]

This should not break any existing code.

Any comments?

I am not sure is the listener approach will work. For example
ComponentMBeanImpl
Has 2 mBean name stored and it unregister them in the method
unregisterMbeans(). I am not sure if these fields would be updated by a
listener.
(Have I missed something here - I am still a relative newbe with mBeans)

David

yhofri wrote:

...
In terms of logics, Mbean Registration shouldn't fall into the Mbean
flow itself, as with registering endpoints, it should be called from the
AsyncBaseLifecycle...

-Original Message-
From: Grant M [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 17, 2007 3:56 AM
To: [EMAIL PROTECTED]
Cc: servicemix-dev@geronimo.apache.org
Subject: Fwd: Websphere 6.1 and MBean registration issue

Hey David,

I was wondering if you already had a workable solution for the MBean
registration issue? I was thinking instead of putting the code in the
AsyncBaseLifecycle it should instead go in the base MBean code. I'll
raise a JIRA issue and we can continue discussion of it.

Grant

-- Forwarded message --
From: Guillaume Nodet [EMAIL PROTECTED]
Date: Mar 17, 2007 9:40 AM
Subject: Re: Websphere 6.1 and MBean registration issue
To: servicemix-dev@geronimo.apache.org

On 3/16/07, Grant M [EMAIL PROTECTED] wrote:

Hi,

I've been out of touch for a while with swapping to a new job and all
and I was wondering whether David Potter had forwarded a solution to
the MBean registration issue in Websphere? If not I'd like to open the

floor to discussions on a possible fix.

I don't think so, but you should ping him and cc this list to see if he
has worked on it already.

I think the possible use of querynames could be fraught with issues
especially in clustered environments. Would it be possible to change
the base MBean itself so that upon registration it updated the
objectName? That way changes would be propagated correctly? I
noticed in the code there is references to property change listeners
and was wondering whether this meant it was already implemented?

Yeah, it should be possible to retrieve the new value of the Objectname
and use it instead of the one ServiceMix generates. I think this is the
only change to make, but i may miss something: where do you want to
propagate the change ?
Anyway, property change listeners should generate jmx notifications,
provided that the setter call the needed method of course.

Cheers,

Grant M

--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

--
View this message in context:
http://www.nabble.com/Websphere-6.1-and-MBean-registration-issue-tf3417186s12049.html#a9604697
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

mvn -Dtest=false = mvn -Dmaven.test.skip=false

(I keep sending things meant for this list to [EMAIL PROTECTED] and  
things meant for [EMAIL PROTECTED] to that list, anyways...)


I just found out that -Dtest=false is the same as - 
Dmaven.test.skip=true... for those that don't like to type so much...  
FYI.


--jason

[STATUS] (geronimo) Wed Mar 21 23:46:22 2007

2007-03-21 Thread Geronimo Weekly Status

APACHE GERONIMO STATUS: -*-text-*-
Last modified at [$Date: 2007-02-22 13:03:58 -0500 (Thu, 22 Feb 2007) $]

The current version of this file can be found at:

  * http://svn.apache.org/repos/asf/geronimo/server/trunk/STATUS


Upcoming Releases:

  Geronimo 1.2 -- geronimo/server/trunk/
Release Manager: Dain Sundstrom and Alan Cabrera
Estimated Date: Q4 2006



RELEASE SHOWSTOPPERS:

The release is stalled waiting for final releases from dependent
projects.  Specifically, we need releases from:

  Yoko 1.0 - Contains many fixes to CORBA interoperability
  ActiveMQ 4.1.1 - We need a release which contains AMQ-1165 and AMQ-1088
  OpenEJB 2.3 - Once Yoko is released, OpenEJB 2.3 can be release

RELEASE HISTORY:
  2006-12-16  Geronimo 1.2-beta
  2006-09-18  Geronimo 1.1.1
  2006-06-26  Geronimo 1.1
  2006-01-05  Geronimo 1.0
  2005-10-04  Geronimo 1.0 milestone 5
  2005-08-10  Geronimo 1.0 milestone 4
  2004-11-11  Geronimo 1.0 milestone 3
  2004-09-09  Geronimo 1.0 milestone 2
  2004-04-29  Geronimo 1.0 milestone 1


If you're a contributor looking for something to do:

  * Review the documentation and suggest improvements
  * Review the bug list and suggest fixes or report reproducibility
  * Report bugs yourself

Re: [STATUS] (geronimo) Wed Mar 21 23:46:22 2007