[jira] Reopened: (SM-628) org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest
[ https://issues.apache.org/activemq/browse/SM-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reopened SM-628: FYI, we tend to resolve issue when the patches are actually committed (but maybe we should change that, as we don't make much differences between resolved and closed: how do you usually use these two states ?) Wrt to your patch, the idea is good. However, this job should be handled by the MessageList. For example, when calling: receiver.getMessageList().assertMessagesReceived(NUM_MESSAGES); the assertMessagesReceived calls waitForMessagesToArrive which already waits for the number of message to arrive. if extending the timeout is sufficient, maybe we should just change the default timeout in the MessageList from 4000 ms to much more. Wdyt ? org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest -- Key: SM-628 URL: https://issues.apache.org/activemq/browse/SM-628 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: 3.0 Reporter: Fritz Oconer Fix For: 3.2 Attachments: SMTestCasesPatches.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-628) org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest
[ https://issues.apache.org/activemq/browse/SM-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky resolved SM-628. - Resolution: Fixed I was able to replicate inconsistencies of this and other similar tests and figure out why they were so unstable. Even though in the async message world we have to do something to give messages enough time to arrive It is hard to rely on Thread.sleep(...). Some of us have better hardware then others, thus making it difficult to know the optimum time needed for messages to arrive. Here is what I did to make sure that I am right Firs I ran this test several times with different Thread.sleep(..) values and start noticing that 9 out of 10 times it will run just fine, but then it would fail the test (mostly in the Cluster portion of the test) failing on this line: assertFalse(receiver.getMessageList().hasReceivedMessage()); That was interesting because we are flushing all the messages before each message batch send. I was even able to verify with few debug statements that receivers are empty. I start suspecting that messages were still arriving after flush was executed. To verify it I had to modify the message content to include some type of unique identifier. When I did (simple static counter such as 1, 2, 3, 4 . . . etc.), everything became clear. First test in the cluster test sends a batch of 10 messages with identifier 1, then flush, then second batch with identifier 2 and so on. Well, very quickly I start seeing that occasionally after sending second batch with identifier 2, I would still get a message on the receiver with identifier 1. So, that is pretty much the story, if you guys need more details, just let me know. The good news is that there are several tests that are very similar (JCAFlowTest, MultimpleJMSFlowTest etc.) which have the same problem and obviously the same fix. I am recommending the attached two patches. One is a new class (ClusterFlowTestHelper) that should be a base class for all the tests similar to JMSFlow test and obviously JMSFlowTest patch which removes all the Thread.sleep(), extends ClusterFlowTestHelper and calls its helper methods to verify that messages were received. Currently I am setting the timeout to 4000 msc even though on my machine all 10 messages arrive in under 200 msc. I've also added another assert, so if after all messages do not arrive in the allotted time, then the test will fail (but at least we'll know exactly why). If you agree with the proposed solution, I'll take care of all other tests in the similar way. org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest -- Key: SM-628 URL: https://issues.apache.org/activemq/browse/SM-628 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: 3.0 Reporter: Fritz Oconer Fix For: 3.2 Attachments: SMTestCasesPatches.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ServiceMix board report - oct 2007
This report for October is the first report since ServiceMix graduation last month. ServiceMix resources have not been moved yet. Hopefully everything will be sorted out soon. We have released our first non incubating version of ServiceMix, the 3.1.2 version, on September 25th. We are currently preparing for our next big release, ServiceMix 3.2, which is planned for the end of October. Work has started on the next major version 4.0 which will be based on OSGi. On the community side, both developer and user community are very active. A new committer has been voted in. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Commented: (SM-624) Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.jms.MultipleJMSFlowTest
[ https://issues.apache.org/activemq/browse/SM-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40368 ] Oleg Zhurakousky commented on SM-624: - Can someone please give me quick pointer on this one. This test only has one test() method which basically follows the flow of 1. Create 4 containers 2. Start 4 Containers 3. Activate Receivers in these containers and so on Then stopping and starting again and producing log messages that look like this: 13:50:33,671 | INFO | main | MultipleJMSFlowTest | nmr.flow.jms.MultipleJMSFlowTest 103 | Nodes: 0, 0, 0, 0 13:50:33,703 | INFO | main | JBIContainer | cemix.jbi.container.JBIContainer 642 | ServiceMix JBI Container (container0) started 13:50:37,703 | INFO | main | MultipleJMSFlowTest | nmr.flow.jms.MultipleJMSFlowTest 103 | Nodes: 1, 0, 0, 0 13:50:37,703 | WARN | main | ClientFactory| emix.jbi.framework.ClientFactory 89 | Cound not start ClientFactory: javax.naming.NamingException: Something already bound at ClientFactory 13:50:37,718 | INFO | main | JBIContainer | cemix.jbi.container.JBIContainer 642 | ServiceMix JBI Container (container1) started 13:50:41,718 | INFO | main | MultipleJMSFlowTest | nmr.flow.jms.MultipleJMSFlowTest 103 | Nodes: 2, 2, 0, 0 13:50:41,718 | WARN | main | ClientFactory| emix.jbi.framework.ClientFactory 89 | Cound not start ClientFactory: javax.naming.NamingException: Something already bound at ClientFactory 13:50:41,734 | INFO | main | JBIContainer | cemix.jbi.container.JBIContainer 642 | ServiceMix JBI Container (container2) started 13:50:45,734 | INFO | main | MultipleJMSFlowTest | nmr.flow.jms.MultipleJMSFlowTest 103 | Nodes: 3, 3, 3, 0 13:50:45,734 | WARN | main | ClientFactory| emix.jbi.framework.ClientFactory 89 | Cound not start ClientFactory: javax.naming.NamingException: Something already bound at ClientFactory 13:50:45,750 | INFO | main | JBIContainer | cemix.jbi.container.JBIContainer 642 | ServiceMix JBI Container (container3) started 13:50:49,750 | INFO | main | MultipleJMSFlowTest | nmr.flow.jms.MultipleJMSFlowTest 103 | Nodes: 4, 4, 4, 4 There are no assertions, and so far it does not produce any errors What was the thought behind this test? Could it be incomplete? Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.jms.MultipleJMSFlowTest --- Key: SM-624 URL: https://issues.apache.org/activemq/browse/SM-624 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: 3.0 Environment: Windows and linux 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] Updated: (SM-1100) Allow containerName to be specified on the command line for projectDeploy
[ https://issues.apache.org/activemq/browse/SM-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Greer updated SM-1100: Attachment: mojo-containerName-patch.txt Allow containerName to be specified on the command line for projectDeploy - Key: SM-1100 URL: https://issues.apache.org/activemq/browse/SM-1100 Project: ServiceMix Issue Type: New Feature Components: tooling Reporter: Brian Greer Priority: Minor Attachments: mojo-containerName-patch.txt The containerName should be specifiable from the command line during deploy, e.g.: mvn jbi:projectDeploy -DcontainerName=mycontainer Patch is attached. -- 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-628) org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest
[ https://issues.apache.org/activemq/browse/SM-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40363 ] ozhurakousky edited comment on SM-628 at 10/12/07 6:23 AM: --- I agree and that was my initial thought to include the timeout logic as part of MessageList or reuse the existing method. The issue that I see is that MessageList represents one receiver. Most of these instabilities were occurring during a cluster test which means we were dealing with more then one receiver and when more then once receiver is active I observed that messages are equally spread between them (i.e., 10 messages, 2 receivers, each receives 5.) which means I can't even use MessageList logic since in the cluster world the amount of messages received by one receiver is not always equal to the amount of messages sent. Even if I assume that such load balancing (2 receivers 5 each) is true round robin and I could potentially reuse MessageList logic (receiver.getMessageList().assertMessagesReceived(NUM_MESSAGES);) by dividing the amount of messages sent by the amount received and place it in NUM_MESSAGES value when I di this check, I have to make sure that in my tests I always have the amount of messages sent divisible my the amount of receivers without a remainder, otherwise if I send 9 messages one receiver gets 5 while other gets 4. Which one ??? I would not know. So, the method I proposed in my patch is to have and independent process that sums the amount of messages form all receivers by actually using MessageList.getMessageCount(). NOTE: Just thought about something. I can reuse waitForMessagesToArrive(..) method in my ClusterHelperTest, to eliminate my timeout logic, but I still have to sum all of the messages before I return true or false. As to your other question about Resolve. I do not have a huge ego nor do I have any problems with it plus I am just starting my contribution with SM, so I would not mind some one watching a bit over what I do for a while (first time I crashed and burned. . .remember). So I would still like to use Resolve as the way of suggesting a FIX and acceptance of such FIX by peers would grant the Close of issue. We actually use this process internaly in my company was (Author: ozhurakousky): I agree and that was my initial thought to include the timeout logic as part of MessageList or reuse the existing method. The issue that I see is that MessageList represents one receiver. Most of these instabilities were occurring during a cluster test which means we were dealing with more then one receiver and when more then once receiver is active I observed that messages are equally spread between them (i.e., 10 messages, 2 receivers, each receives 5.) which means I can't even use MessageList logic since in the cluster world the amount of messages received by one receiver is not always equal to the amount of messages sent. Even if I assume that such load balancing (2 receivers 5 each) is true round robin and I could potentially reuse MessageList logic (receiver.getMessageList().assertMessagesReceived(NUM_MESSAGES);) by dividing the amount of messages sent by the amount received and place it in NUM_MESSAGES value when I di this check, I have to make sure that in my tests I always have the amount of messages sent divisible my the amount of receivers without a remainder, otherwise if I send 9 messages one receiver gets 5 while other gets 4. Which one ??? I would not know. So, the method I proposed in my patch is to have and independent process that sums the amount of messages form all receivers by actually using MessageList.getMessageCount(). As to your other question about Resolve. I do not have a huge ego nor do I have any problems with it plus I am just starting my contribution with SM, so I would not mind some one watching a bit over what I do for a while (first time I crashed and burned. . .remember). So I would still like to use Resolve as the way of suggesting a FIX and acceptance of such FIX by peers would grant the Close of issue. We actually use this process internaly in my company org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest -- Key: SM-628 URL: https://issues.apache.org/activemq/browse/SM-628 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: 3.0 Reporter: Fritz Oconer Fix For: 3.2 Attachments: SMTestCasesPatches.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-1100) Allow containerName to be specified on the command line for projectDeploy
[ https://issues.apache.org/activemq/browse/SM-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Greer updated SM-1100: Attachment: (was: mojo-containerName-patch.txt) Allow containerName to be specified on the command line for projectDeploy - Key: SM-1100 URL: https://issues.apache.org/activemq/browse/SM-1100 Project: ServiceMix Issue Type: New Feature Components: tooling Reporter: Brian Greer Priority: Minor Attachments: mojo-containerName-patch.txt The containerName should be specifiable from the command line during deploy, e.g.: mvn jbi:projectDeploy -DcontainerName=mycontainer Patch is attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: KEYS ?
On 10/12/07, Kevan Miller [EMAIL PROTECTED] wrote: I don't know of any reason to maintain KEYS files in any other svn directory. I propose we delete them from all non-tagged branches/trunks in our svn tree. Thoughts? Was there a reason to keep them in the other places? I'd love to hear what it was so I could say for sure I'm +1 for the single place. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [VOTE] Release geronimo-txmanager 2.0.2
+1 ++Vamsi On 10/10/07, Kevan Miller [EMAIL PROTECTED] wrote: As discussed in the Geronimo 2.0.2 release discussion thread, we need to release geronimo-txmanager 2.0.2 to pick up fixes for the Geronimo 2.0.2 release. geronimo-txmanager contains the geronimo-transaction and geronimo-connector components. The proposed binary release artifacts can be found here -- http:// people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2.zip Your can browse these artifacts here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2/ The source for the release is currently here -- https:// svn.apache.org/repos/asf/geronimo/components/txmanager/branches/2.0.2 Once released, I'll tag this source as -- https://svn.apache.org/ repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager- parent-2.0.2 For your convenience, a zip file containing this source is here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2-src.zip A RAT report for this source is here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2-rat.txt Please vote on this release. [ ] +1 Release geronimo-txmanager 2.0.2 [ ] 0 No opinion [ ] -1 Do not release geronimo-txmanager 2.0.2 Barring any problems or ongoing discussions, I'll plan on calling the vote at 8 AM (EDT) on Saturday October 13. --kevan -- Vamsi ([EMAIL PROTECTED]) (Committer and Member of Apache Geronimo PMC) Blog: http://vamsic007.livejournal.com/ One-stop-shop for configuring JEE Application security in Geronimo ApacheCon US 2007 http://us.apachecon.com/us2007/program/talk/1977 OS Summit Asia 2007 http://www.ossummit.com/2007/program/talk/15
getting invalid option: -javaagent:
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.
Re: geronimo-dependency.xml
On 10/12/07, David Jencks [EMAIL PROTECTED] wrote: On Oct 12, 2007, at 8:28 AM, Prasad Kashyap wrote: This is geronimo's transitive depenendency feature. When you include a jar with such a file in a configuration's dependencies, all the jars listed in the g-d.xml file also get included (recursively). I'm not longer sure this g-d.xml file is a wonderful idea. There aren't that many of them and they seem to mostly cause confusion. Yes, it's definitely confusing me :) Should we try to eliminating the geronimo-dependency.xml files that we have right now? I can take a stab at it if people agree. Jarek
Re: [Discuss] Remaining work items before we create a J2G 1.0.0 branch?
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: [Discuss] Remaining work items before we create a J2G 1.0.0 branch?
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. By the way, the patches seem to be missing a number of license files. Possible that some files hadn't been svn add'ed when the patch was generated? --kevan
Re: [VOTE] Release geronimo-txmanager 2.0.2
+1 -Donald Kevan Miller wrote: As discussed in the Geronimo 2.0.2 release discussion thread, we need to release geronimo-txmanager 2.0.2 to pick up fixes for the Geronimo 2.0.2 release. geronimo-txmanager contains the geronimo-transaction and geronimo-connector components. The proposed binary release artifacts can be found here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2.zip Your can browse these artifacts here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2/ The source for the release is currently here -- https://svn.apache.org/repos/asf/geronimo/components/txmanager/branches/2.0.2 Once released, I'll tag this source as -- https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.0.2 For your convenience, a zip file containing this source is here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2-src.zip A RAT report for this source is here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2-rat.txt Please vote on this release. [ ] +1 Release geronimo-txmanager 2.0.2 [ ] 0 No opinion [ ] -1 Do not release geronimo-txmanager 2.0.2 Barring any problems or ongoing discussions, I'll plan on calling the vote at 8 AM (EDT) on Saturday October 13. --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: KEYS ?
I think we should keep the KEYS file in trunk and copy it to dist when we're releasing... On Oct 12, 2007, at 12:07 AM, Kevan Miller wrote: On Aug 8, 2007, at 3:08 PM, Jason Dillon wrote: And... this is done. I don't know what else needs to be changed... if anyone runs into any problems lemme know. The new location for this puppy in svn is: https://svn.apache.org/repos/asf/geronimo/KEYS Props need to check the current trunk/* and branches/* (except for release in progress branches) bits for other KEYS files and nuke them. I just encountered our proliferation of KEYS files. From an Apache release signing perspective, I think the only important file is http://www.apache.org/dist/geronimo/KEYS. Probably makes sense to keep this file and https://svn.apache.org/repos/asf/geronimo/KEYS in sync (they are currently not in sync). I'm not sure if it's possible to automate this... Ideas? I don't know of any reason to maintain KEYS files in any other svn directory. I propose we delete them from all non-tagged branches/ trunks in our svn tree. Thoughts? --kevan
Re: [jira] Resolved: (GERONIMO-3508) Still cannot build branches/2.0 without building OpenEJB first, due to XBean depends
I was still running into this with the latest 2.0.2-SNAPSHOT level tonight on SLED10, but I can manually add the OpenEJB svn repo for now, since this only seems to be a problem on my machines -Donald Kevan Miller (JIRA) wrote: [ https://issues.apache.org/jira/browse/GERONIMO-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller resolved GERONIMO-3508. Resolution: Fixed I just updated my build version from 2.0.2-SNAPSHOT to 2.0.2. And built from a clean repo. My build succeeded *and* the private builds of xbean and commons-dbcp were not downloaded. So, I think this issue is fixed... Donald, hoping you can verify? Still cannot build branches/2.0 without building OpenEJB first, due to XBean depends Key: GERONIMO-3508 URL: https://issues.apache.org/jira/browse/GERONIMO-3508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0.2 Reporter: Donald Woods Priority: Blocker Fix For: 2.0.2 Unless you build openejb-3.0-beta-1 first, you will not be able to build Geronimo 2.0.2 (client-corba-yoko config build fails), because of the private xbean revisioned jars that are referenced by the openejb POM. The private versions are located by their build by - repository idopenejb-3rdparty-builds/id name3rd Party Build Repository/name urlhttp://svn.apache.org/repos/asf/openejb/repo//url [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.xbean:xbean-naming:jar:3.2-r579367 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.xbean -DartifactId=xbean-nam ing \ -Dversion=3.2-r579367 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.xbean -DartifactId=xbean-naming \ -Dversion=3.2-r579367 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.configs:client-corba-yoko:car:2.0.2-SNAPSHOT 2) org.apache.geronimo.configs:openejb-corba-deployer:car:2.0.2-SNAPSHOT 3) org.apache.geronimo.configs:j2ee-deployer:car:2.0.2-SNAPSHOT 4) org.apache.geronimo.modules:geronimo-client:jar:2.0.2-SNAPSHOT 5) org.apache.geronimo.modules:geronimo-naming:jar:2.0.2-SNAPSHOT 6) org.apache.xbean:xbean-naming:jar:3.2-r579367 -- 1 required artifact is missing. for artifact: org.apache.geronimo.configs:client-corba-yoko:car:2.0.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) smime.p7s Description: S/MIME Cryptographic Signature
[Discuss] Remaining work items before we create a J2G 1.0.0 branch?
Are there are any major items that we want to get into a J2G 1.0.0 release, or is everyone ready to create a branch and start the release process? -Donald smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r584194 - in /geronimo/server/trunk: modules/geronimo-openejb/src/main/resources/META-INF/geronimo-dependency.xml pom.xml
Could we investigate this more and remove the dependency? I really doubt we should need to pull this in. thanks david jencks On Oct 12, 2007, at 8:55 AM, [EMAIL PROTECTED] wrote: Author: gawor Date: Fri Oct 12 08:55:29 2007 New Revision: 584194 URL: http://svn.apache.org/viewvc?rev=584194view=rev Log: openejb now needs commons-dbcp dependency (GERONIMO-3531) Modified: geronimo/server/trunk/modules/geronimo-openejb/src/main/ resources/META-INF/geronimo-dependency.xml geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/modules/geronimo-openejb/src/main/ resources/META-INF/geronimo-dependency.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-openejb/src/main/resources/META-INF/geronimo- dependency.xml?rev=584194r1=584193r2=584194view=diff == --- geronimo/server/trunk/modules/geronimo-openejb/src/main/ resources/META-INF/geronimo-dependency.xml (original) +++ geronimo/server/trunk/modules/geronimo-openejb/src/main/ resources/META-INF/geronimo-dependency.xml Fri Oct 12 08:55:29 2007 @@ -63,4 +63,8 @@ groupIdasm/groupId artifactIdasm-commons/artifactId /dependency +dependency + groupIdcommons-dbcp/groupId + artifactIdcommons-dbcp/artifactId +/dependency /service Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml? rev=584194r1=584193r2=584194view=diff == --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Fri Oct 12 08:55:29 2007 @@ -443,6 +443,12 @@ /dependency dependency +groupIdcommons-dbcp/groupId +artifactIdcommons-dbcp/artifactId +version1.3-SNAPSHOT/version +/dependency + +dependency groupIdorg.objectweb.howl/groupId artifactIdhowl/artifactId version1.0.1-1/version
Transaction Manager
The transaction module (o.a.g.modules) has two GBeans - GeronimoTransactionManagerGBean and GeronimoTransactionManagerImplGBean Can they be merged? I would like to set their J2eeType to JTAResource. Thanks Anita Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more. http://mobile.yahoo.com/go?refer=1GNXIC
Re: geronimo-dependency.xml
On Oct 12, 2007, at 8:28 AM, Prasad Kashyap wrote: A quick investigation into this gave rise to some insights and more questions - Insights: 1) An explicit-versions.properties gets generated by the PackageMojo while building every config. 2) I doubt if this is getting serialized into the car. So I am unsure if this ever gets used. It is used when compiling the car file. It's intended only to restrict the c-m-p view of the local maven repo to make it look more like a geronimo repo. It would definitely not be appropriate to use it at any other time. 3) An explicit-version.properties gets generated by the InstallModulesMojo while building assembles in 2.0 but not in trunk. 4) And obviously, we are not using InstallModulesMojo for assembly in trunk. Actually we are using InstallModuleMojo in trunk, however it now uses the PluginInstallerGBean to do all the work. Since we're using the same plugin installer as we would be in a running geronimo server, there is no way to figure out what an appropriate explicit- version.properties would be or no way to send one from the maven environment into the plugin. Questions: 1) what is the explicit-version.properties used for (in configs and in 2.0 assembly) ? As noted above, to filter the maven repo to the versions specified in the pom 2) what is the geronimo-dependency.xml used for ? (a handful of modules contain it) This is geronimo's transitive depenendency feature. When you include a jar with such a file in a configuration's dependencies, all the jars listed in the g-d.xml file also get included (recursively). I'm not longer sure this g-d.xml file is a wonderful idea. There aren't that many of them and they seem to mostly cause confusion. Thanx Prasad On 10/12/07, Jarek Gawor [EMAIL PROTECTED] wrote: Folks, In trunk, I've noticed that dependencies specified in geronimo-dependency.xml without an explicit version get resolved to an incorrect version when installed. For example, the root pom defines geronimo-schema-j2ee_1.4 dependency with version 1.2. But in the final javaee assembly only the version 1.1-SNAPSHOT was installed. I see the same issue with other such dependencies. Is anyone else seeing that too? Looks like we will need to specify explicit versions in the geronimo-dependency.xml files. If so, how do we keep the versions in synch with the root pom? I'm starting to wonder if we should abandon the idea of allowing you to leave out versions in dependencies so geronimo will pick up the latest available. The alternative hot-upgrade method would be to explicitly map the old version to the new version in artifact_aliases.properties. If we decided on this approach we could insert all the versions into the g-d.xml during the build. This would be a major philosophical change so I'd definitely like some discussion before we decide. thanks david jencks Jarek
[jira] Created: (GERONIMO-3531) Testsuite failure: JNDI lookup fails with java.lang.NoClassDefFoundError
Testsuite failure: JNDI lookup fails with java.lang.NoClassDefFoundError Key: GERONIMO-3531 URL: https://issues.apache.org/jira/browse/GERONIMO-3531 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: OpenEJB Affects Versions: 2.1 Reporter: Jarek Gawor Assignee: Jarek Gawor The standalone ejb client fails with: javax.naming.NamingException: Unknown error in container [Root exception is java.lang.NoClassDefFoundError: org/apache/commons/dbcp/BasicDataSource] at org.apache.openejb.server.ejbd.JndiRequestHandler.processRequest(JndiRequestHandler.java:232) at org.apache.openejb.server.ejbd.EjbDaemon.processJndiRequest(EjbDaemon.java:168) at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:126) at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84) at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60) at org.apache.openejb.server.ServiceLogger.service(ServiceLogger.java:73) at org.apache.openejb.server.ServiceAccessController.service(ServiceAccessController.java:55) at org.apache.openejb.server.ServiceDaemon$1.run(ServiceDaemon.java:117) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NoClassDefFoundError: org/apache/commons/dbcp/BasicDataSource at org.apache.openejb.server.ejbd.JndiRequestHandler.processRequest(JndiRequestHandler.java:133) ... 8 more Looks like commons-dbcp dependency was recently added to OpenEJB's openejb-ejbd module but this dependency was not added in Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: geronimo-dependency.xml
A quick investigation into this gave rise to some insights and more questions - Insights: 1) An explicit-versions.properties gets generated by the PackageMojo while building every config. 2) I doubt if this is getting serialized into the car. So I am unsure if this ever gets used. 3) An explicit-version.properties gets generated by the InstallModulesMojo while building assembles in 2.0 but not in trunk. 4) And obviously, we are not using InstallModulesMojo for assembly in trunk. Questions: 1) what is the explicit-version.properties used for (in configs and in 2.0 assembly) ? 2) what is the geronimo-dependency.xml used for ? (a handful of modules contain it) Thanx Prasad On 10/12/07, Jarek Gawor [EMAIL PROTECTED] wrote: Folks, In trunk, I've noticed that dependencies specified in geronimo-dependency.xml without an explicit version get resolved to an incorrect version when installed. For example, the root pom defines geronimo-schema-j2ee_1.4 dependency with version 1.2. But in the final javaee assembly only the version 1.1-SNAPSHOT was installed. I see the same issue with other such dependencies. Is anyone else seeing that too? Looks like we will need to specify explicit versions in the geronimo-dependency.xml files. If so, how do we keep the versions in synch with the root pom? Jarek
[jira] Commented: (GERONIMODEVTOOLS-238) Server not found after Download additional server adapters
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534302 ] Ted Kirby commented on GERONIMODEVTOOLS-238: For posterity, I wanted to record some things I encountered while working on this problem. That Download additional server adapters function is quirky. It seems to ignore pre-reqs (the requires tag in feature.xml). So, if the AG 2.0 server adapter requires the AG 1.1 server adapter, the Download additional server adapters function happily allows you to download just the AG 2.0 server adapter. Although you may select more than one server adapter to download from the list, it only downloads the first one selected in the list. I also know of no way to test this function, other than to deploy your server adapter to a production site it knows about, and test there. This is slow, as deploy to production is slow. I used the includes tag in feature.xml to have the AG 2.0 server adapter include the AG 1.1 server adapter. For uninstall to work, I had to remove the requires tags for these server adapters from feature.xml. It seems with multiple includes elements, each must have a name, or there are problems processing the file, and the feature is not shown as being available for download. Server not found after Download additional server adapters Key: GERONIMODEVTOOLS-238 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-238 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 2.0.0 Reporter: Ted Kirby Assignee: Tim McConnell Fix For: 2.0.2 Attachments: GD238-2.patch, GD238.patch Starting with no geronimo eclipse plugin artifacts installed in my ecplise environment with all the pre-reqs, I define a new server, then click the Download additional server adatpers link, and install the Geronimo 2.0 Server Adapter. eclipse restarts, but when I go to define a new server, Geronimo v2.0 is not in the list of known servers. I've tried this with the new WTP2.0.1 all in one package, as well as WTP201 RC1 and RC2 versions. This used to work on the RC1 and RC2 versions. I am not sure what is going on here. When I open the Eclipse Error Log view, I get this error: eclipse.buildId=M20070905-1045 java.version=1.5.0_11 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86 Error Tue Oct 09 10:08:02 EDT 2007 Error calling delegate setDefaults() ServerWorkingCopy 10_9_07_10_08_AM0 java.lang.NullPointerException at org.eclipse.jst.server.generic.core.internal.GenericServer.getServerDefinition(GenericServer.java:239) at org.eclipse.jst.server.generic.core.internal.GenericServer.setDefaults(GenericServer.java:324) at org.eclipse.wst.server.core.internal.ServerWorkingCopy.setDefaults(ServerWorkingCopy.java:608) at org.eclipse.wst.server.core.internal.ServerType.createServer(ServerType.java:195) at org.eclipse.wst.server.ui.internal.wizard.page.ServerCreationCache.getServer(ServerCreationCache.java:61) at org.eclipse.wst.server.ui.internal.wizard.page.NewManualServerComposite.loadServerImpl(NewManualServerComposite.java:214) at org.eclipse.wst.server.ui.internal.wizard.page.NewManualServerComposite.handleTypeSelection(NewManualServerComposite.java:383) at org.eclipse.wst.server.ui.internal.wizard.page.NewManualServerComposite$1.serverTypeSelected(NewManualServerComposite.java:123) at org.eclipse.wst.server.ui.internal.viewers.ServerTypeComposite$2.selectionChanged(ServerTypeComposite.java:85) at org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:162) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:857) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:46) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:199) at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:160) at org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:2047) at org.eclipse.jface.viewers.StructuredViewer.setSelection(StructuredViewer.java:1641) at org.eclipse.jface.viewers.TreeViewer.setSelection(TreeViewer.java:1091) at org.eclipse.wst.server.ui.internal.viewers.ServerTypeComposite.setVisible(ServerTypeComposite.java:97) at org.eclipse.wst.server.ui.internal.wizard.page.NewManualServerComposite.setVisible(NewManualServerComposite.java:407) at org.eclipse.wst.server.ui.internal.wizard.page.NewServerComposite.createControl(NewServerComposite.java:233) at org.eclipse.wst.server.ui.internal.wizard.page.NewServerComposite.init(NewServerComposite.java:121) at
Re: svn commit: r584040 - /geronimo/server/branches/2.0.2/RELEASE_NOTES-2.0.2.txt
On Oct 12, 2007, at 8:54 AM, Anita Kulshreshtha wrote: --- [EMAIL PROTECTED] wrote: Author: kevan Date: Thu Oct 11 21:25:03 2007 New Revision: 584040 URL: http://svn.apache.org/viewvc?rev=584040view=rev Log: Add RELEASE-NOTES for 2.0.2 release . . +To enable MEJB access, you will need to configure either an mejb- user or +mejb-admin group. The current deployment of MEJB allows read access to all the users in the default admin group. If you would like the behavior (mejb- user group) as you have described, we can make changes to the MEJB plan. To get read/write access an mejb-admin group must be created. All users in this group will have R/W access. Ok. Faulty memory, I guess. I'll update the release notes. --kevan
Re: svn commit: r584040 - /geronimo/server/branches/2.0.2/RELEASE_NOTES-2.0.2.txt
--- [EMAIL PROTECTED] wrote: Author: kevan Date: Thu Oct 11 21:25:03 2007 New Revision: 584040 URL: http://svn.apache.org/viewvc?rev=584040view=rev Log: Add RELEASE-NOTES for 2.0.2 release . . +To enable MEJB access, you will need to configure either an mejb-user or +mejb-admin group. The current deployment of MEJB allows read access to all the users in the default admin group. If you would like the behavior (mejb-user group) as you have described, we can make changes to the MEJB plan. To get read/write access an mejb-admin group must be created. All users in this group will have R/W access. To enable read/write MEJB access to the 'system' user, +add the following to geronimo_home/var/security/groups.properties file: + +mejb-admin=system Thanks Anita Check out the hottest 2008 models today at Yahoo! Autos. http://autos.yahoo.com/new_cars.html
Re: Transaction Manager
On Oct 12, 2007, at 8:50 AM, Anita Kulshreshtha wrote: The transaction module (o.a.g.modules) has two GBeans - GeronimoTransactionManagerGBean and GeronimoTransactionManagerImplGBean Can they be merged? I would like to set their J2eeType to JTAResource. I added a miniscule amount of documentation to these. I don't see a pressing need to remove the TransactionManagerImplGBean; that would make more sense than merging them. There should be no problem changing the j2eeType as long as you change all uses of NameFactory.TRANSACTION_MANAGER so references to the TM will still get hooked up. thanks david jencks Thanks Anita __ __ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more. http://mobile.yahoo.com/go?refer=1GNXIC
Re: [VOTE] Release geronimo-txmanager 2.0.2
+1 Jarek On 10/10/07, Kevan Miller [EMAIL PROTECTED] wrote: As discussed in the Geronimo 2.0.2 release discussion thread, we need to release geronimo-txmanager 2.0.2 to pick up fixes for the Geronimo 2.0.2 release. geronimo-txmanager contains the geronimo-transaction and geronimo-connector components. The proposed binary release artifacts can be found here -- http:// people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2.zip Your can browse these artifacts here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2/ The source for the release is currently here -- https:// svn.apache.org/repos/asf/geronimo/components/txmanager/branches/2.0.2 Once released, I'll tag this source as -- https://svn.apache.org/ repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager- parent-2.0.2 For your convenience, a zip file containing this source is here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2-src.zip A RAT report for this source is here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2-rat.txt Please vote on this release. [ ] +1 Release geronimo-txmanager 2.0.2 [ ] 0 No opinion [ ] -1 Do not release geronimo-txmanager 2.0.2 Barring any problems or ongoing discussions, I'll plan on calling the vote at 8 AM (EDT) on Saturday October 13. --kevan
Re: [VOTE] Release geronimo-txmanager 2.0.2
+1 On Oct 10, 2007, at 1:42 AM, Kevan Miller wrote: As discussed in the Geronimo 2.0.2 release discussion thread, we need to release geronimo-txmanager 2.0.2 to pick up fixes for the Geronimo 2.0.2 release. geronimo-txmanager contains the geronimo- transaction and geronimo-connector components. The proposed binary release artifacts can be found here -- http:// people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2.zip Your can browse these artifacts here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2/ The source for the release is currently here -- https:// svn.apache.org/repos/asf/geronimo/components/txmanager/branches/2.0.2 Once released, I'll tag this source as -- https://svn.apache.org/ repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager- parent-2.0.2 For your convenience, a zip file containing this source is here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2-src.zip A RAT report for this source is here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2-rat.txt Please vote on this release. [ ] +1 Release geronimo-txmanager 2.0.2 [ ] 0 No opinion [ ] -1 Do not release geronimo-txmanager 2.0.2 Barring any problems or ongoing discussions, I'll plan on calling the vote at 8 AM (EDT) on Saturday October 13. --kevan
Re: svn commit: r584194 - in /geronimo/server/trunk: modules/geronimo-openejb/src/main/resources/META-INF/geronimo-dependency.xml pom.xml
David, I did investigate it. But maybe there is a better solution. Here's the change in OpenEJB: http://svn.apache.org/viewvc/openejb/trunk/openejb3/server/openejb-ejbd/src/main/java/org/apache/openejb/server/ejbd/JndiRequestHandler.java?r1=570629r2=581127 Jarek On 10/12/07, David Jencks [EMAIL PROTECTED] wrote: Could we investigate this more and remove the dependency? I really doubt we should need to pull this in. thanks david jencks On Oct 12, 2007, at 8:55 AM, [EMAIL PROTECTED] wrote: Author: gawor Date: Fri Oct 12 08:55:29 2007 New Revision: 584194 URL: http://svn.apache.org/viewvc?rev=584194view=rev Log: openejb now needs commons-dbcp dependency (GERONIMO-3531) Modified: geronimo/server/trunk/modules/geronimo-openejb/src/main/ resources/META-INF/geronimo-dependency.xml geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/modules/geronimo-openejb/src/main/ resources/META-INF/geronimo-dependency.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-openejb/src/main/resources/META-INF/geronimo- dependency.xml?rev=584194r1=584193r2=584194view=diff == --- geronimo/server/trunk/modules/geronimo-openejb/src/main/ resources/META-INF/geronimo-dependency.xml (original) +++ geronimo/server/trunk/modules/geronimo-openejb/src/main/ resources/META-INF/geronimo-dependency.xml Fri Oct 12 08:55:29 2007 @@ -63,4 +63,8 @@ groupIdasm/groupId artifactIdasm-commons/artifactId /dependency +dependency + groupIdcommons-dbcp/groupId + artifactIdcommons-dbcp/artifactId +/dependency /service Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml? rev=584194r1=584193r2=584194view=diff == --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Fri Oct 12 08:55:29 2007 @@ -443,6 +443,12 @@ /dependency dependency +groupIdcommons-dbcp/groupId +artifactIdcommons-dbcp/artifactId +version1.3-SNAPSHOT/version +/dependency + +dependency groupIdorg.objectweb.howl/groupId artifactIdhowl/artifactId version1.0.1-1/version
Re: getting invalid option: -javaagent:
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.
Re: [VOTE] Release geronimo-txmanager 2.0.2
All A reminder about this release vote. Hoping to call the vote tomorrow. --kevan On Oct 10, 2007, at 1:42 AM, Kevan Miller wrote: As discussed in the Geronimo 2.0.2 release discussion thread, we need to release geronimo-txmanager 2.0.2 to pick up fixes for the Geronimo 2.0.2 release. geronimo-txmanager contains the geronimo- transaction and geronimo-connector components. The proposed binary release artifacts can be found here -- http:// people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2.zip Your can browse these artifacts here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2/ The source for the release is currently here -- https:// svn.apache.org/repos/asf/geronimo/components/txmanager/branches/2.0.2 Once released, I'll tag this source as -- https://svn.apache.org/ repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager- parent-2.0.2 For your convenience, a zip file containing this source is here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2-src.zip A RAT report for this source is here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2-rat.txt Please vote on this release. [ ] +1 Release geronimo-txmanager 2.0.2 [ ] 0 No opinion [ ] -1 Do not release geronimo-txmanager 2.0.2 Barring any problems or ongoing discussions, I'll plan on calling the vote at 8 AM (EDT) on Saturday October 13. --kevan
[jira] Updated: (SM-627) Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.jca.JCAFlowTest
[ https://issues.apache.org/activemq/browse/SM-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated SM-627: Attachment: JCAFlowTest_patch.txt The same solution as JMSFlowTest (see discussion there). Make sure that JMSFlowTest patches are applied first since there is a new Helper class thus making this page a compile dependency. Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.jca.JCAFlowTest --- Key: SM-627 URL: https://issues.apache.org/activemq/browse/SM-627 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: 3.0 Reporter: Fritz Oconer Fix For: 3.2 Attachments: JCAFlowTest_patch.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
geronimo-dependency.xml
Folks, In trunk, I've noticed that dependencies specified in geronimo-dependency.xml without an explicit version get resolved to an incorrect version when installed. For example, the root pom defines geronimo-schema-j2ee_1.4 dependency with version 1.2. But in the final javaee assembly only the version 1.1-SNAPSHOT was installed. I see the same issue with other such dependencies. Is anyone else seeing that too? Looks like we will need to specify explicit versions in the geronimo-dependency.xml files. If so, how do we keep the versions in synch with the root pom? Jarek
[jira] Updated: (SM-628) org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest
[ https://issues.apache.org/activemq/browse/SM-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated SM-628: Attachment: SMTestCasesPatches.zip Patches for JMSFlowTest org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest -- Key: SM-628 URL: https://issues.apache.org/activemq/browse/SM-628 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: 3.0 Reporter: Fritz Oconer Fix For: 3.2 Attachments: SMTestCasesPatches.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-1103) Class not found (org.apache.camel.Component) while starting servicemix-camel component
Class not found (org.apache.camel.Component) while starting servicemix-camel
component
--
Key: SM-1103
URL: https://issues.apache.org/activemq/browse/SM-1103
Project: ServiceMix
Issue Type: Bug
Components: servicemix-camel
Affects Versions: 3.2
Reporter: Gert Vanthienen
servicemix-camel fails with new build from trunk (revision 584233)
{code}
ERROR - InstallerMBeanImpl - Class not found:
org.apache.servicemix.common.DefaultBootstrap
java.lang.NoClassDefFoundError: org/apache/camel/Component
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at
org.apache.xbean.classloader.JarFileClassLoader.access$200(JarFileClassLoader.java:48)
at
org.apache.xbean.classloader.JarFileClassLoader$6.run(JarFileClassLoader.java:272)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.xbean.classloader.JarFileClassLoader.findClass(JarFileClassLoader.java:224)
at
org.apache.xbean.classloader.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:200)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.apache.servicemix.jbi.framework.InstallerMBeanImpl.activateComponent(InstallerMBeanImpl.java:186)
at
org.apache.servicemix.jbi.framework.InstallerMBeanImpl.install(InstallerMBeanImpl.java:165)
at
org.apache.servicemix.jbi.framework.InstallationService.install(InstallationService.java:326)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.checkPendingComponents(AutoDeploymentService.java:515)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.updateSharedLibrary(AutoDeploymentService.java:314)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.updateArchive(AutoDeploymentService.java:251)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.monitorDirectory(AutoDeploymentService.java:647)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.access$2(AutoDeploymentService.java:623)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService$1.run(AutoDeploymentService.java:611)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-628) org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest
[ https://issues.apache.org/activemq/browse/SM-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40365 ] Oleg Zhurakousky commented on SM-628: - Cool, but don't commit yet. I just edited my previous comment with a little NOTE (there is something I can reuse from MessageList. . . you made me think. . .), so I want to change that. Also, let me look at other similar test to make sure that the approach is the same. I will provide another comment here when I am done. As for Jira/Resolve. May be you right Resolve or Close if not accepted could always be reopened. But it would eliminate double work if it is accepted sine the only time you would have to go back if you had to reopen it (you would not have to go back and close something that you agree already). org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest -- Key: SM-628 URL: https://issues.apache.org/activemq/browse/SM-628 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: 3.0 Reporter: Fritz Oconer Fix For: 3.2 Attachments: SMTestCasesPatches.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SM-1103) Class not found (org.apache.camel.Component) while starting servicemix-camel component
[
https://issues.apache.org/activemq/browse/SM-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen closed SM-1103.
---
Resolution: Cannot Reproduce
Never mind... I guess everyone is entitled to a moment of confusion once in a
while...
Class not found (org.apache.camel.Component) while starting servicemix-camel
component
--
Key: SM-1103
URL: https://issues.apache.org/activemq/browse/SM-1103
Project: ServiceMix
Issue Type: Bug
Components: servicemix-camel
Affects Versions: 3.2
Reporter: Gert Vanthienen
servicemix-camel fails with new build from trunk (revision 584233)
{code}
ERROR - InstallerMBeanImpl - Class not found:
org.apache.servicemix.common.DefaultBootstrap
java.lang.NoClassDefFoundError: org/apache/camel/Component
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at
org.apache.xbean.classloader.JarFileClassLoader.access$200(JarFileClassLoader.java:48)
at
org.apache.xbean.classloader.JarFileClassLoader$6.run(JarFileClassLoader.java:272)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.xbean.classloader.JarFileClassLoader.findClass(JarFileClassLoader.java:224)
at
org.apache.xbean.classloader.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:200)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.apache.servicemix.jbi.framework.InstallerMBeanImpl.activateComponent(InstallerMBeanImpl.java:186)
at
org.apache.servicemix.jbi.framework.InstallerMBeanImpl.install(InstallerMBeanImpl.java:165)
at
org.apache.servicemix.jbi.framework.InstallationService.install(InstallationService.java:326)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.checkPendingComponents(AutoDeploymentService.java:515)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.updateSharedLibrary(AutoDeploymentService.java:314)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.updateArchive(AutoDeploymentService.java:251)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.monitorDirectory(AutoDeploymentService.java:647)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.access$2(AutoDeploymentService.java:623)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService$1.run(AutoDeploymentService.java:611)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-628) org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest
[ https://issues.apache.org/activemq/browse/SM-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40366 ] Oleg Zhurakousky commented on SM-628: - Guillaume Go ahead and commit if you like. I just tested it with JCAFlowTest and it works good so I'll be submitting a patch for that shortly, but it has to be after you apply this patch otherwise the code will not compile without having ClusterFlowTestHelper. As to the note I made in the previous comment it would not work unless we start changing more things around since the wait method takes the amount of messages as input paramener and as I said before I would not know that in the clustered flows. So I would keep it the way it is. Let me know if you plan to commit so I know when to submit the JCA and other patches. org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest -- Key: SM-628 URL: https://issues.apache.org/activemq/browse/SM-628 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: 3.0 Reporter: Fritz Oconer Fix For: 3.2 Attachments: SMTestCasesPatches.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-238) Server not found after Download additional server adapters
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Kirby updated GERONIMODEVTOOLS-238: --- Attachment: GD238-2.patch Here is a better patch file. It puts elements in the proper order, and adds a name attribute. Server not found after Download additional server adapters Key: GERONIMODEVTOOLS-238 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-238 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 2.0.0 Reporter: Ted Kirby Assignee: Tim McConnell Fix For: 2.0.2 Attachments: GD238-2.patch, GD238.patch Starting with no geronimo eclipse plugin artifacts installed in my ecplise environment with all the pre-reqs, I define a new server, then click the Download additional server adatpers link, and install the Geronimo 2.0 Server Adapter. eclipse restarts, but when I go to define a new server, Geronimo v2.0 is not in the list of known servers. I've tried this with the new WTP2.0.1 all in one package, as well as WTP201 RC1 and RC2 versions. This used to work on the RC1 and RC2 versions. I am not sure what is going on here. When I open the Eclipse Error Log view, I get this error: eclipse.buildId=M20070905-1045 java.version=1.5.0_11 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86 Error Tue Oct 09 10:08:02 EDT 2007 Error calling delegate setDefaults() ServerWorkingCopy 10_9_07_10_08_AM0 java.lang.NullPointerException at org.eclipse.jst.server.generic.core.internal.GenericServer.getServerDefinition(GenericServer.java:239) at org.eclipse.jst.server.generic.core.internal.GenericServer.setDefaults(GenericServer.java:324) at org.eclipse.wst.server.core.internal.ServerWorkingCopy.setDefaults(ServerWorkingCopy.java:608) at org.eclipse.wst.server.core.internal.ServerType.createServer(ServerType.java:195) at org.eclipse.wst.server.ui.internal.wizard.page.ServerCreationCache.getServer(ServerCreationCache.java:61) at org.eclipse.wst.server.ui.internal.wizard.page.NewManualServerComposite.loadServerImpl(NewManualServerComposite.java:214) at org.eclipse.wst.server.ui.internal.wizard.page.NewManualServerComposite.handleTypeSelection(NewManualServerComposite.java:383) at org.eclipse.wst.server.ui.internal.wizard.page.NewManualServerComposite$1.serverTypeSelected(NewManualServerComposite.java:123) at org.eclipse.wst.server.ui.internal.viewers.ServerTypeComposite$2.selectionChanged(ServerTypeComposite.java:85) at org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:162) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:857) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:46) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:199) at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:160) at org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:2047) at org.eclipse.jface.viewers.StructuredViewer.setSelection(StructuredViewer.java:1641) at org.eclipse.jface.viewers.TreeViewer.setSelection(TreeViewer.java:1091) at org.eclipse.wst.server.ui.internal.viewers.ServerTypeComposite.setVisible(ServerTypeComposite.java:97) at org.eclipse.wst.server.ui.internal.wizard.page.NewManualServerComposite.setVisible(NewManualServerComposite.java:407) at org.eclipse.wst.server.ui.internal.wizard.page.NewServerComposite.createControl(NewServerComposite.java:233) at org.eclipse.wst.server.ui.internal.wizard.page.NewServerComposite.init(NewServerComposite.java:121) at org.eclipse.wst.server.ui.internal.wizard.fragment.NewServerWizardFragment.createComposite(NewServerWizardFragment.java:74) at org.eclipse.wst.server.ui.internal.wizard.TaskWizardPage.createControl(TaskWizardPage.java:43) at org.eclipse.wst.server.ui.internal.wizard.TaskWizard.createPageControls(TaskWizard.java:396) at org.eclipse.jface.wizard.WizardDialog.createPageControls(WizardDialog.java:669) at org.eclipse.jface.wizard.WizardDialog.createContents(WizardDialog.java:543) at org.eclipse.jface.window.Window.create(Window.java:426) at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1081) at org.eclipse.jface.window.Window.open(Window.java:785) at org.eclipse.wst.server.ui.internal.actions.LaunchWizardAction.run(LaunchWizardAction.java:57) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:546) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:490) at
[jira] Resolved: (GERONIMO-3531) Testsuite failure: JNDI lookup fails with java.lang.NoClassDefFoundError
[ https://issues.apache.org/jira/browse/GERONIMO-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3531. --- Resolution: Fixed Fix Version/s: 2.1 Committed fixes to trunk (revision 584194). Testsuite failure: JNDI lookup fails with java.lang.NoClassDefFoundError Key: GERONIMO-3531 URL: https://issues.apache.org/jira/browse/GERONIMO-3531 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.1 Reporter: Jarek Gawor Assignee: Jarek Gawor Fix For: 2.1 The standalone ejb client fails with: javax.naming.NamingException: Unknown error in container [Root exception is java.lang.NoClassDefFoundError: org/apache/commons/dbcp/BasicDataSource] at org.apache.openejb.server.ejbd.JndiRequestHandler.processRequest(JndiRequestHandler.java:232) at org.apache.openejb.server.ejbd.EjbDaemon.processJndiRequest(EjbDaemon.java:168) at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:126) at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84) at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60) at org.apache.openejb.server.ServiceLogger.service(ServiceLogger.java:73) at org.apache.openejb.server.ServiceAccessController.service(ServiceAccessController.java:55) at org.apache.openejb.server.ServiceDaemon$1.run(ServiceDaemon.java:117) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NoClassDefFoundError: org/apache/commons/dbcp/BasicDataSource at org.apache.openejb.server.ejbd.JndiRequestHandler.processRequest(JndiRequestHandler.java:133) ... 8 more Looks like commons-dbcp dependency was recently added to OpenEJB's openejb-ejbd module but this dependency was not added in Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3531) Testsuite failure: EJB JNDI lookup fails with java.lang.NoClassDefFoundError
[ https://issues.apache.org/jira/browse/GERONIMO-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3531: -- Summary: Testsuite failure: EJB JNDI lookup fails with java.lang.NoClassDefFoundError (was: Testsuite failure: JNDI lookup fails with java.lang.NoClassDefFoundError) Testsuite failure: EJB JNDI lookup fails with java.lang.NoClassDefFoundError Key: GERONIMO-3531 URL: https://issues.apache.org/jira/browse/GERONIMO-3531 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.1 Reporter: Jarek Gawor Assignee: Jarek Gawor Fix For: 2.1 The standalone ejb client fails with: javax.naming.NamingException: Unknown error in container [Root exception is java.lang.NoClassDefFoundError: org/apache/commons/dbcp/BasicDataSource] at org.apache.openejb.server.ejbd.JndiRequestHandler.processRequest(JndiRequestHandler.java:232) at org.apache.openejb.server.ejbd.EjbDaemon.processJndiRequest(EjbDaemon.java:168) at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:126) at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84) at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60) at org.apache.openejb.server.ServiceLogger.service(ServiceLogger.java:73) at org.apache.openejb.server.ServiceAccessController.service(ServiceAccessController.java:55) at org.apache.openejb.server.ServiceDaemon$1.run(ServiceDaemon.java:117) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NoClassDefFoundError: org/apache/commons/dbcp/BasicDataSource at org.apache.openejb.server.ejbd.JndiRequestHandler.processRequest(JndiRequestHandler.java:133) ... 8 more Looks like commons-dbcp dependency was recently added to OpenEJB's openejb-ejbd module but this dependency was not added in Geronimo. -- 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?
On Oct 12, 2007, at 11:22 AM, 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. By the way, the patches seem to be missing a number of license files. Possible that some files hadn't been svn add'ed when the patch was generated? I'll push the maven-remote-resources-plugin here again... thanks david jencks --kevan
Re: [Discuss] Remaining work items before we create a J2G 1.0.0 branch?
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. ~ Jason Warner On 10/11/07, Donald Woods [EMAIL PROTECTED] wrote: Are there are any major items that we want to get into a J2G 1.0.0 release, or is everyone ready to create a branch and start the release process? -Donald
Re: [GShell] Plexus dependency in CommandLineBuilder
The core container has only a few dependencies: one on org.codehaus.plexus.personality.plexus.lifecycle.phase package and several on org.codehaus.plexus.util package, but I don't have to include the whole plexus to make gshell run, so I'm quite happy with that. However, whisper heavily rely on plexus for the configuration of transport, so I'll try to abstract that a bit (i'd be happy to delegate that to you if you prefer). Mainly the BaseTransportFactory class should rely on factories somehow instead of asking the container to retrieve a new transport at each connection. On 10/12/07, Jason Dillon [EMAIL PROTECTED] wrote: I'm not actively trying to decouple Plexus from gshell-whisper... or really any of GShel, though if I can add some abstraction to make it easier for you to use GShell w/o Plexus I'm happy to do that as long as it is not intrusive. --jason On Oct 11, 2007, at 12:41 PM, Guillaume Nodet wrote: So I've been able to have a local shell wired with Spring without including any plexus jars in the classpath :-) I'm trying to do the same with the remote shell, but it seems that gshel-whisper is much more tied to plexus. Do you have any ongoing modifications to decouple it a bit from plexus or can I look at that ? On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: FYI, I've found a workaround as Spring can solve such situations if using property injection rather than constructor injection... So creating wrapper solves the problem. On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: Ok, so it seems that wiring gshell using spring is not too difficult. However I have seen a weird dependency between two POJOs which cause a problem when wiring them. It happens between DefaultCommandExecutor which has a dependency on OsgiCommandLineBuilder which also has a dependency on the command executor. Is there any way to refactor things a bit to avoid this circular dependency ? On 10/11/07, Jason Dillon [EMAIL PROTECTED] wrote: Yup, sounds fine. As I mentioned to ya a while ago on IRC I took a few short cuts when I whipped this stuff up... after what now seems like a long time ago. Anyways, go for it. Only comment I've got is you should call the intf CommandLineBuilder and the default impl DefaultCommandLineBuilder (prefix insteand of suffix to follow how the other components play... ). --jason On Oct 11, 2007, at 6:46 AM, Guillaume Nodet wrote: I'm trying to configure GShell through spring because spring can integrate nicely in OSGi (which is my main purpose) and I just crossed one problem: the CommandLineBuilder is a dependency of DefaultCommandExecutor (in terms of POJOs). The problem is that CommandLineBuilder is a class, not an interface, with a strong dependency on plexus. So I'd like to introduce an interface CommandLineBuilder and rename the class as the default implementation CommandLineBuilderDefault. Any objections ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Commented: (SM-1103) Class not found (org.apache.camel.Component) while starting servicemix-camel component
[
https://issues.apache.org/activemq/browse/SM-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40372
]
Guillaume Nodet commented on SM-1103:
-
Actually, this was a real problem until I fixed it a few days ago. The
problem was in the maven plugin which did not support OSGi bundles (camel jars
are now bundles).
Class not found (org.apache.camel.Component) while starting servicemix-camel
component
--
Key: SM-1103
URL: https://issues.apache.org/activemq/browse/SM-1103
Project: ServiceMix
Issue Type: Bug
Components: servicemix-camel
Affects Versions: 3.2
Reporter: Gert Vanthienen
servicemix-camel fails with new build from trunk (revision 584233)
{code}
ERROR - InstallerMBeanImpl - Class not found:
org.apache.servicemix.common.DefaultBootstrap
java.lang.NoClassDefFoundError: org/apache/camel/Component
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at
org.apache.xbean.classloader.JarFileClassLoader.access$200(JarFileClassLoader.java:48)
at
org.apache.xbean.classloader.JarFileClassLoader$6.run(JarFileClassLoader.java:272)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.xbean.classloader.JarFileClassLoader.findClass(JarFileClassLoader.java:224)
at
org.apache.xbean.classloader.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:200)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.apache.servicemix.jbi.framework.InstallerMBeanImpl.activateComponent(InstallerMBeanImpl.java:186)
at
org.apache.servicemix.jbi.framework.InstallerMBeanImpl.install(InstallerMBeanImpl.java:165)
at
org.apache.servicemix.jbi.framework.InstallationService.install(InstallationService.java:326)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.checkPendingComponents(AutoDeploymentService.java:515)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.updateSharedLibrary(AutoDeploymentService.java:314)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.updateArchive(AutoDeploymentService.java:251)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.monitorDirectory(AutoDeploymentService.java:647)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService.access$2(AutoDeploymentService.java:623)
at
org.apache.servicemix.jbi.framework.AutoDeploymentService$1.run(AutoDeploymentService.java:611)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [GShell] Plexus dependency in CommandLineBuilder
I will see about adding a TransportProvider abstraction to deal with this... I'm flying to Hawaii this weeken for a funeral :-( But I might have time to look into this stuff then... else when I get back. --jason On Oct 12, 2007, at 3:48 PM, Guillaume Nodet wrote: The core container has only a few dependencies: one on org.codehaus.plexus.personality.plexus.lifecycle.phase package and several on org.codehaus.plexus.util package, but I don't have to include the whole plexus to make gshell run, so I'm quite happy with that. However, whisper heavily rely on plexus for the configuration of transport, so I'll try to abstract that a bit (i'd be happy to delegate that to you if you prefer). Mainly the BaseTransportFactory class should rely on factories somehow instead of asking the container to retrieve a new transport at each connection. On 10/12/07, Jason Dillon [EMAIL PROTECTED] wrote: I'm not actively trying to decouple Plexus from gshell-whisper... or really any of GShel, though if I can add some abstraction to make it easier for you to use GShell w/o Plexus I'm happy to do that as long as it is not intrusive. --jason On Oct 11, 2007, at 12:41 PM, Guillaume Nodet wrote: So I've been able to have a local shell wired with Spring without including any plexus jars in the classpath :-) I'm trying to do the same with the remote shell, but it seems that gshel-whisper is much more tied to plexus. Do you have any ongoing modifications to decouple it a bit from plexus or can I look at that ? On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: FYI, I've found a workaround as Spring can solve such situations if using property injection rather than constructor injection... So creating wrapper solves the problem. On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: Ok, so it seems that wiring gshell using spring is not too difficult. However I have seen a weird dependency between two POJOs which cause a problem when wiring them. It happens between DefaultCommandExecutor which has a dependency on OsgiCommandLineBuilder which also has a dependency on the command executor. Is there any way to refactor things a bit to avoid this circular dependency ? On 10/11/07, Jason Dillon [EMAIL PROTECTED] wrote: Yup, sounds fine. As I mentioned to ya a while ago on IRC I took a few short cuts when I whipped this stuff up... after what now seems like a long time ago. Anyways, go for it. Only comment I've got is you should call the intf CommandLineBuilder and the default impl DefaultCommandLineBuilder (prefix insteand of suffix to follow how the other components play... ). --jason On Oct 11, 2007, at 6:46 AM, Guillaume Nodet wrote: I'm trying to configure GShell through spring because spring can integrate nicely in OSGi (which is my main purpose) and I just crossed one problem: the CommandLineBuilder is a dependency of DefaultCommandExecutor (in terms of POJOs). The problem is that CommandLineBuilder is a class, not an interface, with a strong dependency on plexus. So I'd like to introduce an interface CommandLineBuilder and rename the class as the default implementation CommandLineBuilderDefault. Any objections ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Help! Exception while stopping geronimo using Journaled JDBC persistence
I got it working.The problem was because I didn't specified useShutDownHook attribute in externalized activemq.xml. So activemq shutdown was happening outside of geronimo shutdown. During shutdown activemq tries to access derby db which was already shutdown by geronimo causing the exception. Best Regards, Anish On 10/11/07, anish pathadan [EMAIL PROTECTED] wrote: Hi, I am using Journaled JDBC for activemq persistence . I am using activemq 4.1 within geronimo 2.0.1 . I used VM connector for sending messages and I have externalized the activemq.xml in geronimo. I am getting the following exception when trying to stop the geronimo.It work fine if I use just JDBC persistence without journal. [] received stop signal XBM02.D : [0] org.apache.derby.iapi.services.stream.InfoStreams ERROR XBM02: XBM02.D : [0] org.apache.derby.iapi.services.stream.InfoStreams at org.apache.derby.iapi.error.StandardException.newException(Unknown So urce) at org.apache.derby.iapi.services.monitor.Monitor.missingImplementation( Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule (Unknow n Source) at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Unkn own Source) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unkno wn Source) at org.apache.derby.impl.services.monitor.FileMonitor.init(Unknown Sou rce) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown S ource) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.init(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source ) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection (Unknown Source ) at org.apache.activemq.store.jdbc.TransactionContext.getConnection (Trans actionContext.java:55) at org.apache.activemq.store.jdbc.TransactionContext.begin (TransactionCo ntext.java :149) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransactio n(JDBCPersistenceAdapter.java:358) at org.apache.activemq.store.journal.JournalPersistenceAdapter.beginTran saction( JournalPersistenceAdapter.java:189) at org.apache.activemq.util.TransactionTemplate.run (TransactionTemplate. java:41) at org.apache.activemq.store.journal.JournalMessageStore.checkpoint(Jour nalMessageStore.java :247) at org.apache.activemq.store.journal.JournalMessageStore.checkpoint(Jour nalMessageStore.java:221) at org.apache.activemq.store.journal.JournalPersistenceAdapter$4.call(Jo urnalPersistenceAdapter.java :356) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run (FutureT ask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor ker.runTask(ThreadPoolExecutor.java :665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor ker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) Got Exception in TransactionContext java.sql.SQLException: No suitable driver at java.sql.DriverManager.getDriver(DriverManager.java:243) at org.apache.derby.jdbc.EmbeddedDataSource.findDriver (Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source ) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source ) at org.apache.activemq.store.jdbc.TransactionContext.getConnection(Trans actionContext.java:55) at org.apache.activemq.store.jdbc.TransactionContext.begin (TransactionCo ntext.java:149) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransactio n(JDBCPersistenceAdapter.java:358) at org.apache.activemq.store.journal.JournalPersistenceAdapter.beginTran saction(JournalPersistenceAdapter.java:189) at org.apache.activemq.util.TransactionTemplate.run(TransactionTemplate. java:41) at org.apache.activemq.store.journal.JournalMessageStore.checkpoint(Jour nalMessageStore.java:247) at org.apache.activemq.store.journal.JournalMessageStore.checkpoint (Jour nalMessageStore.java:221) at org.apache.activemq.store.journal.JournalPersistenceAdapter$4.call(Jo urnalPersistenceAdapter.java:356) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureT ask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor ker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor
[VOTE] Geronimo 2.0.2 (rc1)
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)
On Oct 12, 2007, at 9:57 PM, Kevan Miller wrote: [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) Here's my +1 --kevan
graphs of config module dependencies
I generated some graphs that represent the dependencies of the config/ modules in trunk. I thought it would be fun to share: car-only dependencies: http://people.apache.org/~gawor/carDeps.pdf jar and car dependencies: http://people.apache.org/~gawor/allDeps.pdf rectangles represent car modules and ellipses represent jar modules. Jarek
