date:20060828


Thx !
The preferred way to handle patches is to raise a JIRA issue and attach your
patch.
This ensures they will not be lost ;)

On 8/28/06, lpfarris [EMAIL PROTECTED] wrote:



Posted this about a week ago to user's list, perhaps the wrong place,
posting
again here.
This patch modified org.apache.activemq.transport.tcp with a couple of
extra
classes, and modifications to SSLTransportFactory, to make it possible to
set needClientAuth and wantClientAuth on SSL server sockets. example
transport URI would be
ssl://localhost:61616?transport.socket.needClientAuth=true

http://www.nabble.com/user-files/235718/ssl_client_auth_patch.txt
ssl_client_auth_patch.txt
--
View this message in context:
http://www.nabble.com/patch%3A-set-needClientAuth-and-wantClientAuth-in-SSL-transport-tf2179880.html#a6028102
Sent from the ActiveMQ - Dev forum at Nabble.com.





--
Cheers,
Guillaume Nodet

Re: How to send XML based message in AMQ?

2006-08-28 Thread srodrigues


I always convert xml to string before sending such a message. 

HTH, 

SR. 


Wang Kevin wrote:
 
 Hi, Gents,
 
 I am trying to send XML based message using ActiveMQ, but as I know, I
 can't
 find a related method like *createXMLMessage()*. So I think a way is to
 use
 TextMessage: firstly, convert xml to string, then send it by TextMessage.
 
 Any ideas or example? Thanks a lot!
 
 Best Regard!
 
 Kevin
 
 

-- 
View this message in context: 
http://www.nabble.com/How-to-send-XML-based-message-in-AMQ--tf2175605.html#a6029191
Sent from the ActiveMQ - Dev forum at Nabble.com.

Re: [jira] Created: (AMQ-899) mvn test fails with com.thoughtworks.qdox.parser.ParseException: syntax error @[90,25] in file:.../activemq-core/src/main/java/org/apache/activemq/network/jms/JmsConnect

2006-08-28 Thread Sepand M


Based on your other post (and my results), it doesn't seem to be working.
I've read somewhere that qdox has problems with java 1.5 syntax, but
we're not even using 1.5 right?
Any other ideas?
Where can I get more info on qdox and how its tied into the xbean system?
Is there any other way I could help? I'm a little stuck.

On 8/28/06, Fateev, Maxim [EMAIL PROTECTED] wrote:

The following helped me to fix my local build:

[EMAIL PROTECTED]:/workplace/fateev/activemq-head/trunk svn diff
Index: pom.xml
===
--- pom.xml (revision 437779)
+++ pom.xml (working copy)
@@ -495,17 +495,20 @@
 dependency
 groupIdxmlbeans/groupId
 artifactIdxbean/artifactId
-version${xmlbeans-version}/version
+!--version${xmlbeans-version}/version--
+version2.0.0-beta1/version
 /dependency
 dependency
 groupIdxmlbeans/groupId
 artifactIdxmlpublic/artifactId
-version${xmlbeans-version}/version
+version2.0.0-beta1/version
+!--version${xmlbeans-version}/version--
 /dependency
 dependency
 groupIdxmlbeans/groupId
 artifactIdxbean_xpath/artifactId
-version${xmlbeans-version}/version
+version2.0.0-beta1/version
+!--version${xmlbeans-version}/version--
 /dependency

 !-- For Stax --
[EMAIL PROTECTED]:/workplace/fateev/activemq-head/trunk


-Original Message-
From: Sepand M [mailto:[EMAIL PROTECTED]
Sent: Monday, August 28, 2006 12:22 PM
To: activemq-dev@geronimo.apache.org
Subject: Re: [jira] Created: (AMQ-899) mvn test fails with 
com.thoughtworks.qdox.parser.ParseException: syntax error @[90,25] in 
file:.../activemq-core/src/main/java/org/apache/activemq/network/jms/JmsConnector.java

I'm getting the same thing on a clean checkout (as well as every other checkout 
I have).
Anyone know what's going on?

On 8/28/06, Maxim Fateev (JIRA) [EMAIL PROTECTED] wrote:
 mvn test fails with com.thoughtworks.qdox.parser.ParseException:
 syntax error @[90,25] in
 file:.../activemq-core/src/main/java/org/apache/activemq/network/jms/J
 msConnector.java
 --
 --
 -

  Key: AMQ-899
  URL: https://issues.apache.org/activemq/browse/AMQ-899
  Project: ActiveMQ
   Issue Type: Bug
   Components: Broker
 Affects Versions: 4.x
  Environment: Linux (RHEL3) and Windows XP
 Reporter: Maxim Fateev


 svn co https://svn.apache.org/repos/asf/incubator/activemq/trunk
 
 Atrunk/README.txt
  U   trunk
 Checked out revision 437779.
 [EMAIL PROTECTED]:/workplace/fateev/activemq-head ls trunk/
 [EMAIL PROTECTED]:/workplace/fateev/activemq-head cd trunk/activemq-core
 [EMAIL PROTECTED]:/workplace/fateev/activemq-head/trunk/activemq-core mvn
 test [INFO] Scanning for projects...
 [INFO]
 --
 --
 [INFO] Building ActiveMQ :: Core
 [INFO]task-segment: [test]
 [INFO]
 --
 -- [INFO] artifact
 org.apache.maven.plugins:maven-resources-plugin: checking for updates
 from apache-snapshots [INFO] snapshot
 org.apache.maven.plugins:maven-resources-plugin:2.3-SNAPSHOT: checking for 
updates from apache-snapshots ...
 ...
 ...
 Downloading:
 http://people.apache.org/maven-snapshot-repository/org/apache/activemq
 /maven-gram-plugin/4.1-incubator-SNAPSHOT/maven-gram-plugin-4.1-incuba
 tor-20060803.174437-6.jar
 6K downloaded
 [WARNING] While downloading javacc:javacc:3.2
   This artifact has been relocated to net.java.dev.javacc:javacc:3.2.


 [INFO] [javacc:javacc {execution: default}] Java Compiler Compiler
 Version 3.2 (Parser Generator) (type javacc with no arguments for
 help) Reading from file
 
/workplace/fateev/activemq-head/trunk/activemq-core/src/main/grammar/SelectorParser.jj
 . . .
 Note: UNICODE_INPUT option is specified. Please make sure you create the 
parser/lexer usig a Reader with the correct character encoding.
 File TokenMgrError.java does not exist.  Will create one.
 File ParseException.java does not exist.  Will create one.
 File Token.java does not exist.  Will create one.
 File SimpleCharStream.java does not exist.  Will create one.
 Parser generated successfully.
 Downloading:
 http://people.apache.org/maven-snapshot-repository/qdox/qdox/1.6/qdox-
 1.6.pom [WARNING] Unable to get resource from repository
 apache-snapshots (http://people.apache.org/maven-snapshot-repository)
 Downloading: http://repository.codehaus.org/qdox/qdox/1.6/qdox-1.6.pom
 [WARNING] Unable to

Re: patch: set needClientAuth and wantClientAuth in SSL transport

2006-08-28 Thread lpfarris


Thanks. I should have read the Contributing more thoroughly.

gnodet wrote:
 
 Thx !
 The preferred way to handle patches is to raise a JIRA issue and attach
 your
 patch.
 This ensures they will not be lost ;)
 
 On 8/28/06, lpfarris [EMAIL PROTECTED] wrote:


 Posted this about a week ago to user's list, perhaps the wrong place,
 posting
 again here.
 This patch modified org.apache.activemq.transport.tcp with a couple of
 extra
 classes, and modifications to SSLTransportFactory, to make it possible to
 set needClientAuth and wantClientAuth on SSL server sockets. example
 transport URI would be
 ssl://localhost:61616?transport.socket.needClientAuth=true

 http://www.nabble.com/user-files/235718/ssl_client_auth_patch.txt
 ssl_client_auth_patch.txt
 --
 View this message in context:
 http://www.nabble.com/patch%3A-set-needClientAuth-and-wantClientAuth-in-SSL-transport-tf2179880.html#a6028102
 Sent from the ActiveMQ - Dev forum at Nabble.com.


 
 
 -- 
 Cheers,
 Guillaume Nodet
 
 

-- 
View this message in context: 
http://www.nabble.com/patch%3A-set-needClientAuth-and-wantClientAuth-in-SSL-transport-tf2179880.html#a6029319
Sent from the ActiveMQ - Dev forum at Nabble.com.

Re: Issues found when load tested servicemix


30 is the default size of ServiceMix thread pool.
So it means a component does not correctly implement the MEP used.

From your explanations, it should be the jms out binding.

What's the configuration you used for #4 ?
Also, you should try to upgrade to 3.0-M2, it will certainly fix the
problem.

On 8/28/06, Ujval Mysore [EMAIL PROTECTED] wrote:



Hi,



Right now I am evaluating servicemix 2.0.2. As part of other
requirements I have deployed servicemix2.0.2 on Weblogic 8.1. I have
load tested servicemix in various scenarios and I was confused to see
the results.



I have load tested all the following scenarios using load runner. I ran
the load tests for 5 minutes with 15 simultaneous virtual users, each
vuser resending the request once it gets back the response for its
previous request and with a very small payload of 10KB per request.



Various scenarios include orchestrating the binding components JMS,
router and WSIF in the following ways:



1)   JMSInBinding -- JMSOutBinding:

The client sends the request to servicemix. The JMSInBinding which is
listening to a queue reads the message and sends the normalized message
to the JMSOutBinding which simply creates a jms message and puts it in
another queue.

This worked fine without any problem.



2)   JMSInBinding -- WSIF:

The JMSInBinding sends the message to the WSIF binding component. This
scenario also worked fine.



3)   JMSInBinding -- WSIF -- WSIF

  Adding to the previous scenario, the destination service of the
WSIF will be one more WSIF. This scenario also worked fine.



4)   JMSInBinding -- WSIF -- JMSOutBinding

This scenario failed miserably. It hardly processes 30
requests and then hangs. I have debugged the servicemix code and found
that for the 30 successful requests, all the three components executed
successfully. For the failed transactions, the flow stops at the
JMSInBinding. It seems a deadlock is occurring somewhere.



On further debugging I found that the method doSend(MessageExchangeImpl)
in the SedaFlow.java is also getting executed. When the request flows
from JMSInBinding to the WSIF, the values me.getSyncState() and
me.getMirror().getSyncState() are '0'. Hence enqueue(packet) is being
called. After the execution of WSIF before going to JMSOutBinding, I
found the values to be me.getSyncState() =0 and
me.getMirror().getSyncState() = 1. Hence doRouting is getting called.

This is getting executed perfectly for around first 30 requests. Later,
all the requests are getting stuck in the first flow i.e. JMSInBinding
-- WSIF. The WSIF is also not getting executed.



I also found out that queue.poll method in run() of SedaQueue.java is
working properly, as it is getting the message exchange without any
problem.



I think there is a deadlock occurring somewhere here.



5)   JMSInBinding -- Router -- JMSOutBinding

I was surprised to note that this scenario works without any problem.



6)   JMSInBinding -- Router -- WSIF

This scenario too worked fine.



7)   JMSInBinding -- Router -- WSIF -- JMSOutBinding

This scenario also failed. The results were similar to the point 4.



Is it a problem with servicemix? Kindly look into this and please let me
know at the earliest.



Is there any mechanism to trace the flow of the message in servicemix?



Thanks in advance,

Ujval Mysore





 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
solely for the use of the addressee(s). If you are not the intended
recipient, please notify the sender by e-mail and delete the original
message. Further, you are not to copy, disclose, or distribute this e-mail
or its contents to any other person and any such actions are unlawful. This
e-mail may contain viruses. Infosys has taken every reasonable precaution to
minimize this risk, but is not liable for any damage you may sustain as a
result of any virus in this e-mail. You should carry out your own virus
checks before opening the e-mail or attachment. Infosys reserves the right
to monitor and review the content of all messages sent to or from this
e-mail address. Messages sent to or from this e-mail address may be stored
on the Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***





--
Cheers,
Guillaume Nodet

User Guide


I have duplicate the confluence servicemix site to
 http://goopen.org/confluence/display/SM30UG/Home

I will try to refactor it to provide a better User Guide.

The reason why I duplicated the space, is to be able to
keep one space targetted to a single ServiceMix version,
else it' s difficult to put informations related to all the
versions in the same page.

I have began to write a summary for the UG at
http://goopen.org/confluence/display/SM30UG/Users+Guide
and I plan to work on it for the next weeks, as time permits.
I will first refactor some existing pages in this user guide, and
will reorganize them and fill the holes.

The plan is then to link from the web site to this space
and new ones as versions come.

Comments, thoughts or improvements are welcome.

--
Cheers,
Guillaume Nodet

[jira] Resolved: (SM-561) Error while building assembly.

2006-08-28 Thread Fritz Oconer (JIRA)

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

Fritz Oconer resolved SM-561.
-

Resolution: Fixed

Included ${basedir} on the files path of the assembly descriptor. This is 
because the files path is relative to the parent instead on the executing 
module. 

 Error while building assembly.
 --

 Key: SM-561
 URL: https://issues.apache.org/activemq/browse/SM-561
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-assembly
Reporter: Fritz Oconer
 Assigned To: Fritz Oconer
Priority: Blocker
 Fix For: 3.0


 [WARNING] Unable to get resource from repository codehaus-snapshot-repo 
 (http://
 snapshots.repository.codehaus.org)
 [INFO] [assembly:attached {execution: bin}]
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Error adding file to archive: 
 D:\logicblaze\working-source\servicemix\tar
 get\sas\bridge-sa-3.0-incubating-SNAPSHOT.zip isn't a file.
 [INFO] 
 
 [INFO] For more information, run Maven with the -e switch
 [INFO] 
 
 [INFO] Total time: 48 seconds
 [INFO] Finished at: Tue Aug 29 12:15:10 SGT 2006
 [INFO] Final Memory: 15M/508M
 [INFO] 
 

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

Re: [VOTE] Publish Genesis 1.0 to m2 central


[X] Publish Genesis 1.0 to m2 central


Jacek

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

