Re: build local binary distribution
Sorry, I should have mentioned before that I was working in the 4.0.2 snapshot. Using maven 1 I get the same results. I have tried: maven1 clean install in assembly: maven1 assembly:assembly both build successfully. When I untar the tar file in assembly/target, it is missing the incubator-activemq-4.0.2.jar that I would expect to see in the distribution. So I copy it in to the untarred directory and run bin/activemq (I added the printStackTrace in main()): ACTIVEMQ_HOME: /home/bmadigan/Applications/activemq-4.0/assembly/target/incubator-activemq-4.0.2-SNAPSHOT Loading message broker from: xbean:activemq.xml java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerFactory at org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:82) at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:47) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:50) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:82) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:50) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:46) 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.apache.activemq.console.Main.runTaskClass(Main.java:136) at org.apache.activemq.console.Main.main(Main.java:68) In the shell script, there doesnt appear to be a classpath. I don't see any difference between the snapshot tar and any binary tar that I download, so I'm not sure whats missing. Hiram Chirino wrote: ahhh... maven 2 is not fully supported on that branch. It's only fully implemented in the trunk, a.k.a. activemq 4.1. Use maven 1 on the 4.0 branch. On 8/14/06, bmadigan [EMAIL PROTECTED] wrote: I had done that, but the archives created don't appear to be complete: ACTIVEMQ_HOME: /home/bmadigan/Applications/activemq-4.0/assembly/target/incubator-activemq-4.0.2-SNAPSHOT Loading message broker from: xbean:activemq.xml Failed to execute main task. Reason: java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerFactory Maybe this is an error in the shell script, it does not seem to build a classpath. Hiram Chirino wrote: just run mvn install that should produce binaries in the target directory and even install them into your local maven repo. On 8/14/06, bmadigan [EMAIL PROTECTED] wrote: I need to build a local binary from a source snapshot so we can distribute it to our staging and production enviroments. Are there any maven commands that will build a local distrubtion? thanks, B. -- View this message in context: http://www.nabble.com/build-local-binary-distribution-tf2104394.html#a5799896 Sent from the ActiveMQ - Dev forum at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/build-local-binary-distribution-tf2104394.html#a5800530 Sent from the ActiveMQ - Dev forum at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/build-local-binary-distribution-tf2104394.html#a5835618 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: [jira] Commented: (AMQ-855) Add support for prefetchSize = 0
Hello! Is there anything I can do to move forward with this patch? Thanks. -- View this message in context: http://www.nabble.com/-jira--Created%3A-%28AMQ-855%29-Add-support-for-prefetchSize-%3D-0-tf2035055.html#a5835695 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: build local binary distribution
Ah, never mind. It was in the assembly/target/distributions directory. thanks bmadigan wrote: Sorry, I should have mentioned before that I was working in the 4.0.2 snapshot. Using maven 1 I get the same results. I have tried: maven1 clean install in assembly: maven1 assembly:assembly both build successfully. When I untar the tar file in assembly/target, it is missing the incubator-activemq-4.0.2.jar that I would expect to see in the distribution. So I copy it in to the untarred directory and run bin/activemq (I added the printStackTrace in main()): ACTIVEMQ_HOME: /home/bmadigan/Applications/activemq-4.0/assembly/target/incubator-activemq-4.0.2-SNAPSHOT Loading message broker from: xbean:activemq.xml java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerFactory at org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:82) at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:47) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:50) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:82) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:50) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:46) 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.apache.activemq.console.Main.runTaskClass(Main.java:136) at org.apache.activemq.console.Main.main(Main.java:68) In the shell script, there doesnt appear to be a classpath. I don't see any difference between the snapshot tar and any binary tar that I download, so I'm not sure whats missing. Hiram Chirino wrote: ahhh... maven 2 is not fully supported on that branch. It's only fully implemented in the trunk, a.k.a. activemq 4.1. Use maven 1 on the 4.0 branch. On 8/14/06, bmadigan [EMAIL PROTECTED] wrote: I had done that, but the archives created don't appear to be complete: ACTIVEMQ_HOME: /home/bmadigan/Applications/activemq-4.0/assembly/target/incubator-activemq-4.0.2-SNAPSHOT Loading message broker from: xbean:activemq.xml Failed to execute main task. Reason: java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerFactory Maybe this is an error in the shell script, it does not seem to build a classpath. Hiram Chirino wrote: just run mvn install that should produce binaries in the target directory and even install them into your local maven repo. On 8/14/06, bmadigan [EMAIL PROTECTED] wrote: I need to build a local binary from a source snapshot so we can distribute it to our staging and production enviroments. Are there any maven commands that will build a local distrubtion? thanks, B. -- View this message in context: http://www.nabble.com/build-local-binary-distribution-tf2104394.html#a5799896 Sent from the ActiveMQ - Dev forum at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/build-local-binary-distribution-tf2104394.html#a5800530 Sent from the ActiveMQ - Dev forum at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/build-local-binary-distribution-tf2104394.html#a5835862 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Forming an ActiveMQ PPMC
On Aug 16, 2006, at 12:32 AM, James Strachan wrote: On 8/16/06, Brian McCallister [EMAIL PROTECTED] wrote: The ActiveMQ committers have decided to aim for TLP status (1), as such we need to get a PPMC in place. Thus far we have been working under a committer votes all count style (really, everyone's vote counts, it is on a public list without any of the mine is binding stuff that has become popular), so I would like to open the discussion of formalizing the PPMC as all current committers on ActiveMQ. FWIW we've had a PPMC in place for some time ;) which was mostly the committers plus anyone from Incubator/Geronimo PMCs who wanted to help too. (Brian search your mailbox for activemq-ppmc or activemq-private which is the latest name of the mailing list - I've seen at least 2 posts from you :) Hah, you are right! Okay, I feel stupid. /me is going to find a *lot* more coffee :-)
RE: Forming an ActiveMQ PPMC
James Strachan wrote: Brian McCallister wrote: The ActiveMQ committers have decided to aim for TLP status (1) OK we need to get a PPMC in place. Thus far we have been working under a committer votes all count style FWIW we've had a PPMC in place for some time ;) As James notes, you've already had a PPMC. And, the only votes that ever count are those from PMC members, in this case Incubator PMC members. So those would be you, Jason, James, etc. --- Noel
Re: [ANNOUNCE] Welcome Grant McDonald as our newest committer
Congratuations Grant - keep up the good work :) On 8/16/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We're pleased to announce that Grant McDonald has accepted the invitation to join Apache ServiceMix as a committer. Welcome Grant, and congratulations ! -- James --- http://radio.weblogs.com/0112098/
Re: Move trunk, tags and branches to server/*
+1On 8/16/06, Jason Dillon [EMAIL PROTECTED] wrote: I think we should move the top-level trunk, tags and branches toserver/*.This will make the top-level of our repository moreconsistent.Specifically, I think we should:svn mkdir https://svn.apache.org/repos/asf/geronimo/serversvn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tagssvn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunksvn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branchesAnd then update the pom's in server/trunk to reflect the new locationfor scm tags.--jason-- Cheers, Guillaume Nodet
[jira] Updated: (GERONIMO-1581) webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with /
[ http://issues.apache.org/jira/browse/GERONIMO-1581?page=all ] Manu T George updated GERONIMO-1581: Attachment: WSDescriptorParser.patch '/' will be stripped off in case the paths start with it. webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with / --- Key: GERONIMO-1581 URL: http://issues.apache.org/jira/browse/GERONIMO-1581 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, webservices Affects Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: Verification Required Attachments: WSDescriptorParser.patch It seems like it ought to be legal for the wsdl-file value to start with a / (in fact, the book I got my example from uses that). However, in Geronimo, that results in a java.lang.RuntimeException: Could not open stream to wsdl file. If we can't handle the preceding /, we should probably just strip it if it's there and then go on as normal (without the leading / everything is fine). The same appears to be true for the jaxrpc-mapping-file though it produces an NPE instead of the RuntimeException. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Move trunk, tags and branches to server/*
This is a simple change... but will have a large affect on developers, who will need to checkout again.When is a good time to implement this?--jasonOn Aug 15, 2006, at 11:18 PM, Guillaume Nodet wrote:+1On 8/16/06, Jason Dillon [EMAIL PROTECTED] wrote: I think we should move the top-level trunk, tags and branches toserver/*. This will make the top-level of our repository moreconsistent.Specifically, I think we should:svn mkdir https://svn.apache.org/repos/asf/geronimo/serversvn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tagssvn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunksvn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branchesAnd then update the pom's in server/trunk to reflect the new locationfor scm tags.--jason-- Cheers, Guillaume Nodet
Lets finally nuke the m1 build...
Lets just toss it... IMO it serves no purpose now... and only will end up confusing peeps. I have sent mail about this before... do we need to cast an official vote (or does this fall into lazy consensus... is been informally voted upon for about 9 days now). There are about 350+ files to be removed, as well as the duplicate sources we have laying around in a few places that were needed to support m1 after there were moved for m2. So far on the previous Drop the m1 build thread: +1: dain, jason (me), paul, sachin, david jencks, david blevins, prasad, anita, gianny, alan, matt in favor: aaron all for dropping, w/ tck consideration: jeff don't see any harm in dropping: kevan No -1 or other negative comments. Only comments relating to the TCK, and while we do need to get the TCK using the m2 infrastructure to produce the cts server build... it is not really worthwhile continuing to use the m1 build since it produces a slightly different assembly (different groupIds in plans, etc) and is not what we plan on actually shipping. Anyways, I did start looking into how to move the TCK along... but at this point I do not think that we should wait until the TCK build is on m2 to nuke the m1 build, and I don't think that the results from a m1 build would really be that valid right now anyways. * * * So can I nuke it? --jason
[jira] Commented: (GERONIMO-2325) unable to deploy from console with m2 build
[ http://issues.apache.org/jira/browse/GERONIMO-2325?page=comments#action_12428353 ] Jason Dillon commented on GERONIMO-2325: David Jencks mentioned on IRC that he wanted to peek at this change before its applied... unable to deploy from console with m2 build --- Key: GERONIMO-2325 URL: http://issues.apache.org/jira/browse/GERONIMO-2325 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Jason Dillon Attachments: 2325-console.patch deploy-new is unable to deploy anything with the m2 build because of missing dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Move trunk, tags and branches to server/*
Maybe... I've never used svn switch before... not sure I would trust it ;-)--jasonOn Aug 16, 2006, at 1:01 AM, Guillaume Nodet wrote:On 8/16/06, Jason Dillon [EMAIL PROTECTED] wrote: This is a simple change... but will have a large affect on developers, who will need to checkout again.Maybe a svn switch would work ? When is a good time to implement this?--jason On Aug 15, 2006, at 11:18 PM, Guillaume Nodet wrote:+1On 8/16/06, Jason Dillon [EMAIL PROTECTED] wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository moreconsistent.Specifically, I think we should:svn mkdir https://svn.apache.org/repos/asf/geronimo/serversvn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tagssvn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branchesAnd then update the pom's in server/trunk to reflect the new locationfor scm tags.--jason-- Cheers, Guillaume Nodet -- Cheers,Guillaume Nodet
Re: Where is the source code for the G samples ?
So, anyone know how we can recreate the sources for these. I really think we need to control the generating of these artifacts from out build. Who knows? Lets just add the samples and their customizations to applications/* --jason On Jul 27, 2006, at 1:01 PM, Dave Colasurdo wrote: IIRC, there were a few minor tweaks of the examples.. See GERONIMO-1299 and GERONIMO-1540 for details.. -Dave- Jeff Genender wrote: I believe we used the source from Tomcat verbatim as we did not want to fork the code. In fact IIRC, it was a rename of the jars. Jeff Prasad Kashyap wrote: Does anybody know where I can find the source code for the geronimo samples, jsp-examples and tomcat-examples ? We are using these in our builds from this repository http://people.apache.org/repo/m1-snapshot-repository/geronimo- samples/wars/ We should archive the classes dirs in these wars just like we do to the apps in our build. When these examples wars are used in our build as is, there is a good possibility that it might hit the long path limit on windows. Cheers Prasad
[jira] Updated: (GERONIMO-1581) webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with /
[ http://issues.apache.org/jira/browse/GERONIMO-1581?page=all ] Manu T George updated GERONIMO-1581: Patch Info: [Patch Available] Affects Version/s: 1.1.2 (was: 1.0) webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with / --- Key: GERONIMO-1581 URL: http://issues.apache.org/jira/browse/GERONIMO-1581 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, webservices Affects Versions: 1.1.2 Reporter: Aaron Mulder Priority: Critical Fix For: Verification Required Attachments: WSDescriptorParser.patch It seems like it ought to be legal for the wsdl-file value to start with a / (in fact, the book I got my example from uses that). However, in Geronimo, that results in a java.lang.RuntimeException: Could not open stream to wsdl file. If we can't handle the preceding /, we should probably just strip it if it's there and then go on as normal (without the leading / everything is fine). The same appears to be true for the jaxrpc-mapping-file though it produces an NPE instead of the RuntimeException. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-522) Missing buildSharedLibrary implementation in ServiceMixConfigBuilder gbean
[ https://issues.apache.org/activemq/browse/SM-522?page=all ] Guillaume Nodet resolved SM-522. Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Wed Aug 16 02:56:48 2006 New Revision: 431871 URL: http://svn.apache.org/viewvc?rev=431871view=rev Log: SM-522: fix geronimo integration where the SL were not supported. Also rework it so it now uses the new m2 plugin, and include the necessary informations to make G plugins. ... and moved the all Geronimo integration to the sandbox Missing buildSharedLibrary implementation in ServiceMixConfigBuilder gbean -- Key: SM-522 URL: https://issues.apache.org/activemq/browse/SM-522 Project: ServiceMix Issue Type: Bug Components: geronimo Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.0-M3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2312) Create a New JMS Group throws error for external RAR
[ http://issues.apache.org/jira/browse/GERONIMO-2312?page=comments#action_12428362 ] Krishnakumar B commented on GERONIMO-2312: -- Create a new JMS Group deploys successfully if there is no geronimo-ra plan bundled with RA. This is expected behavior. Hence instead of showing a wrong plan if geronimo-ra is bundled with RA it can either be ignored or a error message can be thrown to remove the plan from RA. Create a New JMS Group throws error for external RAR Key: GERONIMO-2312 URL: http://issues.apache.org/jira/browse/GERONIMO-2312 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Reporter: Krishnakumar B Attachments: GERJMSRAR.rar I deployed a JMS RAR using Deploy new and it is deployed. I tried to create a New JMS Group using the console wizard. When i see the deployment plan it doesnt seem right and i get a deployment error when i deploy this plan. The plan looks like this : connector xmlns=http://geronimo.apache.org/xml/ns/j2ee/connector-1.1; environment moduleId groupIdtest/groupId artifactIdjms.rar/artifactId version1.0/version /moduleId dependencies .. /dependencies /environment dep:environment xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.1; dep:moduleId dep:groupIdconsole.jms/dep:groupId dep:artifactIdTestJMSRA/dep:artifactId dep:version1.0/dep:version dep:typerar/dep:type /dep:moduleId /dep:environment resourceadapter resourceadapter-instance resourceadapter-nameTestJMSRA/resourceadapter-name workmanager gbean-linkDefaultWorkManager/gbean-link /workmanager nam:workmanager xmlns:nam=http://geronimo.apache.org/xml/ns/naming-1.1; nam:gbean-linkDefaultWorkManager/nam:gbean-link /nam:workmanager /resourceadapter-instance . Clearly the deployment plan generated is not correct. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Move trunk, tags and branches to server/*
+1 Gianny On 16/08/2006, at 11:49 AM, Matt Hogstrom wrote: +1...good first step Jason Dillon wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason
Validation Wiki Updated
People, I've updated the Validation wiki page to give examples of how to configure the ValidateComponent using the enhanced error handling interface and a short description of the fault message format. Let me know if it needs further expanding. - Grant M.
Re: Where is the source code for the G samples ?
I remember someone telling me that they were there (applications/*) before to begin with. They were later put elsewhere. Don't recall who said that or where it got moved :-( Cheers Prasad On 8/16/06, Jason Dillon [EMAIL PROTECTED] wrote: So, anyone know how we can recreate the sources for these. I really think we need to control the generating of these artifacts from out build. Who knows? Lets just add the samples and their customizations to applications/* --jason On Jul 27, 2006, at 1:01 PM, Dave Colasurdo wrote: IIRC, there were a few minor tweaks of the examples.. See GERONIMO-1299 and GERONIMO-1540 for details.. -Dave- Jeff Genender wrote: I believe we used the source from Tomcat verbatim as we did not want to fork the code. In fact IIRC, it was a rename of the jars. Jeff Prasad Kashyap wrote: Does anybody know where I can find the source code for the geronimo samples, jsp-examples and tomcat-examples ? We are using these in our builds from this repository http://people.apache.org/repo/m1-snapshot-repository/geronimo- samples/wars/ We should archive the classes dirs in these wars just like we do to the apps in our build. When these examples wars are used in our build as is, there is a good possibility that it might hit the long path limit on windows. Cheers Prasad
Re: Form editors for Geronimo Deployment Plans
Hello Sachin,Sorry for not being in touch for quite some time now. I have been going through Aaron Mulder's book on Geronimo v1.1, especially the chapters on Geronimo Deployment Plans. Apart from that I was also on vacation for two weeks. Not much progress has been made w.r.t. the design devlp of Form editors for Geronimo Deployment Plans.I will bring in some focus into my work. Here is what I am planning to do next. Please suggest if I need to look into something else also. i) Complete the reading understanding of Geronimo Deployment Plans from Aaron's book.ii) Look at the Deployment Plan Editors provided in other IDEs like Rational Application Developer or JBoss Eclipse IDE. iii) Come up with the initial design/layout of Form editors for Geronimo Deployment Plans.-- Thx,Shiva On 7/18/06, Sachin Patel [EMAIL PROTECTED] wrote: Great!On Jul 18, 2006, at 8:37 AM, Shiva Kumar H R wrote:Hello Sachin,I now have the complete build setup for Geronimo Eclipse Plugin on my Windows machine (thanks to your article http://cwiki.apache.org/confluence/display/GMOxDOC11/Geronimo+Eclipse+Plugin+FAQ ).I am planning to get started on developing/enhancing the Geronimo deployment plan editors. I am currently looking at package org.apache.geronimo.st.ui.editors; class SharedDeploymentPlanEditor; class AbstractGeronimoDeploymentPlanEditor;Will keep you posted on my progress.-- Thx,Shiva -sachin
[WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. The Apache Geronimo PMC
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congrats Alan! Matt Hogstrom wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC
Re: [WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
Congrats Guillaume! Matt Hogstrom wrote: All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. The Apache Geronimo PMC
Re: Form editors for Geronimo Deployment Plans
Awesome! This is exactly what is needed!On Aug 16, 2006, at 8:57 AM, Shiva Kumar H R wrote:Hello Sachin,Sorry for not being in touch for quite some time now. I have been going through Aaron Mulder's book on Geronimo v1.1, especially the chapters on Geronimo Deployment Plans. Apart from that I was also on vacation for two weeks. Not much progress has been made w.r.t. the design devlp of "Form editors for Geronimo Deployment Plans".I will bring in some focus into my work. Here is what I am planning to do next. Please suggest if I need to look into something else also. i) Complete the reading understanding of Geronimo Deployment Plans from Aaron's book.ii) Look at the Deployment Plan Editors provided in other IDEs like Rational Application Developer or JBoss Eclipse IDE. iii) Come up with the initial design/layout of "Form editors for Geronimo Deployment Plans".-- Thx,Shiva On 7/18/06, Sachin Patel [EMAIL PROTECTED] wrote: Great!On Jul 18, 2006, at 8:37 AM, Shiva Kumar H R wrote:Hello Sachin,I now have the complete build setup for Geronimo Eclipse Plugin on my Windows machine (thanks to your article http://cwiki.apache.org/confluence/display/GMOxDOC11/Geronimo+Eclipse+Plugin+FAQ ).I am planning to get started on developing/enhancing the Geronimo deployment plan editors. I am currently looking at package org.apache.geronimo.st.ui.editors; class SharedDeploymentPlanEditor; class AbstractGeronimoDeploymentPlanEditor;Will keep you posted on my progress.-- Thx,Shiva -sachin -sachin
Re: [WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
Congrats Guillaume!!! Cheers! Hernan Matt Hogstrom wrote: All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. The Apache Geronimo PMC
Re: 185 changes left in all_changes.log...
Jason, You can achieve the same thing with OpenCalc, which is part of the OpenOffice project which while sponsored by Sun, is Open Source, not to mention Free (as in beer). http://www.openoffice.org Enjoy, Ian It's better to be hated for who you are than loved for who you're not Ian D. Stewart Distributed Computing Engineer II DSS eCommerce Engineering JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Jason Dillon [EMAIL PROTECTED] omTo Sent by: Jasondev@geronimo.apache.org Dillon cc [EMAIL PROTECTED] il.com Subject 185 changes left in all_changes.log... 08/15/2006 07:38 PM Please respond to [EMAIL PROTECTED] he.org I've chopped off the obvious ones... but there are still 185 marked as Not Merged which someone should peep at. I generally hate all things microsoft... except I'm starting to like my xbox, and well excel was really handy to sort the table so its easier to see what is still in need of merging. Attached is a csv (with a bit of funky formatting) sorted by the first column. It would be nice if we could trim down the list of Not Merged even more... and then be done with that branch. Please have a look if you have some free time. Thanks, --jason [attachment dead-1.2-merge-status.csv deleted by Ian D Stewart/OH/ONE] - This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
[jira] Created: (GERONIMODEVTOOLS-103) not able to get geronimo plan editor recognize openejb-jar.xml or geronimo-application.xml
not able to get geronimo plan editor recognize openejb-jar.xml or geronimo-application.xml -- Key: GERONIMODEVTOOLS-103 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-103 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 1.1.0 Environment: Eclipse 3.2 and WTP 1.5 windows XP Reporter: Lin Sun I still have similar prob. The MDB openejb-jar.xml plan actually contains the fully qualified tags but it cannot be opened with the geornimo plan editor. Similar with a new openejb-jar.xml file created by default using the create new ejb project wizard. Is this also some code missed from 1.0? This was working in 1.0 from what I remember. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-867) JMX Management Console Not Working As Documented
[ https://issues.apache.org/activemq/browse/AMQ-867?page=comments#action_36795 ] Oliver Flege commented on AMQ-867: -- I had the same problem; my workaround is to remove the line SUNJMX=-Dcom.sun.management.jmxremote from the activemq script JMX Management Console Not Working As Documented Key: AMQ-867 URL: https://issues.apache.org/activemq/browse/AMQ-867 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1, 4.0.2 Environment: Linux nuk 2.6.15-23-amd64-generic #1 SMP PREEMPT Tue May 23 13:45:47 UTC 2006 x86_64 GNU/Linux Reporter: Douglas A. Seifert Starting in 4.0.1 and continuing in a snapshot 4.0.2 release, the ActiveMQ JMX management console is not working as advertised. In version 4.0, I would see the following message logged to the console when starting activemq: INFO ManagementContext - JMX consoles can connect to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi In Version 4.0.1 and higher, I no longer see this message. When trying to connect to the broker using the jconsole program, in versions 4.0.1 and higher, the following command does not work (get Connection failed message). jconsole service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi However, in 4.0, it does work. With 4.0.1 and higher, I am able to execute jconsole with no arguments and pick the activemq jvm from the dialog that pops up and access the managment mbeans just fine. A symptom of this problem in 4.0.1 and higher is that none of the command line tools in the bin directory work. Here is sample output: [EMAIL PROTECTED]:~/tools/activemq/incubator-activemq-4.0.2/bin$ ./shutdown ACTIVEMQ_HOME: /home/doug/tools/activemq/incubator-activemq-4.0.2 ERROR: java.lang.RuntimeException: Failed to execute stop task. Reason: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused] ERROR: java.lang.Exception: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused] With 4.0, all command line tools work as expected. Not sure what is going on here, but something changed in versions 4.0.1 and above. One last note: in 4.0.1 and higher, I uncommented the managementContext tag in the activemq.xml file, but that had no effect. The problem remained as described here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Organization and versioning of specs; a new proposal
On Aug 16, 2006, at 3:56 AM, Jason Dillon wrote:
What is the status on 1.1.1 wrt this change? Can I go ahead and
make these changes?
My reading of Matt's note (which I agree with) is that you should
wait until 1.1.1 has been shipped (unless 1.1.1 runs into an extended
delay in releasing due to administrative matters).
I think this change should follow the RTC process. This is not a bug
fix, not a doc change, etc. It's updating svn and changing the way we
deliver specs -- my read is that it falls under RTC.
You don't mention geronimo-j2ee_1.4_spec (the uber-jar). It's
currently versioned using the top-level pom version. I assume you
plan on adding a geronimoSpecsJ2eeVersion?
Your process for updating the jms spec would be:
cd specs/geronimo-spec-jms
mvn release
cd ../geronimo-spec-j2ee
mvn release
I'm not so sure that this is any better than we have now... I see two
options:
1) drop the uber-jar
2) release all specs simultaneosly (even if they haven't changed) and
all have the same version...
--kevan
--jason
On Aug 12, 2006, at 12:16 AM, Matt Hogstrom wrote:
Jason,
I'm +1 on the change. In order to release 1.1.1 we need to
release an updated version of the J2EE_JAAC specs. I am waiting
for feedback from Geir on some licensing issues as well as a TCK
run that Kevan is doing. That said I'd prefer to wait until the
we cut the 1.1.1 release. If it looks like its going to be
delayed due to the licensing concerns then we should do this
straight away next week.
Since this isn't a code change I agree with Jason's comments on no
review required. Lazy consensus is appropriate here.
Jason Dillon wrote:
A while ago there was talks about independently versioning specs,
and Alan started a reorg branch which gives each spec module its
own trunk+branches+tags...
I have been thinking about this for a while, and with the recent
desire to split off more modules from geronimo/trunk I've been
pondering it even more. What I have come to believe is that
spitting up spec modules into their own trunk+branches+tags is
probably not the best direction for us to head in.
I believe that all of our specs can, and should, share one
trunk... and still have each module specify its own version.
This is very similar to how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently. The
top-level pom has a version too, which is independent and is only
changed when there is a major configuration change in that pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check out
and building when you just want all of the specs. If each spec
was in its own trunk, you would need to svn co each one, then mvn
install in each tree, which is a pain.
We also almost never branch specs, they just keep chugging along,
only really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
And if needed:
specs/branches/artifactId/name
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/
specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which
we can set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$
{pom.artifactId}
When released, the plugin will svn cp just the module's directory
into a directory under tags, so it will be easy to see what the
released versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own trunk,
and really I think that if we did then it would just make it more
difficult for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change, which
isn't that major, is that the properties which live in the root
pom that control the versions need to be removed... or rather
moved back to the version element of the respective pom.
Comments?
--jason
Re: Possible blocker for 1.1.1 -- console broken
I only saw the problem in Jetty. Tomcat seems to work OK. May have to do with the way that Jetty encodes URLs. But I stopped looking last night when I saw that Alan had a solution in hand. Paul On 8/16/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 8/16/06, Kevan Miller [EMAIL PROTECTED] wrote: I don't think that it's a blocker. Could be fixed in 1.1.2... I disagree -- if this is the JACC issue Alan is working on, it makes it impossible to create a database pool in the console. (Though maybe there are two separate issues here, because I never got to the point of entering a colon) Thanks, Aaron On Aug 15, 2006, at 9:43 PM, David Jencks wrote: Bill Dudney found a problem with the console -- see GERONIMO-2326 I've been able to reproduce it on branches/1.1 so I expect it is also a problem on 1.1.1. I think the problem only occurs when you try to deploy a non-xa driver, which then includes a database url with lots of colons in the servlet/portlet url. These colons don't work with the new fixes alan put in to the web app security. I think the solution is to encode the db urls, but I'm not sure when the url is being constructed nor if the encoding should be our responsibility or pluto's If any console experts such as Aaron have any ideas that would be great. As a completely separate issue it looks like the work in rev 412804 did not make it into trunk... I'm getting worried about drift between the versions. thanks david jencks
[jira] Assigned: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=all ] Sachin Patel reassigned GERONIMO-2324: -- Assignee: Sachin Patel Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=all ] Sachin Patel updated GERONIMO-2324: --- Attachment: GERONIMO-2324.patch Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=all ] Sachin Patel updated GERONIMO-2324: --- Issue Type: RTC (was: Improvement) Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Where is the source code for the G samples ?
I think they were removed from Geronimo as part of the plugins work. Aaron provides the samples as plugins now. Perhaps we need to have them in G as well due to the issues you are tracking. I think it made sense to move them previously but sounds like there are reasons to keep them in both places. Prasad Kashyap wrote: Does anybody know where I can find the source code for the geronimo samples, jsp-examples and tomcat-examples ? We are using these in our builds from this repository http://people.apache.org/repo/m1-snapshot-repository/geronimo-samples/wars/ We should archive the classes dirs in these wars just like we do to the apps in our build. When these examples wars are used in our build as is, there is a good possibility that it might hit the long path limit on windows. Cheers Prasad
Re: Move trunk, tags and branches to server/*
Jason, I'd suggest Wednesday night midnight (Thursday morning 0001 PT) as most peeps will be sleeping, getting ready to sleep or waking up and we have a Friday. I don't think there is ever going to be a universally good time. Next Wednesday would be my vote as I think 1.1.1 will be completed. Others? Jason Dillon wrote: This is a simple change... but will have a large affect on developers, who will need to checkout again. When is a good time to implement this? --jason On Aug 15, 2006, at 11:18 PM, Guillaume Nodet wrote: +1 On 8/16/06, Jason Dillon [EMAIL PROTECTED] wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason --Cheers, Guillaume Nodet
Re: Where is the source code for the G samples ?
On 8/16/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I think they were removed from Geronimo as part of the plugins work. Aaron provides the samples as plugins now. Perhaps we need to have them in G as well due to the issues you are tracking. I think it made sense to move them previously but sounds like there are reasons to keep them in both places. Nope. I just took them out of the assemblies. I didn't change the way that they were built, other than to add the geronimo-plugin.xml to the various config/ modules. I've never seen the source for these examples. Didn't the JARs just pop off of Zeus' leg or something? Thanks, Aaron Prasad Kashyap wrote: Does anybody know where I can find the source code for the geronimo samples, jsp-examples and tomcat-examples ? We are using these in our builds from this repository http://people.apache.org/repo/m1-snapshot-repository/geronimo-samples/wars/ We should archive the classes dirs in these wars just like we do to the apps in our build. When these examples wars are used in our build as is, there is a good possibility that it might hit the long path limit on windows. Cheers Prasad
Re: Where is the source code for the G samples ?
Aaron, Its soming clearer now...I think we grabbed the jars straight from Tomcat. Aaron Mulder wrote: On 8/16/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I think they were removed from Geronimo as part of the plugins work. Aaron provides the samples as plugins now. Perhaps we need to have them in G as well due to the issues you are tracking. I think it made sense to move them previously but sounds like there are reasons to keep them in both places. Nope. I just took them out of the assemblies. I didn't change the way that they were built, other than to add the geronimo-plugin.xml to the various config/ modules. I've never seen the source for these examples. Didn't the JARs just pop off of Zeus' leg or something? Thanks, Aaron Prasad Kashyap wrote: Does anybody know where I can find the source code for the geronimo samples, jsp-examples and tomcat-examples ? We are using these in our builds from this repository http://people.apache.org/repo/m1-snapshot-repository/geronimo-samples/wars/ We should archive the classes dirs in these wars just like we do to the apps in our build. When these examples wars are used in our build as is, there is a good possibility that it might hit the long path limit on windows. Cheers Prasad
Re: JPA Plugin Status
I'm releasing out of branches/1_1_1. Is your stuff in trunk ? David Blevins wrote: Grrr, I'm missing mail again -- pulled it from the archives. Thanks, Dain, for pointing out there was a message for me. On 8/15/06, Matt Hogstrom [EMAIL PROTECTED] wrote: David, I am releasing the specs as a 1.1.1 release due to some changes in jacc. Do you want to include the changes to JPA there? That would be great. In fact all the jee5_exp specs could be released. The related specifications went final so we should be good to go. -David On Aug 15, 2006, at 4:17 AM, David Blevins wrote: I got OpenJPA to run with my JPA code. So we're looking real good. On Aug 13, 2006, at 8:24 PM, Aaron Mulder wrote: So far, it's just got a TopLink provider, but if people want to copy that to create providers for Cayenne or OpenJPA or whatever, that would be great. It basically just needs to have a customized name and ClassPath, though I'm assuming any provider we integrate with will be compatible with the Geronimo JPA spec JAR (currently org.apache.geronimo.specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/jar) OpenJPA and the Geronimo JPA spec jar weren't happy. Our JPA jar had some bad signatures and was missing a few exception classes. I fixed those and managed to get OpenJPA to compile and run with our JPA jar rather than the CDDL version they use. If you try to build and run this, you'll be held up by a couple things: For me its: - Still missing the some JNDI stuff Dain is working on (mentioned earlier in the thread). - Need the plugin goop But when that is there, this should run for ejbs or servlets in 1.1.1 and maybe 1.1 (should work). My goal is to have a release of this plugin with sufficient user documentation when G 1.1.1 is released. It would be great to have some open source JPA providers for that release too. I also started talking to David B about the JPA work being done in OpenEJB, and I think we're agreed that we probably don't need two such plugins for G 1.1.x, so hopefully we can work toward a unification as we move forward. I'm sure we can figure something out. I'll give it some more thought tomorrow, time for bed now -David
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428410 ] David Jencks commented on GERONIMO-2324: I'm not thoroughly convinced this is a good idea. Does tomcat offer a similar feature? Some of my concerns: - Can you get the same effect by changing the classes and libs properties of the existing gbean? - Why would we encourage people to use shared lib rather than explicit dependencies? I'd rather see the repo code modified to include links to the actual jar/exploded jar location so you could point bits of the repo into your development environment. - What is the value of writing out an empty externals file? I think if you don't supply a file, we should assume you are not interested in this feature and not modify the environment. Certainly if no externals file name is supplied, we shouldn't try to write a file. - Does this actually work for both classes directories and individual jars? A test would be nice. On a technical level, the e.printStackTrace should be replaced with a log statement. In general there look to be a lot of failure cases that aren't taken care of. If an externals file is listed and not present, it's possible we should fail startup. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-545) jbi-maven-plugin throws an error when building a jbi-service-assembly with 2 or more dependencies using the same component.
jbi-maven-plugin throws an error when building a jbi-service-assembly with 2 or more dependencies using the same component. --- Key: SM-545 URL: https://issues.apache.org/activemq/browse/SM-545 Project: ServiceMix Issue Type: Bug Components: tooling Reporter: Fritz Oconer Assigned To: Fritz Oconer Fix For: 3.0 Buiding a jbi-servicemix-assembly containing 2 or more service-units dependencies that uses same component an exception is thrown. [INFO] The service unit grocery-demo-poll does not have a dependency which is pa ckaged as a jbi-component or a project property 'componentName' [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The service unit grocery -demo-poll does not have a dependency which is packaged as a jbi-component or a project property 'componentName' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428413 ] Sachin Patel commented on GERONIMO-2324: Keep in mind this is to support development scenarios only. If a project in an IDE references jars in lets say a maven repo. We need the ability to add individual entries to the shard lib, without having to copy each individual jar over to the shared library.So the answer to your first question is no, this is not the same, there is no way to add invidivial entries. I don't quite understand your second bullet. Third bullet, true, just thought it would be nice to have an empty template. Yes, agree a test case should be added. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Merge GERONIMO-2313 into 1.1.1??
GERONIMO-2313 is a fairly serious security problem: basically ejb security is totally broken when the ejb is called from a web app. I think this could be merged easily from the 1.1 branch into 1.1.1, however it requires openejb changes as well. Alan suggested that since 1.1.1 is already delayed for security problems we might want to include this fix as well. I think this is a good idea but wait for Matt the release manager's approval. thanks david jencks
[jira] Commented: (GERONIMO-2325) unable to deploy from console with m2 build
[ http://issues.apache.org/jira/browse/GERONIMO-2325?page=comments#action_12428428 ] David Jencks commented on GERONIMO-2325: The patch isn't a very good solution to the problem, it results in duplicated classes. I'm not quite sure how the console works at the moment with its dependencies as they are I'm working on cleaning them up a bit. Basically a better fix is to include the j2ee-deployer car as a dependency, and remove a lot of stuff it pulls in. unable to deploy from console with m2 build --- Key: GERONIMO-2325 URL: http://issues.apache.org/jira/browse/GERONIMO-2325 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Jason Dillon Attachments: 2325-console.patch deploy-new is unable to deploy anything with the m2 build because of missing dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Merge GERONIMO-2313 into 1.1.1??
After agonizing over this on IRC let's put in 2313. Close the door and start testing. David Jencks wrote: GERONIMO-2313 is a fairly serious security problem: basically ejb security is totally broken when the ejb is called from a web app. I think this could be merged easily from the 1.1 branch into 1.1.1, however it requires openejb changes as well. Alan suggested that since 1.1.1 is already delayed for security problems we might want to include this fix as well. I think this is a good idea but wait for Matt the release manager's approval. thanks david jencks
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428429 ] Paul McMahan commented on GERONIMO-2324: I agree this is an important feature, I would use this in Eclipse all the time. The patch didn't apply cleanly for me on branches/1.1: bash-3.1$ patch -p0 ../patches/GERONIMO-2324.patch patching file configs/sharedlib/src/plan/plan.xml patching file modules/system/src/java/org/apache/geronimo/system/sharedlib/SharedLib.java Hunk #1 FAILED at 16. 1 out of 3 hunks FAILED -- saving rejects to file modules/system/src/java/org/apache/geronimo/system/sharedlib/SharedLib.java.rej bash-3.1$ Also, I'm wondering if adding the external jars via SharedLib is ideal since as I understand it SharedLib makes the classes available server wide and this might cause complications when two applications in the development environment want to use different versions of an external jar. But maybe I am misunderstanding SharedLib . Could the Eclipse plugin add the external dependencies into the application's MANIFEST.MF instead? Might be cleaner since it's application specific. One more question :-) What happens when the application is exported from Eclipse? Are the external references exported somehow or is that left to be resolved later at deployment time? Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428431 ] Sachin Patel commented on GERONIMO-2324: Modifying the application's manifest isn't the solution to the problem. The problem is we need to be able to provide support in an IDE to allow projects who reference the sharedlib and have external references to jars and what to represent those external jars as shared-lib entries. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428439 ] Paul McMahan commented on GERONIMO-2324: OK, I think I understand the usage scenario better now. i.e. these users are *already* using SharedLib and just want more/better support for it in the dev tooling(?). I'll watch for an updated patch and test it out. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r431882 - /geronimo/branches/1.1.1/configs/openejb-deployer/src/plan/plan.xml
I'm not picking up the corresponding changes in the openejb 2.1.1
branch for this to work did you really mean for this to go into
the 1.1.1 branch?
thanks
david jencks
On Aug 16, 2006, at 5:01 AM, [EMAIL PROTECTED] wrote:
Author: gdamour
Date: Wed Aug 16 05:01:06 2006
New Revision: 431882
URL: http://svn.apache.org/viewvc?rev=431882view=rev
Log:
merge 367589:367590
Modified:
geronimo/branches/1.1.1/configs/openejb-deployer/src/plan/plan.xml
Modified: geronimo/branches/1.1.1/configs/openejb-deployer/src/plan/
plan.xml
URL: http://svn.apache.org/viewvc/geronimo/branches/1.1.1/configs/
openejb-deployer/src/plan/plan.xml?
rev=431882r1=431881r2=431882view=diff
==
--- geronimo/branches/1.1.1/configs/openejb-deployer/src/plan/
plan.xml (original)
+++ geronimo/branches/1.1.1/configs/openejb-deployer/src/plan/
plan.xml Wed Aug 16 05:01:06 2006
@@ -57,7 +57,11 @@
gbean name=CSSAttributeBuilder
class=org.openejb.corba.security.config.css.CSSConfigEditor/
gbean name=TSSAttributeBuilder
class=org.openejb.corba.security.config.tss.TSSConfigEditor/
-gbean name=ClientEJBReferenceBuilder
class=org.openejb.deployment.RemoteEJBReferenceBuilder/
+gbean name=ClientEJBReferenceBuilder
class=org.openejb.deployment.RemoteEJBReferenceBuilder
+attribute name=host${PlanServerHostname}/attribute
+attribute name=port${PlanOpenEJBPort}/attribute
+/gbean
+
gbean name=ServerEJBReferenceBuilder
class=org.openejb.deployment.OpenEJBReferenceBuilder/
gbean name=WebServiceEJBLinkTemplate
class=org.openejb.server.axis.WSContainerGBean/
Re: Validation Wiki Updated
Cool, thanks. On 8/16/06, Grant McDonald [EMAIL PROTECTED] wrote: People, I've updated the Validation wiki page to give examples of how to configure the ValidateComponent using the enhanced error handling interface and a short description of the fault message format. Let me know if it needs further expanding. - Grant M. -- Cheers, Guillaume Nodet
[jira] Updated: (GERONIMO-2313) Subject not propagated correctly between web app and ejb
[ http://issues.apache.org/jira/browse/GERONIMO-2313?page=all ] David Jencks updated GERONIMO-2313: --- Fix Version/s: 1.1.1 Subject not propagated correctly between web app and ejb Key: GERONIMO-2313 URL: http://issues.apache.org/jira/browse/GERONIMO-2313 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1, 1.1.1, 1.1.x Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 1.1.2, 1.1.1 Attachments: ejbrefsec-ear-1.0-SNAPSHOT.ear, ejbrefsec.src.jar, GERONIMO-2313-openejb.diff, GERONIMO-2313.diff With a web app with security, that calls an ejb, isCallerInRole in the ejb always returns false. this is caused by the web app not setting nextCaller and the ejb interceptors shifting nextCaller to currentCaller, so when the isCallerInRole is tested there is a null subject so it returns false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428473 ] Sachin Patel commented on GERONIMO-2324: I think this is a perfectly reasonable feature request... if we're going to provide features in the runtime, we need to be sure a development enviorment can propertly support it as well. Otherwise, I suggest we compltely take out the sharedlib support so that users don't treat it as a deployment mechanism. Thus avoiding feature reqests such as this. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Where is the source code for the G samples ?
We grabbed the jars from Tomcat, unpacked them and manually made a few changes to them (outside of source control) and published the resulting wars. Here is the description of the manual changes: http://issues.apache.org/jira/browse/GERONIMO-1299 -Dave- Matt Hogstrom wrote: Aaron, Its soming clearer now...I think we grabbed the jars straight from Tomcat. Aaron Mulder wrote: On 8/16/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I think they were removed from Geronimo as part of the plugins work. Aaron provides the samples as plugins now. Perhaps we need to have them in G as well due to the issues you are tracking. I think it made sense to move them previously but sounds like there are reasons to keep them in both places. Nope. I just took them out of the assemblies. I didn't change the way that they were built, other than to add the geronimo-plugin.xml to the various config/ modules. I've never seen the source for these examples. Didn't the JARs just pop off of Zeus' leg or something? Thanks, Aaron Prasad Kashyap wrote: Does anybody know where I can find the source code for the geronimo samples, jsp-examples and tomcat-examples ? We are using these in our builds from this repository http://people.apache.org/repo/m1-snapshot-repository/geronimo-samples/wars/ We should archive the classes dirs in these wars just like we do to the apps in our build. When these examples wars are used in our build as is, there is a good possibility that it might hit the long path limit on windows. Cheers Prasad
Re: Build problems with SerivceMix
Hi Philip, I tried the instructions from the above site, but getting the same error. It could not download a plugin JAR. The error is the same as I have posted in my previous post. Is there some other issue involved in this. Some help will truly be appreciated. Thanks a lot in advance. Mahbubur Mahbubur wrote: Thanks a lot. I will try it. I truly appreciate the help. Mahbub. Philip Dodds-2 wrote: See the Building information on the website - http://www.servicemix.org/site/building.html Note that it recently changed for the coming M3. P On 8/15/06, Mahbubur [EMAIL PROTECTED] wrote: Hello All, I am a newbie to the world of ServiceMix. I have downloaded the ServiceMix source from: apache-servicemix-3.0-M2-incubating and the maven-2.0.4 When I am trying to build with the following command: mvn -Dmaven.test.skip=true install I am getting the following messages. Would anyone let me know what I should (or should not) be doing? Thanks a lot in advance. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] ServiceMix [INFO] ServiceMix :: JBI [INFO] ServiceMix :: Services [INFO] ServiceMix :: Core [INFO] ServiceMix :: Components [INFO] ServiceMix :: Common [INFO] ServiceMix :: SOAP [INFO] ServiceMix :: Console [INFO] ServiceMix :: Tooling [INFO] ServiceMix :: Maven2 :: JBI Plugin [INFO] ServiceMix :: HTTP [INFO] ServiceMix :: BPE [INFO] ServiceMix :: JMS [INFO] ServiceMix :: JSR-181 Service Engine [INFO] ServiceMix :: WS-Notification Service Engine [INFO] ServiceMix :: Lightweight container Service Engine [INFO] ServiceMix :: SCA Service Engine [INFO] ServiceMix :: Web [INFO] ServiceMix :: EIP [INFO] ServiceMix :: ITests [INFO] ServiceMix :: BeanFlow [INFO] ServiceMix :: Maven2 :: Archetypes :: BindingComponent [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceEngine [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceUnit [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceAssembly [INFO] ServiceMix :: Samples [INFO] ServiceMix :: Samples :: WSDL first [INFO] ServiceMix :: Samples :: WSDL first :: JSR181 [INFO] ServiceMix :: Samples :: WSDL first :: HTTP [INFO] ServiceMix :: Samples :: WSDL first :: SA [INFO] Servicemix :: Assembly Downloading: http://servicemix.org/m2-repo/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-m2-repo (http://servicemix.org/m2-repo) Downloading: http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.tooling -DartifactId=jbi-maven-plugin \ -Dversion=1.0-M2-incubating -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.servicemix.tooling:jbi-maven-plugin:maven-plugin:1.0-M2-incubating from the specified remote repositories: central (http://repo1.maven.org/maven2), servicemix-m2-repo (http://servicemix.org/m2-repo), servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) org.apache.servicemix.tooling:jbi-maven-plugin:maven-plugin:1.0-M2-incubating from the specified remote repositories: central (http://repo1.maven.org/maven2), servicemix-m2-repo (http://servicemix.org/m2-repo), servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Tue Aug 15 09:40:14 CDT 2006 [INFO] Final Memory: 5M/159M [INFO] -- View this message in context: http://www.nabble.com/Build-problems-with-SerivceMix-tf2109810.html#a5816326 Sent from the ServiceMix - Dev forum at Nabble.com. -- View this
[jira] Updated: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=all ] Joe Bohn updated GERONIMO-2324: --- Attachment: GERONIMO-2324.patch I couldn't get the original patch to apply clean. Here is an updated patch that does apply (at least for me). The content of this patch is the same as the original (none of the comments/recommendations have been implemented in this patch ... it just applies now). Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Build problems with SerivceMix
Can you run mvn -Dmaven.test.skip=true -Pstep1 install from the root of the source tree , and then try mvn -Dmaven.test.skip=true install from the same location? Note sure why people are having problems with the build I refreshed yesterday without any issues? might be a problem with first builds :( P On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi Philip, I tried the instructions from the above site, but getting the same error. It could not download a plugin JAR. The error is the same as I have posted in my previous post. Is there some other issue involved in this. Some help will truly be appreciated. Thanks a lot in advance. Mahbubur Mahbubur wrote: Thanks a lot. I will try it. I truly appreciate the help. Mahbub. Philip Dodds-2 wrote: See the Building information on the website - http://www.servicemix.org/site/building.html Note that it recently changed for the coming M3. P On 8/15/06, Mahbubur [EMAIL PROTECTED] wrote: Hello All, I am a newbie to the world of ServiceMix. I have downloaded the ServiceMix source from: apache-servicemix-3.0-M2-incubating and the maven-2.0.4 When I am trying to build with the following command: mvn -Dmaven.test.skip=true install I am getting the following messages. Would anyone let me know what I should (or should not) be doing? Thanks a lot in advance. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] ServiceMix [INFO] ServiceMix :: JBI [INFO] ServiceMix :: Services [INFO] ServiceMix :: Core [INFO] ServiceMix :: Components [INFO] ServiceMix :: Common [INFO] ServiceMix :: SOAP [INFO] ServiceMix :: Console [INFO] ServiceMix :: Tooling [INFO] ServiceMix :: Maven2 :: JBI Plugin [INFO] ServiceMix :: HTTP [INFO] ServiceMix :: BPE [INFO] ServiceMix :: JMS [INFO] ServiceMix :: JSR-181 Service Engine [INFO] ServiceMix :: WS-Notification Service Engine [INFO] ServiceMix :: Lightweight container Service Engine [INFO] ServiceMix :: SCA Service Engine [INFO] ServiceMix :: Web [INFO] ServiceMix :: EIP [INFO] ServiceMix :: ITests [INFO] ServiceMix :: BeanFlow [INFO] ServiceMix :: Maven2 :: Archetypes :: BindingComponent [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceEngine [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceUnit [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceAssembly [INFO] ServiceMix :: Samples [INFO] ServiceMix :: Samples :: WSDL first [INFO] ServiceMix :: Samples :: WSDL first :: JSR181 [INFO] ServiceMix :: Samples :: WSDL first :: HTTP [INFO] ServiceMix :: Samples :: WSDL first :: SA [INFO] Servicemix :: Assembly Downloading: http://servicemix.org/m2-repo/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-m2-repo (http://servicemix.org/m2-repo) Downloading: http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.tooling -DartifactId=jbi-maven-plugin \ -Dversion=1.0-M2-incubating -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.servicemix.tooling:jbi-maven-plugin:maven-plugin:1.0-M2-incubating from the specified remote repositories: central (http://repo1.maven.org/maven2), servicemix-m2-repo (http://servicemix.org/m2-repo), servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) org.apache.servicemix.tooling:jbi-maven-plugin:maven-plugin:1.0-M2-incubating from the specified remote repositories: central (http://repo1.maven.org/maven2), servicemix-m2-repo (http://servicemix.org/m2-repo), servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO]
Re: Build problems with SerivceMix
It's not a problem with the first build, as I did a *clean* (deleting my m2 repo) build without any problems using the known instructions (step1, step2). On 8/16/06, Philip Dodds [EMAIL PROTECTED] wrote: Can you run mvn -Dmaven.test.skip=true -Pstep1 install from the root of the source tree , and then try mvn -Dmaven.test.skip=true install from the same location? Note sure why people are having problems with the build I refreshed yesterday without any issues? might be a problem with first builds :( P On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi Philip, I tried the instructions from the above site, but getting the same error. It could not download a plugin JAR. The error is the same as I have posted in my previous post. Is there some other issue involved in this. Some help will truly be appreciated. Thanks a lot in advance. Mahbubur Mahbubur wrote: Thanks a lot. I will try it. I truly appreciate the help. Mahbub. Philip Dodds-2 wrote: See the Building information on the website - http://www.servicemix.org/site/building.html Note that it recently changed for the coming M3. P On 8/15/06, Mahbubur [EMAIL PROTECTED] wrote: Hello All, I am a newbie to the world of ServiceMix. I have downloaded the ServiceMix source from: apache-servicemix-3.0-M2-incubating and the maven-2.0.4 When I am trying to build with the following command: mvn -Dmaven.test.skip=true install I am getting the following messages. Would anyone let me know what I should (or should not) be doing? Thanks a lot in advance. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] ServiceMix [INFO] ServiceMix :: JBI [INFO] ServiceMix :: Services [INFO] ServiceMix :: Core [INFO] ServiceMix :: Components [INFO] ServiceMix :: Common [INFO] ServiceMix :: SOAP [INFO] ServiceMix :: Console [INFO] ServiceMix :: Tooling [INFO] ServiceMix :: Maven2 :: JBI Plugin [INFO] ServiceMix :: HTTP [INFO] ServiceMix :: BPE [INFO] ServiceMix :: JMS [INFO] ServiceMix :: JSR-181 Service Engine [INFO] ServiceMix :: WS-Notification Service Engine [INFO] ServiceMix :: Lightweight container Service Engine [INFO] ServiceMix :: SCA Service Engine [INFO] ServiceMix :: Web [INFO] ServiceMix :: EIP [INFO] ServiceMix :: ITests [INFO] ServiceMix :: BeanFlow [INFO] ServiceMix :: Maven2 :: Archetypes :: BindingComponent [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceEngine [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceUnit [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceAssembly [INFO] ServiceMix :: Samples [INFO] ServiceMix :: Samples :: WSDL first [INFO] ServiceMix :: Samples :: WSDL first :: JSR181 [INFO] ServiceMix :: Samples :: WSDL first :: HTTP [INFO] ServiceMix :: Samples :: WSDL first :: SA [INFO] Servicemix :: Assembly Downloading: http://servicemix.org/m2-repo/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-m2-repo (http://servicemix.org/m2-repo) Downloading: http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.tooling -DartifactId=jbi-maven-plugin \ -Dversion=1.0-M2-incubating -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.servicemix.tooling:jbi-maven-plugin:maven-plugin:1.0-M2-incubating from the specified remote repositories: central (http://repo1.maven.org/maven2), servicemix-m2-repo (http://servicemix.org/m2-repo), servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) org.apache.servicemix.tooling:jbi-maven-plugin:maven-plugin:1.0-M2-incubating from the specified remote repositories: central (http://repo1.maven.org/maven2), servicemix-m2-repo (http://servicemix.org/m2-repo), servicemix-distribution
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congratulation !On 8/16/06, Joe Bohn [EMAIL PROTECTED] wrote: Congrats Alan!Matt Hogstrom wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC.We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC-- Cheers,Guillaume Nodet
Re: Build problems with SerivceMix
Hi, I just tried doing it and gettig the same results. Following is the series of steps that I am following: 1. Download the apache-servicemix-3.0-M2-incubating-src.tar.gz from servicemix download site. 2. Unzip and untar it. 3. Go to the src directory of the apache-servicemix-3.0-M2-incubating directory. 4. Issue the following command from the command line: mvn -Dmaven.test.skip=true -Pstep1 install After that I am getting the previously posted set of outputs. Am I missing something in the process? Thanks. Mahbubur. Philip Dodds-2 wrote: Can you run mvn -Dmaven.test.skip=true -Pstep1 install from the root of the source tree , and then try mvn -Dmaven.test.skip=true install from the same location? Note sure why people are having problems with the build I refreshed yesterday without any issues? might be a problem with first builds :( P On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi Philip, I tried the instructions from the above site, but getting the same error. It could not download a plugin JAR. The error is the same as I have posted in my previous post. Is there some other issue involved in this. Some help will truly be appreciated. Thanks a lot in advance. Mahbubur Mahbubur wrote: Thanks a lot. I will try it. I truly appreciate the help. Mahbub. Philip Dodds-2 wrote: See the Building information on the website - http://www.servicemix.org/site/building.html Note that it recently changed for the coming M3. P On 8/15/06, Mahbubur [EMAIL PROTECTED] wrote: Hello All, I am a newbie to the world of ServiceMix. I have downloaded the ServiceMix source from: apache-servicemix-3.0-M2-incubating and the maven-2.0.4 When I am trying to build with the following command: mvn -Dmaven.test.skip=true install I am getting the following messages. Would anyone let me know what I should (or should not) be doing? Thanks a lot in advance. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] ServiceMix [INFO] ServiceMix :: JBI [INFO] ServiceMix :: Services [INFO] ServiceMix :: Core [INFO] ServiceMix :: Components [INFO] ServiceMix :: Common [INFO] ServiceMix :: SOAP [INFO] ServiceMix :: Console [INFO] ServiceMix :: Tooling [INFO] ServiceMix :: Maven2 :: JBI Plugin [INFO] ServiceMix :: HTTP [INFO] ServiceMix :: BPE [INFO] ServiceMix :: JMS [INFO] ServiceMix :: JSR-181 Service Engine [INFO] ServiceMix :: WS-Notification Service Engine [INFO] ServiceMix :: Lightweight container Service Engine [INFO] ServiceMix :: SCA Service Engine [INFO] ServiceMix :: Web [INFO] ServiceMix :: EIP [INFO] ServiceMix :: ITests [INFO] ServiceMix :: BeanFlow [INFO] ServiceMix :: Maven2 :: Archetypes :: BindingComponent [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceEngine [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceUnit [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceAssembly [INFO] ServiceMix :: Samples [INFO] ServiceMix :: Samples :: WSDL first [INFO] ServiceMix :: Samples :: WSDL first :: JSR181 [INFO] ServiceMix :: Samples :: WSDL first :: HTTP [INFO] ServiceMix :: Samples :: WSDL first :: SA [INFO] Servicemix :: Assembly Downloading: http://servicemix.org/m2-repo/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-m2-repo (http://servicemix.org/m2-repo) Downloading: http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.tooling -DartifactId=jbi-maven-plugin \ -Dversion=1.0-M2-incubating -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.servicemix.tooling:jbi-maven-plugin:maven-plugin:1.0-M2-incubating from the specified remote repositories: central (http://repo1.maven.org/maven2), servicemix-m2-repo
Re: Build problems with SerivceMix
Can you try building from the svn repository ? Notes on getting the version from SVN are available here - http://www.servicemix.org/site/source.html P On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi, I just tried doing it and gettig the same results. Following is the series of steps that I am following: 1. Download the apache-servicemix-3.0-M2-incubating-src.tar.gz from servicemix download site. 2. Unzip and untar it. 3. Go to the src directory of the apache-servicemix-3.0-M2-incubating directory. 4. Issue the following command from the command line: mvn -Dmaven.test.skip=true -Pstep1 install After that I am getting the previously posted set of outputs. Am I missing something in the process? Thanks. Mahbubur. Philip Dodds-2 wrote: Can you run mvn -Dmaven.test.skip=true -Pstep1 install from the root of the source tree , and then try mvn -Dmaven.test.skip=true install from the same location? Note sure why people are having problems with the build I refreshed yesterday without any issues? might be a problem with first builds :( P On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi Philip, I tried the instructions from the above site, but getting the same error. It could not download a plugin JAR. The error is the same as I have posted in my previous post. Is there some other issue involved in this. Some help will truly be appreciated. Thanks a lot in advance. Mahbubur Mahbubur wrote: Thanks a lot. I will try it. I truly appreciate the help. Mahbub. Philip Dodds-2 wrote: See the Building information on the website - http://www.servicemix.org/site/building.html Note that it recently changed for the coming M3. P On 8/15/06, Mahbubur [EMAIL PROTECTED] wrote: Hello All, I am a newbie to the world of ServiceMix. I have downloaded the ServiceMix source from: apache-servicemix-3.0-M2-incubating and the maven-2.0.4 When I am trying to build with the following command: mvn -Dmaven.test.skip=true install I am getting the following messages. Would anyone let me know what I should (or should not) be doing? Thanks a lot in advance. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] ServiceMix [INFO] ServiceMix :: JBI [INFO] ServiceMix :: Services [INFO] ServiceMix :: Core [INFO] ServiceMix :: Components [INFO] ServiceMix :: Common [INFO] ServiceMix :: SOAP [INFO] ServiceMix :: Console [INFO] ServiceMix :: Tooling [INFO] ServiceMix :: Maven2 :: JBI Plugin [INFO] ServiceMix :: HTTP [INFO] ServiceMix :: BPE [INFO] ServiceMix :: JMS [INFO] ServiceMix :: JSR-181 Service Engine [INFO] ServiceMix :: WS-Notification Service Engine [INFO] ServiceMix :: Lightweight container Service Engine [INFO] ServiceMix :: SCA Service Engine [INFO] ServiceMix :: Web [INFO] ServiceMix :: EIP [INFO] ServiceMix :: ITests [INFO] ServiceMix :: BeanFlow [INFO] ServiceMix :: Maven2 :: Archetypes :: BindingComponent [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceEngine [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceUnit [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceAssembly [INFO] ServiceMix :: Samples [INFO] ServiceMix :: Samples :: WSDL first [INFO] ServiceMix :: Samples :: WSDL first :: JSR181 [INFO] ServiceMix :: Samples :: WSDL first :: HTTP [INFO] ServiceMix :: Samples :: WSDL first :: SA [INFO] Servicemix :: Assembly Downloading: http://servicemix.org/m2-repo/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-m2-repo (http://servicemix.org/m2-repo) Downloading: http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.tooling -DartifactId=jbi-maven-plugin \ -Dversion=1.0-M2-incubating -Dpackaging=maven-plugin -Dfile=/path/to/file
Re: Build problems with SerivceMix
Could you try using the exact command written at http://servicemix.goopen.org/site/building.html mvn -Dmaven.test.skip=true -Dprofile=step1 install and not mvn -Dmaven.test.skip=true -Pstep1 install On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi, I just tried doing it and gettig the same results. Following is the series of steps that I am following: 1. Download the apache-servicemix-3.0-M2-incubating-src.tar.gz from servicemix download site. 2. Unzip and untar it. 3. Go to the src directory of the apache-servicemix-3.0-M2-incubating directory. 4. Issue the following command from the command line: mvn -Dmaven.test.skip=true -Pstep1 install After that I am getting the previously posted set of outputs. Am I missing something in the process? Thanks. Mahbubur. Philip Dodds-2 wrote: Can you run mvn -Dmaven.test.skip=true -Pstep1 install from the root of the source tree , and then try mvn -Dmaven.test.skip=true install from the same location? Note sure why people are having problems with the build I refreshed yesterday without any issues? might be a problem with first builds :( P On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi Philip, I tried the instructions from the above site, but getting the same error. It could not download a plugin JAR. The error is the same as I have posted in my previous post. Is there some other issue involved in this. Some help will truly be appreciated. Thanks a lot in advance. Mahbubur Mahbubur wrote: Thanks a lot. I will try it. I truly appreciate the help. Mahbub. Philip Dodds-2 wrote: See the Building information on the website - http://www.servicemix.org/site/building.html Note that it recently changed for the coming M3. P On 8/15/06, Mahbubur [EMAIL PROTECTED] wrote: Hello All, I am a newbie to the world of ServiceMix. I have downloaded the ServiceMix source from: apache-servicemix-3.0-M2-incubating and the maven-2.0.4 When I am trying to build with the following command: mvn -Dmaven.test.skip=true install I am getting the following messages. Would anyone let me know what I should (or should not) be doing? Thanks a lot in advance. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] ServiceMix [INFO] ServiceMix :: JBI [INFO] ServiceMix :: Services [INFO] ServiceMix :: Core [INFO] ServiceMix :: Components [INFO] ServiceMix :: Common [INFO] ServiceMix :: SOAP [INFO] ServiceMix :: Console [INFO] ServiceMix :: Tooling [INFO] ServiceMix :: Maven2 :: JBI Plugin [INFO] ServiceMix :: HTTP [INFO] ServiceMix :: BPE [INFO] ServiceMix :: JMS [INFO] ServiceMix :: JSR-181 Service Engine [INFO] ServiceMix :: WS-Notification Service Engine [INFO] ServiceMix :: Lightweight container Service Engine [INFO] ServiceMix :: SCA Service Engine [INFO] ServiceMix :: Web [INFO] ServiceMix :: EIP [INFO] ServiceMix :: ITests [INFO] ServiceMix :: BeanFlow [INFO] ServiceMix :: Maven2 :: Archetypes :: BindingComponent [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceEngine [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceUnit [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceAssembly [INFO] ServiceMix :: Samples [INFO] ServiceMix :: Samples :: WSDL first [INFO] ServiceMix :: Samples :: WSDL first :: JSR181 [INFO] ServiceMix :: Samples :: WSDL first :: HTTP [INFO] ServiceMix :: Samples :: WSDL first :: SA [INFO] Servicemix :: Assembly Downloading: http://servicemix.org/m2-repo/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-m2-repo (http://servicemix.org/m2-repo) Downloading: http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.tooling -DartifactId=jbi-maven-plugin \ -Dversion=1.0-M2-incubating
Re: Build problems with SerivceMix
I think they are building the M2 incubating version, which was before the profiles came in :) P On 8/16/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Could you try using the exact command written at http://servicemix.goopen.org/site/building.html mvn -Dmaven.test.skip=true -Dprofile=step1 install and not mvn -Dmaven.test.skip=true -Pstep1 install On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi, I just tried doing it and gettig the same results. Following is the series of steps that I am following: 1. Download the apache-servicemix-3.0-M2-incubating-src.tar.gz from servicemix download site. 2. Unzip and untar it. 3. Go to the src directory of the apache-servicemix-3.0-M2-incubating directory. 4. Issue the following command from the command line: mvn -Dmaven.test.skip=true -Pstep1 install After that I am getting the previously posted set of outputs. Am I missing something in the process? Thanks. Mahbubur. Philip Dodds-2 wrote: Can you run mvn -Dmaven.test.skip=true -Pstep1 install from the root of the source tree , and then try mvn -Dmaven.test.skip=true install from the same location? Note sure why people are having problems with the build I refreshed yesterday without any issues? might be a problem with first builds :( P On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi Philip, I tried the instructions from the above site, but getting the same error. It could not download a plugin JAR. The error is the same as I have posted in my previous post. Is there some other issue involved in this. Some help will truly be appreciated. Thanks a lot in advance. Mahbubur Mahbubur wrote: Thanks a lot. I will try it. I truly appreciate the help. Mahbub. Philip Dodds-2 wrote: See the Building information on the website - http://www.servicemix.org/site/building.html Note that it recently changed for the coming M3. P On 8/15/06, Mahbubur [EMAIL PROTECTED] wrote: Hello All, I am a newbie to the world of ServiceMix. I have downloaded the ServiceMix source from: apache-servicemix-3.0-M2-incubating and the maven-2.0.4 When I am trying to build with the following command: mvn -Dmaven.test.skip=true install I am getting the following messages. Would anyone let me know what I should (or should not) be doing? Thanks a lot in advance. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] ServiceMix [INFO] ServiceMix :: JBI [INFO] ServiceMix :: Services [INFO] ServiceMix :: Core [INFO] ServiceMix :: Components [INFO] ServiceMix :: Common [INFO] ServiceMix :: SOAP [INFO] ServiceMix :: Console [INFO] ServiceMix :: Tooling [INFO] ServiceMix :: Maven2 :: JBI Plugin [INFO] ServiceMix :: HTTP [INFO] ServiceMix :: BPE [INFO] ServiceMix :: JMS [INFO] ServiceMix :: JSR-181 Service Engine [INFO] ServiceMix :: WS-Notification Service Engine [INFO] ServiceMix :: Lightweight container Service Engine [INFO] ServiceMix :: SCA Service Engine [INFO] ServiceMix :: Web [INFO] ServiceMix :: EIP [INFO] ServiceMix :: ITests [INFO] ServiceMix :: BeanFlow [INFO] ServiceMix :: Maven2 :: Archetypes :: BindingComponent [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceEngine [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceUnit [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceAssembly [INFO] ServiceMix :: Samples [INFO] ServiceMix :: Samples :: WSDL first [INFO] ServiceMix :: Samples :: WSDL first :: JSR181 [INFO] ServiceMix :: Samples :: WSDL first :: HTTP [INFO] ServiceMix :: Samples :: WSDL first :: SA [INFO] Servicemix :: Assembly Downloading: http://servicemix.org/m2-repo/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-m2-repo (http://servicemix.org/m2-repo) Downloading: http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable
Re: Organization and versioning of specs; a new proposal
I have always been in favor of dropping any uber-jars. They cause
more problems then they are worth.
As for RTC... I am not so sure that this applies really. Its not
going to surprise anyone, its not adding any new code... just fixing
up the poms and moving a few bits around in svn.
But, I can jump though the RTC hoop if that is what the PMC wants...
I think its a waste of time... mostly mine.
--jason
On Aug 16, 2006, at 7:13 AM, Kevan Miller wrote:
On Aug 16, 2006, at 3:56 AM, Jason Dillon wrote:
What is the status on 1.1.1 wrt this change? Can I go ahead and
make these changes?
My reading of Matt's note (which I agree with) is that you should
wait until 1.1.1 has been shipped (unless 1.1.1 runs into an
extended delay in releasing due to administrative matters).
I think this change should follow the RTC process. This is not a
bug fix, not a doc change, etc. It's updating svn and changing the
way we deliver specs -- my read is that it falls under RTC.
You don't mention geronimo-j2ee_1.4_spec (the uber-jar). It's
currently versioned using the top-level pom version. I assume you
plan on adding a geronimoSpecsJ2eeVersion?
Your process for updating the jms spec would be:
cd specs/geronimo-spec-jms
mvn release
cd ../geronimo-spec-j2ee
mvn release
I'm not so sure that this is any better than we have now... I see
two options:
1) drop the uber-jar
2) release all specs simultaneosly (even if they haven't changed)
and all have the same version...
--kevan
--jason
On Aug 12, 2006, at 12:16 AM, Matt Hogstrom wrote:
Jason,
I'm +1 on the change. In order to release 1.1.1 we need to
release an updated version of the J2EE_JAAC specs. I am waiting
for feedback from Geir on some licensing issues as well as a TCK
run that Kevan is doing. That said I'd prefer to wait until the
we cut the 1.1.1 release. If it looks like its going to be
delayed due to the licensing concerns then we should do this
straight away next week.
Since this isn't a code change I agree with Jason's comments on
no review required. Lazy consensus is appropriate here.
Jason Dillon wrote:
A while ago there was talks about independently versioning
specs, and Alan started a reorg branch which gives each spec
module its own trunk+branches+tags...
I have been thinking about this for a while, and with the recent
desire to split off more modules from geronimo/trunk I've been
pondering it even more. What I have come to believe is that
spitting up spec modules into their own trunk+branches+tags is
probably not the best direction for us to head in.
I believe that all of our specs can, and should, share one
trunk... and still have each module specify its own version.
This is very similar to how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently. The
top-level pom has a version too, which is independent and is
only changed when there is a major configuration change in that
pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check
out and building when you just want all of the specs. If each
spec was in its own trunk, you would need to svn co each one,
then mvn install in each tree, which is a pain.
We also almost never branch specs, they just keep chugging
along, only really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
And if needed:
specs/branches/artifactId/name
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/
trunk/ specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which
we can set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$
{pom.artifactId}
When released, the plugin will svn cp just the module's
directory into a directory under tags, so it will be easy to see
what the released versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own
trunk, and really I think that if we did then it would just make
it more difficult for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change,
which isn't that major, is that the properties which live in the
root pom that control the versions need to be removed... or
rather moved back to the version element of the respective pom.
Comments?
--jason
Re: Build problems with SerivceMix
Hi, Yes I tried that also, but I am getting the same messages. Somebody in a different forum thread mentioned that Maven could not download dependencies because of the proxy settings. Could that be an issue here? Mahbubur. gnodet wrote: Could you try using the exact command written at http://servicemix.goopen.org/site/building.html mvn -Dmaven.test.skip=true -Dprofile=step1 install and not mvn -Dmaven.test.skip=true -Pstep1 install On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi, I just tried doing it and gettig the same results. Following is the series of steps that I am following: 1. Download the apache-servicemix-3.0-M2-incubating-src.tar.gz from servicemix download site. 2. Unzip and untar it. 3. Go to the src directory of the apache-servicemix-3.0-M2-incubating directory. 4. Issue the following command from the command line: mvn -Dmaven.test.skip=true -Pstep1 install After that I am getting the previously posted set of outputs. Am I missing something in the process? Thanks. Mahbubur. Philip Dodds-2 wrote: Can you run mvn -Dmaven.test.skip=true -Pstep1 install from the root of the source tree , and then try mvn -Dmaven.test.skip=true install from the same location? Note sure why people are having problems with the build I refreshed yesterday without any issues? might be a problem with first builds :( P On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi Philip, I tried the instructions from the above site, but getting the same error. It could not download a plugin JAR. The error is the same as I have posted in my previous post. Is there some other issue involved in this. Some help will truly be appreciated. Thanks a lot in advance. Mahbubur Mahbubur wrote: Thanks a lot. I will try it. I truly appreciate the help. Mahbub. Philip Dodds-2 wrote: See the Building information on the website - http://www.servicemix.org/site/building.html Note that it recently changed for the coming M3. P On 8/15/06, Mahbubur [EMAIL PROTECTED] wrote: Hello All, I am a newbie to the world of ServiceMix. I have downloaded the ServiceMix source from: apache-servicemix-3.0-M2-incubating and the maven-2.0.4 When I am trying to build with the following command: mvn -Dmaven.test.skip=true install I am getting the following messages. Would anyone let me know what I should (or should not) be doing? Thanks a lot in advance. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] ServiceMix [INFO] ServiceMix :: JBI [INFO] ServiceMix :: Services [INFO] ServiceMix :: Core [INFO] ServiceMix :: Components [INFO] ServiceMix :: Common [INFO] ServiceMix :: SOAP [INFO] ServiceMix :: Console [INFO] ServiceMix :: Tooling [INFO] ServiceMix :: Maven2 :: JBI Plugin [INFO] ServiceMix :: HTTP [INFO] ServiceMix :: BPE [INFO] ServiceMix :: JMS [INFO] ServiceMix :: JSR-181 Service Engine [INFO] ServiceMix :: WS-Notification Service Engine [INFO] ServiceMix :: Lightweight container Service Engine [INFO] ServiceMix :: SCA Service Engine [INFO] ServiceMix :: Web [INFO] ServiceMix :: EIP [INFO] ServiceMix :: ITests [INFO] ServiceMix :: BeanFlow [INFO] ServiceMix :: Maven2 :: Archetypes :: BindingComponent [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceEngine [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceUnit [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceAssembly [INFO] ServiceMix :: Samples [INFO] ServiceMix :: Samples :: WSDL first [INFO] ServiceMix :: Samples :: WSDL first :: JSR181 [INFO] ServiceMix :: Samples :: WSDL first :: HTTP [INFO] ServiceMix :: Samples :: WSDL first :: SA [INFO] Servicemix :: Assembly Downloading: http://servicemix.org/m2-repo/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-m2-repo (http://servicemix.org/m2-repo) Downloading: http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO]
[jira] Commented: (GERONIMO-2313) Subject not propagated correctly between web app and ejb
[ http://issues.apache.org/jira/browse/GERONIMO-2313?page=comments#action_12428499 ] Donald Woods commented on GERONIMO-2313: I see the update in the openejb 2.1 branch (aka. 2.1.2-snapshot), but not in the 2.1.1 branch yet Subject not propagated correctly between web app and ejb Key: GERONIMO-2313 URL: http://issues.apache.org/jira/browse/GERONIMO-2313 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1, 1.1.1, 1.1.x Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 1.1.2, 1.1.1 Attachments: ejbrefsec-ear-1.0-SNAPSHOT.ear, ejbrefsec.src.jar, GERONIMO-2313-openejb.diff, GERONIMO-2313.diff With a web app with security, that calls an ejb, isCallerInRole in the ejb always returns false. this is caused by the web app not setting nextCaller and the ejb interceptors shifting nextCaller to currentCaller, so when the isCallerInRole is tested there is a null subject so it returns false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Build problems with SerivceMix
You will need your proxy configured in Maven if you have one between you and the internet. Though I don't believe you would end up with a problem getting that plugin on step1 if you didn't? So whats the error when you build step1 from the source tree? Can you send the output of the first mvn command against the fresh check out of the trunk? P On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi, Yes I tried that also, but I am getting the same messages. Somebody in a different forum thread mentioned that Maven could not download dependencies because of the proxy settings. Could that be an issue here? Mahbubur. gnodet wrote: Could you try using the exact command written at http://servicemix.goopen.org/site/building.html mvn -Dmaven.test.skip=true -Dprofile=step1 install and not mvn -Dmaven.test.skip=true -Pstep1 install On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi, I just tried doing it and gettig the same results. Following is the series of steps that I am following: 1. Download the apache-servicemix-3.0-M2-incubating-src.tar.gz from servicemix download site. 2. Unzip and untar it. 3. Go to the src directory of the apache-servicemix-3.0-M2-incubating directory. 4. Issue the following command from the command line: mvn -Dmaven.test.skip=true -Pstep1 install After that I am getting the previously posted set of outputs. Am I missing something in the process? Thanks. Mahbubur. Philip Dodds-2 wrote: Can you run mvn -Dmaven.test.skip=true -Pstep1 install from the root of the source tree , and then try mvn -Dmaven.test.skip=true install from the same location? Note sure why people are having problems with the build I refreshed yesterday without any issues? might be a problem with first builds :( P On 8/16/06, Mahbubur [EMAIL PROTECTED] wrote: Hi Philip, I tried the instructions from the above site, but getting the same error. It could not download a plugin JAR. The error is the same as I have posted in my previous post. Is there some other issue involved in this. Some help will truly be appreciated. Thanks a lot in advance. Mahbubur Mahbubur wrote: Thanks a lot. I will try it. I truly appreciate the help. Mahbub. Philip Dodds-2 wrote: See the Building information on the website - http://www.servicemix.org/site/building.html Note that it recently changed for the coming M3. P On 8/15/06, Mahbubur [EMAIL PROTECTED] wrote: Hello All, I am a newbie to the world of ServiceMix. I have downloaded the ServiceMix source from: apache-servicemix-3.0-M2-incubating and the maven-2.0.4 When I am trying to build with the following command: mvn -Dmaven.test.skip=true install I am getting the following messages. Would anyone let me know what I should (or should not) be doing? Thanks a lot in advance. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] ServiceMix [INFO] ServiceMix :: JBI [INFO] ServiceMix :: Services [INFO] ServiceMix :: Core [INFO] ServiceMix :: Components [INFO] ServiceMix :: Common [INFO] ServiceMix :: SOAP [INFO] ServiceMix :: Console [INFO] ServiceMix :: Tooling [INFO] ServiceMix :: Maven2 :: JBI Plugin [INFO] ServiceMix :: HTTP [INFO] ServiceMix :: BPE [INFO] ServiceMix :: JMS [INFO] ServiceMix :: JSR-181 Service Engine [INFO] ServiceMix :: WS-Notification Service Engine [INFO] ServiceMix :: Lightweight container Service Engine [INFO] ServiceMix :: SCA Service Engine [INFO] ServiceMix :: Web [INFO] ServiceMix :: EIP [INFO] ServiceMix :: ITests [INFO] ServiceMix :: BeanFlow [INFO] ServiceMix :: Maven2 :: Archetypes :: BindingComponent [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceEngine [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceUnit [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceAssembly [INFO] ServiceMix :: Samples [INFO] ServiceMix :: Samples :: WSDL first [INFO] ServiceMix :: Samples :: WSDL first :: JSR181 [INFO] ServiceMix :: Samples :: WSDL first :: HTTP [INFO] ServiceMix :: Samples :: WSDL first :: SA [INFO] Servicemix :: Assembly Downloading: http://servicemix.org/m2-repo/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-m2-repo (http://servicemix.org/m2-repo) Downloading: http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar [WARNING] Unable to get resource from repository servicemix-distribution (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) Downloading:
[jira] Created: (GERONIMO-2329) Remote-deploy failures between Windows and Linux machines
Remote-deploy failures between Windows and Linux machines - Key: GERONIMO-2329 URL: http://issues.apache.org/jira/browse/GERONIMO-2329 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 1.1, 1.0, 1.1.1 Environment: Geronimo 1.1.1 using Tomcat with IBM 1.4.2 SR5 or 1.5.0 SR2 SDK between Win2003 server and SLES9 Reporter: Donald Woods Assigned To: Donald Woods Fix For: 1.1.1, 1.2 The remote-deployer is not returning fully qualified hostnames. This can be easily observed when starting the server with --long and looking as the web URLs being displayed at startup. Simple fix, is to switch the following in the modules/tomcat//ConnectorGBean.java and HttpsConnectorGBean.java from host = address.getHostName(); to host = address.getCanonicalHostName(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-2313) Subject not propagated correctly between web app and ejb
It came through the [EMAIL PROTECTED] list for me... did you get rev 2856? thanks david jencks On Aug 16, 2006, at 1:46 PM, Donald Woods (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2313? page=comments#action_12428499 ] Donald Woods commented on GERONIMO-2313: I see the update in the openejb 2.1 branch (aka. 2.1.2-snapshot), but not in the 2.1.1 branch yet Subject not propagated correctly between web app and ejb Key: GERONIMO-2313 URL: http://issues.apache.org/jira/browse/ GERONIMO-2313 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1, 1.1.1, 1.1.x Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 1.1.2, 1.1.1 Attachments: ejbrefsec-ear-1.0-SNAPSHOT.ear, ejbrefsec.src.jar, GERONIMO-2313-openejb.diff, GERONIMO-2313.diff With a web app with security, that calls an ejb, isCallerInRole in the ejb always returns false. this is caused by the web app not setting nextCaller and the ejb interceptors shifting nextCaller to currentCaller, so when the isCallerInRole is tested there is a null subject so it returns false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/ Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira
[jira] Updated: (GERONIMO-2329) Remote-deploy failures between Windows and Linux machines
[ http://issues.apache.org/jira/browse/GERONIMO-2329?page=all ] Donald Woods updated GERONIMO-2329: --- Description: The remote-deployer is not returning fully qualified hostnames. This can be easily observed when starting the server with --long and looking as the web URLs being displayed at startup. Simple fix, is to switch the following in the modules/tomcat//ConnectorGBean.java and modules/jetty//JettyConnector.java from host = address.getHostName(); to host = address.getCanonicalHostName(); was: The remote-deployer is not returning fully qualified hostnames. This can be easily observed when starting the server with --long and looking as the web URLs being displayed at startup. Simple fix, is to switch the following in the modules/tomcat//ConnectorGBean.java and HttpsConnectorGBean.java from host = address.getHostName(); to host = address.getCanonicalHostName(); Remote-deploy failures between Windows and Linux machines - Key: GERONIMO-2329 URL: http://issues.apache.org/jira/browse/GERONIMO-2329 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.0, 1.1, 1.1.1 Environment: Geronimo 1.1.1 using Tomcat with IBM 1.4.2 SR5 or 1.5.0 SR2 SDK between Win2003 server and SLES9 Reporter: Donald Woods Assigned To: Donald Woods Fix For: 1.2, 1.1.1 The remote-deployer is not returning fully qualified hostnames. This can be easily observed when starting the server with --long and looking as the web URLs being displayed at startup. Simple fix, is to switch the following in the modules/tomcat//ConnectorGBean.java and modules/jetty//JettyConnector.java from host = address.getHostName(); to host = address.getCanonicalHostName(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
Congratulations! -dain On Aug 16, 2006, at 6:02 AM, Matt Hogstrom wrote: All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. The Apache Geronimo PMC
[jira] Updated: (GERONIMO-2329) Remote-deploy failures between Windows and Linux machines
[ http://issues.apache.org/jira/browse/GERONIMO-2329?page=all ] Donald Woods updated GERONIMO-2329: --- Attachment: G2329-1.1.1.patch Attaching patch based on Geronimo 1.1.1 branch directory. Remote-deploy failures between Windows and Linux machines - Key: GERONIMO-2329 URL: http://issues.apache.org/jira/browse/GERONIMO-2329 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.0, 1.1, 1.1.1 Environment: Geronimo 1.1.1 using Tomcat with IBM 1.4.2 SR5 or 1.5.0 SR2 SDK between Win2003 server and SLES9 Reporter: Donald Woods Assigned To: Donald Woods Fix For: 1.2, 1.1.1 Attachments: G2329-1.1.1.patch The remote-deployer is not returning fully qualified hostnames. This can be easily observed when starting the server with --long and looking as the web URLs being displayed at startup. Simple fix, is to switch the following in the modules/tomcat//ConnectorGBean.java and modules/jetty//JettyConnector.java from host = address.getHostName(); to host = address.getCanonicalHostName(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Organization and versioning of specs; a new proposal
Does not really look like anything needs to be moved. The only things (other than svn ci) would be svn mkdir for each spec in tags, since mvn release will not make that tree... as in: snip svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-activation svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-commonj svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-corba svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-corba-2.3 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-corba-3.0 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-ejb svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-connector svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-deployment svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-jacc svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-management svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-javamail-1.3.1 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-javamail-1.4 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jaxr svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jaxrpc svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jms svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jsp svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jta svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-qname svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-saaj svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-servlet-2.4 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-servlet-2.5 /snip I think everything else is just pom updates. --jason On Aug 16, 2006, at 1:50 PM, David Jencks wrote: On Aug 16, 2006, at 1:40 PM, Jason Dillon wrote: I have always been in favor of dropping any uber-jars. They cause more problems then they are worth. As for RTC... I am not so sure that this applies really. Its not going to surprise anyone, its not adding any new code... just fixing up the poms and moving a few bits around in svn. But, I can jump though the RTC hoop if that is what the PMC wants... I think its a waste of time... mostly mine. This is obviously not something that a patch will work for in terms of comprehension and probably function. If we need RTC I think that supplying the svn mv commands is what we'd vote on. I think we have voted on the desired outcome and that is sufficient, but I won't push the issue. Jason, how hard would it be to come up with the svn commands you'd use, and what else is there to do? thanks david jencks --jason On Aug 16, 2006, at 7:13 AM, Kevan Miller wrote: On Aug 16, 2006, at 3:56 AM, Jason Dillon wrote: What is the status on 1.1.1 wrt this change? Can I go ahead and make these changes? My reading of Matt's note (which I agree with) is that you should wait until 1.1.1 has been shipped (unless 1.1.1 runs into an extended delay in releasing due to administrative matters). I think this change should follow the RTC process. This is not a bug fix, not a doc change, etc. It's updating svn and changing the way we deliver specs -- my read is that it falls under RTC. You don't mention geronimo-j2ee_1.4_spec (the uber-jar). It's currently versioned using the top-level pom version. I assume you plan on adding a geronimoSpecsJ2eeVersion? Your process for updating the jms spec would be: cd specs/geronimo-spec-jms mvn release cd ../geronimo-spec-j2ee mvn release I'm not so sure that this is any better than we have now... I see two options: 1) drop the uber-jar 2) release all specs simultaneosly (even if they haven't changed) and all have the same version... --kevan --jason On Aug 12, 2006, at 12:16 AM, Matt Hogstrom wrote: Jason, I'm +1 on the change. In order to release 1.1.1 we need to release an updated version of the J2EE_JAAC specs. I am waiting for feedback from Geir on some licensing issues as well as a TCK run that Kevan is doing. That said I'd prefer to wait until the we cut the 1.1.1 release. If it looks like its going to be delayed due to the licensing concerns then we should do this straight away next week. Since this isn't a code change I agree with Jason's comments on no review required. Lazy consensus is appropriate here. Jason Dillon wrote: A while ago there was talks about independently versioning specs, and Alan started a reorg branch
[jira] Assigned: (GERONIMO-2329) Remote-deploy failures between Windows and Linux machines
[ http://issues.apache.org/jira/browse/GERONIMO-2329?page=all ] Donald Woods reassigned GERONIMO-2329: -- Assignee: (was: Donald Woods) Unassigning so a committer can grab it. Remote-deploy failures between Windows and Linux machines - Key: GERONIMO-2329 URL: http://issues.apache.org/jira/browse/GERONIMO-2329 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.0, 1.1, 1.1.1 Environment: Geronimo 1.1.1 using Tomcat with IBM 1.4.2 SR5 or 1.5.0 SR2 SDK between Win2003 server and SLES9 Reporter: Donald Woods Fix For: 1.2, 1.1.1 Attachments: G2329-1.1.1.patch The remote-deployer is not returning fully qualified hostnames. This can be easily observed when starting the server with --long and looking as the web URLs being displayed at startup. Simple fix, is to switch the following in the modules/tomcat//ConnectorGBean.java and modules/jetty//JettyConnector.java from host = address.getHostName(); to host = address.getCanonicalHostName(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
activemq architecture with jboss
Hi all, Execuse me but i am new in JMS and ActiveMQ... I'd like to create an architecture with a client that send messages to 2 brokers (in cluster) and a MDB that consume the messages. Must I use JBOSS for use MDB? In this case, must i have two instance of Jboss in order to avoid the single point of failure? That is a good road??? Help me...it is very important. Regards Max -- View this message in context: http://www.nabble.com/activemq-architecture-with-jboss-tf2118066.html#a5841372 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: [WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
Nice going, Guillaume! -David On Aug 16, 2006, at 6:02 AM, Matt Hogstrom wrote: All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. The Apache Geronimo PMC
Re: JPA Plugin Status
On Aug 16, 2006, at 8:01 AM, Matt Hogstrom wrote: I'm releasing out of branches/1_1_1. Is your stuff in trunk ? No it's in a branch, so we'd have to vote it into trunk. If you were thinking it was in branches/1.1.1, don't worry about it. Probably best to let Jason get his spec layout change in first. -David David Blevins wrote: Grrr, I'm missing mail again -- pulled it from the archives. Thanks, Dain, for pointing out there was a message for me. On 8/15/06, Matt Hogstrom [EMAIL PROTECTED] wrote: David, I am releasing the specs as a 1.1.1 release due to some changes in jacc. Do you want to include the changes to JPA there? That would be great. In fact all the jee5_exp specs could be released. The related specifications went final so we should be good to go. -David On Aug 15, 2006, at 4:17 AM, David Blevins wrote: I got OpenJPA to run with my JPA code. So we're looking real good. On Aug 13, 2006, at 8:24 PM, Aaron Mulder wrote: So far, it's just got a TopLink provider, but if people want to copy that to create providers for Cayenne or OpenJPA or whatever, that would be great. It basically just needs to have a customized name and ClassPath, though I'm assuming any provider we integrate with will be compatible with the Geronimo JPA spec JAR (currently org.apache.geronimo.specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/jar) OpenJPA and the Geronimo JPA spec jar weren't happy. Our JPA jar had some bad signatures and was missing a few exception classes. I fixed those and managed to get OpenJPA to compile and run with our JPA jar rather than the CDDL version they use. If you try to build and run this, you'll be held up by a couple things: For me its: - Still missing the some JNDI stuff Dain is working on (mentioned earlier in the thread). - Need the plugin goop But when that is there, this should run for ejbs or servlets in 1.1.1 and maybe 1.1 (should work). My goal is to have a release of this plugin with sufficient user documentation when G 1.1.1 is released. It would be great to have some open source JPA providers for that release too. I also started talking to David B about the JPA work being done in OpenEJB, and I think we're agreed that we probably don't need two such plugins for G 1.1.x, so hopefully we can work toward a unification as we move forward. I'm sure we can figure something out. I'll give it some more thought tomorrow, time for bed now -David
Re: [WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
On 8/16/06, Matt Hogstrom [EMAIL PROTECTED] wrote: All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. I remember when you earned the karma for XBean and now it's a Geronimo PMC ticket. Good job Guillaume! I'll keep an eye on you to figure out how you manage your time and are doing your fabolous contributions. Congrats! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
On 8/17/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 8/16/06, Matt Hogstrom [EMAIL PROTECTED] wrote: All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. I remember when you earned the karma for XBean and now it's a Geronimo PMC ticket. Good job Guillaume! I'll keep an eye on you to figure out how you manage your time and are doing your fabolous contributions. I never sleep. That' s my secret ;) Congrats! Jacek -- Jacek Laskowski http://www.laskowski.net.pl -- Cheers, Guillaume Nodet
Re: Organization and versioning of specs; a new proposal
I guess I'd still prefer we do artifactId-version for the tag names as maven does. There's also a small catch in that the directories we've been using are not the artifactIds. -David On Aug 16, 2006, at 2:06 PM, Jason Dillon wrote: Does not really look like anything needs to be moved. The only things (other than svn ci) would be svn mkdir for each spec in tags, since mvn release will not make that tree... as in: snip svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-activation svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-commonj svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-corba svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-corba-2.3 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-corba-3.0 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-connector svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-deployment svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-jacc svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-management svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-javamail-1.3.1 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-javamail-1.4 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jaxr svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jaxrpc svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jms svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jsp svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jta svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-qname svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-saaj svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-servlet-2.4 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-servlet-2.5 /snip I think everything else is just pom updates. --jason On Aug 16, 2006, at 1:50 PM, David Jencks wrote: On Aug 16, 2006, at 1:40 PM, Jason Dillon wrote: I have always been in favor of dropping any uber-jars. They cause more problems then they are worth. As for RTC... I am not so sure that this applies really. Its not going to surprise anyone, its not adding any new code... just fixing up the poms and moving a few bits around in svn. But, I can jump though the RTC hoop if that is what the PMC wants... I think its a waste of time... mostly mine. This is obviously not something that a patch will work for in terms of comprehension and probably function. If we need RTC I think that supplying the svn mv commands is what we'd vote on. I think we have voted on the desired outcome and that is sufficient, but I won't push the issue. Jason, how hard would it be to come up with the svn commands you'd use, and what else is there to do? thanks david jencks --jason On Aug 16, 2006, at 7:13 AM, Kevan Miller wrote: On Aug 16, 2006, at 3:56 AM, Jason Dillon wrote: What is the status on 1.1.1 wrt this change? Can I go ahead and make these changes? My reading of Matt's note (which I agree with) is that you should wait until 1.1.1 has been shipped (unless 1.1.1 runs into an extended delay in releasing due to administrative matters). I think this change should follow the RTC process. This is not a bug fix, not a doc change, etc. It's updating svn and changing the way we deliver specs -- my read is that it falls under RTC. You don't mention geronimo-j2ee_1.4_spec (the uber-jar). It's currently versioned using the top-level pom version. I assume you plan on adding a geronimoSpecsJ2eeVersion? Your process for updating the jms spec would be: cd specs/geronimo-spec-jms mvn release cd ../geronimo-spec-j2ee mvn release I'm not so sure that this is any better than we have now... I see two options: 1) drop the uber-jar 2) release all specs simultaneosly (even if they haven't changed) and all have the same version... --kevan --jason On Aug 12, 2006, at 12:16 AM, Matt Hogstrom wrote: Jason, I'm +1 on the change. In order to release 1.1.1 we need to release an updated version of the J2EE_JAAC specs. I am waiting for feedback from Geir on some licensing issues as well as a TCK run that Kevan is doing. That said I'd prefer to wait until the we cut the 1.1.1 release. If it looks like its going to be delayed due to the licensing concerns then we should do this straight away next week. Since this isn't a code change I agree with Jason's comments on no review required.
Re: Organization and versioning of specs; a new proposal
On Aug 16, 2006, at 3:21 PM, David Blevins wrote: I guess I'd still prefer we do artifactId-version for the tag names as maven does. I'm planning on putting artifactId-version under artifactId/ but m2 handles this, all it needs it the root to exist. There's also a small catch in that the directories we've been using are not the artifactIds. I don't understand... :-\ --jason -David On Aug 16, 2006, at 2:06 PM, Jason Dillon wrote: Does not really look like anything needs to be moved. The only things (other than svn ci) would be svn mkdir for each spec in tags, since mvn release will not make that tree... as in: snip svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-activation svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-commonj svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-corba svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-corba-2.3 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-corba-3.0 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-connector svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-deployment svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-jacc svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-management svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-javamail-1.3.1 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-javamail-1.4 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jaxr svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jaxrpc svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jms svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jsp svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jta svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-qname svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-saaj svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-servlet-2.4 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-servlet-2.5 /snip I think everything else is just pom updates. --jason On Aug 16, 2006, at 1:50 PM, David Jencks wrote: On Aug 16, 2006, at 1:40 PM, Jason Dillon wrote: I have always been in favor of dropping any uber-jars. They cause more problems then they are worth. As for RTC... I am not so sure that this applies really. Its not going to surprise anyone, its not adding any new code... just fixing up the poms and moving a few bits around in svn. But, I can jump though the RTC hoop if that is what the PMC wants... I think its a waste of time... mostly mine. This is obviously not something that a patch will work for in terms of comprehension and probably function. If we need RTC I think that supplying the svn mv commands is what we'd vote on. I think we have voted on the desired outcome and that is sufficient, but I won't push the issue. Jason, how hard would it be to come up with the svn commands you'd use, and what else is there to do? thanks david jencks --jason On Aug 16, 2006, at 7:13 AM, Kevan Miller wrote: On Aug 16, 2006, at 3:56 AM, Jason Dillon wrote: What is the status on 1.1.1 wrt this change? Can I go ahead and make these changes? My reading of Matt's note (which I agree with) is that you should wait until 1.1.1 has been shipped (unless 1.1.1 runs into an extended delay in releasing due to administrative matters). I think this change should follow the RTC process. This is not a bug fix, not a doc change, etc. It's updating svn and changing the way we deliver specs -- my read is that it falls under RTC. You don't mention geronimo-j2ee_1.4_spec (the uber-jar). It's currently versioned using the top-level pom version. I assume you plan on adding a geronimoSpecsJ2eeVersion? Your process for updating the jms spec would be: cd specs/geronimo-spec-jms mvn release cd ../geronimo-spec-j2ee mvn release I'm not so sure that this is any better than we have now... I see two options: 1) drop the uber-jar 2) release all specs simultaneosly (even if they haven't changed) and all have the same version... --kevan --jason On Aug 12, 2006, at 12:16 AM, Matt Hogstrom wrote: Jason, I'm +1 on the change. In order to release 1.1.1 we need to release an updated version of the J2EE_JAAC specs. I am waiting for feedback from Geir on some licensing issues as well as a TCK run that Kevan is doing. That said I'd prefer to wait until the we cut the 1.1.1
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428525 ] David Jencks commented on GERONIMO-2324: To clarify my earlier points, in order - It is certainly possible to get support for exploded jars by adding more entries to the classes attribute. If each jars were to be all by itself in a directory it would be possible to add an entry to libs for each jar. I think that the runtime refresh characteristics of both solutions would be the same. I'm not convinced dragging xml into this class is worth it for the minimal gains in functionality, namely not pulling in all the jars in a directory in which you only have one jar you want. - IMO the shared lib is a bad idea that is included only for those who are not willing to explicitly specify their dependencies. Adding extra-fancy features to it doesn't make it a better idea. I think we should be encouraging people to use the geronimo/maven repo. A corresponding feature for the repo would be some metadata in the repo that says, actually the artifact is over here, unpacked I'd rather see that feature than this one. - I think writing out the externals file will fail in a lot of scenarios. - tests are still good In addition: - I think that exactly the same effect can be obtained with no code change by putting a jar in shared/lib with a manifest classpath that points to the locations of interest - I would also much rather see a solution that does not require restarting the shared lib config in order to pick up changes. (I'm not actually sure about the behavior of shared lib -- maybe someone who knows can clarify) Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2103) Console config declares dependency on Jetty/Tomcat JAR instead of Jetty/Tomcat CAR
[ http://issues.apache.org/jira/browse/GERONIMO-2103?page=comments#action_12428532 ] David Jencks commented on GERONIMO-2103: I don't think either dependency is needed. I commented them out in trunk in the fix for GERONIMO-2313 and haven't seen any bad effects yet Console config declares dependency on Jetty/Tomcat JAR instead of Jetty/Tomcat CAR -- Key: GERONIMO-2103 URL: http://issues.apache.org/jira/browse/GERONIMO-2103 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem, console Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428534 ] Sachin Patel commented on GERONIMO-2324: From talking to Joe, modifying the config to add additional entries requires a server restart, modifying the contents of the sharedLib folder requires only a config restart. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Colossus Notes
I mentioned a few weeks ago that I would post my notes about the stuff I'm working on in colossus, but as usual I forgot. I posted my note last week and then forgot again to tell anyone that they were there. So here's the link http://geronimo.apache.org/xbean/colossus Those notes are still accurate, except I know blevins has some more details about the Dot File Layout idea bouncing around in his noggin. -dain
[jira] Closed: (GERONIMO-2325) unable to deploy from console with m2 build
[ http://issues.apache.org/jira/browse/GERONIMO-2325?page=all ] David Jencks closed GERONIMO-2325. -- Fix Version/s: 1.2 Resolution: Fixed Assignee: David Jencks (was: Jason Dillon) The basic fix is to depend on the j2ee-deployer car and remove a lot of unneeded dependencies. I might have removed too many: I commented out the ones I wasn't entirely sure of to make restoring easier in case problems show up later. rev 432066 unable to deploy from console with m2 build --- Key: GERONIMO-2325 URL: http://issues.apache.org/jira/browse/GERONIMO-2325 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: David Jencks Fix For: 1.2 Attachments: 2325-console.patch deploy-new is unable to deploy anything with the m2 build because of missing dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
m2 build - validating
Hi All, i've been using the m2 build for several days now and I've noticed that while it works well there are several details that are still not nailed down. Particularly I've been hitting lots of dependency issues around deployment. So what I've started doing is slogging through each of them one at a time, posting a jira and a patch. It struck me that there are probably similar issues throughout the server WRT the m2 build. I'm open to other methods (and would love to hear of a silver bullet:) but seems to me that we need to basically hit everything in the console and tools and such and make sure it works so we can be sure the dependencies are correct. While I don't think I'll be able to hit 'everything' I'll try to poke on most of the console and the CLI tools and make sure that it 'works'. My plan of attack: 1 - provide patches for the stuff i know about now (tranql/tranql- connector is missing for example from the repository) 2 - finish getting deployment working from the console (data sources, ejb-jar's, wars etc) 3 - poke on the rest of the console 4 - deploy daytrader 5 - anything else anyone comes up with I will be posting bunches of jira's and fixes over the next few days as I work through this stuff (unless someone has a better idea about how to tackle it). TTFN, -bd-
Re: Organization and versioning of specs; a new proposal
On Aug 16, 2006, at 3:28 PM, Jason Dillon wrote: On Aug 16, 2006, at 3:21 PM, David Blevins wrote: I guess I'd still prefer we do artifactId-version for the tag names as maven does. I'm planning on putting artifactId-version under artifactId/ but m2 handles this, all it needs it the root to exist. I see. When I suggested specs/tags/artifactId-version I hadn't noticed you expand that to specs/tags/artifactId/artifactId- version Seems like over-organizing as 70% of those directories will have only 1 file in them ever. The ones that do change, change only once or twice a year [1]. There's also a small catch in that the directories we've been using are not the artifactIds. I don't understand... :-\ Here's what I mean: $ grep -A 3 modelVersion */pom.xml | grep artifactId geronimo-spec-activation/pom.xml- artifactIdgeronimo- activation_1.0.2_spec/artifactId geronimo-spec-commonj/pom.xml- artifactIdgeronimo- commonj_1.1_spec/artifactId geronimo-spec-corba-2.3/pom.xml- artifactIdgeronimo- corba_2.3_spec/artifactId geronimo-spec-corba-3.0/pom.xml- artifactIdgeronimo- corba_3.0_spec/artifactId geronimo-spec-corba/pom.xml- artifactIdgeronimo-spec-corba/ artifactId geronimo-spec-ejb/pom.xml- artifactIdgeronimo-ejb_2.1_spec/ artifactId geronimo-spec-j2ee-connector/pom.xml- artifactIdgeronimo-j2ee- connector_1.5_spec/artifactId geronimo-spec-j2ee-deployment/pom.xml- artifactIdgeronimo-j2ee- deployment_1.1_spec/artifactId geronimo-spec-j2ee-jacc/pom.xml- artifactIdgeronimo-j2ee- jacc_1.0_spec/artifactId geronimo-spec-j2ee-management/pom.xml- artifactIdgeronimo-j2ee- management_1.0_spec/artifactId geronimo-spec-j2ee/pom.xml- artifactIdgeronimo-j2ee_1.4_spec/ artifactId geronimo-spec-javamail-1.3.1/pom.xml- artifactIdgeronimo- javamail_1.3.1_spec/artifactId geronimo-spec-javamail-1.4/pom.xml- artifactIdgeronimo- javamail_1.4_spec/artifactId geronimo-spec-jaxr/pom.xml- artifactIdgeronimo-jaxr_1.0_spec/ artifactId geronimo-spec-jaxrpc/pom.xml- artifactIdgeronimo-jaxrpc_1.1_spec/ artifactId geronimo-spec-jms/pom.xml- artifactIdgeronimo-jms_1.1_spec/ artifactId geronimo-spec-jsp/pom.xml- artifactIdgeronimo-jsp_2.0_spec/ artifactId geronimo-spec-jta/pom.xml- artifactIdgeronimo-jta_1.0.1B_spec/ artifactId geronimo-spec-qname/pom.xml- artifactIdgeronimo-qname_1.1_spec/ artifactId geronimo-spec-saaj/pom.xml- artifactIdgeronimo-saaj_1.1_spec/ artifactId geronimo-spec-servlet-2.4/pom.xml- artifactIdgeronimo- servlet_2.4_spec/artifactId geronimo-spec-servlet-2.5/pom.xml- artifactIdgeronimo- servlet_2.5_spec/artifactId -David [1] http://marc.theaimsgroup.com/?l=geronimo-devm=113857091823325w=2 --jason -David On Aug 16, 2006, at 2:06 PM, Jason Dillon wrote: Does not really look like anything needs to be moved. The only things (other than svn ci) would be svn mkdir for each spec in tags, since mvn release will not make that tree... as in: snip svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-activation svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-commonj svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-corba svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-corba-2.3 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-corba-3.0 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-connector svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-deployment svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-jacc svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-j2ee-management svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-javamail-1.3.1 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-javamail-1.4 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jaxr svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jaxrpc svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jms svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jsp svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-jta svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-qname svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-saaj svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-servlet-2.4 svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ geronimo-spec-servlet-2.5 /snip I think everything else is just pom updates. --jason On Aug 16, 2006, at 1:50 PM, David Jencks wrote: On Aug 16, 2006, at 1:40 PM, Jason Dillon wrote: I have always
[jira] Updated: (GERONIMODEVTOOLS-100) publishing hundreds of web projects / dependencies - GUI usability
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-100?page=all ] Oleg Gusakov updated GERONIMODEVTOOLS-100: -- Priority: Trivial (was: Critical) After analyzing the developer's usage pattern - I came to a conclusion that no one can humanly manage hundreds of WAR projects inside a single development cycle. Current approach of checkboxing existing WTP project should be sufficient. publishing hundreds of web projects / dependencies - GUI usability -- Key: GERONIMODEVTOOLS-100 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-100 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.1.0 Environment: IBM Java 1.5, Eclipse 3.2.0, WTP 1.5, w2k/w3k Reporter: Oleg Gusakov Priority: Trivial When there are several hundred projects, publishing/removing them from Geronimo becomes a tedious task. We need a clearer GUI to address that, probably some kind of hierarchical markup in the project metadata. Or combine that with Maven POM metadata ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: m2 build - validating
On Aug 16, 2006, at 4:33 PM, Bill Dudney wrote: Hi All, i've been using the m2 build for several days now and I've noticed that while it works well there are several details that are still not nailed down. Particularly I've been hitting lots of dependency issues around deployment. So what I've started doing is slogging through each of them one at a time, posting a jira and a patch. It struck me that there are probably similar issues throughout the server WRT the m2 build. I'm open to other methods (and would love to hear of a silver bullet:) but seems to me that we need to basically hit everything in the console and tools and such and make sure it works so we can be sure the dependencies are correct. While I don't think I'll be able to hit 'everything' I'll try to poke on most of the console and the CLI tools and make sure that it 'works'. My plan of attack: 1 - provide patches for the stuff i know about now (tranql/tranql- connector is missing for example from the repository) 2 - finish getting deployment working from the console (data sources, ejb-jar's, wars etc) 3 - poke on the rest of the console 4 - deploy daytrader 5 - anything else anyone comes up with I will be posting bunches of jira's and fixes over the next few days as I work through this stuff (unless someone has a better idea about how to tackle it). This is great that you are taking a look at this. Here are some tips that may help fix dependency problems: 1. The modules use resources2/META-INF/geronimo-dependency.xml files to specify transitive dependencies. We could use a lot more of these. You may find the best solution to a classpath problem is adding one of these. 2. There are often several ways to get a jar into a classloader, such as a) depending on a car, from a car b) depending on a jar from a jar (using geornimo-dependency.xml) c) depending directly on the jar from a car I'd say this is the order of preference 3) It is really important that the builder cars don't start any runtime cars: if you violate this rule the packaging plugin is likely to stop working. You can have 2.a and enforce this rule by using the scope element in the dependency and setting it to scopeclasses/ scope. This means the dependency's classloader will be constructed and available for use but that no services from the car will be started. This is in my experience somewhat nerve wracking and gruesome work, so I really appreciate your taking it on, and I'll do whatever I can to help you with it. thanks david jencks TTFN, -bd-
Re: [WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
Congrats! On 8/16/06, Matt Hogstrom [EMAIL PROTECTED] wrote: All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. The Apache Geronimo PMC -- Regards, Hiram Blog: http://hiramchirino.com
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congrats! On 8/14/06, Matt Hogstrom [EMAIL PROTECTED] wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC -- Regards, Hiram Blog: http://hiramchirino.com
Re: Colossus Notes
On Aug 16, 2006, at 4:04 PM, Dain Sundstrom wrote: I mentioned a few weeks ago that I would post my notes about the stuff I'm working on in colossus, but as usual I forgot. I posted my note last week and then forgot again to tell anyone that they were there. So here's the link http://geronimo.apache.org/xbean/colossus Those notes are still accurate, except I know blevins has some more details about the Dot File Layout idea bouncing around in his noggin. Yep. I'd like to hack on a prototype after I'm done the jpa plugin code I'm working on. -David -dain
Introducing myself ...
Sorry for wasting a thread for this purpose, but I thought that it's important to introduce myself to this honorable community as I created some entries in JIRA ( GERONIMODEVTOOLS-99, etc.)My company has started using Geronimo AS as our main deployment platform and once it's there - I have to organize decent developer's support for debugging application on it. We are using Eclipse, so the easiest solution seems to be Geronimo plugin. Unfortunately this plugin is still in it's infancy and is just making baby steps. My challenge is that we are already using Geronimo, so I cannot wait for this plugin to grow naturally - success of Geronimo in our organization depends of this plugin; if we cannot make it work - this entire direction may die with it. Several hundred developers cannot rely on just JPDA while debugging web applications. This probably explains why I started making waves in JIRA - not just for the fun of it, but trying to promote success of this wonderful OSS project.I hope the above helps to understand the importance for us of various decisions that are taken to expedite or postpone this or that feature. And I am also convinced that success of projects like Geronimo largely depends on how well they fit into real-life enviroment such as a company I work for.A little bit about myself - programming for the last 25 years and hope do the same when I die :) Java since 1996, software development in different roles all my life, seen a lot of platforms and technologies .. Thanks,Oleg Gusakov
Re: 185 changes left in all_changes.log...
On Aug 15, 2006, at 7:38 PM, Jason Dillon wrote: I've chopped off the obvious ones... but there are still 185 marked as Not Merged which someone should peep at. I generally hate all things microsoft... except I'm starting to like my xbox, and well excel was really handy to sort the table so its easier to see what is still in need of merging. Attached is a csv (with a bit of funky formatting) sorted by the first column. It would be nice if we could trim down the list of Not Merged even more... and then be done with that branch. Please have a look if you have some free time. I haven't looked at your nice tables, but I know that I have some unmerged changes. Afraid I won't be able to get to them until next week, though. --kevan
Re: Organization and versioning of specs; a new proposal
On Aug 16, 2006, at 4:38 PM, David Blevins wrote: On Aug 16, 2006, at 3:28 PM, Jason Dillon wrote: On Aug 16, 2006, at 3:21 PM, David Blevins wrote: I guess I'd still prefer we do artifactId-version for the tag names as maven does. I'm planning on putting artifactId-version under artifactId/ but m2 handles this, all it needs it the root to exist. I see. When I suggested specs/tags/artifactId-version I hadn't noticed you expand that to specs/tags/artifactId/ artifactId-version Seems like over-organizing as 70% of those directories will have only 1 file in them ever. The ones that do change, change only once or twice a year [1]. Maybe... I don't care either way. Here's what I mean: $ grep -A 3 modelVersion */pom.xml | grep artifactId geronimo-spec-activation/pom.xml- artifactIdgeronimo- activation_1.0.2_spec/artifactId geronimo-spec-commonj/pom.xml- artifactIdgeronimo- commonj_1.1_spec/artifactId geronimo-spec-corba-2.3/pom.xml- artifactIdgeronimo- corba_2.3_spec/artifactId geronimo-spec-corba-3.0/pom.xml- artifactIdgeronimo- corba_3.0_spec/artifactId geronimo-spec-corba/pom.xml- artifactIdgeronimo-spec-corba/ artifactId geronimo-spec-ejb/pom.xml- artifactIdgeronimo-ejb_2.1_spec/ artifactId geronimo-spec-j2ee-connector/pom.xml- artifactIdgeronimo-j2ee- connector_1.5_spec/artifactId geronimo-spec-j2ee-deployment/pom.xml- artifactIdgeronimo-j2ee- deployment_1.1_spec/artifactId geronimo-spec-j2ee-jacc/pom.xml- artifactIdgeronimo-j2ee- jacc_1.0_spec/artifactId geronimo-spec-j2ee-management/pom.xml- artifactIdgeronimo-j2ee- management_1.0_spec/artifactId geronimo-spec-j2ee/pom.xml- artifactIdgeronimo-j2ee_1.4_spec/ artifactId geronimo-spec-javamail-1.3.1/pom.xml- artifactIdgeronimo- javamail_1.3.1_spec/artifactId geronimo-spec-javamail-1.4/pom.xml- artifactIdgeronimo- javamail_1.4_spec/artifactId geronimo-spec-jaxr/pom.xml- artifactIdgeronimo-jaxr_1.0_spec/ artifactId geronimo-spec-jaxrpc/pom.xml- artifactIdgeronimo- jaxrpc_1.1_spec/artifactId geronimo-spec-jms/pom.xml- artifactIdgeronimo-jms_1.1_spec/ artifactId geronimo-spec-jsp/pom.xml- artifactIdgeronimo-jsp_2.0_spec/ artifactId geronimo-spec-jta/pom.xml- artifactIdgeronimo-jta_1.0.1B_spec/ artifactId geronimo-spec-qname/pom.xml- artifactIdgeronimo-qname_1.1_spec/ artifactId geronimo-spec-saaj/pom.xml- artifactIdgeronimo-saaj_1.1_spec/ artifactId geronimo-spec-servlet-2.4/pom.xml- artifactIdgeronimo- servlet_2.4_spec/artifactId geronimo-spec-servlet-2.5/pom.xml- artifactIdgeronimo- servlet_2.5_spec/artifactId Ahh... well that will need to get fixed for sure. The artifactId needs to be the same as the directory name to take advantage of maven's ability to autoconfigure somethings. If they are not in sync, then we end up with extra config to put them in the right place... which is uneeded IMO. --jason
sandbox/geronimo-deployment-plugin
Is anyone still using this: https://svn.apache.org/viewvc/geronimo/sandbox/geronimo- deployment-plugin If not, I'd like to remove it. --jason
Re: 185 changes left in all_changes.log...
When you have time please do check :-) --jason PS. My xbox crashed twice yesterday... gotta luv that microsoft quality. On Aug 16, 2006, at 5:14 PM, Kevan Miller wrote: On Aug 15, 2006, at 7:38 PM, Jason Dillon wrote: I've chopped off the obvious ones... but there are still 185 marked as Not Merged which someone should peep at. I generally hate all things microsoft... except I'm starting to like my xbox, and well excel was really handy to sort the table so its easier to see what is still in need of merging. Attached is a csv (with a bit of funky formatting) sorted by the first column. It would be nice if we could trim down the list of Not Merged even more... and then be done with that branch. Please have a look if you have some free time. I haven't looked at your nice tables, but I know that I have some unmerged changes. Afraid I won't be able to get to them until next week, though. --kevan
[jira] Created: (AMQ-881) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.
Patch: refactoring to allow alternative (using different storage interface)
Destinations implementations.
-
Key: AMQ-881
URL: https://issues.apache.org/activemq/browse/AMQ-881
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 4.x
Reporter: Maxim Fateev
We were looking at alternate message persistence mechanisms that can co-exist
in current ActiveMQ code base and we are thinking of a mechanism that is
somewhat incompatible with the current MessageStore and PersistenceAdapter
APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a
change as the PersistenceAdapter and MessageStore interfaces are referenced
directly by the RegionBroker and by both the Queue and Topic region
implementations. Therefore, we are proposing a relatively small backwards
compatible refactoring of the broker code that would eliminate all dependencies
on the PersistenceAdapter and MessageStore interfaces from those classes that
do not use them directly. This refactoring would also allow creation of a
custom Destination implementation that may use an alternative persistence
mechanism on a destination by destination basis (which is exactly what we need
to do).
The main idea behind the refactoring is to replace many references to
PersistenceAdapter with a new interface: DestinationFactory:
public abstract class DestinationFactory {
abstract public Destination createDestination(ConnectionContext
context, ActiveMQDestination destination, DestinationStatistics
destinationStatistics) throws Exception;
abstract public Set getDestinations();
abstract public SubscriptionInfo[]
getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException;
abstract public long getLastMessageBrokerSequenceId() throws
IOException;
abstract public void setRegionBroker(RegionBroker regionBroker);
}
Note that DestinationFactory doesn't mandate any specific persistence
mechanism. The classes that would reference it instead of PersistenceAdapter
are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the
AbstractRegion.createDestination method would be changed from abstract to an
implementation that uses DestinationFactory to create a destination.
BrokerService could be changed to use DestinationFactory if one is
provided. If none is provided, it will create a DestinationFactory
implementation that instantiates Queue and Topic using PersistenceAdapter as it
does currently. Hence, full backwards compatibility will be maintained.
Patch is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (AMQ-881) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.
[ https://issues.apache.org/activemq/browse/AMQ-881?page=all ]
Maxim Fateev closed AMQ-881.
Resolution: Duplicate
Patch: refactoring to allow alternative (using different storage interface)
Destinations implementations.
-
Key: AMQ-881
URL: https://issues.apache.org/activemq/browse/AMQ-881
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 4.x
Reporter: Maxim Fateev
We were looking at alternate message persistence mechanisms that can co-exist
in current ActiveMQ code base and we are thinking of a mechanism that is
somewhat incompatible with the current MessageStore and PersistenceAdapter
APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a
change as the PersistenceAdapter and MessageStore interfaces are referenced
directly by the RegionBroker and by both the Queue and Topic region
implementations. Therefore, we are proposing a relatively small backwards
compatible refactoring of the broker code that would eliminate all
dependencies on the PersistenceAdapter and MessageStore interfaces from those
classes that do not use them directly. This refactoring would also allow
creation of a custom Destination implementation that may use an alternative
persistence mechanism on a destination by destination basis (which is exactly
what we need to do).
The main idea behind the refactoring is to replace many references to
PersistenceAdapter with a new interface: DestinationFactory:
public abstract class DestinationFactory {
abstract public Destination createDestination(ConnectionContext
context, ActiveMQDestination destination, DestinationStatistics
destinationStatistics) throws Exception;
abstract public Set getDestinations();
abstract public SubscriptionInfo[]
getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException;
abstract public long getLastMessageBrokerSequenceId() throws
IOException;
abstract public void setRegionBroker(RegionBroker regionBroker);
}
Note that DestinationFactory doesn't mandate any specific persistence
mechanism. The classes that would reference it instead of PersistenceAdapter
are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the
AbstractRegion.createDestination method would be changed from abstract to an
implementation that uses DestinationFactory to create a destination.
BrokerService could be changed to use DestinationFactory if one is
provided. If none is provided, it will create a DestinationFactory
implementation that instantiates Queue and Topic using PersistenceAdapter as
it does currently. Hence, full backwards compatibility will be maintained.
Patch is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Issue for 4.x version is not being looked at
I've submitted a patch at Friday against 4.x: http://issues.apache.org/activemq/browse/AMQ-877 But it doesn't show up in the list of outstanding issues for 4.x (https://issues.apache.org/activemq/secure/IssueNavigator.jspa?mode=hiderequestId=11102). Should I resubmit it against 4.1 to get it looked at? Thanks, Maxim.
Re: sandbox/geronimo-deployment-plugin
You may remove it. We have it in the m2-plugins now Cheers Prasad On 8/16/06, Jason Dillon [EMAIL PROTECTED] wrote: Is anyone still using this: https://svn.apache.org/viewvc/geronimo/sandbox/geronimo- deployment-plugin If not, I'd like to remove it. --jason
