[jira] Commented: (SM-625) Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.MultipleFlowsTest
[
https://issues.apache.org/activemq/browse/SM-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40378
]
Oleg Zhurakousky commented on SM-625:
-
You're right; there is no way of knowing if an Endpoint exists anywhere in the
cluster. But I think the question I am raising is: Would it be a good idea to
give a requester a benefit of the doubt. In other words if you ask for
something and I don't see it right away, I'll make an attempt and take some
time to look for it before I give you a definitive NO.
In this situation we are at the mercy of network, its speed and configuration
(something we can't control from SM) and I think the least we could do is to
give networking components to do what it is supposed to do and either come up
with an endpoint or with message stating a potential reason why endpoint was
not found.
Here is a sample code representing what I am talking about.
int retries = 0;
while (endpoints.length 1 || retries 5){
endpoints = resolveAvailableEndpoints(context, exchange);
Thread.sleep(500);
retries++;
}
Most of the time if Endpoint is there the loop will exit right away. It will
only execute retry logic if array is empty.
P.S. I am purposely trying to be a devils advocate here. I am not sure I
completely agree with this solution and mainly doing it to facilitate the
discussion since one thing I definitely agree. . . it is a part of the bigger
issue.
Meanwhile I'll be digging. . . .
Also, as far as fixing the test, I can definitely wrap the sendMessages(..)
call in the retry logic instead of relying on Thread.sleep(..) but would it
really solve a bigger problem. . .
Failed unit test (servicemix-core) :
org.apache.servicemix.jbi.nmr.flow.MultipleFlowsTest
-
Key: SM-625
URL: https://issues.apache.org/activemq/browse/SM-625
Project: ServiceMix
Issue Type: Sub-task
Components: servicemix-core
Affects Versions: 3.0
Reporter: Fritz Oconer
Fix For: 3.2
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SM-625) Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.MultipleFlowsTest
[
https://issues.apache.org/activemq/browse/SM-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40378
]
ozhurakousky edited comment on SM-625 at 10/15/07 5:38 AM:
---
You're right; there is no way of knowing if an Endpoint exists anywhere in the
cluster. But I think the question I am raising is: Would it be a good idea to
give a requester a benefit of the doubt. In other words if you ask for
something and I don't see it right away, I'll make an attempt and take some
time to look for it before I give you a definitive NO.
In this situation we are at the mercy of network, its speed and configuration
(something we can't control from SM) and I think the least we could do is to
give networking components to do what it is supposed to do and either come up
with an endpoint or with message stating a potential reason why endpoint was
not found.
Here is a sample code representing what I am talking about.
{code}
int retries = 0;
while (endpoints.length 1 || retries 5){
endpoints = resolveAvailableEndpoints(context, exchange);
Thread.sleep(500);
retries++;
}
{/code}
Most of the time if Endpoint is there the loop will exit right away. It will
only execute retry logic if array is empty.
P.S. I am purposely trying to be a devils advocate here. I am not sure I
completely agree with this solution and mainly doing it to facilitate the
discussion since one thing I definitely agree. . . it is a part of the bigger
issue.
Meanwhile I'll be digging. . . .
Also, as far as fixing the test, I can definitely wrap the sendMessages(..)
call in the retry logic instead of relying on Thread.sleep(..) but would it
really solve a bigger problem. . .
was (Author: ozhurakousky):
You're right; there is no way of knowing if an Endpoint exists anywhere in
the cluster. But I think the question I am raising is: Would it be a good idea
to give a requester a benefit of the doubt. In other words if you ask for
something and I don't see it right away, I'll make an attempt and take some
time to look for it before I give you a definitive NO.
In this situation we are at the mercy of network, its speed and configuration
(something we can't control from SM) and I think the least we could do is to
give networking components to do what it is supposed to do and either come up
with an endpoint or with message stating a potential reason why endpoint was
not found.
Here is a sample code representing what I am talking about.
int retries = 0;
while (endpoints.length 1 || retries 5){
endpoints = resolveAvailableEndpoints(context, exchange);
Thread.sleep(500);
retries++;
}
Most of the time if Endpoint is there the loop will exit right away. It will
only execute retry logic if array is empty.
P.S. I am purposely trying to be a devils advocate here. I am not sure I
completely agree with this solution and mainly doing it to facilitate the
discussion since one thing I definitely agree. . . it is a part of the bigger
issue.
Meanwhile I'll be digging. . . .
Also, as far as fixing the test, I can definitely wrap the sendMessages(..)
call in the retry logic instead of relying on Thread.sleep(..) but would it
really solve a bigger problem. . .
Failed unit test (servicemix-core) :
org.apache.servicemix.jbi.nmr.flow.MultipleFlowsTest
-
Key: SM-625
URL: https://issues.apache.org/activemq/browse/SM-625
Project: ServiceMix
Issue Type: Sub-task
Components: servicemix-core
Affects Versions: 3.0
Reporter: Fritz Oconer
Fix For: 3.2
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
ServiceMix Bean issues with send()
Hi I try to figure out what is going wrong with the ServiceMix Bean component when used with an asynchronous message exchange (send()). There is a good chance to I do not understand how the message exchange should work. This is what I tried: - Bean SU 1 sends an In-Out ME to another Bean SU 2 with send() on the Delivery Channel - B SU 2 handles the message and puts in an Out normalized message and then sends the ME back with send() on its Delivery Channel What I see is that the Delivery Channel is sending the Mirror ME which is nearly the same but just has the opposite role (here consumer). This means that the message is sent back to the Consumer Bean Endpoint because that is the address set in the Mirror ME. Is my assumption right that when a message is read from the NMR that it goes through the Provider endpoint and when the message is sent back that it then goes first through the Consumer endpoint of the same service or should it go to the Consumer endpoint of the calling service? If the consumer endpoint of he SAME service is called then who is responsible on sending the message back to the calling service (B SU 1) and is there a way to do this automatically (meaning with having to code anything in the Bean SUs)? Thank you Andreas Schaefer CEO of Madplanet.com Inc. [EMAIL PROTECTED] PGP.sig Description: This is a digitally signed message part
[jira] Created: (SM-1107) Deploy endpoints and listeners through the lwcontainer
Deploy endpoints and listeners through the lwcontainer -- Key: SM-1107 URL: https://issues.apache.org/activemq/browse/SM-1107 Project: ServiceMix Issue Type: New Feature Components: servicemix-lwcontainer Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ServiceMix Bean issues with send()
On 10/16/07, Andreas Schaefer (2) [EMAIL PROTECTED] wrote: Hi I try to figure out what is going wrong with the ServiceMix Bean component when used with an asynchronous message exchange (send()). There is a good chance to I do not understand how the message exchange should work. This is what I tried: - Bean SU 1 sends an In-Out ME to another Bean SU 2 with send() on the Delivery Channel - B SU 2 handles the message and puts in an Out normalized message and then sends the ME back with send() on its Delivery Channel What I see is that the Delivery Channel is sending the Mirror ME which is nearly the same but just has the opposite role (here consumer). This means that the message is sent back to the Consumer Bean Endpoint because that is the address set in the Mirror ME. Yeah. The thing is that in JBI, an exchange is sent from a component to an endpoint. In an InOut mep, the provider will send the exchange with the out message inside, the nmr will route it to the consumer component, which will dispatch it to the consumer endpoint. The endpoint processes the response and need to send back the exchange with a DONE status. The mirror stuff is used internally. Is my assumption right that when a message is read from the NMR that it goes through the Provider endpoint and when the message is sent back that it then goes first through the Consumer endpoint of the same service or should it go to the Consumer endpoint of the calling service? I don't understand what is the difference you make between Consumer endpoint of the same service and Consumer endpoint of the calling service ? Do you mean the POJO instance ? If the consumer endpoint of he SAME service is called then who is responsible on sending the message back to the calling service (B SU 1) and is there a way to do this automatically (meaning with having to code anything in the Bean SUs)? If you don't implement MessageExchangeListener and you want to use InOut asynchronously, then you need to use the @Callback annotation and the Destination. Else, I think the problem is that the component does not track that a given endpoint acts as a consumer and send an exchange, so that it can not route it back to the endpoint. This would require wrapping the DeliveryChannel or simply overriding the sendConsumerExchange method from the component. All exchanges sent from endpoints could be tracked, but we still don't have any way to call the bean, unless it has a @Callback. Can you post your beans, because servicemix-bean has different ways of writing a bean, so... Thank you Andreas Schaefer CEO of Madplanet.com Inc. [EMAIL PROTECTED] -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Commented: (SM-1097) Remote shell console based on GShell
[ https://issues.apache.org/activemq/browse/SM-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40388 ] Guillaume Nodet commented on SM-1097: - GShell integration has been moved to ServiceMix 4.0 branch. https://svn.apache.org/repos/asf/incubator/servicemix/branches/servicemix-4.0/gshell Remote shell console based on GShell Key: SM-1097 URL: https://issues.apache.org/activemq/browse/SM-1097 Project: ServiceMix Issue Type: New Feature Reporter: Guillaume Nodet Fix For: 4.0 Work is in progress at http://svn.apache.org/repos/asf/incubator/servicemix/branches/osgi/gshell/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3416) make some -test artifacts that for instance start up a mock server suitable for testing deployment parts
[ https://issues.apache.org/jira/browse/GERONIMO-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534756 ] Vamsavardhana Reddy commented on GERONIMO-3416: --- Related rev 566893. make some -test artifacts that for instance start up a mock server suitable for testing deployment parts Key: GERONIMO-3416 URL: https://issues.apache.org/jira/browse/GERONIMO-3416 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 There's a lot of duplicated code among the deployer tests. A lot of it could be simplified if we had one or two -test.jar artifacts from appropriate modules (kernel and system come to mind) that for instance set up a mock server with config stores, repos, etc etc started. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r584163 - /geronimo/server/branches/2.0.2/RELEASE_NOTES-2.0.2.txt
On 10/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: kevan Date: Fri Oct 12 06:45:18 2007 New Revision: 584163 URL: http://svn.apache.org/viewvc?rev=584163view=rev Log: Update MEJB group information Modified: geronimo/server/branches/2.0.2/RELEASE_NOTES-2.0.2.txt Modified: geronimo/server/branches/2.0.2/RELEASE_NOTES-2.0.2.txt URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.0.2/RELEASE_NOTES-2.0.2.txt?rev=584163r1=584162r2=584163view=diff == --- geronimo/server/branches/2.0.2/RELEASE_NOTES-2.0.2.txt (original) +++ geronimo/server/branches/2.0.2/RELEASE_NOTES-2.0.2.txt Fri Oct 12 06:45:18 2007 @@ -28,8 +28,11 @@ Significant Changes in the 2.0.2 Release +- Updated CA (Certification Authority) Helper on the Geronimo Administration Console +* Certificate requests and downloads are now supported using Internet Explorer I should have reported this early. This should read Updated CA (Certification Authority) Helper application. CA Helper application is not part of the Admin Console. Not a big thing though, but, do consider this change if there is an need to spin another RC. + - MEJB security issue fixed -* Access to the Maintenance EJB (MEJB) is now controlled by the mejb-read (read access) +* Access to the Maintenance EJB (MEJB) is now controlled by the admin (read access) and mejb-admin (read/write access) groups. - Changes in the default JNDI names for EJB's @@ -37,9 +40,6 @@ on the default JNDI names generated by Geronimo 2.0.1 will not work with Geronimo 2.0.2 For information on the new format, see http://cwiki.apache.org/GMOxDEV/client-jndi-names.html -- Updated CA (Certification Authority) Helper on the Geronimo Administration Console -* Certificate requests and downloads are now supported using Internet Explorer - - Multiple bug fixes * A number of issues are resolved by Geronimo 2.0.2. A summary of issues is provided below. @@ -146,11 +146,6 @@ To prevent potential security exposures, we strongly recommend you update the default user names and passwords on your system. -To enable MEJB access, you will need to configure either an mejb-user or -mejb-admin group. To enable read/write MEJB access to the 'system' user, -add the following to geronimo_home/var/security/groups.properties file: - -mejb-admin=system Deploying Applications -- @@ -196,9 +191,16 @@ changed are already included in the supplied config.xml file, while others may need to be added manually. +To enable MEJB write access, you will need to configure either an mejb-admin +group. For example, to enable read/write MEJB access to the 'system' user, +add the following to geronimo_home/var/security/groups.properties file: + +mejb-admin=system + Known Issues and Limitations + Spring jars packaged within the lib directory of an EAR file will not be accessible to web applications packaged within the same EAR file. To workaround this issue you must either override Spring class filtering which is automatically configured
Re: getting invalid option: -javaagent:
annaiah wrote: invalid option: -javaagent:C:\Profiler\lib\xyz.jar Do you see the -javaagent option when you do java -help? The latest version of Harmony on the site doesn't seem to have a -javaagent option. Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java version 1.5.0 pre-alpha : not complete or compatible svn = r580985, (Oct 8 2007), Linux/ia32/gcc 4.1.0, release build http://harmony.apache.org -- View this message in context: http://www.nabble.com/getting-invalid-option%3A--javaagent%3A-tf4612188s134.html#a13207890 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: getting invalid option: -javaagent:
We would like to know how to set this -javaagent parameter in JAVA_OPTS. We are facing some problem while running the geronima batch file with geronima debug command . I have copied the console message below after running the command geronima debug, I have made the font bold at the place of occurrence of the problem. E:\geronimo-1.1.1\bincall E:\geronimo-1.1.1\bin\setJavaEnv.bat xyz Profiler Home: C:\Xyzprofiler3.0 classpath: .;C:\Xyzprofiler3.0\lib\aspectjrt.jar;C:\Xyzprofiler3.0\li b\concrete.jar;C:\Xyzprofiler3.0\lib\aspects.jar;C:\Xyzprofiler3.0\lib\age nt.jar;C:\Xyzprofiler3.0\lib\servlet.jar Using GERONIMO_BASE: E:\geronimo-1.1.1 Using GERONIMO_HOME: E:\geronimo-1.1.1 Using GERONIMO_TMPDIR: E:\geronimo-1.1.1\var\temp Using JRE_HOME:C:\Program Files\Java\jdk1.5.0_02 Note: The jdb debugger will start Geronimo in another process and connect to it. To terminate Geronimo when running under jdb, run the geronimo stop comm and in another window. Do not use Ctrl-C as that will terminate the jdb clien t (the debugger itself) but will not stop the Geronimo process. JAVA_HOME = C:\Program Files\Java\jdk1.5.0_02 Radien Profiler Home: C:\Xyzprofiler3.0 classpath: C:\Xyzprofiler3.0;C:\Xyzprofiler3.0\lib\agent.jar; C:\XyzProfiler3.0\lib\aspects.jar;C:\Xyzprofiler3.0\lib\concrete.jar; C:\XyzProfiler3.0\lib\aspectjrt.jar;.;C:\Xyzprofiler3.0\lib\aspectjrt.jar; C:\XyzProfiler3.0\lib\concrete.jar;C:\Xyzprofiler3.0\lib\aspects.jar; C:\XyzProfiler3.0\lib\agent.jar;C:\Xyzprofiler3.0\lib\servlet.jar class path JVM_ARGS: -Xruninfprof *** // facing problem here invalid option: -javaagent:C:\Xyzprofiler3.0\lib\ajweaver.jar * Usage: jdb options class arguments where options include: -help print out this message and exit -sourcepath directories separated by ; directories in which to look for source files -attach address attach to a running VM at the specified address using stan dard connector -listen address wait for a running VM to connect at the specified address using standard connector -listenany wait for a running VM to connect at any available address using standard connector -launch launch VM immediately instead of waiting for 'run' command -listconnectors list the connectors available in this VM -connect connector-name:name1=value1,... connect to target VM using named connector with listed arg ument values -dbgtrace [flags] print info for debugging jdb -tclient run the application in the Hotspot(tm) Performance Engine (Client) -tserver run the application in the Hotspot(tm) Performance Engine (Server) options forwarded to debuggee process: -v -verbose[:class|gc|jni] turn on verbose mode -Dname=value set a system property -classpath directories separated by ; list directories in which to look for classes -Xoptionnon-standard target VM option class is the name of the class to begin debugging arguments are the arguments passed to the main() method of class For command help type 'help' at jdb prompt E:\geronimo-1.1.1\bin Please let me know , where the problem is occurring. Ted Kirby-2 wrote: Can you show the full java command-line invocation that is starting the server? Thanks, Ted Kirby On 10/12/07, annaiah [EMAIL PROTECTED] wrote: Hi all, we are running our application on Geronimo, we want our apllication to be profile by making use of a profiler to know details like CPU usage memory,time. So we are calling profiler in geronimo batch file. when we debug the geronimo batch file , we are getting the following message. invalid option: -javaagent:C:\Profiler\lib\xyz.jar the same profiler is working for other apllication server like JBoss, but not working well with the geronimo. we are unable to trace where the problem is . please could u tell where we are going wrong. -- View this message in context: http://www.nabble.com/getting-invalid-option%3A--javaagent%3A-tf4612188s134.html#a13171385 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/getting-invalid-option%3A--javaagent%3A-tf4612188s134.html#a13208645 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: svn commit: r584163 - /geronimo/server/branches/2.0.2/RELEASE_NOTES-2.0.2.txt
On Oct 15, 2007, at 3:06 AM, Vamsavardhana Reddy wrote: snip I should have reported this early. This should read Updated CA (Certification Authority) Helper application. CA Helper application is not part of the Admin Console. Not a big thing though, but, do consider this change if there is an need to spin another RC. Thanks Vamsi. I've updated the Wiki version (http://cwiki.apache.org/ confluence/display/GMOxDOC20/RELEASE-NOTES-2.0.2.TXT) with this change and and also changed maintenance EJB to management EJB in the MEJB bullet. I agree these changes don't require a new RC. Possible that the changes could be included as we roll out the release. --kevan
Re: [VOTE] Geronimo 2.0.2 (rc1)
+1 On Oct 12, 2007, at 9:57 PM, Kevan Miller wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/ jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/ ~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/ geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https:// svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https:// svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan
Re: [VOTE] Geronimo 2.0.2 (rc1)
+1 Kevan Miller wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http://people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https://svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https://svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan
Re: [VOTE] Geronimo 2.0.2 (rc1)
+1 Cheers Prasad On 10/12/07, Kevan Miller [EMAIL PROTECTED] wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/ ~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/ geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https:// svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https:// svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan
Re: [VOTE] Geronimo 2.0.2 (rc1)
+1 Prasad Kashyap wrote: +1 Cheers Prasad On 10/12/07, Kevan Miller [EMAIL PROTECTED] wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/ ~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/ geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https:// svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https:// svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan
[jira] Assigned: (GERONIMO-3309) Add missing LICENSE.txt and NOTICE.txt files to the J2G conversion tool
[ https://issues.apache.org/jira/browse/GERONIMO-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun reassigned GERONIMO-3309: - Assignee: Lin Sun (was: Kevan Miller) Add missing LICENSE.txt and NOTICE.txt files to the J2G conversion tool --- Key: GERONIMO-3309 URL: https://issues.apache.org/jira/browse/GERONIMO-3309 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: J2G Reporter: Jason Warner Assignee: Lin Sun Attachments: Geronimo-3309.patch, Geronimo-3309Update.patch The J2G conversion tool is missing the LICENSE.txt and NOTICE.txt files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Discuss] Remaining work items before we create a J2G 1.0.0 branch?
Kevan, I'll look at it. I agree the license issues should be fixed before we release j2g 1.0. Lin Kevan Miller wrote: On Oct 12, 2007, at 1:55 PM, Jason Warner wrote: Donald, I'm still unsure of the status of the license files for J2G. If we can get a confirmation that those are ok, then I'm all for releasing a 1.0.0. Otherwise, I think we should hold off. Right. They aren't ok. And must be fixed before j2g can be released. I had problems building and haven't gotten back to it... There's a jira (GERONIMO-3309) with 2 patches that are supposed to fix. If somebody can have a look, that'd be great... --kevan
Re: [VOTE] Geronimo 2.0.2 (rc1)
+1. briefly tested the tomcat jee5 assembly, able to start and using the database pool portlet. lin Kevan Miller wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http://people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https://svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https://svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan
Re: [VOTE] Geronimo 2.0.2 (rc1)
+1 Jarek On 10/12/07, Kevan Miller [EMAIL PROTECTED] wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/ ~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/ geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https:// svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https:// svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan
Re: [VOTE] Geronimo 2.0.2 (rc1)
+1 Tested geronimo-tomcat6-jee5-2.0.2-bin.zip with the sample web-apps at GERONIMO-3254 and everything ran fine. - Shiva On 10/13/07, Kevan Miller [EMAIL PROTECTED] wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/ ~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/ geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https:// svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https:// svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan
Re: [VOTE] Geronimo 2.0.2 (rc1)
+1 Kevan Miller wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http://people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https://svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https://svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan -- Thanks, Tim McConnell
Re: [VOTE] Geronimo 2.0.2 (rc1)
+1 Cheers! Hernan Kevan Miller wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http://people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https://svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https://svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan
Alternative packaging for monitoring collecting agent
Hi All, The monitoring plugin has been going smoothly, up until the recent MEJB security fix. The previous architecture was for the monitoring collecting agent (a GBean which resided on the server to be monitored) to interface with the MEJB. However, I was told that GBeans are not security configurable. This is a problem, because now the GBean cannot talk to the MEJB to collect statistics or any other JSR-77 information. David Jencks suggested to write an EJB instead of using a GBean. However, I wanted to use the GBean because of how nicely it stops/starts/fails with the server. I know that an EJB's constructor is called once it is started (this takes care of the doStart() functionality). But what about the doStop()/doFail()? Is there a way to for me to run some housekeeping code before the server or EAR is stopped? Or, does anyone else have a better idea of how to package the monitoring collecting agent so that it can be configured to overcome the security restrictions of the new MEJB? Thanks, Viet -- View this message in context: http://www.nabble.com/Alternative-packaging-for-monitoring-collecting-agent-tf4629861s134.html#a13220222 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: [VOTE] Geronimo 2.0.2 (rc1)
Thanks for the votes so far. The 72 hours expires at 10 PM (EDT), this evening. I'll give it a bit more time for others to inspect. I'll plan on calling the vote tomorrow morning -- around 9 AM my time... --kevan
Re: gshell broken in trunk?
This should be fixed now. Sorry for the delay. --jason On Oct 11, 2007, at 4:05 PM, David Jencks wrote: I see this also. I have no idea what caused it. I was wondering if we could all agree on some manual integration tests before committing to gshell so that the projects that depend on it can continue to work while it evolves. I think its great that ServiceMix is also starting to use gshell but without a stable released version we might need to be extra careful. I expect for geronimo building the boilerplate and framework assemblies and making sure the framework assembly starts w/gshell would suffice. Is there something fairly simple we could do for a SM smoke test? thanks david jencks On Oct 11, 2007, at 3:14 PM, Jeff Genender wrote: When I try to start the server with gshell...I am getting this: java.lang.NullPointerException: Cannot get property: homeDir on null object at org.codehaus.groovy.runtime.Invoker.getProperty (Invoker.java:179) at org.codehaus.groovy.runtime.InvokerHelper.getProperty (InvokerHelper.java:179) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty (ScriptBytecodeAdapter.java:469) at org.apache.geronimo.commands.StartServerCommand.doExecute (StartServerCommand.groovy:159) at org.apache.geronimo.gshell.command.CommandSupport.execute (CommandSupport.java:103) at org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute (PlexusCommandWrapper.java:71) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute (DefaultCommandExecutor.java:128) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute (DefaultCommandExecutor.java:97) at org.apache.geronimo.gshell.DefaultShell.execute(DefaultShell.java: 124) at org.apache.geronimo.gshell.DefaultShell.run(DefaultShell.java:209) at org.apache.geronimo.gshell.GShell.run(GShell.java:156) at org.apache.geronimo.gshell.cli.Main.boot(Main.java:247) at org.apache.geronimo.gshell.cli.Main.main(Main.java:264) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:408) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:351) at org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)
[jira] Commented: (GERONIMO-3309) Add missing LICENSE.txt and NOTICE.txt files to the J2G conversion tool
[ https://issues.apache.org/jira/browse/GERONIMO-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534966 ] Lin Sun commented on GERONIMO-3309: --- I think there are a few remaining work items need to be done for this jira (checked in some of the patch in rev 584907 - -make sure all the jars we include in the plugin jars are needed for runtime. I removed junit today as it is only used at build time. -update license and notice file. I checked in the proposed build script changes to include the license and notice files when they are in place. Add missing LICENSE.txt and NOTICE.txt files to the J2G conversion tool --- Key: GERONIMO-3309 URL: https://issues.apache.org/jira/browse/GERONIMO-3309 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: J2G Reporter: Jason Warner Assignee: Lin Sun Attachments: Geronimo-3309.patch, Geronimo-3309Update.patch The J2G conversion tool is missing the LICENSE.txt and NOTICE.txt files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-630) org.apache.servicemix.jbi.messaging.JcaFlowTransactionTest
[ https://issues.apache.org/activemq/browse/SM-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40383 ] Oleg Zhurakousky commented on SM-630: - Quick comment The scenarios within this test seem to be following what's described here: http://incubator.apache.org/servicemix/transactions.html Each test is encapsulated in the try/catch block with fail(. . .) call which never gets executed (and it shouldn't). If there is any other problems I can't seem to replicate it other then a potential issue with clustered send/receives, but they all part of the bigger issue where there is not enough time (especially on the good hardware) for Demand Forwarding Bridge to setup. org.apache.servicemix.jbi.messaging.JcaFlowTransactionTest -- Key: SM-630 URL: https://issues.apache.org/activemq/browse/SM-630 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Build issue with trunk - build hangs
Is nobody else hitting this problem?
Is anybody else building on OpenSUSE? I have two machines and get hang
in the same place on each machine while trying to install the
car-maven-plugin.
Even bumping my MAVEN_OPTS to -XX:MaxPermSize=512m -Xms512m -Xmx1024m
didn't seem to have any effect.
Joe
Joe Bohn wrote:
I'm consistently hitting a build hang with trunk that I can't get past.
Is anybody else hitting these problems or does anybody know what might
be going wrong? Perhaps I need to bump up the MaxPermSize?
The build hangs when I get to building the car-maven-plugin. This is on
OpenSUSE 10.2 with maven 2.0.7 (although I had the failures first with
2.0.5 and moving to 2.0.7 didn't change the results) and Sun JDK 1.5.0_11.
My MAVEN_OPTS are set to:
-XX:MaxPermSize=128m -Xms512m -Xmx512m
Here's the last thing I always see:
---
T E S T S
---
Running org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.6 sec
Running org.apache.geronimo.mavenplugins.car.PluginMetadataTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.691 sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/jbohn/geronimo/maven-plugins/car-maven-plugin/target/car-maven-plugin-2.1-SNAPSHOT.jar
[INFO] [plugin:addPluginArtifactMetadata]
[INFO] [shitty:install {execution: default}]
[INFO] Installing
/home/jbohn/geronimo/maven-plugins/car-maven-plugin/target/car-maven-plugin-2.1-SNAPSHOT.jar
to
/home/jbohn/.m2/repository/org/apache/geronimo/plugins/car-maven-plugin/2.1-SNAPSHOT/car-maven-plugin-2.1-SNAPSHOT.jar
Re: Build issue with trunk - build hangs
Joe,
I was running into the same issue on CentOS, my MAVEN_OPTS were -Xmx512m
-XX:MaxPermSize=128m.
After I changed them to -Xmx2048m -XX:MaxPermSize=512m , the problem
went away immediately.
This is on Maven 2.0.7 and Sun JDK 1.5.0_12
Dunno if that will help you at all, but there you go =)
-Erik
Joe Bohn wrote:
Is nobody else hitting this problem?
Is anybody else building on OpenSUSE? I have two machines and get
hang in the same place on each machine while trying to install the
car-maven-plugin.
Even bumping my MAVEN_OPTS to -XX:MaxPermSize=512m -Xms512m
-Xmx1024m didn't seem to have any effect.
Joe
Joe Bohn wrote:
I'm consistently hitting a build hang with trunk that I can't get
past. Is anybody else hitting these problems or does anybody know
what might be going wrong? Perhaps I need to bump up the MaxPermSize?
The build hangs when I get to building the car-maven-plugin. This is
on OpenSUSE 10.2 with maven 2.0.7 (although I had the failures first
with 2.0.5 and moving to 2.0.7 didn't change the results) and Sun JDK
1.5.0_11.
My MAVEN_OPTS are set to:
-XX:MaxPermSize=128m -Xms512m -Xmx512m
Here's the last thing I always see:
---
T E S T S
---
Running org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.6 sec
Running org.apache.geronimo.mavenplugins.car.PluginMetadataTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.691
sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/jbohn/geronimo/maven-plugins/car-maven-plugin/target/car-maven-plugin-2.1-SNAPSHOT.jar
[INFO] [plugin:addPluginArtifactMetadata]
[INFO] [shitty:install {execution: default}]
[INFO] Installing
/home/jbohn/geronimo/maven-plugins/car-maven-plugin/target/car-maven-plugin-2.1-SNAPSHOT.jar
to
/home/jbohn/.m2/repository/org/apache/geronimo/plugins/car-maven-plugin/2.1-SNAPSHOT/car-maven-plugin-2.1-SNAPSHOT.jar
Re: [VOTE] Geronimo 2.0.2 (rc1)
+1 david jencks On Oct 12, 2007, at 6:57 PM, Kevan Miller wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/ jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/ ~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/ geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https:// svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https:// svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan
Re: gshell broken in trunk?
Thanks! Sent from my iPhone On Oct 15, 2007, at 2:22 PM, Jason Dillon [EMAIL PROTECTED] wrote: This should be fixed now. Sorry for the delay. --jason On Oct 11, 2007, at 4:05 PM, David Jencks wrote: I see this also. I have no idea what caused it. I was wondering if we could all agree on some manual integration tests before committing to gshell so that the projects that depend on it can continue to work while it evolves. I think its great that ServiceMix is also starting to use gshell but without a stable released version we might need to be extra careful. I expect for geronimo building the boilerplate and framework assemblies and making sure the framework assembly starts w/gshell would suffice. Is there something fairly simple we could do for a SM smoke test? thanks david jencks On Oct 11, 2007, at 3:14 PM, Jeff Genender wrote: When I try to start the server with gshell...I am getting this: java.lang.NullPointerException: Cannot get property: homeDir on null object at org.codehaus.groovy.runtime.Invoker.getProperty (Invoker.java:179) at org.codehaus.groovy.runtime.InvokerHelper.getProperty (InvokerHelper.java:179) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty (ScriptBytecodeAdapter.java:469) at org.apache.geronimo.commands.StartServerCommand.doExecute (StartServerCommand.groovy:159) at org.apache.geronimo.gshell.command.CommandSupport.execute (CommandSupport.java:103) at org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute (PlexusCommandWrapper.java:71) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute (DefaultCommandExecutor.java:128) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute (DefaultCommandExecutor.java:97) at org.apache.geronimo.gshell.DefaultShell.execute(DefaultShell.java: 124) at org.apache.geronimo.gshell.DefaultShell.run(DefaultShell.java:209) at org.apache.geronimo.gshell.GShell.run(GShell.java:156) at org.apache.geronimo.gshell.cli.Main.boot(Main.java:247) at org.apache.geronimo.gshell.cli.Main.main(Main.java:264) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:408) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:351) at org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)
Re: [VOTE] Geronimo 2.0.2 (rc1)
+1 Anita --- Kevan Miller [EMAIL PROTECTED] wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/ ~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/ geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https:// svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https:// svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