Re: Change redirects/* to .htaccess RewriteRules


On 8/28/06, Jason Dillon [EMAIL PROTECTED] wrote:

Any objection to changing the meta http-equiv=refresh pages for
redirects/* to use .htaccess RewriteRules?


+1

Jacek

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

Re: Why ClockDaemon instead of java.util.Timer?

I think we should switch to backport-util-concurrent instead of concurrent.This will allow for easier switch to full JDK 5 later (and this is the library usedby retrotranslator, btw).
On 8/28/06, Jason Dillon [EMAIL PROTECTED] wrote:
Does not look like ClockDaemon is going to ever make it into java.util.concurrent (or the backport). I've also found several sources online that suggest that Doug Lea says that it replaces its ClockDaemon class., though I have not actually found anywhere that Doug actually says that.
It also looks like ClockDaemon was added way back before there was java.util.Timer in the JDK... and I'm guessing that since they did not bring it into 
java.util.concurrent that it is probably recommended to just use java.util.Timer.--jason
-- Cheers,Guillaume Nodet

Re: Why ClockDaemon instead of java.util.Timer?

Retrostranslator uses Timer?--jasonOn Aug 28, 2006, at 12:32 AM, Guillaume Nodet wrote:I think we should switch to backport-util-concurrent instead of concurrent.This will allow for easier switch to full JDK 5 later (and this is the library usedby retrotranslator, btw). On 8/28/06, Jason Dillon [EMAIL PROTECTED] wrote: Does not look like ClockDaemon is going to ever make it into java.util.concurrent (or the backport).  I've also found several sources online that suggest that "Doug Lea says that it replaces its ClockDaemon class.", though I have not actually found anywhere that Doug actually says that. It also looks like ClockDaemon was added way back before there was java.util.Timer in the JDK... and I'm guessing that since they did not bring it into java.util.concurrent that it is probably recommended to just use java.util.Timer.--jason -- Cheers,Guillaume Nodet

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

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

Guillaume Nodet commented on GERONIMO-2354:
---

Note that the activio lib released with AMQ 4 now uses backport-util-concurrent.

 Replace concurrent with backport-concurrent-util
 

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


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

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

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

2006-08-28 Thread Jason Dillon (JIRA)

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

Jason Dillon commented on GERONIMO-2354:


What version is that?  Is it released to central?

 Replace concurrent with backport-concurrent-util
 

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


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

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

Re: [VOTE] Publish Genesis 1.0 to m2 central

+1On 8/28/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
 [X] Publish Genesis 1.0 to m2 centralJacek--Jacek Laskowskihttp://www.laskowski.net.pl-- Cheers,
Guillaume Nodet

Re: Why ClockDaemon instead of java.util.Timer?

When weaving java.util.concurrent specific JDK 5 classes to JDK 1.4,retrotranslator changes calls to the standard packages to calls tothe backport-util-concurrent package.
On 8/28/06, Jason Dillon [EMAIL PROTECTED] wrote:
Retrostranslator uses Timer?--jasonOn Aug 28, 2006, at 12:32 AM, Guillaume Nodet wrote:
I think we should switch to backport-util-concurrent instead of concurrent.This will allow for easier switch to full JDK 5 later (and this is the library usedby retrotranslator, btw).
 On 8/28/06, Jason Dillon [EMAIL PROTECTED]
 wrote: Does not look like ClockDaemon is going to ever make it into 
java.util.concurrent (or the backport). I've also found several sources online that suggest that Doug Lea says that it replaces its ClockDaemon class., though I have not actually found anywhere that Doug actually says that. 
It also looks like ClockDaemon was added way back before there was java.util.Timer in the JDK... and I'm guessing that since they did not bring it into 
java.util.concurrent that it is probably recommended to just use java.util.Timer.--jason 
-- Cheers,Guillaume Nodet
-- Cheers,Guillaume Nodet

Re: Why ClockDaemon instead of java.util.Timer?

Ya, I know that :-PBut what does that have to do with ClockDaemon and Timer?--jasonOn Aug 28, 2006, at 12:45 AM, Guillaume Nodet wrote:When weaving java.util.concurrent specific JDK 5 classes to JDK 1.4,retrotranslator changes calls to the standard packages to calls tothe backport-util-concurrent package. On 8/28/06, Jason Dillon [EMAIL PROTECTED] wrote: Retrostranslator uses Timer?--jasonOn Aug 28, 2006, at 12:32 AM, Guillaume Nodet wrote: I think we should switch to backport-util-concurrent instead of concurrent.This will allow for easier switch to full JDK 5 later (and this is the library usedby retrotranslator, btw).  On 8/28/06, Jason Dillon [EMAIL PROTECTED]  wrote: Does not look like ClockDaemon is going to ever make it into java.util.concurrent (or the backport).  I've also found several sources online that suggest that "Doug Lea says that it replaces its ClockDaemon class.", though I have not actually found anywhere that Doug actually says that. It also looks like ClockDaemon was added way back before there was java.util.Timer in the JDK... and I'm guessing that since they did not bring it into java.util.concurrent that it is probably recommended to just use java.util.Timer.--jason  -- Cheers,Guillaume Nodet -- Cheers,Guillaume Nodet

Re: Why ClockDaemon instead of java.util.Timer?

If we switch to backport-util-concurrent, the ClockDaemon references will have to be removed. What I meant is that the ClockDaemon vs Timer problem is superseeded by the concurrent vs backport-util-concurrent problem.
I brought retrotranslator in as an argument for the switch to backport, nothing more.Sorry if it was not clear.On 8/28/06, Jason Dillon 
[EMAIL PROTECTED] wrote:Ya, I know that :-P
But what does that have to do with ClockDaemon and Timer?--jason
On Aug 28, 2006, at 12:45 AM, Guillaume Nodet wrote:When weaving java.util.concurrent specific JDK 5 classes to JDK 1.4,retrotranslator changes calls to the standard packages to calls to
the backport-util-concurrent package. On 8/28/06, Jason Dillon 
[EMAIL PROTECTED] wrote: Retrostranslator uses Timer?
--jasonOn Aug 28, 2006, at 12:32 AM, Guillaume Nodet wrote: I think we should switch to backport-util-concurrent instead of concurrent.
This will allow for easier switch to full JDK 5 later (and this is the library usedby retrotranslator, btw).  On 8/28/06, Jason Dillon 
[EMAIL PROTECTED]  wrote: Does not look like ClockDaemon is going to ever make it into 
java.util.concurrent (or the backport). I've also found several sources online that suggest that Doug Lea says that it replaces its ClockDaemon class., though I have not actually found anywhere that Doug actually says that. 
It also looks like ClockDaemon was added way back before there was java.util.Timer in the JDK... and I'm guessing that since they did not bring it into 
java.util.concurrent that it is probably recommended to just use java.util.Timer.--jason 
 -- Cheers,Guillaume Nodet -- Cheers,Guillaume Nodet

-- Cheers,Guillaume Nodet

Re: Why ClockDaemon instead of java.util.Timer?

I understand now, thx :-)BTW, looks like the port from ClockDaemon to Timer is very simple.  The patch for server/trunk in GERONIMO-2354 does just that to avoid needing ClockDaemon.--jasonOn Aug 28, 2006, at 12:56 AM, Guillaume Nodet wrote:If we switch to backport-util-concurrent, the ClockDaemon references will have to be removed.  What I meant is that the ClockDaemon vs Timer problem is superseeded by the  concurrent vs backport-util-concurrent problem. I brought retrotranslator in as an argument for the switch to backport, nothing more.Sorry if it was not clear.On 8/28/06, Jason Dillon  [EMAIL PROTECTED] wrote:Ya, I know that :-P But what does that have to do with ClockDaemon and Timer?--jason On Aug 28, 2006, at 12:45 AM, Guillaume Nodet wrote:When weaving java.util.concurrent specific JDK 5 classes to JDK 1.4,retrotranslator changes calls to the standard packages to calls to the backport-util-concurrent package. On 8/28/06, Jason Dillon  [EMAIL PROTECTED] wrote: Retrostranslator uses Timer? --jasonOn Aug 28, 2006, at 12:32 AM, Guillaume Nodet wrote: I think we should switch to backport-util-concurrent instead of concurrent. This will allow for easier switch to full JDK 5 later (and this is the library usedby retrotranslator, btw).  On 8/28/06, Jason Dillon  [EMAIL PROTECTED]  wrote: Does not look like ClockDaemon is going to ever make it into java.util.concurrent (or the backport).  I've also found several sources online that suggest that "Doug Lea says that it replaces its ClockDaemon class.", though I have not actually found anywhere that Doug actually says that. It also looks like ClockDaemon was added way back before there was java.util.Timer in the JDK... and I'm guessing that since they did not bring it into java.util.concurrent that it is probably recommended to just use java.util.Timer.--jason  -- Cheers,Guillaume Nodet -- Cheers,Guillaume Nodet  -- Cheers,Guillaume Nodet

Anyone know how to make the kernel tests be quiet?


These tests make way... way to much noise.

Anyone know how to make them shut up?

--jason

[VOTE] XBean 2.6 release

I have tagged the xbean-2.6 branch http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.6/and uploaded a version at 
http://people.apache.org/~gnodet/xbean-2.6/org/apache/xbean/Please vote.Here's my +1As soon as the vote is off, I will upload the release to the m2 repo at 
http://people.apache.org/repo/m2-ibiblio-rsync-repository/-- Cheers,Guillaume Nodet

Re: [VOTE] XBean 2.6 release

+1--jasonOn Aug 28, 2006, at 3:10 AM, Guillaume Nodet wrote:I have tagged the xbean-2.6 branch  http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.6/and uploaded a version at   http://people.apache.org/~gnodet/xbean-2.6/org/apache/xbean/Please vote.Here's my +1As soon as the vote is off, I will upload the release to the m2 repo at    http://people.apache.org/repo/m2-ibiblio-rsync-repository/-- Cheers,Guillaume Nodet

Re: [VOTE] XBean 2.6 release


On 8/28/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

I have tagged the xbean-2.6 branch

http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.6/

and uploaded a version at

http://people.apache.org/~gnodet/xbean-2.6/org/apache/xbean/


What does it need to be built? I'm getting the following error message:

[EMAIL PROTECTED] /cygdrive/c/oss/xbean-2.6
$ mvn clean install
[INFO] Scanning for projects...
Downloading: 
http://repo.mergere.com/maven2/org/apache/geronimo/genesis/config/project-config/1.0/project-config-1.0.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] Failed to resolve artifact.

GroupId: org.apache.geronimo.genesis.config
ArtifactId: project-config
Version: 1.0

Reason: Unable to download the artifact from any repository

 org.apache.geronimo.genesis.config:project-config:pom:1.0

from the specified remote repositories:
 central (http://repo1.maven.org/maven2),
 apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository)

Jacek

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

Re: [VOTE] XBean 2.6 release

Genesis is currently being voted in another thread.What I did is put the following in my settings.xml: profiles profile idapache-m2-repo/id repositories
 repository idapache-m2/id nameapache-m2/name urlhttp://people.apache.org/repo/m2-ibiblio-rsync-repository
/url /repository /repositories /profile /profiles activeProfiles activeProfileapache-m2-repo/activeProfile
 /activeProfilesOf, course, once genesis will be uploaded to ibiblio, such a thing will not be needed.On 8/28/06, Jacek Laskowski 
[EMAIL PROTECTED] wrote:On 8/28/06, Guillaume Nodet 
[EMAIL PROTECTED] wrote: I have tagged the xbean-2.6 branch http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.6/
 and uploaded a version at http://people.apache.org/~gnodet/xbean-2.6/org/apache/xbean/What does it need to be built? I'm getting the following error message:
[EMAIL PROTECTED] /cygdrive/c/oss/xbean-2.6$ mvn clean install[INFO] Scanning for projects...Downloading: 
http://repo.mergere.com/maven2/org/apache/geronimo/genesis/config/project-config/1.0/project-config-1.0.pom[WARNING] Unable to get resource from repository central(http://repo1.maven.org/maven2
)[INFO] [ERROR] FATAL ERROR[INFO] [INFO] Failed to resolve artifact.
GroupId: org.apache.geronimo.genesis.configArtifactId: project-configVersion: 1.0Reason: Unable to download the artifact from any repositoryorg.apache.geronimo.genesis.config:project-config:pom:1.0
from the specified remote repositories:central (http://repo1.maven.org/maven2),apache-snapshots (
http://people.apache.org/repo/m2-snapshot-repository)Jacek--Jacek Laskowskihttp://www.laskowski.net.pl-- 
Cheers,Guillaume Nodet

Re: [VOTE] XBean 2.6 release


On 8/28/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

Genesis is currently being voted in another thread.
What I did is put the following in my settings.xml:


It's helped. Thanks!

Going on with the build I run across another issue:

[INFO] [compiler:compile]
Compiling 44 source files to c:\oss\xbean-2.6\xbean-spring-common\target\classes
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

c:\oss\xbean-2.6\xbean-spring-common\src\main\java\org\apache\xbean\spring\generator\QdoxMappingLoader.java:[35,-1]
cannot access com.thoughtworks.qdox.JavaDocBuilder
bad class file: C:\Documents and
Settings\jlaskowski\.m2\repository\qdox\qdox\1.6\qdox-1.6.jar(com/thoughtworks/qdox/JavaDocBuilder.class)
class file has wrong version 49.0, should be 48.0

Am I reading it correctly that XBean 2.6 requires Java 5 to be built with?

Jacek

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

Re: [VOTE] XBean 2.6 release

Yes, right.But it can run on 1.4.On 8/28/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
On 8/28/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
 Genesis is currently being voted in another thread. What I did is put the following in my settings.xml:It's helped. Thanks!Going on with the build I run across another issue:[INFO] [compiler:compile]
Compiling 44 source files to c:\oss\xbean-2.6\xbean-spring-common\target\classes[INFO] [ERROR] BUILD FAILURE[INFO] 
[INFO] Compilation failurec:\oss\xbean-2.6\xbean-spring-common\src\main\java\org\apache\xbean\spring\generator\QdoxMappingLoader.java:[35,-1]cannot access com.thoughtworks.qdox.JavaDocBuilderbad class file: C:\Documents and
Settings\jlaskowski\.m2\repository\qdox\qdox\1.6\qdox-1.6.jar(com/thoughtworks/qdox/JavaDocBuilder.class)class file has wrong version 49.0, should be 48.0Am I reading it correctly that XBean 2.6 requires Java 5 to be built with?
Jacek--Jacek Laskowskihttp://www.laskowski.net.pl-- Cheers,Guillaume Nodet

Re: [VOTE] XBean 2.6 release


On 8/28/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

Yes, right.
But it can run on 1.4.


[EMAIL PROTECTED] /cygdrive/c/oss/xbean-2.6
$ mvn clean install
...
[INFO] 
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 8 minutes 48 seconds
[INFO] Finished at: Mon Aug 28 12:52:34 CEST 2006
[INFO] Final Memory: 17M/254M
[INFO] 

Thanks!

Jacek

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

Re: Test failure in javamail 1.3.1 spec

2006-08-28 Thread Rick McGuire

Grrr, I thought I finally had that test case working everywhere.  What 
platform are you running on?  I'm guessing you're using a non-US English 
locale? 


Rick

Jacek Laskowski wrote:

Hi,

Does anyone know how to get rid of it:

[EMAIL PROTECTED] /cygdrive/c/oss/geronimo-specs/trunk
$ less 
geronimo-javamail_1.3.1_spec/target/surefire-reports/javax.mail.internet.MimeUtilityTest.txt 

--- 


Test set: javax.mail.internet.MimeUtilityTest
--- 


Tests run: 4, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.344
sec  FAILURE!
testEncodeWord(javax.mail.internet.MimeUtilityTest)  Time elapsed: 0
sec   FAILURE!
junit.framework.ComparisonFailure: expected:...??... but was:...??...
   at junit.framework.Assert.assertEquals(Assert.java:81)
   at junit.framework.Assert.assertEquals(Assert.java:87)
   at 
javax.mail.internet.MimeUtilityTest.testEncodeWord(MimeUtilityTest.java:94) 



testEncodeText(javax.mail.internet.MimeUtilityTest)  Time elapsed: 0
sec   FAILURE!
junit.framework.ComparisonFailure: expected:...??... but was:...??...
   at junit.framework.Assert.assertEquals(Assert.java:81)
   at junit.framework.Assert.assertEquals(Assert.java:87)
   at 
javax.mail.internet.MimeUtilityTest.testEncodeText(MimeUtilityTest.java:111) 



It blows up the build. I'd prefer not to disable the tests, but find a
final solution or eventually disable the tests once they're described
appropriately.

Jacek

Re: Test failure in javamail 1.3.1 spec


On 8/28/06, Rick McGuire [EMAIL PROTECTED] wrote:

Grrr, I thought I finally had that test case working everywhere.  What
platform are you running on?


[EMAIL PROTECTED] /cygdrive/c/oss/geronimo-specs/trunk
$ uname -a
CYGWIN_NT-5.1 dev 1.5.20(0.156/4/2) 2006-07-01 02:22 i686 Cygwin

[EMAIL PROTECTED] /cygdrive/c/oss/geronimo-specs/trunk
$ cmd
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

c:\oss\geronimo-specs\trunkver

Microsoft Windows XP [Version 5.1.2600]

c:\oss\geronimo-specs\trunkjava -version
java version 1.4.2_11
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_11-b06)
Java HotSpot(TM) Client VM (build 1.4.2_11-b06, mixed mode)


I'm guessing you're using a non-US English locale?


Yes - pl (Polish)

Jacek

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

Re: [VOTE] XBean 2.6 release


On 8/28/06, Jacek Laskowski [EMAIL PROTECTED] wrote:


[INFO] BUILD SUCCESSFUL


Got the build finished properly, but am wondering what I should be
doing next. I can't find 'Getting started' or '2-minute introduction'
or 'How to become a XBean master' or alike on
http://geronimo.apache.org/xbean. Please lend me a helping hand...

Jacek

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

[jira] Created: (GERONIMO-2355) javamail MimeUtility tests will not work in all code pages.

2006-08-28 Thread Rick McGuire (JIRA)

javamail MimeUtility tests will not work in all code pages.
---

 Key: GERONIMO-2355
 URL: http://issues.apache.org/jira/browse/GERONIMO-2355
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: mail
Affects Versions: 1.2
Reporter: Rick McGuire
 Assigned To: Rick McGuire
 Fix For: 1.2


The MimeUtility test cases include some test for encodeText() and encodeWord() 
that use the default code page.  Unfortunately, this test will not function 
correctly on all default code pages because the test characters will not make 
the encoding round trip properly (unknown characters in the code page get 
mapped to a marker character).  These tests need to be disabled. 

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

[jira] Resolved: (GERONIMO-2355) javamail MimeUtility tests will not work in all code pages.

2006-08-28 Thread Rick McGuire (JIRA)

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

Rick McGuire resolved GERONIMO-2355.


Resolution: Fixed

Committed revision 437657.

The problematic tests have been commented out for now. 

 javamail MimeUtility tests will not work in all code pages.
 ---

 Key: GERONIMO-2355
 URL: http://issues.apache.org/jira/browse/GERONIMO-2355
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: mail
Affects Versions: 1.2
Reporter: Rick McGuire
 Assigned To: Rick McGuire
 Fix For: 1.2


 The MimeUtility test cases include some test for encodeText() and 
 encodeWord() that use the default code page.  Unfortunately, this test will 
 not function correctly on all default code pages because the test characters 
 will not make the encoding round trip properly (unknown characters in the 
 code page get mapped to a marker character).  These tests need to be 
 disabled. 

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

Re: Test failure in javamail 1.3.1 spec

2006-08-28 Thread Rick McGuire


Jacek Laskowski wrote:

On 8/28/06, Rick McGuire [EMAIL PROTECTED] wrote:

Grrr, I thought I finally had that test case working everywhere.  What
platform are you running on?


[EMAIL PROTECTED] /cygdrive/c/oss/geronimo-specs/trunk
$ uname -a
CYGWIN_NT-5.1 dev 1.5.20(0.156/4/2) 2006-07-01 02:22 i686 Cygwin

[EMAIL PROTECTED] /cygdrive/c/oss/geronimo-specs/trunk
$ cmd
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

c:\oss\geronimo-specs\trunkver

Microsoft Windows XP [Version 5.1.2600]

c:\oss\geronimo-specs\trunkjava -version
java version 1.4.2_11
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_11-b06)
Java HotSpot(TM) Client VM (build 1.4.2_11-b06, mixed mode)


I'm guessing you're using a non-US English locale?
That's what I was afraid of.  The tests involving encoding/decoding 
using the default code pages have been causing problems because not all 
of the test characters can round-trip with all code pages.  I thought 
I had finally gotten that sorted out into a version that would run 
anywhere, but the solution once again proved elusive.  For now, I've 
just commented out the tests that have been causing problems. 


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

Rick




Yes - pl (Polish)

Jacek

[jira] Commented: (GERONIMODEVTOOLS-104) When TomcatWebContainer moved default location - plugin cannot publish projects

2006-08-28 Thread Sachin Patel (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-104?page=comments#action_12430971
 ] 

Sachin Patel commented on GERONIMODEVTOOLS-104:
---

Ok, so from my understanding the Eclipse plugin simply needs to provide support 
in the deployment plan editor as well as the new web project creation wizard 
for the WebContainer element.

- What I don't understand is since there is a TomcatWebContainer defined, why 
isn't Geronimo defaulting to the first one found?

Alternatively, the Eclipse WTP Server Framework allows extensiblility to the 
publishing processes.  So you could actually extend the Geronimo publish 
processes by providing a publish task, that sets the appropriate WebContainer.

 When TomcatWebContainer moved default location - plugin cannot publish 
 projects
 ---

 Key: GERONIMODEVTOOLS-104
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-104
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.1.0
 Environment: IBM VM 1.5, Win2k SP4, Eclipse 3.2.0, Little-G 1.1
Reporter: Oleg Gusakov

 I defined Tomcat engine on the application level (in 
 geronimo-application.xml) because I need to define a lot of virtual hosts.
 When I try to deploy a project into the server - I get  
 org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve 
 reference Container in gbean 
 default/gtest2/1.0/car?J2EEApplication=null,j2eeType=WebModule,name=default/gtest2/1.0/car
  to a gbean matching the pattern [?name=TomcatWebContainer#]
 caused by org.apache.geronimo.kernel.GBeanNotFoundException: No matches for 
 referencePatterns: [?name=TomcatWebContainer#]
 Two problems here (or one as they have the same root cause):
 - plugin should be able to present user a choice of available web containers 
 to deploy to
 - what if I rename bean container (can I?) and it becomes 
 MyTomcatContainer35 ?

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

Re: Change redirects/* to .htaccess RewriteRules


+1 good idea

Paul

On 8/28/06, Jason Dillon [EMAIL PROTECTED] wrote:

Any objection to changing the meta http-equiv=refresh pages for
redirects/* to use .htaccess RewriteRules?

Doing so will avoid the need for users to see the Redirecting your
request... messages.  We can also use the rules to redirect urls w/o
page names, so like:

 http://geronimo.apache.org/issues - http://issues.apache.org/
jira/browse/GERONIMO
 http://geronimo.apache.org/wiki - http://cwiki.apache.org/geronimo
 ...

How about it?

--jason

Re: [VOTE] Publish Genesis 1.0 to m2 central

2006-08-28 Thread Kevan Miller


Is there a download available?
--kevan
On Aug 28, 2006, at 1:42 AM, Jason Dillon wrote:

This weekend I cleaned up Genesis and made an initial release of  
1.0 to the m2-ibiblio-rsync-repository.


In order to release other projects, like specs, xbean, gbuild,  
gshell, javamail and server... we need to have genesis 1.0  
published to central.


[+1] Publish Genesis 1.0 to m2 central
[+0] Um, I don't have an opinion
[-1] Heck no... and this is why...

--jason

Re: [VOTE] Publish Genesis 1.0 to m2 central

2006-08-28 Thread Jeff Genender


[+1] Publish Genesis 1.0 to m2 central

Jason Dillon wrote:
 This weekend I cleaned up Genesis and made an initial release of 1.0 to
 the m2-ibiblio-rsync-repository.
 
 In order to release other projects, like specs, xbean, gbuild, gshell,
 javamail and server... we need to have genesis 1.0 published to central.
 
 [+1] Publish Genesis 1.0 to m2 central
 [+0] Um, I don't have an opinion
 [-1] Heck no... and this is why...
 
 --jason

Re: [VOTE] XBean 2.6 release

2006-08-28 Thread Jeff Genender

+1

Guillaume Nodet wrote:
 I have tagged the xbean-2.6 branch
   http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.6/
 
 and uploaded a version at
   http://people.apache.org/~gnodet/xbean-2.6/org/apache/xbean/
 
 Please vote.
 Here's my +1
 
 As soon as the vote is off, I will upload the release to the m2 repo at
http://people.apache.org/repo/m2-ibiblio-rsync-repository/
 
 -- 
 Cheers,
 Guillaume Nodet

Re: Change redirects/* to .htaccess RewriteRules

2006-08-28 Thread Hernan Cunico

It sounds good. Quick question, how will we maintain these rules once we 
 are using confluence for authoring the site?


I would like to keep a single authoring tool, do you think we could 
manage it as an attachment on the site's space?


Cheers!
Hernan

Jason Dillon wrote:
Any objection to changing the meta http-equiv=refresh pages for 
redirects/* to use .htaccess RewriteRules?


Doing so will avoid the need for users to see the Redirecting your 
request... messages.  We can also use the rules to redirect urls w/o 
page names, so like:


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

http://geronimo.apache.org/wiki - http://cwiki.apache.org/geronimo
...

How about it?

--jason

Re: Returning to Commit-Then-Review?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jacek Laskowski wrote:
 
 Sure. I wish there were an editor or alike who would put our decisions
 from emails for others who only follow the project rarely, and can't
 cope with the flow.

Edit the STATUS file, which is getting autoposted.
- --
#kenP-)}

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

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

iQCVAwUBRPMAvZrNPMCpn3XdAQL/GAP/eORqsUtLF2fHgwC/7cmc70FHH4uHnoO7
xZn/Sf8x923D+tZE5S0xZolDoXTWdO6zCaTzYqhEgBq/5fjz3mmtOPwO6dOzKRgx
B2kHeC0PBUKHJJXdYzZXTDeXv7g27AAZxMbNqE7oT7V9bYdXR71SbUrhhPScrfrT
HELp9rPbqgU=
=G2uL
-END PGP SIGNATURE-

Re: Restructuring trunk, then next steps


Jason, the distinction between framework and system might be
unclear to a novice.  Something like bootstrap and system might be
clearer.  Also, I think of plugin as a packaging/distribution
mechanism instead of a statement of functionality so I would call that
directory something like ext and put modules in there that are
optional extensions to the server (probably implemented as plugins,
but not necessarily).

Best wishes,
Paul

On 8/28/06, Jason Dillon [EMAIL PROTECTED] wrote:

So, I've mentioned a few times before that we should start thinking
about how to split up modules in trunk into a few smaller chunks.  I
took a few minutes and took a crude stab at what that might look
like.  This is just an example of how it might work... I did not do
any extensive research into dependencies...

Basically, I split things up into 5 main trees:

  * framework - common stuff, not really the server, but supports the
server, modules here should have minimal deps
  * system - the major components which make up the server's system
(should be the bits to start up a server shell)
  * tools - bits that support the system
  * plugins - components which plugin to the system
  * testsuite - placeholder for modules which will be aded soon that
use the itest plugin to perform integration tests

I'm not sure if this is the best split, but it kinda comes closer to
what I hope we can get to.  Below is how the modules that exists fit
into these sections.



framework/
 geronimo-testsupport (may need to be in other tree? so can
include in all modules by default)
 geronimo-common
 geronimo-util
 geronimo-interceptor
 geronimo-activation
 geronimo-kernel

system/
 geronimo-management
 geronimo-security
 geronimo-security-builder
 geronimo-service-builder
 geronimo-core
 geronimo-system
 geronimo-transaction
 geronimo-connector
 geronimo-connector-builder
 geronimo-jmx-remoting
 geronimo-naming
 geronimo-naming-builder
 geronimo-test-ddbean (wtf is this for?)
 geronimo-deployment/
 geronimo-deployment (rename to -core) ?
 geronimo-deploy-config
 geronimo-deploy-jsr88
 geronimo-deploy-tool
 geronimo-hot-deploy
 geronimo-client
 geronimo-client-builder
 geronimo-j2ee/
 geronimo-j2ee
 geronimo-j2ee-builder
 geronimo-j2ee-schema
 geronimo-web-builder

plugins/
 geronimo-activemq/
 ge-activemq-rar (rename)
 geronimo-activemq-gbean
 geronimo-activemq-gbean-management
 geronimo-axis
 geronimo-axis-builder
 geronimo-derby
 geronimo-directory
 geronimo-tomcat
 geronimo-tomcat-builder
 geronimo-jetty
 geronimo-jetty-builder
 geronimo-mail
 geronimo-timer
 geronimo-webservices

tools/
 geronimo-upgrade
 geronimo-converter

testsuite/
 TODO, home for itest usage



Anyways, I wanted to post what I am thinking.  I think that we are
really close to the point where we will want to implement this sort
of split up.

Comments?

--jason

[jira] Resolved: (SM-546) Race condition present in servicemix-bpe module

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

Guillaume Nodet resolved SM-546.


Fix Version/s: (was: 3.0)
   Resolution: Cannot Reproduce

 Race condition present in servicemix-bpe module
 ---

 Key: SM-546
 URL: https://issues.apache.org/activemq/browse/SM-546
 Project: ServiceMix
  Issue Type: Bug
Affects Versions: 3.0-M1, 3.0-M2, 3.0, 3.0-M3
 Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD
Reporter: Grant McDonald
 Assigned To: Grant McDonald
 Fix For: 3.0-M3


 When external messages are routed to a waiting BPEL (BPE) process instance a 
 ThreadLocal is initialised with a reference to the BPEEndpoint that is being 
 routed to.  Once the BPE event director returns at the completion of the 
 business process this ThreadLocal is set to null.  Normally this doesn't pose 
 a problem, but in the case where the last statement before the reply (if the 
 process doesn't have a reply the problem does not appear) is an InOnly MEP 
 the business process returns immediately and by the time the InOnly invoke 
 has filtered out to the integration layer the ThreadLocal variable has been 
 set to null creating a race condition.
 The workaround is not to have an InOnly as the last statement in the business 
 process that declares a receive/reply pair.  This is not optimal but may be 
 the best we can do until the new jbi deployment/integration using the new 
 merged ODE is fully stable.  I will start testing the merged trunk over the 
 next week or so to gauge what the best direction to proceed with is.

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

[jira] Resolved: (SM-552) JBoss Deployer fails when uninstalling / reinstalling Service Assemblies

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

Guillaume Nodet resolved SM-552.


Fix Version/s: 3.0-M3
   Resolution: Fixed
 Assignee: Guillaume Nodet

Fixed, thx

 JBoss Deployer fails when uninstalling / reinstalling Service Assemblies
 

 Key: SM-552
 URL: https://issues.apache.org/activemq/browse/SM-552
 Project: ServiceMix
  Issue Type: Bug
Affects Versions: 3.0-M2
 Environment: JBoss 4.0.4 GA, ServiceMix 3.0-M2
Reporter: Frank Trietsch
 Assigned To: Guillaume Nodet
 Fix For: 3.0-M3

 Attachments: JBIService.java

   Original Estimate: 10 minutes
  Remaining Estimate: 10 minutes

 Uninstallation / reinstallation of ServiceAssemblies fails with different 
 errors (KernelAlreadyExistsException, etc.). This is due to a buggy 
 JBIService.uninstallArchive() method.
 Fixed with this patch (complete file attached):
 RCS file: 
 /opt/cvs/cvsroot/OpenSource/jboss-deployer/src/java/org/servicemix/jboss/deployment/JBIService.java,v
 retrieving revision 1.1
 retrieving revision 1.2
 diff -w -b -r1.1 -r1.2
 22d21
  import java.util.Date;
 34,36c33
  import org.apache.servicemix.jbi.deployment.Descriptor;
  import org.apache.servicemix.jbi.deployment.DescriptorFactory;
  import org.apache.servicemix.jbi.framework.AutoDeploymentService;
 ---
  import 
  org.apache.servicemix.jbi.framework.AutoDeploymentService.ArchiveEntry;
 56a54,55
  private MapString, ArchiveEntry archiveMap = new HashMapString, 
  ArchiveEntry();
  
 120c119,120
  jbiContainer.updateExternalArchive(archive);
 ---
  ArchiveEntry entry = 
  jbiContainer.getAutoDeploymentService().updateExternalArchive(archive, 
  true);
  archiveMap.put(archive, entry);
 138,139c138,142
  jbiContainer.getAutoDeploymentService().removeArchive(
  
 jbiContainer.getAutoDeploymentService().updateExternalArchive(archive,false));
 ---
  ArchiveEntry entry = archiveMap.get(archive);
  if (entry == null) {
  throw new DeploymentException(No service assembly  + 
  archive +  registered!);
  }
  jbiContainer.getAutoDeploymentService().removeArchive(entry);

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

[jira] Reopened: (SM-546) Race condition present in servicemix-bpe module

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

Guillaume Nodet reopened SM-546:


 
Sorry, closed the wrong issue :(

 Race condition present in servicemix-bpe module
 ---

 Key: SM-546
 URL: https://issues.apache.org/activemq/browse/SM-546
 Project: ServiceMix
  Issue Type: Bug
Affects Versions: 3.0-M1, 3.0-M2, 3.0, 3.0-M3
 Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD
Reporter: Grant McDonald
 Assigned To: Grant McDonald
 Fix For: 3.0-M3


 When external messages are routed to a waiting BPEL (BPE) process instance a 
 ThreadLocal is initialised with a reference to the BPEEndpoint that is being 
 routed to.  Once the BPE event director returns at the completion of the 
 business process this ThreadLocal is set to null.  Normally this doesn't pose 
 a problem, but in the case where the last statement before the reply (if the 
 process doesn't have a reply the problem does not appear) is an InOnly MEP 
 the business process returns immediately and by the time the InOnly invoke 
 has filtered out to the integration layer the ThreadLocal variable has been 
 set to null creating a race condition.
 The workaround is not to have an InOnly as the last statement in the business 
 process that declares a receive/reply pair.  This is not optimal but may be 
 the best we can do until the new jbi deployment/integration using the new 
 merged ODE is fully stable.  I will start testing the merged trunk over the 
 next week or so to gauge what the best direction to proceed with is.

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

[jira] Updated: (SM-558) ComponentContext.resolveEndpointReference does not resolve JBI internal EPR format

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

Guillaume Nodet updated SM-558:
---

Patch Info:   (was: [Patch Available])

 ComponentContext.resolveEndpointReference does not resolve JBI internal EPR 
 format
 --

 Key: SM-558
 URL: https://issues.apache.org/activemq/browse/SM-558
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-core
 Environment: all
Reporter: maciej szefler
   Original Estimate: 2 hours
  Remaining Estimate: 2 hours

 According to JBI spec, the internal EPR format:
  jbi:end-point-reference xmlns:jbi=http://java.sun.com/xml/ns/jbi;
   jbi:end-point-name=endpointName 
   jbi:service-name=foo:serviceName 
   xmlns:foo=urn:FooNamespace/
 should be supported by the ComponentContex.resolvedEndpointReference method. 
 Currently this is not the case.

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

[jira] Resolved: (SM-529) Servicemix-Component's MPSSettingTest.java hangs indefinitely.

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

Guillaume Nodet resolved SM-529.


Fix Version/s: 3.0-M3
   (was: 3.1)
   Resolution: Cannot Reproduce

 Servicemix-Component's MPSSettingTest.java hangs indefinitely.
 --

 Key: SM-529
 URL: https://issues.apache.org/activemq/browse/SM-529
 Project: ServiceMix
  Issue Type: Bug
Reporter: Fritz Oconer
 Assigned To: Fritz Oconer
 Fix For: 3.0-M3


 Unit test org.apache.servicemix.components.mps.MPSSettingTest found in 
 servicemix-components module hangs indefinitely. 

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

[jira] Commented: (AMQ-509) list, query and bstat scripts don't seem to work any more

2006-08-28 Thread Jelmer Kuperus (JIRA)

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

Jelmer Kuperus commented on AMQ-509:


-Djava.rmi.server.hostname=localhost 

seemed to fix it for me

 list, query and bstat scripts don't seem to work any more
 -

 Key: AMQ-509
 URL: https://issues.apache.org/activemq/browse/AMQ-509
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0 M4
Reporter: james strachan
 Assigned To: Adrian Co
 Fix For: 4.0 M4


 I get this...
 bigmac-6:~/Desktop/activemq-4-1.0-M4/bin jstrachan$ bstat
 ACTIVEMQ_HOME: /Users/jstrachan/Desktop/activemq-4-1.0-M4
 Failed to execute query task. Reason: java.io.IOException: Failed to retrieve 
 RMIServer stub: javax.naming.NameNotFoundException: jmxrmi
 bigmac-6:~/Desktop/activemq-4-1.0-M4/bin jstrachan$ list
 ACTIVEMQ_HOME: /Users/jstrachan/Desktop/activemq-4-1.0-M4
 Failed to execute list task. Reason: java.io.IOException: Failed to retrieve 
 RMIServer stub: javax.naming.NameNotFoundException: jmxrmi

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

Patches in RTC (Geronimo - 2006-08-28)

2006-08-28 Thread dblevins

Geronimo - Monday, August 28, 2006

  5 Patches in RTC

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

[GERONIMO-2332] RTC Put the generated xmlbeans files for the j2ee 1.4 
schemas in svn in a spec module so we don't need the schemas in svn at all
  - Assignee: David Jencks
  - Reporter: David Jencks
  - Created:  Fri Aug 18 13:13:47 PDT 2006
  - Updated:  Fri Aug 25 18:32:52 PDT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2332

[GERONIMO-2163] WADI Integration for Jetty
  - Assignee: Gianny Damour
  - Reporter: Gianny Damour
  - Created:  Sun Jul 02 14:16:35 PDT 2006
  - Updated:  Sun Aug 27 12:00:32 PDT 2006
  - Votes: 1
  1  David Jencks
  - http://issues.apache.org/jira/browse/GERONIMO-2163

[GERONIMO-2349] jta 1.1 support with container manager jpa support in 
transaction module
  - Assignee: David Jencks
  - Reporter: David Jencks
  - Created:  Wed Aug 23 13:22:37 PDT 2006
  - Updated:  Sun Aug 27 12:02:54 PDT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2349

[GERONIMO-2248] Applications portlets: List Parent and Child components 
against each component
  - Assignee: Unassigned
  - Reporter: Vamsavardhana Reddy
  - Created:  Sun Jul 30 08:15:34 PDT 2006
  - Updated:  Sat Aug 19 10:44:11 PDT 2006
  - Votes: 1
  1  Donald Woods
  - http://issues.apache.org/jira/browse/GERONIMO-2248


NOTE: This email is generated and does not constitute and offical
vote or vote result.  All official voting is done on the dev list.

If you do not see your issue here, click the Begin RTC Review
link under the Available Workflow Actions of the JIRA page.

If you do not see your vote here, click the Vote link under the
Operations section of the JIRA page.


 *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE ***

Template: 
http://svn.apache.org/repos/asf/geronimo/gbuild/jirareports/patchesInRtc.vm

Re: Returning to Commit-Then-Review?

2006-08-28 Thread Aaron Mulder


On 8/28/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote:

Edit the STATUS file, which is getting autoposted.


I've tried valiantly, but I can no longer resist posting to this
thread.  I'm sure my position is well known, but I feel like it needs
to be stated anyway.

Looking at development progress, RTC has been a disaster.  At JavaOne,
we had more than 10 people volunteer to implement more than 30 tasks,
targeting a release date (including testing and candidates) of 3
months out.  There were also 20+ other tasks that we thought would be
great but we needed a volunteer to work on them.  The notes on all
this stuff was posted to this mailing list.

It's been more than three months since then (under RTC), and by my
count two of the thirty tasks have been completed.  Sure, people may
be talking more, but this is ridiculous.  Maybe OK for a maintenance
branch, but a joke for a feature release.  I'm OK doing all feature
development elsewhere, but it kind of kills the project proper.
Clearly I believe trunk should switch to CTR.

Also, I'm not sure why the PMC Chair continues to attempt to control
and direct communications, posting a nearly empty and useless text
file to the list on a regular basis and telling people how they are or
are not allowed to use the Wiki.  If we're not even allowed to talk
among ourselves freely, I can't see how we could be trusted to commit
code freely, so on that basis we should clearly stay in RTC.  For my 2
cents, a monolithic text file is absolutely not the right forum for
summarizing discussions, tallying votes, recording bug status, and so
on.  We have Jira and a Wiki for a reason, and they should be used
appropriately.

Thanks,
Aaron


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

iQCVAwUBRPMAvZrNPMCpn3XdAQL/GAP/eORqsUtLF2fHgwC/7cmc70FHH4uHnoO7
xZn/Sf8x923D+tZE5S0xZolDoXTWdO6zCaTzYqhEgBq/5fjz3mmtOPwO6dOzKRgx
B2kHeC0PBUKHJJXdYzZXTDeXv7g27AAZxMbNqE7oT7V9bYdXR71SbUrhhPScrfrT
HELp9rPbqgU=
=G2uL
-END PGP SIGNATURE-

[jira] Commented: (GERONIMO-2163) WADI Integration for Jetty

2006-08-28 Thread Gianny Damour (JIRA)

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

Gianny Damour commented on GERONIMO-2163:
-

Many thanks David for having ported this patch to the new module layout and 
improved NamespaceDrivenBuilders to allow environment modifications.

v4 applies cleanly except for a couple of problems with PlanParsingTest and 
JettyModuleBuilderTest. I think that svn was confused somewhere during the 
diff. For instance, here is a relevant snip:


Index: 
modules/geronimo-jetty-builder/src/test/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilderTest.java===---
 
modules/geronimo-jetty-builder/src/test/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilderTest.java
   (revision 437418)
+++ 
modules/geronimo-jetty-builder/src/test/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilderTest.java
   (working copy)

further in the same diff

-public class JettyModuleBuilderTest extends TestSupport {
+public class PlanParsingTest extends TestSupport {


It seems that svn tried to diff JettyModuleBuilderTest and PlanParsingTest :(.

Having said that, it seems that substitution group is not happening for an 
obscure reason. After having modified WADIJettyClusteringBuilder to register a 
namespace conversion via the following line:

SchemaConversionUtils.registerNamespaceConversions(
Collections.singletonMap(clustering-wadi, new 
NamespaceElementConverter(WADI_NAMESPACE)));

and added an empty clustering-wadi element to the geronimo-web.xml DD. I still 
get the following error:

Error: Operation failed: xml problem for web app .

Invalid deployment descriptor: [error: cvc-complex-type.2.4a:
Expected elements
'[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/application-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.2
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.2' instead of
'[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/clustering-wadi-1.2'
here]

Descriptor: xml-fragment
xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2;
xmlns:clus=http://geronimo.apache.org/xml/ns/clustering-wadi-1.2;
  dep:environment
dep:moduleId
  dep:groupIdorg.codehaus.wadi/dep:groupId
  dep:artifactIdwadi-webapp/dep:artifactId
  dep:version2.0M2-SNAPSHOT/dep:version
  dep:typewar/dep:type
/dep:moduleId
  /dep:environment

  clus:clustering-wadi/

/xml-fragment

This is weird as clus:clustering-wadi/ should be a valid substitution to 
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/application-1.2. I will 
investigate further this problem. However, if you do already know the problem, 
then please let me know.


 WADI Integration for Jetty
 --

 Key: GERONIMO-2163
 URL: http://issues.apache.org/jira/browse/GERONIMO-2163
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: Clustering
Reporter: Gianny Damour
 Assigned To: Gianny Damour
Priority: Minor
 Attachments: GERONIMO-2163-v3.patch, GERONIMO-2163-v3b.patch, 
 GERONIMO-2163-v4-old.patch, GERONIMO-2163-v4.patch, 
 geronimo-wadi-integration-preview.patch, geronimo-wadi-integration-RTC.patch, 
 geronimo.patch, setUpServers.tar.gz, wadi-geronimo-integration-preview.patch, 
 wadi.patch


 Email sent to the dev@ list.
 Hi,
 I have been working on a second integration attempt of WADI and I am posting 
 here a high-level description of the current state of progress such that 
 people can jump in.
 At this stage, this is a Jetty only attempt and I do believe that the same 
 approach can be applied for Tomcat. The current integration provides (very 
 unreliable) HttpSession state migration. It only works for a single 
 Web-application; more effort is required on the WADI side to support multiple 
 Web-applications and this will not impact the integration piece of code. I 
 (more or less

Re: Returning to Commit-Then-Review?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rodent of Unusual Size wrote:
 Jacek Laskowski wrote:
 Sure. I wish there were an editor or alike who would put our decisions
 from emails for others who only follow the project rarely, and can't
 cope with the flow.
 
 Edit the STATUS file, which is getting autoposted.

By the way, lest someone think I'm attempting to control
communications, the above was meant as a suggestion.  Since
that's exactly haw the mechanism has been successfully used
by other projects.
- --
#kenP-)}

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

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

iQCVAwUBRPMLU5rNPMCpn3XdAQIXUgQA1fdP3RWhe5XABbVD86YuFKsdnEsJE7eq
wRvg7ek6JmcB7A9PTKS6+SWcJYpeKNDpVl+Jym5f2ppShd4cbNEp974+S+w/s0NB
6xNXqYq3Q1DcnXvAK7KSNe0PEo+2pc1cr4+UbcjESQ+9pl2UWaFFEbzXgNUZSwTC
PxZobzxTFnc=
=YaGH
-END PGP SIGNATURE-

[jira] Updated: (SM-558) ComponentContext.resolveEndpointReference does not resolve JBI internal EPR format

2006-08-28 Thread maciej szefler (JIRA)

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

maciej szefler updated SM-558:
--

Attachment: sm558.patch

Patch to servicemix-core. 

 ComponentContext.resolveEndpointReference does not resolve JBI internal EPR 
 format
 --

 Key: SM-558
 URL: https://issues.apache.org/activemq/browse/SM-558
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-core
 Environment: all
Reporter: maciej szefler
 Attachments: sm558.patch

   Original Estimate: 2 hours
  Remaining Estimate: 2 hours

 According to JBI spec, the internal EPR format:
  jbi:end-point-reference xmlns:jbi=http://java.sun.com/xml/ns/jbi;
   jbi:end-point-name=endpointName 
   jbi:service-name=foo:serviceName 
   xmlns:foo=urn:FooNamespace/
 should be supported by the ComponentContex.resolvedEndpointReference method. 
 Currently this is not the case.

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

Re: j2ee-builder tests?

2006-08-28 Thread Bill Dudney


Hi Jason,

Yes I made some progress. Not quite done as I ran into a redeploy bug  
that I spent a bit of time poking at over the weekend. I think the  
thing to do is to get the test stuff moved over and then I'll  
experiment more with the redeploy bug.


From past experience patches generated by svn after an svn mv are  
not the best. So I was thinking that you should move the stuff  
around, then I'll submit a patch against the moved content. Does that  
sound OK or is there a better way?


Once the move is complete I'll generate a patch that can be applied  
to these bits to make them deploy and get rid of the j2ee-builder pom  
and ant stuff that uses these. There are two other test deployables  
(test-plan and test-unpacked-ear) that I'd also like to move but I  
was thinking it would be better to get this done first then move the  
other two.


Thanks,

-bd-

Here is the list of commands that will get us to the point of an easy  
patch. Again I'm totally open to a better way if there is one.


svn mkdir test-deployables
svn mv modules/j2ee-builder/src/test-ear test-deployables/test-ear- 
j2ee-1.4
svn mv modules/j2ee-builder/src/test-ear13 test-deployables/test-ear- 
j2ee-1.3


svn ci -m 'initial move of test stuff'

cd test-deployables/test-ear-j2ee-1.4 (repeat from here down for the  
test-ear-j2ee-1.3 as well)


svn mv test-ejb-ear ejb
svn mv test-rar rar
svn mv test-war war
svn mkdir ear/src/main/resources (these have to be done one at a time  
AFAIK)

svn mv META-INF ear/src/main/resources

cd ejb

svn mkdir src/main/java
svn mkdir src/main/resources

svn mv org src/main/java
svn mv META-INF src/main/resources

cd ../rar

svn mkdir src/main/resources
svn mv META-INF src/main/resources

cd ../web

svn mkdir src/main/webapp
svn mv hello.txt src/main/webapp
svn mv WEB-INF src/main/webapp

svn ci -m moving the test stuff


On Aug 27, 2006, at 11:51 PM, Jason Dillon wrote:


Hiya Bill... didya happen to make any progress on this?

--jason


On Aug 25, 2006, at 1:28 PM, Bill Dudney wrote:


Hi Jason,

I'd be happy to do this. Do you have a direction yet on the  
movement of modules? This would probably best fit in something like


trunk/test-deployables/${module-name}

Does that sit well, or would you rather me put it into modules?  
Then you can move it around when you move everything else.


TTFN,

-bd-

On Aug 25, 2006, at 1:54 PM, Jason Dillon wrote:

I think it would be good to turn those mock test apps into a set  
of real m2 modules that build the j2ee deployables, then j2ee- 
deployer can depend on them  and not have to hack up its build to  
generate them... and then those mock apps could be reused outside  
of that module too... say to test the cli deployer and more.


You want to take a whack at this?

Should be easy enough... I'd like to use these mock apps instead  
of converting all of those hacks to use the m2 standard layout  
for j2ee-builder.


--jason


On Aug 23, 2006, at 3:59 PM, Bill Dudney wrote:


Hi All,

The tests in the j2ee-builder do not currently have valid  
deployment descriptors. While that's ok for this module because  
of the mocked out deployment bits I was hoping to use them in  
other tests. I have most of the stuff fixed up but there are a  
few things that I don't want to do without feedback.


1) there rar is empty, no jar's no xml in the deployment  
descriptors its just a place holder. Thoughts on what to do with  
that? cook up a simple rar? delete it? I lean towards making a  
simple rar.


2) The web.xml references a bogus bunch of ejb's with refs like  
'fake-ejb-ref'. Couple of things we could do with this, make  
them point to valid ejb references in the ejb jar files that are  
part of this ear or delete them. I would/could add some extra  
EJB's to the ejb jar to make sure we covered all the reference  
types.


3) This is less important but I'd like to change the  
artifactId's so they are unique (i.e. test-ear-j2ee-1.{3,4}) so  
that I can deploy both of the ear files when its all said and done.


4) I'm not sure exactly how to do this with ear/war/ejb-jar but  
I'd like to have this module produce a 'tests' jar (we do this  
in cayenne with simple junit tests so we can reuse it across  
modules) and then reuse these deployment units in other  
automated tests. I'm game to poke at it but figure I might get a  
few of Jason's brain cells so I can be a bit lazier :-)


I posted this jira;

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

to track this issue.

Thanks!

-bd-

[jira] Created: (AMQ-898) SocketWrite hangs indefinitely

2006-08-28 Thread Edward Tolson (JIRA)

SocketWrite hangs indefinitely
--

 Key: AMQ-898
 URL: https://issues.apache.org/activemq/browse/AMQ-898
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0.1
 Environment: Linux, Java 1.5, JBoss appserver
Reporter: Edward Tolson
Priority: Critical


We routinely have our message distribution locked up permanently and without 
means of recovery by a socketWrite0 call that hangs indefinitely in a thread 
holding a number of the Active MQ locks.  Here is a stack trace of such a 
locked up thread:

at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at 
org.apache.activemq.transport.tcp.TcpBufferedOutputStream.write(TcpBufferedOutputStream.java:95)
at java.io.DataOutputStream.write(DataOutputStream.java:90)
- locked 0x4bc298c8 (a java.io.DataOutputStream)
at 
org.apache.activemq.openwire.v1.BaseDataStreamMarshaller.tightMarshalByteSequence2(BaseDataStreamMarshaller.java:403)
at 
org.apache.activemq.openwire.v1.MessageMarshaller.tightMarshal2(MessageMarshaller.java:160)
at 
org.apache.activemq.openwire.v1.ActiveMQMessageMarshaller.tightMarshal2(ActiveMQMessageMarshaller.java:88)
at 
org.apache.activemq.openwire.v1.ActiveMQObjectMessageMarshaller.tightMarshal2(ActiveMQObjectMessageMarshaller.java:88)
at 
org.apache.activemq.openwire.OpenWireFormat.marshal(OpenWireFormat.java:240)
at 
org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:124)
at 
org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:141)
at 
org.apache.activemq.transport.TransportFilter.oneway(TransportFilter.java:78)
at 
org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:77)
at 
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
- locked 0x4bac2b80 (a java.lang.Object)
at 
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at 
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:)
at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1553)
at 
org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:462)
at com.hb.jms.api.util.JmsSession.sendObjects(JmsSession.java:345)
- locked 0x4aca1230 (a org.apache.activemq.ActiveMQSession)
at com.hb.jms.api.util.JmsSession.sendObjects(JmsSession.java:307)
at 
com.hb.jms.api.util.JmsSession$QueueProcessor.sendFromSessionQueue(JmsSession.java:1002)
- locked 0x6adc9f80 (a com.hb.jms.api.util.JmsSession$SessionQueue)
at 
com.hb.jms.api.util.JmsSession$QueueProcessor.run(JmsSession.java:981)
at java.lang.Thread.run(Thread.java:595)

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

Re: [VOTE] Specs organization, versioning, and releasing

2006-08-28 Thread Bill Dudney


+1 to releasing them all as one version #.

It will make everyones life easier (dev's and users) having one # to  
remember than many.


TTFN,

-bd-

On Aug 27, 2006, at 5:50 PM, Jason Dillon wrote:


I've implemented #5, which was to restructure to use the same
directory and artifactIds... I renamed the directories to match.

I think we need to have another round of discussion on how to handle
the versioning.

I'm starting to lean heavily towards having *one* version for *all* of
the specs.  I don't care too much that if spec A makes a change that
we release new versions of all of the other specs.  It is actually
similar to the server, when a bugfix release is made, a bunch of
modules will have no change since the last version, but we release
them anyways because it is simpler for use to manage, and easier for
users too, since they just need to know one version number... not the
version number of each module.

IMO, less version numbers to manage is easier... and better.  The side
effect is that more artifacts get released when we cut a new version.
But I don't see that we are going to be making tons of these spec
releases... so I don't see any harm in the additional artifacts.

So, my recommendation is to use one version for all of them.  I
believe this will be best in the short to medium term at least, and if
we find that it not working for the long run, then we can revisit
later.  But right now I'd like to get a consistent release of these
artifacts so we can remove the need for the bootstrap step to check
them out and build them.

I'd like to discus for a few days, create a new proposal, vote and
then implement in the near future.

Comments?

--jason



On 8/18/06, Jason Dillon [EMAIL PROTECTED] wrote:

PROPOSAL:

1.  Each spec will no longer be split up into trunk+branches+tags.
There will instead be one trunk+branches+tags for all specs laid out
as follows:

 specs/trunk/pom.xml
 specs/trunk/artifactId
 specs/tags/artifactId-version
 specs/branches/

2.  Each plugin will continue to have its own version and will be
released independently.

3.  The top-level will have it's own version, which will remain
independent.  When there is a major configuration change in that pom,
the version will be changed and the pom will be republished.

4.  Releasing will be done with the maven release plugin ('mvn
release') and should occur at a stable point after any major change
to a spec module.

5. Change all module directories to match artifactIds.

MOTIVATION:

1.  one trunk allows the entire set of specs to be checked out all at
 once and built all at once.

  * * *

[ ] +1 Allow changes
[ ] 0  No opinion
[ ] -1 No, leave the specs asis (provide rationale)

--jason

[jira] Created: (SM-560) Internal EPR document fragments provided by ServiceMix are not valid NS-aware DOMs

2006-08-28 Thread maciej szefler (JIRA)

Internal EPR document fragments provided by ServiceMix are not valid NS-aware 
DOMs
--

 Key: SM-560
 URL: https://issues.apache.org/activemq/browse/SM-560
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-core
Affects Versions: 3.0-M2
 Environment: all
Reporter: maciej szefler
 Attachments: InternalEPR.patch

The DocumentFragment that is provided by Endpoint.getAsReference() for internal 
ServiceMix endpoints does not serialize well: duplicate xmlns:jbi attributes 
are generated. This is due to some slight problems in how the document 
fragement is constructed. Also the jbi namespace used is incorrect, it should 
be http://java.sun.com/jbi/end-point-reference not 
http://java.sun.com/xml/ns/jbi.


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

Eclipse as development tool for Geronimo components

2006-08-28 Thread Heinz Drews


Hello,

I want to use Eclipse for development and debugging of Geronimo components.
The Eclipse plugin I have already used for application development.

I have run mvn eclipse:eclipse, imported manually the projects but I'm
hoping for a faster approach.  And I'm facing several problems. First
I could not found the xmlbeans in the source tree, modules referring
them don't compile.  Then I have not found a way to run G directly
from the compilation produced by Eclipse.  Only approach now is to
build a module with Maven and  copy the jar to the Geronimo tree.

Help would be very much appreciated.
Regards,
Heinz

[jira] Commented: (GERONIMODEVTOOLS-104) When TomcatWebContainer moved default location - plugin cannot publish projects

2006-08-28 Thread Oleg Gusakov (JIRA)

[
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-104?page=comments#action_12430999
]

Oleg Gusakov commented on GERONIMODEVTOOLS-104:
---

- What I don't understand is since there is a TomcatWebContainer defined, why
isn't Geronimo defaulting to the first one found?

It would not be a good thing for runtime to mess with applications it runs. If
an application defines a WebContainer - it plans to use it for it's own web
modules. So deploying a module into a first container foung does not fly.

The only logical alternative - ability to select container. Could that be done
with a dendency or reference definition in geronimo-web.xml? Then plugin can
use that plan if one exists.

Alternatively, the Eclipse WTP Server Framework allows extensiblility to the
publishing processes. So you could actually extend the Geronimo publish
processes by providing a publish task, that sets the appropriate WebContainer.

I guess - everything is possible. But what's the value of plugin if it supports
only trivial use cases? It is as if car manufacturer assembles a frame with
wheels, engine and steering wheel and sells to you, saying that the rest you
can add yourself. Possible, but hardly practical :)

I think we should attract users to this project. And the only way to do that is
by providing convenient and flexible tools.

When TomcatWebContainer moved default location - plugin cannot publish
projects
---

Key: GERONIMODEVTOOLS-104
URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-104
Project: Geronimo-Devtools
Issue Type: Bug
Components: eclipse-plugin
Affects Versions: 1.1.0
Environment: IBM VM 1.5, Win2k SP4, Eclipse 3.2.0, Little-G 1.1
Reporter: Oleg Gusakov

I defined Tomcat engine on the application level (in
geronimo-application.xml) because I need to define a lot of virtual hosts.
When I try to deploy a project into the server - I get
org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve
reference Container in gbean
default/gtest2/1.0/car?J2EEApplication=null,j2eeType=WebModule,name=default/gtest2/1.0/car
to a gbean matching the pattern [?name=TomcatWebContainer#]
caused by org.apache.geronimo.kernel.GBeanNotFoundException: No matches for
referencePatterns: [?name=TomcatWebContainer#]
Two problems here (or one as they have the same root cause):
- plugin should be able to present user a choice of available web containers
to deploy to
- what if I rename bean container (can I?) and it becomes
MyTomcatContainer35 ?

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

[jira] Resolved: (SM-560) Internal EPR document fragments provided by ServiceMix are not valid NS-aware DOMs

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

Guillaume Nodet resolved SM-560.


Fix Version/s: 3.0-M3
   Resolution: Fixed
 Assignee: Guillaume Nodet

Author: gnodet
Date: Mon Aug 28 09:18:06 2006
New Revision: 437739

URL: http://svn.apache.org/viewvc?rev=437739view=rev
Log:
SM-560: Internal EPR document fragments provided by ServiceMix are not valid 
NS-aware DOMs

Modified:

incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/EndpointReferenceBuilder.java

incubator/servicemix/trunk/servicemix-core/src/test/java/org/apache/servicemix/jbi/servicedesc/EndpointReferenceBuilderTest.java



 Internal EPR document fragments provided by ServiceMix are not valid NS-aware 
 DOMs
 --

 Key: SM-560
 URL: https://issues.apache.org/activemq/browse/SM-560
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-core
Affects Versions: 3.0-M2
 Environment: all
Reporter: maciej szefler
 Assigned To: Guillaume Nodet
 Fix For: 3.0-M3

 Attachments: InternalEPR.patch


 The DocumentFragment that is provided by Endpoint.getAsReference() for 
 internal ServiceMix endpoints does not serialize well: duplicate xmlns:jbi 
 attributes are generated. This is due to some slight problems in how the 
 document fragement is constructed. Also the jbi namespace used is 
 incorrect, it should be http://java.sun.com/jbi/end-point-reference not 
 http://java.sun.com/xml/ns/jbi.

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

[jira] Commented: (GERONIMO-2340) Network Listener state not persisted across server startups

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

Donald Woods commented on GERONIMO-2340:


If we change Stop to also mean load=false, then we need an Info dialog telling 
the Admin that the stop operation will be preserved across server restarts.

 Network Listener state not persisted across server startups
 ---

 Key: GERONIMO-2340
 URL: http://issues.apache.org/jira/browse/GERONIMO-2340
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 1.1.1
 Environment: Win XP, Geronimo 1.1.1-SNAPSHOT
Reporter: Vamsavardhana Reddy
 Fix For: 1.2, 1.1.2


 I have stopped the HTTPS and AJP Network Listeners thru Web Servers 
 portlet.  Upon restarting the server, these stopped listeners have started 
 automatically.  Happens with both Jetty and Tomcat.

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

[jira] Updated: (GERONIMO-2343) tomcat does not use maxPostSize set in config.xml

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

Donald Woods updated GERONIMO-2343:
---

Fix Version/s: 1.1.2
   1.2
Affects Version/s: 1.1
   1.2
   (was: 1.1.x)

 tomcat does not use maxPostSize set in config.xml
 -

 Key: GERONIMO-2343
 URL: http://issues.apache.org/jira/browse/GERONIMO-2343
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Tomcat
Affects Versions: 1.2, 1.1, 1.1.1, 1.1.2
Reporter: Krishnakumar B
 Fix For: 1.1.2, 1.2

 Attachments: tomcat-maxPostSize.patch


 I set a value for maxPostSize in config.xml
 gbean name=TomcatWebConnector
   attribute name=host0.0.0.0/attribute
   attribute name=port8080/attribute
   attribute name=redirectPort8443/attribute
   attribute name=bufferSizeBytes2048/attribute
   attribute name=maxThreads150/attribute
   attribute name=acceptQueueSize100/attribute
   attribute name=lingerMillis-1/attribute
   attribute name=tcpNoDelaytrue/attribute
   attribute name=minSpareThreads25/attribute
   attribute name=maxSpareThreads75/attribute
   attribute name=maxHttpHeaderSizeBytes8192/attribute
   attribute name=hostLookupEnabledfalse/attribute
   attribute name=connectionTimeoutMillis2/attribute
   attribute name=uploadTimeoutEnabledfalse/attribute
   attribute name=maxPostSize20/attribute
   attribute name=maxSavePostSize4096/attribute
   attribute name=emptySessionPathfalse/attribute
 /gbean
 Tomcat Connector uses the value set in Connector to check for POST size.
 if (len  0) {
 int maxPostSize = connector.getMaxPostSize();
 if ((maxPostSize  0)  (len  maxPostSize)) {
 context.getLogger().info
 (sm.getString(coyoteRequest.postTooLarge));
 throw new IllegalStateException(Post too large);
 }
 While in Connector GBean setAttribute does not set in Connector
 connector.setAttribute(maxPostSize, new Integer(bytes));
 This is set in hashtable in HTTP11Protocol Handler. As a result the default 
 value is maintained in connector ( 2097152 )
 This fix uses setter method in connector to set this value. ( 
 connector.setMaxPostSize(bytes) )

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

[jira] Updated: (GERONIMO-2341) EditableConfigurationManager problems!!???!!!!

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

Donald Woods updated GERONIMO-2341:
---

Fix Version/s: 1.1.2
   (was: 1.1.1)
Affects Version/s: 1.1
   1.1.2
   1.2

 EditableConfigurationManager problems!!???
 --

 Key: GERONIMO-2341
 URL: http://issues.apache.org/jira/browse/GERONIMO-2341
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: ActiveMQ, kernel
Affects Versions: 1.2, 1.1, 1.1.1, 1.1.2
Reporter: Vamsavardhana Reddy
Priority: Critical
 Fix For: 1.1.2

 Attachments: GERONIMO-2341.patch


 Here are a few problems I noticed.
 1.  Delete a network listener (Jetty Web/Tomcat Web/JMS) thru administration 
 console and the listener showsup after server restart.
 2.  Stop any network listener, the listener is started automatically at 
 server restart (Related JIRA GERONIMO-2340)
 I think these problems have been fixed several times in the past.  But the 
 problem still remains.  It will be a big relief I am wrong and this JIRA is 
 invalid.

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

Re: Eclipse as development tool for Geronimo components

2006-08-28 Thread Sachin Patel

One of the big problems is that you can not use pure Eclipse to develop Geronimo. (just make code changes and compile)  The maven eclipse plugin generates the .classpath in which all the projects reference only the built jars in the maven repository rather then the projects set up to reference each other.  This causes a huge annoyance in that every time you make a change that affects another module, you will not see any compilation errors since the modified module has to be rebuilt and redeployed with maven so that the affected jar picks up the change.Also using the maven plugin for eclipse doesn't help, and enabling the maven build to occur using it helps the issue but makes the build process extremlely long.  I haven't tried the m2 eclipse goal to see if it addresses some of these issues or not.On Aug 28, 2006, at 12:01 PM, Heinz Drews wrote:Hello,I want to use Eclipse for development and debugging of Geronimo components.The Eclipse plugin I have already used for application development.I have run mvn eclipse:eclipse, imported manually the projects but I'mhoping for a faster approach.  And I'm facing several problems. FirstI could not found the xmlbeans in the source tree, modules referringthem don't compile.  Then I have not found a way to run G directlyfrom the compilation produced by Eclipse.  Only approach now is tobuild a module with Maven and  copy the jar to the Geronimo tree.Help would be very much appreciated.Regards,Heinz  -sachin

Re: 1.2 Release - Who's next and what is it?


For 1.2 I'd like to start introducing some console usability
improvements using AJAX and see if I can help with the new admin
portlets that Chris Cardona contributed.  I can also help with JEE5
readiness, especially on any UI related items like JSF. I'll go stare
at the JEE5 report card on our wiki and see where I can help.  I plan
to continue working on the community plugin site too.

Best wishes,
Paul

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

All,

Aaron started a thread back a ways about the 1.2 release.  I know that there 
has been discussion,
interest and some action in getting it on the table.  At this point I'm not 
exactly sure what our
goals are for the next step of Geronimo and when it will be done.

First step is defining what goes into the release and then who wants to guide 
the release to
fruition.  I'll start the what's in it thread and I think the whose going to do 
it will get resolved
once we finish this piece.

Given our past experience if we would like to hit another dot release this year 
then I think we have
to be releasing in November.  Thanksgiving and Christmas seem to burn up the 
last month and a half.
  So I think a release around November 15th sounds about right.

This means (working backwards) we'd need to have a branch by October 15th.  So, 
with that in mind we
have a little less than 2 months for development.

With that in mind here is the list of things I remember off the top of my head. 
 I'll follow this
thread and put out a summary note.  I'm putting people's names next to items I 
remember them
mentioning; I'm not assigning work :)

Java 5 Ready
JPA Integration (Open JPA / Cayenne) (I think Dain or Blevins ?)
Clustering support (Gianny / Jeff)
Pluggable JACC (Jencks)
Performance (Matt)

Lot's of other stuff I'm missing ?

Re: Why both concurrent and backport-util-concurrent?


On Aug 27, 2006, at 4:36 PM, Jason Dillon wrote:

Any reason why we are using both of these libraries?  Why don't we  
just convert to backport-util-concurrent so that we are closer to  
being ready to use 1.5's java.util.concurrent... and have one less  
bootstrap library to load?


...and that is the reason.  No one has taken the time to convert over  
the code.


-dain

[jira] Commented: (GERONIMODEVTOOLS-104) When TomcatWebContainer moved default location - plugin cannot publish projects

2006-08-28 Thread Sachin Patel (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-104?page=comments#action_12431008
 ] 

Sachin Patel commented on GERONIMODEVTOOLS-104:
---

 Could that be done with a dendency or reference definition in 
 geronimo-web.xml? Then plugin can use that plan if one exists. 

I'm non sure what you mean, but the geronimo-web schema provides a web 
container element, and it seems that all that needs to be done is to expose 
this element in the UI, in both the plan editor and in the project creation 
wizard.  

 When TomcatWebContainer moved default location - plugin cannot publish 
 projects
 ---

 Key: GERONIMODEVTOOLS-104
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-104
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.1.0
 Environment: IBM VM 1.5, Win2k SP4, Eclipse 3.2.0, Little-G 1.1
Reporter: Oleg Gusakov

 I defined Tomcat engine on the application level (in 
 geronimo-application.xml) because I need to define a lot of virtual hosts.
 When I try to deploy a project into the server - I get  
 org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve 
 reference Container in gbean 
 default/gtest2/1.0/car?J2EEApplication=null,j2eeType=WebModule,name=default/gtest2/1.0/car
  to a gbean matching the pattern [?name=TomcatWebContainer#]
 caused by org.apache.geronimo.kernel.GBeanNotFoundException: No matches for 
 referencePatterns: [?name=TomcatWebContainer#]
 Two problems here (or one as they have the same root cause):
 - plugin should be able to present user a choice of available web containers 
 to deploy to
 - what if I rename bean container (can I?) and it becomes 
 MyTomcatContainer35 ?

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

[jira] Commented: (GERONIMO-2340) Network Listener state not persisted across server startups

2006-08-28 Thread Paul McMahan (JIRA)

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

Paul McMahan commented on GERONIMO-2340:


Instead of changing the stop behavior to persist across server restarts (which 
is desirable in some cases, but not in others) it might be better to broaden 
the accepted values from the load attribute from 
   true | false
to
   automatic |  manual |  disabled

 Network Listener state not persisted across server startups
 ---

 Key: GERONIMO-2340
 URL: http://issues.apache.org/jira/browse/GERONIMO-2340
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 1.1.1
 Environment: Win XP, Geronimo 1.1.1-SNAPSHOT
Reporter: Vamsavardhana Reddy
 Fix For: 1.2, 1.1.2


 I have stopped the HTTPS and AJP Network Listeners thru Web Servers 
 portlet.  Upon restarting the server, these stopped listeners have started 
 automatically.  Happens with both Jetty and Tomcat.

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

[jira] Assigned: (GERONIMO-2314) Can not create a datasource with the name jdbc/EmployeeDatasource from console

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

Donald Woods reassigned GERONIMO-2314:
--

Assignee: Donald Woods

 Can not create a datasource with the name jdbc/EmployeeDatasource from 
 console
 

 Key: GERONIMO-2314
 URL: http://issues.apache.org/jira/browse/GERONIMO-2314
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 1.1
Reporter: Yunfeng Ma
 Assigned To: Donald Woods

 Follow the database pool wizard,  create a datasource with the name 
 jdbc/EmployeeDatasource, the connection test is successful, but when click 
 on the button deploy, see the following stacktrace in the server output 
 window:
 org.apache.geronimo.common.DeploymentException: 
 java.lang.IllegalArgumentException: Invalid id: 
 console.dbpool/jdbc/EmployeeDatasource/1.0/rar
at 
 org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:364)
at 
 org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
at 
 org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at 
 org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
at 
 org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at 
 org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106)
at 
 org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60)
at java.lang.Thread.run(Thread.java:797)
 Caused by: 
 java.lang.IllegalArgumentException: Invalid id: 
 console.dbpool/jdbc/EmployeeDatasource/1.0/rar
at 
 org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49)
at 
 org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376)
at 
 org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325)
... 10 more
 This error just happens in the condition of the database pool name includes 
 the character /, such as jdbc/EmployeeDatasource. If database pool name 
 is EmployeeDatasource, then everything is OK.
 Have a look at the souce codes of Artifact.java, the snippet of create method 
 as following:
 public static Artifact create(String id) {
 String[] parts = id.split(/, -1);
 if (parts.length != 4) { 
 throw new IllegalArgumentException(Invalid id:  + id);
 }
 for (int i = 0; i  parts.length; i++) {
 if (parts[i].equals()) {
 parts[i] = null;
 }
 }
 return new Artifact(parts[0], parts[1], parts[2], parts[3]);
 }
 If database pool name is jdbc/EmployeeDatasource, the parts.length would be 
 5 and IllegalArgumentException would be throwed.

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

Re: Returning to Commit-Then-Review?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Um, crock o' FUD time, I see.

Aaron Mulder wrote:
 
 Also, I'm not sure why the PMC Chair continues to attempt to control
 and direct communications,

Control?  No.  Direct?  Where they don't seem to be happening
productively, absolutely.

 posting a nearly empty and useless text
 file to the list on a regular basis

I was all set to remove that when I saw it was actually
being used.  So I've left it alone.

 and telling people how they are or
 are not allowed to use the Wiki.

Crock indeed.  The wiki is fine, it should be used in whatever
manners are considered the best, but it isn't our primary
means of communication.  For one thing it's pull rather
than push, so someone might miss a critical item simply
through forgetting to check the wiki.  For another, it's
not the primary communication medium of *any* ASF function,
so using it here would be raising an artificial barrier
between Geronimo and people from other projects.  Thirdly
- -- and this is the killer -- it's not archived holistically
with other discussions for future reference.  You don't
have discussions on a wiki.
- --
#kenP-|}

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

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

iQCVAwUBRPMQo5rNPMCpn3XdAQL2wQQAwo9U320YrrNQTpvjE9ou58fpvgdxZ2Gb
diNy3yey+Pam2gVQ9TmxE/hKGY7IeAcs4Dtag37oTNJu1ArXBwN614isMChQStD0
ZMQV4gVtkCpcpnL6OgicC/IosvBx1sfwqcGYdsUv5nRJ9I9fZQOf0nyScWSG18fr
JEzjojAeRGw=
=z/oP
-END PGP SIGNATURE-

[jira] Updated: (GERONIMO-2314) Can not create a datasource with the name jdbc/EmployeeDatasource from console

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

Donald Woods updated GERONIMO-2314:
---

Fix Version/s: 1.1.2
Affects Version/s: 1.1.1
   1.1.2
   1.2

Users should be allowed to create/recreate datasources with the same names that 
they can through deployment plans.
That way, if they need to upgrade or move a DB to another server, they can do 
so through the console without needing access to the original/updated db plan 
and remote deployer access (which they may not have in hosting environments)


 Can not create a datasource with the name jdbc/EmployeeDatasource from 
 console
 

 Key: GERONIMO-2314
 URL: http://issues.apache.org/jira/browse/GERONIMO-2314
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 1.2, 1.1, 1.1.1, 1.1.2
Reporter: Yunfeng Ma
 Assigned To: Donald Woods
 Fix For: 1.1.2


 Follow the database pool wizard,  create a datasource with the name 
 jdbc/EmployeeDatasource, the connection test is successful, but when click 
 on the button deploy, see the following stacktrace in the server output 
 window:
 org.apache.geronimo.common.DeploymentException: 
 java.lang.IllegalArgumentException: Invalid id: 
 console.dbpool/jdbc/EmployeeDatasource/1.0/rar
at 
 org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:364)
at 
 org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
at 
 org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at 
 org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
at 
 org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at 
 org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106)
at 
 org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60)
at java.lang.Thread.run(Thread.java:797)
 Caused by: 
 java.lang.IllegalArgumentException: Invalid id: 
 console.dbpool/jdbc/EmployeeDatasource/1.0/rar
at 
 org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49)
at 
 org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376)
at 
 org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325)
... 10 more
 This error just happens in the condition of the database pool name includes 
 the character /, such as jdbc/EmployeeDatasource. If database pool name 
 is EmployeeDatasource, then everything is OK.
 Have a look at the souce codes of Artifact.java, the snippet of create method 
 as following:
 public static Artifact create(String id) {
 String[] parts = id.split(/, -1);
 if (parts.length != 4) { 
 throw new IllegalArgumentException(Invalid id:  + id);
 }
 for (int i = 0; i  parts.length; i++) {
 if (parts[i].equals()) {
 parts[i] = null;
 }
 }
 return new Artifact(parts[0], parts[1], parts[2], parts[3]);
 }
 If database pool name is jdbc/EmployeeDatasource, the parts.length would be 
 5 and IllegalArgumentException would be throwed.

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

Re: [VOTE] Specs organization, versioning, and releasing

2006-08-28 Thread Kevan Miller



On Aug 27, 2006, at 7:50 PM, Jason Dillon wrote:


I've implemented #5, which was to restructure to use the same
directory and artifactIds... I renamed the directories to match.

I think we need to have another round of discussion on how to handle
the versioning.

I'm starting to lean heavily towards having *one* version for *all* of
the specs.  I don't care too much that if spec A makes a change that
we release new versions of all of the other specs.  It is actually
similar to the server, when a bugfix release is made, a bunch of
modules will have no change since the last version, but we release
them anyways because it is simpler for use to manage, and easier for
users too, since they just need to know one version number... not the
version number of each module.

IMO, less version numbers to manage is easier... and better.  The side
effect is that more artifacts get released when we cut a new version.
But I don't see that we are going to be making tons of these spec
releases... so I don't see any harm in the additional artifacts.

So, my recommendation is to use one version for all of them.  I
believe this will be best in the short to medium term at least, and if
we find that it not working for the long run, then we can revisit
later.  But right now I'd like to get a consistent release of these
artifacts so we can remove the need for the bootstrap step to check
them out and build them.

I'd like to discus for a few days, create a new proposal, vote and
then implement in the near future.

Comments?


You've got my support... :-) One specs version is what I've proposed  
in the past and would still like to see.


--kevan

Re: Endorsed dirs

IIRC you will get exceptions on a 1.4 JVM if xerces is not available  
since the local attribute manager uses a few custom xerces properties.


-dain

On Aug 27, 2006, at 10:47 PM, Jason Dillon wrote:

I guess we could try omitting the xerces jars from the classpath of  
server.jar and see if it works or not...


--jason


On Aug 26, 2006, at 5:41 PM, Heinz Drews wrote:


Everything loaded from directories specified by
-Djava.endorsed.dirs={dirlist} is loaded by the bootstrap  
classloader.

The documentation in Tomcat indicates that the endorsed dirs are
managed differently.  But the classes are visible in a classloader.

On 8/26/06, David Jencks [EMAIL PROTECTED] wrote:

IIRC Tomcat needs this stuff set only for validation: it doesn't
actually do _anything_ with the endorsed directories or their
contents to set up or influence any classloaders.

I think someone needs to do some experiments to determine:
- if the jars in endorsed need to be added explicitly to some
classloader
- if that classloader has to be the system (?? application??
boot??) classloader or if any classloader that includes a jar in
endorsed gets to use the stuff in the jar in preference to the stuff
in the jvm.

My unvalidated impression agrees with Dain

thanks
david jencks

On Aug 25, 2006, at 7:44 PM, anita kulshreshtha wrote:

IIRC, The tomcat container needs to be started with
 java.endorsed.dirs system property set to a dir where the xerces
 parser
 is available. It uses the endorsed dir mechanism to override the
 default parser. The server manifest.mf contains an entry
 Endorsed-Dirs: lib/endorsed
   which is used by Deamon (read by CommandLineManifest) to set  
this
 property before starting Geronimo. It should have been enough,  
but it
 seems we have been adding it to the classpath also. I do not  
know if

 this property is used by anyone else.

 Thanks
 Anita

 --- Dain Sundstrom [EMAIL PROTECTED] wrote:

 IIRC, they have to be on the classpath.

 -dain

 On Aug 25, 2006, at 12:21 PM, Jason Dillon wrote:

 Anyone know if the jars in the endorsed dir need to be added  
to the


 classpath... or will the jvm just suck up all *.jar files and  
load


 them anyways?

 Was just wondering that if that is the case, and we add them  
to the


 classpath, does that just waste bytes for an unused classloader
 and/
 or slow down the initial boot?

 --jason




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

[jira] Commented: (GERONIMODEVTOOLS-104) When TomcatWebContainer moved default location - plugin cannot publish projects

2006-08-28 Thread Oleg Gusakov (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-104?page=comments#action_12431016
 ] 

Oleg Gusakov commented on GERONIMODEVTOOLS-104:
---

 but the geronimo-web schema provides a web container element, and it seems 
 that all that needs to be done is to expose this element in the UI, in both 
 the plan editor and in the project creation wizard.

web-app provides container-config element. But the goal is not to define 
WebContainer on the WAR level, but rather point to a container defined 
somewhere up the hierarchy - in enclosing EAR or on server level. Though 
nothing prevents a user from fully defining WebContainer in geronimo-web.xml.

So both plan editor and the wizard should differenciate these two cases. Still 
- can you clarify if it is possible to include a reference to a WebContainer 
defined elsewhere into web deployment plan? This may solve the issue raised in 
this topic.

 When TomcatWebContainer moved default location - plugin cannot publish 
 projects
 ---

 Key: GERONIMODEVTOOLS-104
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-104
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.1.0
 Environment: IBM VM 1.5, Win2k SP4, Eclipse 3.2.0, Little-G 1.1
Reporter: Oleg Gusakov

 I defined Tomcat engine on the application level (in 
 geronimo-application.xml) because I need to define a lot of virtual hosts.
 When I try to deploy a project into the server - I get  
 org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve 
 reference Container in gbean 
 default/gtest2/1.0/car?J2EEApplication=null,j2eeType=WebModule,name=default/gtest2/1.0/car
  to a gbean matching the pattern [?name=TomcatWebContainer#]
 caused by org.apache.geronimo.kernel.GBeanNotFoundException: No matches for 
 referencePatterns: [?name=TomcatWebContainer#]
 Two problems here (or one as they have the same root cause):
 - plugin should be able to present user a choice of available web containers 
 to deploy to
 - what if I rename bean container (can I?) and it becomes 
 MyTomcatContainer35 ?

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

Re: Returning to Commit-Then-Review?

2006-08-28 Thread Aaron Mulder


On 8/28/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote:

Crock indeed.  The wiki is fine, it should be used in whatever
manners are considered the best, but it isn't our primary
means of communication.  For one thing it's pull rather
than push, so someone might miss a critical item simply
through forgetting to check the wiki.  For another, it's
not the primary communication medium of *any* ASF function,
so using it here would be raising an artificial barrier
between Geronimo and people from other projects.  Thirdly
- -- and this is the killer -- it's not archived holistically
with other discussions for future reference.  You don't
have discussions on a wiki.


The proposal you shot down wasn't to carry on a conversation on the
Wiki, but to summarize the conversation so far so that people who
didn't catch all the e-mails could stay in the loop.  FUD?

Thanks,
Aaron

[jira] Updated: (GERONIMO-2294) In security realm with multiple login modules, anything after the first is ignored

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

Donald Woods updated GERONIMO-2294:
---

Fix Version/s: 1.1.2
   1.2
   (was: 1.1.1)
Affects Version/s: 1.1.1
   1.1.2

 In security realm with multiple login modules, anything after the first is 
 ignored
 --

 Key: GERONIMO-2294
 URL: http://issues.apache.org/jira/browse/GERONIMO-2294
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 1.1, 1.1.1, 1.1.2
Reporter: Aaron Mulder
 Assigned To: Alan Cabrera
Priority: Blocker
 Fix For: 1.2, 1.1.2

 Attachments: GERONIMO-2294-2.patch, GERONIMO-2294.patch, 
 security-test-webapp.war, test-realm.xml


 If you deploy the attached plan to create a security realm the same as the 
 default except with a second login module, and put breakpoints in the login() 
 method of both login modules, the first login module is called twice as 
 expected (once to gather callbacks and again for real) but the second login 
 module is never called at all!
 The attached web app uses this realm, just deploy it at point to 
 http://localhost:8080/security/index.html to get the login, and put 
 breakpoints in 
 org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule and 
 org.apache.geronimo.security.realm.providers.RepeatedFailureLockoutLoginModule

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

[jira] Commented: (GERONIMODEVTOOLS-104) When TomcatWebContainer moved default location - plugin cannot publish projects

2006-08-28 Thread Sachin Patel (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-104?page=comments#action_12431017
 ] 

Sachin Patel commented on GERONIMODEVTOOLS-104:
---

Sorry I do not know.   David could you clarrify or answer what Oleg is asking?  
Is the container-config element not suffient?

 When TomcatWebContainer moved default location - plugin cannot publish 
 projects
 ---

 Key: GERONIMODEVTOOLS-104
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-104
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.1.0
 Environment: IBM VM 1.5, Win2k SP4, Eclipse 3.2.0, Little-G 1.1
Reporter: Oleg Gusakov

 I defined Tomcat engine on the application level (in 
 geronimo-application.xml) because I need to define a lot of virtual hosts.
 When I try to deploy a project into the server - I get  
 org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve 
 reference Container in gbean 
 default/gtest2/1.0/car?J2EEApplication=null,j2eeType=WebModule,name=default/gtest2/1.0/car
  to a gbean matching the pattern [?name=TomcatWebContainer#]
 caused by org.apache.geronimo.kernel.GBeanNotFoundException: No matches for 
 referencePatterns: [?name=TomcatWebContainer#]
 Two problems here (or one as they have the same root cause):
 - plugin should be able to present user a choice of available web containers 
 to deploy to
 - what if I rename bean container (can I?) and it becomes 
 MyTomcatContainer35 ?

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

Re: Anyone know how to make the kernel tests be quiet?

Not me.  They were quiet before the m2 change but it looks like  
logging got turned up.


-dain

On Aug 28, 2006, at 2:26 AM, Jason Dillon wrote:


These tests make way... way to much noise.

Anyone know how to make them shut up?

--jason

Re: Test failure in javamail 1.3.1 spec


On Aug 28, 2006, at 4:15 AM, Rick McGuire wrote:


Jacek Laskowski wrote:

On 8/28/06, Rick McGuire [EMAIL PROTECTED] wrote:
Grrr, I thought I finally had that test case working everywhere.   
What

platform are you running on?


[EMAIL PROTECTED] /cygdrive/c/oss/geronimo-specs/trunk
$ uname -a
CYGWIN_NT-5.1 dev 1.5.20(0.156/4/2) 2006-07-01 02:22 i686 Cygwin

[EMAIL PROTECTED] /cygdrive/c/oss/geronimo-specs/trunk
$ cmd
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

c:\oss\geronimo-specs\trunkver

Microsoft Windows XP [Version 5.1.2600]

c:\oss\geronimo-specs\trunkjava -version
java version 1.4.2_11
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_11-b06)
Java HotSpot(TM) Client VM (build 1.4.2_11-b06, mixed mode)


I'm guessing you're using a non-US English locale?
That's what I was afraid of.  The tests involving encoding/decoding  
using the default code pages have been causing problems because not  
all of the test characters can round-trip with all code pages.  I  
thought I had finally gotten that sorted out into a version that  
would run anywhere, but the solution once again proved elusive.   
For now, I've just commented out the tests that have been causing  
problems.

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


How about wrapping that test in a big 'if' block that only executes  
the test code if the locale is what you expect?


-dain

Re: Eclipse as development tool for Geronimo components

2006-08-28 Thread Heinz Drews


Hi Sachin,
The mvn eclipse:eclipse generates the .project files with the proper reference.
This solves the problem you mentioned.  Generally it would be a nice
start but naturally is the manual import a long and tedious exercise.
I guess an exported workspace might help.

With debugging there is currently the problem that o.g...Daemon
requires the server.jar which then refers the modules via the manifest
as jars.  This forces then to build with maven instead of directly
using the generated classes.
Just building the changed component is sufficient with exception of
the ones referring xmlbeans.

I was hoing that somebody had already made more progress but I will not give up.

Heinz

On 8/28/06, Sachin Patel [EMAIL PROTECTED] wrote:


One of the big problems is that you can not use pure Eclipse to develop
Geronimo. (just make code changes and compile)  The maven eclipse plugin
generates the .classpath in which all the projects reference only the built
jars in the maven repository rather then the projects set up to reference
each other.  This causes a huge annoyance in that every time you make a
change that affects another module, you will not see any compilation errors
since the modified module has to be rebuilt and redeployed with maven so
that the affected jar picks up the change.

Also using the maven plugin for eclipse doesn't help, and enabling the maven
build to occur using it helps the issue but makes the build process
extremlely long.  I haven't tried the m2 eclipse goal to see if it addresses
some of these issues or not.


On Aug 28, 2006, at 12:01 PM, Heinz Drews wrote:

Hello,

I want to use Eclipse for development and debugging of Geronimo components.
The Eclipse plugin I have already used for application development.

I have run mvn eclipse:eclipse, imported manually the projects but I'm
hoping for a faster approach.  And I'm facing several problems. First
I could not found the xmlbeans in the source tree, modules referring
them don't compile.  Then I have not found a way to run G directly
from the compilation produced by Eclipse.  Only approach now is to
build a module with Maven and  copy the jar to the Geronimo tree.

Help would be very much appreciated.
Regards,
Heinz


-sachin

Re: Returning to Commit-Then-Review?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Aaron Mulder wrote:
 
 The proposal you shot down wasn't to carry on a conversation on the
 Wiki, but to summarize the conversation so far so that people who
 didn't catch all the e-mails could stay in the loop.  FUD?

Yes, FUD.  Because I didn't shoot *anything* down.  I said:

 No, at least not solely.  They need to appear in email
 messages.

Read it again.  Can you say 'not only on the wiki'?  Can
you explain how that equates to 'don't use the wiki at all'?
- --
#kenP-(}

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

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

iQCVAwUBRPMlcZrNPMCpn3XdAQINegQAqDR//AcIbi7WaaDybe0rlGyQDRWWIADn
0/B/a6GwpKhzNd36Ps8h+zDmJ/NlKnUhUAZihLS8/ufyuQKZ2IlssiAWCFzzQgiI
5QA1tlFwMD4ovy6L2v2mlgXpOewuHnXhpCvBP8iDzE/dHT+wzowYd+5q4Q8cGBYs
GXlKOlvL1FA=
=Dc0u
-END PGP SIGNATURE-

Re: Change redirects/* to .htaccess RewriteRules


+1

-dain

On Aug 27, 2006, at 10:36 PM, Jason Dillon wrote:

Any objection to changing the meta http-equiv=refresh pages for  
redirects/* to use .htaccess RewriteRules?


Doing so will avoid the need for users to see the Redirecting your  
request... messages.  We can also use the rules to redirect urls w/ 
o page names, so like:


http://geronimo.apache.org/issues - http://issues.apache.org/ 
jira/browse/GERONIMO
http://geronimo.apache.org/wiki - http://cwiki.apache.org/ 
geronimo

...

How about it?

--jason

Re: Eclipse as development tool for Geronimo components

2006-08-28 Thread Sachin Patel

On Aug 28, 2006, at 1:17 PM, Heinz Drews wrote:Hi Sachin,The mvn eclipse:eclipse generates the .project files with the proper reference.This solves the problem you mentioned.  Generally it would be a nicestart but naturally is the manual import a long and tedious exercise.I guess an exported workspace might help.With debugging there is currently the problem that o.g...Daemonrequires the server.jar which then refers the modules via the manifestas jars.  This forces then to build with maven instead of directlyusing the generated classes.Yes that is correct.  Unfortunately there is no current solution for this.Just building the changed component is sufficient with exception ofthe ones referring xmlbeans.I was hoing that somebody had already made more progress but I will not give up.HeinzOn 8/28/06, Sachin Patel [EMAIL PROTECTED] wrote: One of the big problems is that you can not use pure Eclipse to developGeronimo. (just make code changes and compile)  The maven eclipse plugingenerates the .classpath in which all the projects reference only the builtjars in the maven repository rather then the projects set up to referenceeach other.  This causes a huge annoyance in that every time you make achange that affects another module, you will not see any compilation errorssince the modified module has to be rebuilt and redeployed with maven sothat the affected jar picks up the change.Also using the maven plugin for eclipse doesn't help, and enabling the mavenbuild to occur using it helps the issue but makes the build processextremlely long.  I haven't tried the m2 eclipse goal to see if it addressessome of these issues or not.On Aug 28, 2006, at 12:01 PM, Heinz Drews wrote:Hello,I want to use Eclipse for development and debugging of Geronimo components.The Eclipse plugin I have already used for application development.I have run mvn eclipse:eclipse, imported manually the projects but I'mhoping for a faster approach.  And I'm facing several problems. FirstI could not found the xmlbeans in the source tree, modules referringthem don't compile.  Then I have not found a way to run G directlyfrom the compilation produced by Eclipse.  Only approach now is tobuild a module with Maven and  copy the jar to the Geronimo tree.Help would be very much appreciated.Regards,Heinz-sachin  -sachin

Re: Eclipse as development tool for Geronimo components


Heinz,  what you're describing has been my experience with Eclipse as
well.  Depending on which part of Geronimo you change there are
different ways to get your changes loaded into the debug env.  In some
cases you can rebuild and then redeploy the code using the command
line interface, perhaps from a script you invoke from an eclipse
button.  In other cases you might need to rebuild a jar, shut down the
server, replace the jar in the repository directory, and then restart
the server.  In any case I haven't figured out a way to use hot
replace from the IDE, which would be nice.  As you know, debugging
applications in Eclipse is easier than debugging the server because
the Eclipse plugin handles the redeployment for you.

Best wishes,
Paul

On 8/28/06, Heinz Drews [EMAIL PROTECTED] wrote:

Hi Sachin,
The mvn eclipse:eclipse generates the .project files with the proper reference.
This solves the problem you mentioned.  Generally it would be a nice
start but naturally is the manual import a long and tedious exercise.
I guess an exported workspace might help.

With debugging there is currently the problem that o.g...Daemon
requires the server.jar which then refers the modules via the manifest
as jars.  This forces then to build with maven instead of directly
using the generated classes.
Just building the changed component is sufficient with exception of
the ones referring xmlbeans.

I was hoing that somebody had already made more progress but I will not give up.

Heinz

On 8/28/06, Sachin Patel [EMAIL PROTECTED] wrote:

 One of the big problems is that you can not use pure Eclipse to develop
 Geronimo. (just make code changes and compile)  The maven eclipse plugin
 generates the .classpath in which all the projects reference only the built
 jars in the maven repository rather then the projects set up to reference
 each other.  This causes a huge annoyance in that every time you make a
 change that affects another module, you will not see any compilation errors
 since the modified module has to be rebuilt and redeployed with maven so
 that the affected jar picks up the change.

 Also using the maven plugin for eclipse doesn't help, and enabling the maven
 build to occur using it helps the issue but makes the build process
 extremlely long.  I haven't tried the m2 eclipse goal to see if it addresses
 some of these issues or not.


 On Aug 28, 2006, at 12:01 PM, Heinz Drews wrote:

 Hello,

 I want to use Eclipse for development and debugging of Geronimo components.
 The Eclipse plugin I have already used for application development.

 I have run mvn eclipse:eclipse, imported manually the projects but I'm
 hoping for a faster approach.  And I'm facing several problems. First
 I could not found the xmlbeans in the source tree, modules referring
 them don't compile.  Then I have not found a way to run G directly
 from the compilation produced by Eclipse.  Only approach now is to
 build a module with Maven and  copy the jar to the Geronimo tree.

 Help would be very much appreciated.
 Regards,
 Heinz


 -sachin

[jira] Resolved: (SM-558) ComponentContext.resolveEndpointReference does not resolve JBI internal EPR format

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

Guillaume Nodet resolved SM-558.


Fix Version/s: 3.0-M3
   Resolution: Fixed
 Assignee: Guillaume Nodet

Author: gnodet
Date: Mon Aug 28 10:30:20 2006
New Revision: 437763

URL: http://svn.apache.org/viewvc?rev=437763view=rev
Log:
SM-558: ComponentContext.resolveEndpointReference does not resolve JBI internal 
EPR format
Patch provided by Maciej Szefler

Added:

incubator/servicemix/trunk/servicemix-core/src/test/java/org/apache/servicemix/jbi/framework/RegistryTest.java
Modified:

incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/Registry.java



 ComponentContext.resolveEndpointReference does not resolve JBI internal EPR 
 format
 --

 Key: SM-558
 URL: https://issues.apache.org/activemq/browse/SM-558
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-core
 Environment: all
Reporter: maciej szefler
 Assigned To: Guillaume Nodet
 Fix For: 3.0-M3

 Attachments: sm558.patch

   Original Estimate: 2 hours
  Remaining Estimate: 2 hours

 According to JBI spec, the internal EPR format:
  jbi:end-point-reference xmlns:jbi=http://java.sun.com/xml/ns/jbi;
   jbi:end-point-name=endpointName 
   jbi:service-name=foo:serviceName 
   xmlns:foo=urn:FooNamespace/
 should be supported by the ComponentContex.resolvedEndpointReference method. 
 Currently this is not the case.

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

Geronimo v1.2 documentation

2006-08-28 Thread Hernan Cunico


Hi All,
I would like to initiate a thread for discussing the topics to cover in 
the Geronimo v1.2 documentation.


The idea is to build a prioritized list and then derive it into a TOC.

What would you guys like to see in the Geronimo v1.2 doc?

Cheers!
Hernan

[jira] Assigned: (GERONIMO-2318) Database path validation not present

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

Donald Woods reassigned GERONIMO-2318:
--

Assignee: Donald Woods

 Database path validation not present
 

 Key: GERONIMO-2318
 URL: http://issues.apache.org/jira/browse/GERONIMO-2318
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 1.2, 1.1, 1.1.1, 1.1.2
 Environment: All Supported Platforms
Reporter: Manu T George
 Assigned To: Donald Woods
 Fix For: 1.2, 1.1.2


 On deploying pools referring to derby databases. Deployment is shown to be 
 sucessful but the pool does not start.
 Steps are given below
 (1)Logged into Administrative Console.
 (2)Clicked Database Pools.
 (3) Next, clicked Create a new database pool: Using the Geronimo database
 pool wizard.
 (4)Entered Name of Database Pool: CPRO and Database Type: Derby Embedded.
 Then clicked Next.
 (5)Thereafter entered the following:-
 JDBC Driver Class: org.apache.derby.jdbc.EmbeddedDriver
 Driver JAR: org.apache.derby/derby/10.1.2.ibm/jar
 DB Username: cpro
 DB Password: cpro
 Database: c:\cprodb\cprodb_COSMO\csdb
 Then clicked Next.
 (5)The next screen showed:-
 JDBC Connection URL: jdbc:derby:c:cprodbcprodb_COSMOcsdb (This being
 incorrect, it was changed to jdbc:derby:c:\cprodb\cprodb_COSMO\csdb).
 (6)Driver Status: Loaded successfully
 (7)Now clicked Test Connection. This showed:-
 Test Result: Connected to Apache Derby 10.1.2.4
 (8)Finally clicked Deploy It appears that this step was successful
 because:-
 (i)The DOS window showed Deployment completed successfully!
 Even though this happens when we refer to this DB Pool in an application
 error occurs.
 Thus there is no handling of '\' character in these two fields
 Giving '/' instead of '\' solves this issue

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

[jira] Updated: (GERONIMO-2318) Database path validation not present

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

Donald Woods updated GERONIMO-2318:
---

Fix Version/s: 1.1.2
   (was: 1.1.x)
Affects Version/s: 1.1.2
   1.2

 Database path validation not present
 

 Key: GERONIMO-2318
 URL: http://issues.apache.org/jira/browse/GERONIMO-2318
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 1.2, 1.1, 1.1.1, 1.1.2
 Environment: All Supported Platforms
Reporter: Manu T George
 Assigned To: Donald Woods
 Fix For: 1.2, 1.1.2


 On deploying pools referring to derby databases. Deployment is shown to be 
 sucessful but the pool does not start.
 Steps are given below
 (1)Logged into Administrative Console.
 (2)Clicked Database Pools.
 (3) Next, clicked Create a new database pool: Using the Geronimo database
 pool wizard.
 (4)Entered Name of Database Pool: CPRO and Database Type: Derby Embedded.
 Then clicked Next.
 (5)Thereafter entered the following:-
 JDBC Driver Class: org.apache.derby.jdbc.EmbeddedDriver
 Driver JAR: org.apache.derby/derby/10.1.2.ibm/jar
 DB Username: cpro
 DB Password: cpro
 Database: c:\cprodb\cprodb_COSMO\csdb
 Then clicked Next.
 (5)The next screen showed:-
 JDBC Connection URL: jdbc:derby:c:cprodbcprodb_COSMOcsdb (This being
 incorrect, it was changed to jdbc:derby:c:\cprodb\cprodb_COSMO\csdb).
 (6)Driver Status: Loaded successfully
 (7)Now clicked Test Connection. This showed:-
 Test Result: Connected to Apache Derby 10.1.2.4
 (8)Finally clicked Deploy It appears that this step was successful
 because:-
 (i)The DOS window showed Deployment completed successfully!
 Even though this happens when we refer to this DB Pool in an application
 error occurs.
 Thus there is no handling of '\' character in these two fields
 Giving '/' instead of '\' solves this issue

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

Re: [VOTE] XBean 2.6 release

-1 for the xbean-spring-itests-* jars -- are missing the NOTICE and  
LICENSE files


I don't think we should be publishing these jars, but FWIU there is  
currently no way to flag a tell maven to not publish certain modules.


You can verify my work by executing the following command from the  
publish directory on people.apache.org:


/home/gnodet/public_html/xbean-2.6/org/apache/xbean
[11:08:23] dain$ for n in $(find . -name '*.jar'); do echo ### $n;  
jar -tf $n | egrep (NOTICE|LICENSE); echo; done

### ./xbean-spring-common/2.6/xbean-spring-common-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./xbean-spring-v1/2.6/xbean-spring-v1-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./xbean-spring-v2/2.6/xbean-spring-v2-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./xbean-spring/2.6/xbean-spring-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./maven-xbean-plugin/2.6/maven-xbean-plugin-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./xbean-classloader/2.6/xbean-classloader-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./xbean-classpath/2.6/xbean-classpath-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./xbean-kernel/2.6/xbean-kernel-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./xbean-osgi/2.6/xbean-osgi-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./xbean-reflect/2.6/xbean-reflect-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./xbean-server/2.6/xbean-server-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./xbean-spring-itests-core/2.6/xbean-spring-itests-core-2.6.jar

### ./xbean-spring-itests-124/2.6/xbean-spring-itests-124-2.6.jar

### ./xbean-spring-itests-125/2.6/xbean-spring-itests-125-2.6.jar

### ./xbean-spring-itests-126/2.6/xbean-spring-itests-126-2.6.jar

### ./xbean-spring-itests-127/2.6/xbean-spring-itests-127-2.6.jar

### ./xbean-spring-itests-128/2.6/xbean-spring-itests-128-2.6.jar

### ./xbean-spring-itests-20m5/2.6/xbean-spring-itests-20m5-2.6.jar

### ./xbean-spring-itests-20rc1/2.6/xbean-spring-itests-20rc1-2.6.jar

### ./xbean-spring-itests-20rc2/2.6/xbean-spring-itests-20rc2-2.6.jar

### ./xbean-telnet/2.6/xbean-telnet-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./xbean-tiger/2.6/xbean-tiger-2.6.jar
META-INF/LICENSE
META-INF/NOTICE

### ./xbean-finder/2.6/xbean-finder-2.6.jar
META-INF/LICENSE
META-INF/NOTICE


On Aug 28, 2006, at 3:10 AM, Guillaume Nodet wrote:


I have tagged the xbean-2.6 branch
  http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.6/

and uploaded a version at
  http://people.apache.org/~gnodet/xbean-2.6/org/apache/xbean/

Please vote.
Here's my +1

As soon as the vote is off, I will upload the release to the m2  
repo at

   http://people.apache.org/repo/m2-ibiblio-rsync-repository/

--
Cheers,
Guillaume Nodet

Re: servicemix-http and normalization


I have not had time to fully review the patch, but here are a few remarks.

Some existing components
may already expose a WSDL 1.1 (as WSDL 2.0 is not supported
yet) which may contain a soap binding.  While this is not a good thing,
we need to cope with them.
That' s the reason why I don't really like the mechanism to auto-discover
the WSDL and engage the WSDL 1.1 normalization if the target
endpoint WSDL contain a soap binding.  I think this should be
configured with a flag on the http consumer endpoint.  And existing
components should be enhanced to use this normalization (but that' s
another problem).

Another slight oversight I think, is that the SoapHelper#findOperation
should
only check the WSDL for the current endpoint, and this WSDL should be
modified according to the binding used.  We should also provide a way to
easily configure the binding with default values (let's say just doclit /
rpc)
by setting a flag on the http endpoint.

So, while I think this is a really good patch that enhance the current http
component, it is part of a bigger feature.  It may even be linked to WSDL
2.0 support, or full rest support.

If I find enough time (may not be this week), I'll try to handle these two
points
in a simple way for the moment, so that this great and needed feature can be
used.  But if you want to take a look at it, feel free to do so.

Also, I think I have seen some removed / commented features about
security.  I think this is a patch I applied recently...


On 8/25/06, Alex Boisvert [EMAIL PROTECTED] wrote:


Hi all,

To follow-up on prior discussion around normalization, I've now created
a patch https://issues.apache.org/activemq/browse/SM-557 [1] that
provides WSDL 1.1 normalization for the servicemix-http component.
More specifically, the code provides a set of reusable classes for
converting between SOAP 1.1 messages and JBI messages using WSDL 1.1
definitions.  This code now sits in the servicemix-soap shared library
and I should mention that it's fairly strict about WS-I BasicProfile
compliance to reduce complexity and encourage people to write
interoperable service definitions.

I have not implemented a flag to turn normalization on/off.   It should
be pretty simple but I figured I'd throw it out there to see how people
want to configure this (e.g. in the WSDL?)

Feedback on the patch itself or the configuration aspect would be
appreciated.

cheers,
alex

[1] https://issues.apache.org/activemq/browse/SM-557






--
Cheers,
Guillaume Nodet

Re: [VOTE] Specs organization, versioning, and releasing

2006-08-28 Thread David Blevins



On Aug 28, 2006, at 10:51 AM, Dain Sundstrom wrote:

but for maven users I don't think either matters since you can  
simply use a version range dependency like this:


dependency
  groupIdorg.apache.geronimo.specs/groupId
  artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId
  version[1.0,)/version
/dependency

This gives you the most resent published version of the connector  
1.5 spec (BTW I tried this out in the jencks project and it worked  
perfectly).  Either solution for a maven user shouldn't be a problem.


So I think that leaves us with the question what is going to be  
easiest and quickest layout for us to release when we find a spec bug?


Seems like we could use that in our own pom.xml files and that would  
perfectly solve Kevan's original concern:


On Aug 22, 2006, at 6:24 AM, Kevan Miller wrote:
Well, the current activation spec is at version 1.1. When that  
version was bumped from 1.0 (or 1.0.x), you'd have needed to know/ 
remember to change the poms in the following specs: geronimo-spec- 
j2ee, geronimo-spec-javamail, geronimo-spec-jaxr, and geronimo-spec- 
saaj.


It would also address my concerns from eight months ago (which had  
nothing to do with easy vs hard, btw):


On Jan 29, 2006, at 1:41 PM, David Blevins wrote:
 1. issuing new versions of jars that don't change creates a  
confusing mess in public repos and classpaths.
 2. snapshots and new jars off all the specs is a terrible way to  
deal with one or two edge cases of jars that change.


Seems both concerns can be met.

-David

Re: [VOTE] Publish Genesis 1.0 to m2 central

2006-08-28 Thread David Blevins



On Aug 27, 2006, at 10:42 PM, Jason Dillon wrote:


[+1] Publish Genesis 1.0 to m2 central


-David

[ANNOUNCE] Welcome Anita Kulshreshtha as our newest committer

2006-08-28 Thread Jeff Genender

All,

We're pleased to let you know that we have a new committer in our midst.
 Anita Kulshreshtha has recently accepted an invitation to join the
Geronimo project.  Anita has been active on Geronimo for quite some time
and has provided numerous patches for the Maven2 build and Tomcat.

We're anxious to see Anita's continued enthusiasm and contributions to
the project.

Welcome Anita!

Re: [ANNOUNCE] Welcome Anita Kulshreshtha as our newest committer