[jira] Created: (GERONIMO-4343) Tuscany Geronimo plugin bring up
Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: ant elder JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated GERONIMO-4343: Attachment: tuscany-xsd-dependency.diff The geronimo-tuscany\tuscany-xsd-dependency.diff adds another missing dependencies on the tuscany-xsd and tuscanyxsd-xml modules Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: tuscany-xsd-dependency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tuscany Geronimo integration and the SCA JEE spec
On Tue, Oct 7, 2008 at 5:34 PM, David Jencks [EMAIL PROTECTED] wrote: On Oct 7, 2008, at 2:56 AM, ant elder wrote: Tuscany uses JDK logging but putting a logging.properties file into the Geronimo var\log folder doesn't seem to get picked up. Any ideas on where that should go or how to configure Tuscany logging options when running in Geronimo? Does this help? http://cwiki.apache.org/GMOxDOC21/locating-your-application-specific-configuration-files.html thanks david jencks Thanks it certainly looks interesting, i'll have a play around and see if i can get it to work based on that info. ...ant
Re: Tuscany Geronimo integration and the SCA JEE spec
On Fri, Oct 3, 2008 at 2:12 PM, Dan Becker [EMAIL PROTECTED] wrote: ant elder wrote: Currently the old TGP has got out of date and doesn't work with any current releases of Geronimo or Tuscany so the first thing to do is to get a basic plugin going again and then gradually add functionality to it so it does things like: - adds all Tuscany jars and their dependencys into Geronimo - supports existing Tuscany webapps without needing to include any Tuscany jars or dependencys in the lib directory - supports simple jar contributions into a Tuscany standalone node - supports Tuscany using Geronimo infrastructure for things such as HTTP and JMS hosts - supports for SCA enabled JEE application local assembly - supports SCA wiring across JEE applications and modules All excellent goals. Additionally I would like to see how trimmed and lean we can make this platform. Can we make it the smallest footprint, quickest bringup SCA runtime out there? -- Thanks, Dan Becker Sounds good. We could look at using the Geronimo Little-G and Framework distributions to base that on. ...ant
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637806#action_12637806 ] ant elder commented on GERONIMO-4343: - Another patch needed to get this further was posted to the ML: http://apache.markmail.org/message/kfvn2p5wbxthww56 Thats a patch to a released 1.3 module, we probably need to change the plugin to use the latest Tuscany SNAPSHOTs to make picking up fixes in the Tuscany modules a bit easier. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: tuscany-xsd-dependency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637816#action_12637816 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- tuscany-xsd-dependency.diff applied in rev 702746. Thanks Ant. Regarding the Tuscany SNAPSHOTs, should we stick to 1.3 branch or the trunk (i.e. 1.4-SNAPSHOT)? Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: tuscany-xsd-dependency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 702742
Geronimo Revision: 702742 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081008/build-0300.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20081008 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 40 minutes [INFO] Finished at: Wed Oct 08 03:43:39 EDT 2008 [INFO] Final Memory: 401M/972M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081008/logs-0300-tomcat/test.log Booting Geronimo Kernel (in Java 1.5.0_12)... Module 1/71 org.apache.geronimo.framework/j2ee-system/2.2-SNAPSHOT/car started in .000s Module 2/71 org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car started in .001s Module 3/71 org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car started in .287s Module 4/71 org.apache.geronimo.plugins.classloaders/geronimo-javaee-deployment_1.1MR3_spec/2.2-SNAPSHOT/car started in .000s Module 5/71 org.apache.geronimo.framework/plugin/2.2-SNAPSHOT/car started in .772s Module 6/71 org.apache.geronimo.framework/j2ee-security/2.2-SNAPSHOT/car started in .294s Module 7/71 org.apache.geronimo.configs/j2ee-server/2.2-SNAPSHOT/car started in .081s Module 8/71 org.apache.geronimo.configs/transaction/2.2-SNAPSHOT/car started in .351s Module 9/71 org.apache.geronimo.framework/server-security-config/2.2-SNAPSHOT/car started in .053s Module 10/71 org.apache.geronimo.configs/jasper/2.2-SNAPSHOT/car started in .004s Module 11/71 org.apache.geronimo.framework/xmlbeans/2.2-SNAPSHOT/car started in .000s Module 12/71 org.apache.geronimo.plugins.classloaders/geronimo-schema-jee_5/2.2-SNAPSHOT/car started in .000s Module 13/71 org.apache.geronimo.configs/webservices-common/2.2-SNAPSHOT/car started in .000s Module 14/71 org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car started in 2.873s Module 15/71 org.apache.geronimo.configs/welcome-tomcat/2.2-SNAPSHOT/car started in .340s Module 16/71 org.apache.geronimo.framework/gshell-framework/2.2-SNAPSHOT/car started in .001s Module 17/71 org.apache.geronimo.framework/gshell-geronimo/2.2-SNAPSHOT/car started in .001s Module 18/71 org.apache.geronimo.framework/gshell-remote/2.2-SNAPSHOT/car started in .000s Module 19/71 org.apache.geronimo.configs/sharedlib/2.2-SNAPSHOT/car started in .009s Module 20/71 org.apache.geronimo.framework/transformer-agent/2.2-SNAPSHOT/car started in .000s Module 21/71 org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car started in .469s Module 22/71 org.apache.geronimo.configs/remote-deploy-tomcat/2.2-SNAPSHOT/car started in .175s Module 23/71 org.apache.geronimo.plugins.classloaders/xbean-finder/2.2-SNAPSHOT/car started in .000s Module 24/71 org.apache.geronimo.configs/j2ee-deployer/2.2-SNAPSHOT/car started in .230s Module 25/71 org.apache.geronimo.configs/connector-deployer/2.2-SNAPSHOT/car started in .123s Module 26/71 org.apache.geronimo.configs/tomcat6-deployer/2.2-SNAPSHOT/car started in .087s Module 27/71 org.apache.geronimo.configs/jasper-deployer/2.2-SNAPSHOT/car started in .010s Module 28/71 org.apache.geronimo.configs/hot-deployer/2.2-SNAPSHOT/car started in .335s Module 29/71 org.apache.geronimo.configs/client-deployer/2.2-SNAPSHOT/car 03:49:15,832 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/client-deployer/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/client-deployer/2.2-SNAPSHOT/car,j2eeType
[jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated GERONIMO-4343: Attachment: wsdlgen-depenency.diff The geronimo-tuscany\wsdlgen-depenency.diff fixes another missing dependency and fixes the EmbeddedRuntimeGBean to use the correct build method to match the latest Tuscany code. The diff also includes the change from the tuscany-xsd-dependency.diff Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up
With that latest patch (wsdlgen-depenency.diff) i have the plugin building, installing, and successfully deploying a simple Java only SCA contribution. trying an SCA contribution fails, i'm looking at that right now... ...ant On Wed, Oct 8, 2008 at 9:15 AM, ant elder (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] ant elder updated GERONIMO-4343: Attachment: wsdlgen-depenency.diff The geronimo-tuscany\wsdlgen-depenency.diff fixes another missing dependency and fixes the EmbeddedRuntimeGBean to use the correct build method to match the latest Tuscany code. The diff also includes the change from thetuscany-xsd-dependency.diff Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up
Opps, I meant ...trying an SCA contribution _with Web Services_ fails... ...ant On Wed, Oct 8, 2008 at 9:36 AM, ant elder [EMAIL PROTECTED] wrote: With that latest patch (wsdlgen-depenency.diff) i have the plugin building, installing, and successfully deploying a simple Java only SCA contribution. trying an SCA contribution fails, i'm looking at that right now... ...ant On Wed, Oct 8, 2008 at 9:15 AM, ant elder (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] ant elder updated GERONIMO-4343: Attachment: wsdlgen-depenency.diff The geronimo-tuscany\wsdlgen-depenency.diff fixes another missing dependency and fixes the EmbeddedRuntimeGBean to use the correct build method to match the latest Tuscany code. The diff also includes the change from thetuscany-xsd-dependency.diff Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637890#action_12637890 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- wsdlgen-depenency.diff applied in rev 702817. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: GeronimoServletHost1.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated GERONIMO-4343: Attachment: GeronimoServletHost1.diff geronimo-tuscany\GeronimoServletHost1.diff adds getURLMapping method impl as that hadn't been implemented in the existing code. The code is copied fom the Tuscany WebappServletHost, its a a hack and needs redoing, this is just a stepping stone to get something working for now. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: GeronimoServletHost1.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated GERONIMO-4343: Attachment: GeronimoServletHost2.diff GeronimoServletHost2.diff includes the change in GeronimoServletHost1.diff and adds a fix to the test of if the tuscany context exists , the context is now null whereas it must have used to be a context with an empty name. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: GeronimoServletHost1.diff, GeronimoServletHost2.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4342) MimeMessage#writeTo doesn't flush the encoder stream
[ https://issues.apache.org/jira/browse/GERONIMO-4342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637904#action_12637904 ] Rick McGuire commented on GERONIMO-4342: Great1 This was largely just a curiosity question. You're doing a great job so far figuring out the failures and providing patches. Don't be afraid to ask for assistance if you need any. The api specs are not terrible rigorous in defining how somethings are supposed to behave, so we've been handling things on a failure-by-failure basis. MimeMessage#writeTo doesn't flush the encoder stream Key: GERONIMO-4342 URL: https://issues.apache.org/jira/browse/GERONIMO-4342 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Andreas Veithen Assignee: Rick McGuire Attachments: GERONIMO-4342.patch.txt MimeMessage#writeTo only flushes the underlying output stream provided by the caller, but not the encoder stream that wraps it. If the transfer encoding is Base64, this causes bytes at the end of the content to be lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up
Have you switched to latest Tuscany SNAPSHOT in your local build or using 1.3? ++Vamsi On Wed, Oct 8, 2008 at 2:07 PM, ant elder [EMAIL PROTECTED] wrote: Opps, I meant ...trying an SCA contribution _with Web Services_ fails... ...ant On Wed, Oct 8, 2008 at 9:36 AM, ant elder [EMAIL PROTECTED] wrote: With that latest patch (wsdlgen-depenency.diff) i have the plugin building, installing, and successfully deploying a simple Java only SCA contribution. trying an SCA contribution fails, i'm looking at that right now... ...ant On Wed, Oct 8, 2008 at 9:15 AM, ant elder (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] ant elder updated GERONIMO-4343: Attachment: wsdlgen-depenency.diff The geronimo-tuscany\wsdlgen-depenency.diff fixes another missing dependency and fixes the EmbeddedRuntimeGBean to use the correct build method to match the latest Tuscany code. The diff also includes the change from thetuscany-xsd-dependency.diff Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated GERONIMO-4343: Attachment: asm.diff asm.diff adds the asm-all dependency. it also adds it to the hidden classes in tuscany-tomcat/src/main/plan/plan.xml, i'm not sure if that is really necessary Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: asm.diff, GeronimoServletHost1.diff, GeronimoServletHost2.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated GERONIMO-4343: Attachment: tuscany-core-1.3.jar The \tuscany-core-1.3.jar attachement is the tuscany-core module built with the patch mentioned above in the email: http://apache.markmail.org/message/kfvn2p5wbxthww56 Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4342) MimeMessage#writeTo doesn't flush the encoder stream
[ https://issues.apache.org/jira/browse/GERONIMO-4342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637888#action_12637888 ] Andreas Veithen commented on GERONIMO-4342: --- Rick, Over the last couple of months I developed a test suite for the Axis2 transports, which include a SOAP over mail transport. All tests pass fine with Sun's implementation of JavaMail, and now I'm trying to make them work with Geronimo's implementation. MimeMessage#writeTo doesn't flush the encoder stream Key: GERONIMO-4342 URL: https://issues.apache.org/jira/browse/GERONIMO-4342 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Andreas Veithen Assignee: Rick McGuire Attachments: GERONIMO-4342.patch.txt MimeMessage#writeTo only flushes the underlying output stream provided by the caller, but not the encoder stream that wraps it. If the transfer encoding is Base64, this causes bytes at the end of the content to be lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4342) MimeMessage#writeTo doesn't flush the encoder stream
[ https://issues.apache.org/jira/browse/GERONIMO-4342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved GERONIMO-4342. Resolution: Fixed Committed revision 702800. Thank you once again! I'm curious, what are you using this for that's uncovering these problems? It always nice to know the sort uses this that this code is getting applied to. MimeMessage#writeTo doesn't flush the encoder stream Key: GERONIMO-4342 URL: https://issues.apache.org/jira/browse/GERONIMO-4342 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Andreas Veithen Assignee: Rick McGuire Attachments: GERONIMO-4342.patch.txt MimeMessage#writeTo only flushes the underlying output stream provided by the caller, but not the encoder stream that wraps it. If the transfer encoding is Base64, this causes bytes at the end of the content to be lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637902#action_12637902 ] ant elder commented on GERONIMO-4343: - With that latest patch (GeronimoServletHost2.diff) the plugin works installing an sca contribution that uses the Tuscany Web Service binding, well the contribution install works and you can access the service wsdl but actually invoking the service fails witha classloader issue. There's a test contribution jar at: http://people.apache.org/~antelder/temp/sample-helloworld-ws-service.jar Install the plugin to Geronimo, then install that jar with the regular Geronimo deploy application portal, then you can go to http://localhost:8080/tuscany/HelloWorldService?wsdl and the WSDL for the service will be displayed. Trying to invoke the service, eg with the Tuscany helloworld-ws-reference sample,(or something like the Eclipse WTP WS invoker utility) cause the service to fail with: 08-Oct-2008 13:30:18 org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver invokeBusinessLogic SEVERE: java.lang.NoSuchMethodError: org.objectweb.asm.ClassWriter.init(I)V org.osoa.sca.ServiceRuntimeException: java.lang.NoSuchMethodError: org.objectweb.asm.ClassWriter.init(I)V at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:119) at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:85) at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:79) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.invoke(RuntimeWireImpl.java:138) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTarget(Axis2ServiceProvider.java:693) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(Axis2Service InOutSyncMessageReceiver.java:68) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageRecei ver.java:42) at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:96) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:120) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NoSuchMethodError: org.objectweb.asm.ClassWriter.init(I)V at org.apache.tuscany.sca.interfacedef.java.jaxws.BaseBeanGenerator.generate(BaseBeanGenerator.java:314) at org.apache.tuscany.sca.interfacedef.java.jaxws.WrapperBeanGenerator.generateRequestWrapper(WrapperBeanGenerat or.java:74) at org.apache.tuscany.sca.interfacedef.java.jaxws.GeneratedDataTypeImpl.getPhysical(GeneratedDataTypeImpl.java:9 9) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.findClasses(JAXBContextHelper.java:228) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:208) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:95) at org.apache.tuscany.sca.databinding.jaxb.XMLStreamReader2JAXB.transform(XMLStreamReader2JAXB.java:46) at org.apache.tuscany.sca.databinding.jaxb.XMLStreamReader2JAXB.transform(XMLStreamReader2JAXB.java:34) at
Re: [jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up
No, i've just locally patched the tuscany-core-1.3.jar. I've just attached that patched jar to the GERONIMO-4343 jira. ...ant On Wed, Oct 8, 2008 at 10:34 AM, Vamsavardhana Reddy [EMAIL PROTECTED]wrote: Have you switched to latest Tuscany SNAPSHOT in your local build or using 1.3? ++Vamsi On Wed, Oct 8, 2008 at 2:07 PM, ant elder [EMAIL PROTECTED] wrote: Opps, I meant ...trying an SCA contribution _with Web Services_ fails... ...ant On Wed, Oct 8, 2008 at 9:36 AM, ant elder [EMAIL PROTECTED] wrote: With that latest patch (wsdlgen-depenency.diff) i have the plugin building, installing, and successfully deploying a simple Java only SCA contribution. trying an SCA contribution fails, i'm looking at that right now... ...ant On Wed, Oct 8, 2008 at 9:15 AM, ant elder (JIRA) [EMAIL PROTECTED]wrote: [ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] ant elder updated GERONIMO-4343: Attachment: wsdlgen-depenency.diff The geronimo-tuscany\wsdlgen-depenency.diff fixes another missing dependency and fixes the EmbeddedRuntimeGBean to use the correct build method to match the latest Tuscany code. The diff also includes the change from thetuscany-xsd-dependency.diff Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4342) MimeMessage#writeTo doesn't flush the encoder stream
[ https://issues.apache.org/jira/browse/GERONIMO-4342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire reassigned GERONIMO-4342: -- Assignee: Rick McGuire MimeMessage#writeTo doesn't flush the encoder stream Key: GERONIMO-4342 URL: https://issues.apache.org/jira/browse/GERONIMO-4342 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Andreas Veithen Assignee: Rick McGuire Attachments: GERONIMO-4342.patch.txt MimeMessage#writeTo only flushes the underlying output stream provided by the caller, but not the encoder stream that wraps it. If the transfer encoding is Base64, this causes bytes at the end of the content to be lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: dojo-tomcat/jetty6
Hi Lin, I am using it in the EjbServer Portlet I am developing. But I guess that it can also be made an optional console plugin Regards Manu On Wed, Oct 8, 2008 at 1:43 AM, Lin Sun [EMAIL PROTECTED] wrote: Jay, Right, I don't know how far that work went either. Thus, I didn't include the dojo-tomcat/jetty6 in the new javaee5-tomcat/jetty plugin group(profile), which will be used to build the javaee5 assemblies. Lin n Tue, Oct 7, 2008 at 3:41 PM, Jay D. McHugh [EMAIL PROTECTED] wrote: Lin, Someone was working on upgrading the views in Geronimo to use the widgets in the new version of Dojo. I don't know how far that work went. So, I believe you are correct that the legacy set are the only ones that are currently in use. Jay Lin Sun wrote: I think these two portlets are using the dojo-legacy-tomcat/jetty6. Nothing except the javaee5 assemblies lists dojo-tomcat/jetty6 as dependency. Lin On Tue, Oct 7, 2008 at 3:10 PM, Donald Woods [EMAIL PROTECTED] wrote: I believe only the Debug Views and Plan Creator portlets need Dojo right now, which I'm going to remove from the JEE5 assemblies and let users optionally install them, once I've updated the Welcome portlet to include some information about what optional Console plugins are available -Donald Lin Sun wrote: Hi, I don't see dojo-tomcat/jetty6 is used by admin console right now in trunk thus I plan to remove it from the javaee5 assembly. Any objection? Whenever we have converted some of our admin console to use dojo-tomcat/jetty6, dojo-tomcat/jetty6 should be automatically pulled into javaee5 assembly via transitive dependency, similar like dojo-legacy-tomcat/jetty6 today. Lin
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637901#action_12637901 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- GeronimoServletHost2.diff applied in rev 702838. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: GeronimoServletHost1.diff, GeronimoServletHost2.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
These are the console plugin groups, basically it provides the
required console function for the javaee5 assemblies. I think the
list suggested the following profiles a while back ago:
JMS
EJB
Web Services
Admin Console
...
Also, I need the console plugin group to construct the javaee5 plugin
groups/assemblies.
Regarding activemq-console-xxx, my initial thought was to include it
in the JMS plugin group, but I realize that you are working on the
optional console and people may not want the JMS console function when
they want JMS function (for example, there is one user trying to add
JMS on top of little G). When you have your optional console stuff
in, you can remove the optional ones from the console plugin group.
Plugin groups are basically groups of plugins for users to easily
understand and consume them. They can be used in the following ways:
1. custom server assemblies
2. G server assemblies (framework, javaee5)
3. install plugin group as regular plugin. For example, a user should
be able to install the JMS plugin group in little G to get little G +
JMS environment.
Lin
On Tue, Oct 7, 2008 at 11:03 PM, Donald Woods [EMAIL PROTECTED] wrote:
Why are we recreating the existing console-jetty and console-tomcat as yet
another plugin?
Also, why are you including optional console plugins like
activemq-console-xxx, which should only be included if the ActiveMQ plugins
are installed? By including it here, you're basically pulling in the JMS
plugins.
I'm starting to reconsider why we need plugingroups, if we're going to have
to recreate dozens of existing plugins just in a slightly different format
just so we can include them in a special view just for custom server
assemblies
-Donald
[EMAIL PROTECTED] wrote:
Author: linsun
Date: Tue Oct 7 12:09:59 2008
New Revision: 702586
URL: http://svn.apache.org/viewvc?rev=702586view=rev
Log:
Add the console-jetty plugin group
Added:
geronimo/server/trunk/plugingroups/console-jetty/
geronimo/server/trunk/plugingroups/console-jetty/pom.xml (with props)
geronimo/server/trunk/plugingroups/console-jetty/src/
geronimo/server/trunk/plugingroups/console-jetty/src/main/
geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
(with props)
geronimo/server/trunk/plugingroups/console-jetty/src/main/plan/
Added: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/pom.xml?rev=702586view=auto
==
--- geronimo/server/trunk/plugingroups/console-jetty/pom.xml (added)
+++ geronimo/server/trunk/plugingroups/console-jetty/pom.xml Tue Oct 7
12:09:59 2008
@@ -0,0 +1,98 @@
+?xml version=1.0 encoding=ISO-8859-1?
+!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+License); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
++ http://www.apache.org/licenses/LICENSE-2.0
++Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+--
+!-- @version $Rev$ $Date$ --
+
+project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
+
+modelVersion4.0.0/modelVersion
+
+parent
+groupIdorg.apache.geronimo.plugingroups/groupId
+artifactIdplugingroups/artifactId
+version2.2-SNAPSHOT/version
+/parent
+
+artifactIdconsole-jetty/artifactId
+packagingcar/packaging
+nameGeronimo Plugin Group :: Admin Console Jetty/name
+
+description
+This plugin group provides Admin Console Jetty functionality.
+/description
+
+dependencies
+dependency
+groupIdorg.apache.geronimo.configs/groupId
+artifactIdca-helper-jetty/artifactId
+version${version}/version
+typecar/type
+/dependency
+
+dependency
+groupIdorg.apache.geronimo.plugins/groupId
+artifactIdagent/artifactId
+version${version}/version
+typecar/type
+/dependency
+
+dependency
+groupIdorg.apache.geronimo.plugins/groupId
+
[jira] Resolved: (GERONIMO-4328) change boilerplate geronimo plugin to use car format (instead of current jar format)
[ https://issues.apache.org/jira/browse/GERONIMO-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4328. --- Resolution: Fixed Per discuss on the list, I dont think this breaks the build or anything. change boilerplate geronimo plugin to use car format (instead of current jar format) Key: GERONIMO-4328 URL: https://issues.apache.org/jira/browse/GERONIMO-4328 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 2.2 Reporter: Lin Sun Assignee: Lin Sun Priority: Minor Fix For: 2.2 This has been discussed on dev list here - http://www.nabble.com/boilerplate,-jaxws-tools-(convert-from-jar-to-car-format-)-td19727867s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: dojo-tomcat/jetty6
Hi Manu, Ok, making it optional sounds good. Lin On Wed, Oct 8, 2008 at 8:24 AM, Manu George [EMAIL PROTECTED] wrote: Hi Lin, I am using it in the EjbServer Portlet I am developing. But I guess that it can also be made an optional console plugin Regards Manu On Wed, Oct 8, 2008 at 1:43 AM, Lin Sun [EMAIL PROTECTED] wrote: Jay, Right, I don't know how far that work went either. Thus, I didn't include the dojo-tomcat/jetty6 in the new javaee5-tomcat/jetty plugin group(profile), which will be used to build the javaee5 assemblies. Lin n Tue, Oct 7, 2008 at 3:41 PM, Jay D. McHugh [EMAIL PROTECTED] wrote: Lin, Someone was working on upgrading the views in Geronimo to use the widgets in the new version of Dojo. I don't know how far that work went. So, I believe you are correct that the legacy set are the only ones that are currently in use. Jay Lin Sun wrote: I think these two portlets are using the dojo-legacy-tomcat/jetty6. Nothing except the javaee5 assemblies lists dojo-tomcat/jetty6 as dependency. Lin On Tue, Oct 7, 2008 at 3:10 PM, Donald Woods [EMAIL PROTECTED] wrote: I believe only the Debug Views and Plan Creator portlets need Dojo right now, which I'm going to remove from the JEE5 assemblies and let users optionally install them, once I've updated the Welcome portlet to include some information about what optional Console plugins are available -Donald Lin Sun wrote: Hi, I don't see dojo-tomcat/jetty6 is used by admin console right now in trunk thus I plan to remove it from the javaee5 assembly. Any objection? Whenever we have converted some of our admin console to use dojo-tomcat/jetty6, dojo-tomcat/jetty6 should be automatically pulled into javaee5 assembly via transitive dependency, similar like dojo-legacy-tomcat/jetty6 today. Lin
Fwd: CFP open for ApacheCon Europe 2009
FYI -- Forwarded message -- From: Noirin Shirley [EMAIL PROTECTED] Date: Thu, Oct 2, 2008 at 4:22 AM Subject: CFP open for ApacheCon Europe 2009 To: [EMAIL PROTECTED] PMCs: Please send this on to your users@ lists! If you only have thirty seconds: The Call for Papers for ApacheCon Europe 2009, to be held in Amsterdam, from 23rd to 27th March, is now open! Submit your proposals at http://eu.apachecon.com/c/aceu2009/cfp/ before 24th October. Remember that early bird prices for ApacheCon US 2008, to be held in New Orleans, from 3rd to 7th November, will go up this Friday, at midnight Eastern time! Sponsorship opportunities for ApacheCon US 2008 and ApacheCon EU 2009 are still available. If you or your company are interested in becoming a sponsor, please contact Delia Frees at [EMAIL PROTECTED] for details. *** If you want all the details: ApacheCon Europe 2009 - Leading the Wave of Open Source Amsterdam, The Netherlands 23rd to 27th March, 2009 Call for Papers Opens for ApacheCon Europe 2009 The Apache Software Foundation (ASF) invites submissions to its official conference, ApacheCon Europe 2009. To be held 23rd to 27th March, 2009 at the Mövenpick Hotel Amsterdam City Centre, ApacheCon serves as a forum for showcasing the ASF's latest developments, including its projects, membership, and community. ApacheCon offers unparalleled educational opportunities, with dedicated presentations, hands-on trainings, and sessions that address core technology, development, business/marketing, and licensing issues in Open Source. ApacheCon's wide range of activities are designed to promote the exchange of ideas amongst ASF Members, innovators, developers, vendors, and users interested in the future of Open Source technology. The conference program includes competitively selected presentations, trainings/workshops, and a small number of invited speakers. All sessions undergo a peer review process by the ApacheCon Conference Planning team. The following information provides presentation category descriptions, and information about how to submit your proposal. Conference Themes and Topics APACHECON 2009 - LEADING THE WAVE OF OPEN SOURCE Building on the success of the last two years, we are excited to return to Amsterdam in 2009. We'll be continuing to offer our very popular two-day trainings, including certifications of completion for those who fulfill all the requirements of these trainings. The ASF comprises some of the most active and recognized developers in the Open Source community. By bringing together the pioneers, developers, and users of flagship Open Source technologies, ApacheCon provides an influential platform for dialogue, between the speaker and the audience, between project contributors and the community at large, traversing a wide range of ideas, expertise, and personalities. ApacheCon welcomes submissions from like-minded delegates across many fields, geographic locations, and areas of development. The breadth and loosely-structured nature of the Apache community lends itself to conference content that is also somewhat loosely-structured. Common themes of interest address groundbreaking technologies and emerging trends, successful practices (from development to deployment), and lessons learned (tips, tools, and tricks). In addition to technical content, ApacheCon invites Business Track submissions that address Open Source business, marketing, and legal/licensing issues. Topics appropriate for submission to this conference are manifold, and may include but are not restricted to: - Apache HTTP server topics such as installation, configuration, and migration - ASF-wide projects such as Lucene, SpamAssassin, Jackrabbit, and Maven - Scripting languages and dynamic content such as Java, Perl, Python, Ruby, XSL, and PHP - Security and e-commerce - Performance tuning, load balancing and high availability - New technologies and broader initiatives such as Web Services and Web 2.0 - ASF-Incubated projects such as Sling, UIMA, and Shindig Submission Guidelines Submissions must include - Title - Speaker name, with affiliation and email address - Speaker bio (100 words or less) - Short description (50 words or less) - Full description including abstract and objectives (200 words or less) - Expertise level (beginner to advanced) - Format and duration (trainings vs. general presentation; half-, full- or two-day workshop, etc.) - Intended audience and maximum number of participants (trainings only) - Background knowledge expected of the participants (trainings only) Types of Presentations - Trainings/Workshops - General Sessions - Case Studies/Industry Profiles - Invited Keynotes/Panels/Speakers - Corporate Showcases Demonstrations BoF sessions and Fast Feather Track talks will be selected separately Pre Conference Trainings/Workshops Held on the first and second day of the conference – 2008-03-23 and 2008-03-24, Trainings require a registration fee beyond the regular
Re: Tuscany Geronimo integration and the SCA JEE spec
On Oct 8, 2008, at 3:02 AM, ant elder wrote: On Fri, Oct 3, 2008 at 2:12 PM, Dan Becker [EMAIL PROTECTED] wrote: ant elder wrote: Currently the old TGP has got out of date and doesn't work with any current releases of Geronimo or Tuscany so the first thing to do is to get a basic plugin going again and then gradually add functionality to it so it does things like: - adds all Tuscany jars and their dependencys into Geronimo - supports existing Tuscany webapps without needing to include any Tuscany jars or dependencys in the lib directory - supports simple jar contributions into a Tuscany standalone node - supports Tuscany using Geronimo infrastructure for things such as HTTP and JMS hosts - supports for SCA enabled JEE application local assembly - supports SCA wiring across JEE applications and modules All excellent goals. Additionally I would like to see how trimmed and lean we can make this platform. Can we make it the smallest footprint, quickest bringup SCA runtime out there? -- Thanks, Dan Becker Sounds good. We could look at using the Geronimo Little-G and Framework distributions to base that on. Right. This is where I'm interested in the Tuscany/Geronimo integration... Once we have a working Tuscany plugin, this type of integration will be nearly automatic... You could install the tuscany plugin and generate a custom assembly. Will also want to add a server assembly stage to the plugin build. So, that a geronimo-tuscany server assembly would be created as part of the tuscany plugin build. Ultimately, I think we'll want to split the Tuscany plugin into multiple parts -- rather than one big plugin -- so that a server can only contain only the functionality that application(s) require. --kevan
Re: Improved EJB integration... can we get some portlets?
Hi David B, All the attributes that you added in the container wrapper gbeans are final. I understand the reason for them being final i.e. the attributes are used only during the creation of the container. Previously all the gbeans had a properties attribute and I used to add the configuration properties to that. I also think that it was not final. Currently without setters and with attributes being final I can no longer edit the gbean attributes. The way i see it we need to add setter methods and also make the attributes non final. Let me know what you think. Previously the portlet would just edit the properties attributes of the gbean and inform the user that a server restart is necessary for the changes to be applied. What do you think is the approach i should take here? I observe that the admin console has a restart functionality which also starts all the dependencies so currently we will need only a restart of the openejb configuration Regards Manu On Fri, Oct 3, 2008 at 3:46 PM, Manu George [EMAIL PROTECTED] wrote: Hi David, What is the accessTimeout attribute of the BmpContainerGBean for? It seems to map to poolSize. You are doing a set(AccessTimeout, Integer.toString(accessTimeout)); but there doesn't seem to be such a property in EntityContainer. Shouldn't this property be poolSize? Regards Manu On Fri, Sep 26, 2008 at 6:14 PM, Manu George [EMAIL PROTECTED] wrote: I will modify that patch to use the changes David has made. Let me know if you have any suggestions on the UI Regards Manu On 9/26/08, Donald Woods [EMAIL PROTECTED] wrote: I can try to check in the patch that's there, but I've never really looked at or used EJBs and really don't have a burning desire to learn it before we get 2.2 released :-) I went ahead a assigned it back to Manu, since he's a committer now and understands the OpenEJB side of things -Donald David Blevins wrote: Wow, the screenshots on that issue look about perfect. Is this something you'd want to hack on? -David On Sep 25, 2008, at 12:00 PM, Donald Woods wrote: Maybe the code provided in https://issues.apache.org/jira/browse/GERONIMO-3811 can be used as a starting point? -Donald David Blevins wrote: So I improved the EJB integration so that there's a gbean for each container type and the exact attributes for each container are strongly typed gbean attributes. Is it possible we can get someone to create a portlet that shows each ejb container in the system and allows people to edit the gbean attributes? Any volunteers? -David
Re: An idea for defining custom valves in config.xml
David, Could you describe to me in a little more detail what you were thinking in regards to defining a new tomcat server in a child classloader? I'm still working on creating an example, but I found some documentation confirming tomcat's use of a TCCL in loading components and would like to continue the discussion. It seems you are proposing that a user create a plugin that defines a new tomcat instance that includes their custom valve. Am I understanding correctly? I've taken a look at the app-per-port sample you described and this does not seem like a trivial task. Thanks, On Mon, Oct 6, 2008 at 3:08 PM, Jason Warner [EMAIL PROTECTED] wrote: On Mon, Oct 6, 2008 at 1:59 PM, David Jencks [EMAIL PROTECTED]wrote: On Oct 6, 2008, at 10:35 AM, Jason Warner wrote: On Mon, Oct 6, 2008 at 11:56 AM, David Jencks [EMAIL PROTECTED]wrote: On Oct 6, 2008, at 7:22 AM, Jason Warner wrote: On Fri, Oct 3, 2008 at 6:55 PM, David Jencks [EMAIL PROTECTED]wrote: On Oct 3, 2008, at 12:51 PM, Jason Warner wrote: Hey all. I'm working on an idea for allowing custom valves to be defined in config.xml. Currently this isn't possible since the tomcat classloader would not contain the custom classes for the valve. I've create a jira for tracking this issue [1] and it contains a few links to workarounds. IMHO, The solution we should be looking for is a way to add classes to a module without having to undeploy, modify the module config, and redeploying. People have suggested stuff like this before. IMO it pretty much goes against the fundamental idea of geronimo of having fairly fixed plugins with only a few knobs to turn to adjust things in config.xml and config-substitutions.properties. Why is changing the classloader contents in config.xml a good idea? What is so hard about redeploying the app if you want to change its classloader significantly? If you want to change a class in the app you have to redeploy it why is this situation different? The specific instance I have in mind for this change is using a custom valve for tomcat, so I think the scope really should be limited to just the tomcat module. I can't think of another instance where this would be useful, so it's probably not necessary or desirable to expand it further. I believe this situation is different because the structure of geronimo is causing a disconnect between the functionality of tomcat and the functionality of tomcat as it is embedded in geronimo. As Don just said in the middle of my typing this, I don't believe we should expect the average user to have to rebuild one of our modules to add something that can be added in a much simpler way within tomcat itself. Could you explain more about the circumstances for this custom valve? Is it intended to be for every app deployed on this tomcat server instance rather than for one particular app? Will it work if it is in a child classloader of the tomcat plugin classloader? When a valve is added to the tomcat valve chain, it becomes part of the request processing pipeline. Every request that is made to that tomcat server instance passes through this valve chain as it's processed regardless of whether the valve will act upon it or not. It's possible that a single web app will be the only app to use the valve, and for that instance it is already possible to define the valve in the context of the web app rather than the tomcat server. We need to be able to define a valve as part of tomcat server instance as well, though, to be consistent with tomcat. Currently we can only define the valves on the per web app basis. I don't think this would work in a child classloader of the tomcat plugin classloader. When we start up the tomcat module now, the currently defined valves are processed and added to the engine. The custom valves would need to be added to the valves already in the tomcat engine to be available in the way described previously. Once the valves were added to the engine (which would be using the tomcat classloader, I believe) the class def not found issues we currently see would pop back up. For this to work, the custom valve classes and the tomcat engine would need to share the same classloader. Could you try this to be sure? I would hope that tomcat would use a TCCL or supplied classloader for loading components rather than something like TomcatEngine.class.getClassLoader() which I believe is what you are suggesting it does. One example of an inconvenient tomcat configuration is the app-per-port sample where we set up a whole additional tomcat server in a child configuration. I think all the server components in that example are also in a standard tomcat server but its a similar situation to what I'm thinking of here in terms of configuring a tomcat server in a child classloader. Sure. It'll take me a bit as I don't actually have any examples prepared yet. At the moment I
[jira] Resolved: (GERONIMO-4318) All the plugins are marked as installable on the install plugins portlet
[ https://issues.apache.org/jira/browse/GERONIMO-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4318. --- Resolution: Fixed See subversion commits. Many thanks to David Jencks for making changes that work for the farm scenario. Currently plugin groups and regular plugins (that are added to the config) are all tracked correctly.There are one minor issue: plugin that doesn't get added to configuration, such as boilerplate and jaxws-tools are marked as installable even if they are already installed. I am not sure the best way to solve this (is there an easy way to detect these type of geronimo plugins? I know for c-m-p it is easy as it just detect if it has plan.xml file). All the plugins are marked as installable on the install plugins portlet Key: GERONIMO-4318 URL: https://issues.apache.org/jira/browse/GERONIMO-4318 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.2 Attachments: G4318.patch All the plugins are marked as installable on the install plugins portlet. We check if a plugin is installable by using pluginInstaller.validatePlugin. If an exception is thrown, then we set the installable to false. The throw of MissingDependencyException in validatePlugin method is commented out during rev 696105. A proposed fix is to throw ConfigurationAlreadyExistsException when validatePlugin fails because of the configuration is already installed. This seems more reasonable and will also get rid of the confusion message of Missing Dependency: XXX when a user attempts to install a plugin that has already been installed using the deploy install-plugin command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637944#action_12637944 ] Kevan Miller commented on GERONIMO-4343: There's a problem with re-starting a server with the plugin installed: Caused by: java.lang.NullPointerException: You have accessed the java:comp jndi context on a thread that has not initialized it at org.apache.geronimo.gjndi.JavaCompContextGBean.getContext(JavaCompContextGBean.java:34) at org.apache.xbean.naming.context.ContextFlyweight.lookup(ContextFlyweight.java:44) at org.apache.xbean.naming.context.ContextFederation.getFederatedBinding(ContextFederation.java:71) at org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(AbstractFederatedContext.java:63) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:135) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:617) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:158) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:603) at javax.naming.InitialContext.lookup(InitialContext.java:351) at org.apache.tuscany.sca.core.work.Jsr237WorkScheduler.init(Jsr237WorkScheduler.java:62) ... 32 more Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: asm.diff, GeronimoServletHost1.diff, GeronimoServletHost2.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 702860
Geronimo Revision: 702860 built with tests included
See the full build-0900.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081008/build-0900.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081008
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 56 seconds
[INFO] Finished at: Wed Oct 08 09:42:43 EDT 2008
[INFO] Final Memory: 379M/1016M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081008/logs-0900-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.framework:geronimo-deploy-jsr88:2.2-SNAPSHOT: checking for
updates from apache.snapshots
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:42.732
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 33 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:09.946)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:29.414)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.292)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:15.889)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:24.396)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:40.285)
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:44.552)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:44.099)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:58.725)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:46.431)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:29.896)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:26.751)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:28.894)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:44.678)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:47.407)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:58.374)
[INFO] enterprise-testsuite/sec-client RUNNING
[INFO] enterprise-testsuite/sec-client SUCCESS (0:00:25.668)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637953#action_12637953 ] ant elder commented on GERONIMO-4343: - That is the problem fixed in the tuscany-core-1.3.jar thats attached to the JIRA. To fix that properly we need to change the plugin to use the latest Tuscany SNAPSHOT jars instead of the 1.3 release jars so we can make fixes in the Tuscany code base for the plugin to pick up Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: asm.diff, GeronimoServletHost1.diff, GeronimoServletHost2.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Continuous TCK Testing
Here's a quick question. Where does AHP come from? On Mon, Oct 6, 2008 at 1:18 PM, Jason Dillon [EMAIL PROTECTED] wrote: Sure np, took me a while to get around to writing it too ;-) --jason On Oct 6, 2008, at 10:24 PM, Jason Warner wrote: Just got around to reading this. Thanks for the brain dump, Jason. No questions as of yet, but I'm sure I'll need a few more reads before I understand it all. On Thu, Oct 2, 2008 at 2:34 PM, Jason Dillon [EMAIL PROTECTED]wrote: On Oct 1, 2008, at 11:20 PM, Jason Warner wrote: Is the GBuild stuff in svn the same as the anthill-based code or is that something different? GBuild seems to have scripts for running tck and that leads me to think they're the same thing, but I see no mention of anthill in the code. The Anthill stuff is completely different than the GBuild stuff. I started out trying to get the TCK automated using GBuild, but decided that the system lacked too many features to perform as I desired, and went ahead with Anthill as it did pretty much everything, though had some stability problems. One of the main reasons why I choose Anthill (AHP, Anthill Pro that is) was its build agent and code repository systems. This allowed me to ensure that each build used exactly the desired artifacts. Another was the configurable workflow, which allowed me to create a custom chain of events to handle running builds on remote agents and control what data gets set to them, what it will collect and what logic to execute once all distributed work has been completed for a particular build. And the kicker which help facilitate bringing it all together was its concept of a build life. At the time I could find *no other* build tool which could meet all of these needs, and so I went with AHP instead of spending months building/testing features in GBuild. While AHP supports configuring a lot of stuff via its web-interface, I found that it was very cumbersome, so I opted to write some glue, which was stored in svn here: https://svn.apache.org/viewvc/geronimo/sandbox/build-support/?pathrev=632245 Its been a while, so I have to refresh my memory on how this stuff actually worked. First let me explain about the code repository (what it calls codestation) and why it was critical to the TCK testing IMO. When we use Maven normally, it pulls data from a set of external repositories, picks up more repositories from the stuff it downloads and quickly we loose control where stuff comes from. After it pulls down all that stuff, it churns though a build and spits out the stuff we care about, normally stuffing them (via mvn install) into the local repository. AHP supports by default tasks to publish artifacts (really just a set of files controlled by an Ant-like include/exclude path) from a build agent into Codestation, as well as tasks to resolve artifacts (ie. download them from Codestation to the local working directory on the build agents system). Each top-level build in AHP gets assigned a new (empty) build life. Artifacts are always published to/resolved from a build life, either that of the current build, or of a dependency build. So what I did was I setup builds for Geronimo Server (the normal server/trunk stuff), which did the normal mvn install thingy, but I always gave it a custom -Dmaven.local.repository which resolved to something inside the working directory for the running build. The build was still online, so it pulled down a bunch of stuff into an empty local repository (so it was a clean build wrt the repository, as well as the source code, which was always fetched for each new build). Once the build had finished, I used the artifact publisher task to push *all* of the stuff in the local repository into Codestation, labled as something like Maven repository artifacts for the current build life. Then I setup another build for Apache Geronimo CTS Server (the porting/branches/* stuff). This build was dependent upon the Maven repository artifacts of the Geronimo Server build, and I configured those artifacts to get installed on the build agents system in the same directory that I configured the CTS Server build to use for its local maven repository. So again the repo started out empty, then got populated with all of the outputs from the normal G build, and then the cts-server build was started. The build of the components and assemblies is normally fairly quick and aside from some stuff in the private tck repo won't download muck more stuff, because it already had most of its dependencies installed via the Codestation dependency resolution. Once the build finished, I published to cts-server assembly artifacts back to Codestation under like CTS Server Assemblies or something. Up until this point its normal builds, but now we have built the G server, then built the CTS server (using the *exact* artifacts from the G server build, even though each might have happened on a
[jira] Commented: (GERONIMO-4226) GShell can not be started in a server assembly which only includes geronimo-boilerplate plugin
[
https://issues.apache.org/jira/browse/GERONIMO-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637972#action_12637972
]
Lin Sun commented on GERONIMO-4226:
---
Also ran into the same error when issuing ./start-server command to start
server using gshell.
I am proposing to make framework the minimal plugin, instead of boilerplate.
GShell can not be started in a server assembly which only includes
geronimo-boilerplate plugin
--
Key: GERONIMO-4226
URL: https://issues.apache.org/jira/browse/GERONIMO-4226
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: dependencies
Affects Versions: 2.1.2, 2.2
Reporter: YunFeng Ma
Assignee: Lin Sun
Priority: Minor
Fix For: 2.2
Assemble a server which only includes geronimo-boilerplate plugin, start gsh
and get the following error:
{noformat}
C:\gshell2-1.0\bingsh
java.io.FileNotFoundException:
C:\gshell2-1.0\repository\org\apache\ant\ant\1.7.0
at
org.codehaus.plexus.classworlds.launcher.Configurator.loadGlob(Configurator.java:484)
at
org.codehaus.plexus.classworlds.launcher.Configurator.loadGlob(Configurator.java:454)
at
org.codehaus.plexus.classworlds.launcher.Configurator.configure(Configurator.java:315)
at
org.codehaus.plexus.classworlds.launcher.Launcher.configure(Launcher.java:131)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:404)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
at
org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Improved EJB integration... can we get some portlets?
On Oct 8, 2008, at 7:42 AM, Manu George wrote: Hi David B, All the attributes that you added in the container wrapper gbeans are final. I understand the reason for them being final i.e. the attributes are used only during the creation of the container. Previously all the gbeans had a properties attribute and I used to add the configuration properties to that. I also think that it was not final. Currently without setters and with attributes being final I can no longer edit the gbean attributes. The way i see it we need to add setter methods and also make the attributes non final. Let me know what you think. Previously the portlet would just edit the properties attributes of the gbean and inform the user that a server restart is necessary for the changes to be applied. What do you think is the approach i should take here? I observe that the admin console has a restart functionality which also starts all the dependencies so currently we will need only a restart of the openejb configuration To me it looks like you are basically proposing a plan editor or config.xml editor for openejb. You can't safely change the actual attribute values at runtime so lets look for a solution that doesn't pretend to be able to. I think you have three possible strategies here: 1. create a plan editor for plans similar to the openejb plugin and use it to generate replacements for the openejb plugin 2. create an editor for specified customizations of config.xml. This might or might not be practical. It's more likely to work if the openejb plugin is stopped when you edit gbean attribute values. 3. put all the things you want to be able to change into config- substitutions as variables and edit those (in the in-memory map accessible through () ArtifactResolver). thanks david jencks Regards Manu On Fri, Oct 3, 2008 at 3:46 PM, Manu George [EMAIL PROTECTED] wrote: Hi David, What is the accessTimeout attribute of the BmpContainerGBean for? It seems to map to poolSize. You are doing a set(AccessTimeout, Integer.toString(accessTimeout)); but there doesn't seem to be such a property in EntityContainer. Shouldn't this property be poolSize? Regards Manu On Fri, Sep 26, 2008 at 6:14 PM, Manu George [EMAIL PROTECTED] wrote: I will modify that patch to use the changes David has made. Let me know if you have any suggestions on the UI Regards Manu On 9/26/08, Donald Woods [EMAIL PROTECTED] wrote: I can try to check in the patch that's there, but I've never really looked at or used EJBs and really don't have a burning desire to learn it before we get 2.2 released :-) I went ahead a assigned it back to Manu, since he's a committer now and understands the OpenEJB side of things -Donald David Blevins wrote: Wow, the screenshots on that issue look about perfect. Is this something you'd want to hack on? -David On Sep 25, 2008, at 12:00 PM, Donald Woods wrote: Maybe the code provided in https://issues.apache.org/jira/browse/GERONIMO-3811 can be used as a starting point? -Donald David Blevins wrote: So I improved the EJB integration so that there's a gbean for each container type and the exact attributes for each container are strongly typed gbean attributes. Is it possible we can get someone to create a portlet that shows each ejb container in the system and allows people to edit the gbean attributes? Any volunteers? -David
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
I'm also getting worried that the plugin groups are starting to duplicate the plugins and wondering if the concept is providing significant value beyond the framework plugin group. Also, I think that the current jms console stuff is unlikely to survive in anything like its current form for activemq 5. The last time I talked with the amq developers they indicated pretty strongly that trying to reconfigure a running broker was not safe and that editing the broker (xbean-spring) plan and restarting was the desired approach. thanks david jencks On Oct 8, 2008, at 6:45 AM, Lin Sun wrote: These are the console plugin groups, basically it provides the required console function for the javaee5 assemblies. I think the list suggested the following profiles a while back ago: JMS EJB Web Services Admin Console ... Also, I need the console plugin group to construct the javaee5 plugin groups/assemblies. Regarding activemq-console-xxx, my initial thought was to include it in the JMS plugin group, but I realize that you are working on the optional console and people may not want the JMS console function when they want JMS function (for example, there is one user trying to add JMS on top of little G). When you have your optional console stuff in, you can remove the optional ones from the console plugin group. Plugin groups are basically groups of plugins for users to easily understand and consume them. They can be used in the following ways: 1. custom server assemblies 2. G server assemblies (framework, javaee5) 3. install plugin group as regular plugin. For example, a user should be able to install the JMS plugin group in little G to get little G + JMS environment. Lin On Tue, Oct 7, 2008 at 11:03 PM, Donald Woods [EMAIL PROTECTED] wrote: Why are we recreating the existing console-jetty and console-tomcat as yet another plugin? Also, why are you including optional console plugins like activemq-console-xxx, which should only be included if the ActiveMQ plugins are installed? By including it here, you're basically pulling in the JMS plugins. I'm starting to reconsider why we need plugingroups, if we're going to have to recreate dozens of existing plugins just in a slightly different format just so we can include them in a special view just for custom server assemblies -Donald [EMAIL PROTECTED] wrote: Author: linsun Date: Tue Oct 7 12:09:59 2008 New Revision: 702586 URL: http://svn.apache.org/viewvc?rev=702586view=rev Log: Add the console-jetty plugin group Added: geronimo/server/trunk/plugingroups/console-jetty/ geronimo/server/trunk/plugingroups/console-jetty/pom.xml (with props) geronimo/server/trunk/plugingroups/console-jetty/src/ geronimo/server/trunk/plugingroups/console-jetty/src/main/ geronimo/server/trunk/plugingroups/console-jetty/src/main/history/ geronimo/server/trunk/plugingroups/console-jetty/src/main/history/ dependencies.xml (with props) geronimo/server/trunk/plugingroups/console-jetty/src/main/plan/ Added: geronimo/server/trunk/plugingroups/console-jetty/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/pom.xml?rev=702586view=auto = = = = = = = = = = --- geronimo/server/trunk/plugingroups/console-jetty/pom.xml (added) +++ geronimo/server/trunk/plugingroups/console-jetty/pom.xml Tue Oct 7 12:09:59 2008 @@ -0,0 +1,98 @@ +?xml version=1.0 encoding=ISO-8859-1? +!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +License); you may not use this file except in compliance +with the License. You may obtain a copy of the License at ++ http://www.apache.org/licenses/LICENSE-2.0 ++Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +-- +!-- @version $Rev$ $Date$ -- + +project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; + +modelVersion4.0.0/modelVersion + +parent +groupIdorg.apache.geronimo.plugingroups/groupId +artifactIdplugingroups/artifactId +version2.2-SNAPSHOT/version +/parent + +artifactIdconsole-jetty/artifactId +packagingcar/packaging +nameGeronimo Plugin Group :: Admin Console Jetty/name + +description +This plugin group provides Admin Console
boilerplate vs. framework as required plugin for custom server assembly
Hi, I have been looking at GERONIMO-4226 today. For a while, we have been recommending users to pick boilerplate as a required plugin when assembling a custom server, in order to get a working server. However, this working server isn't really working, as a user won't be able to start the server using gshell (see G4226). I am proposing to recommend users to pick the framework plugin group (org.apache.geronimo.plugingroups/framework/2.2-SNAPSHOT/car) as the required plugin when assembling a custom server, in order to get a working server.I don't think this is possible with 2.1.x releases as the framework plugin group doesn't exist there. Any issue with that? If no, I'll update our code and user docs. Lin
Re: boilerplate vs. framework as required plugin for custom server assembly
On Oct 8, 2008, at 9:43 AM, Lin Sun wrote: Hi, I have been looking at GERONIMO-4226 today. For a while, we have been recommending users to pick boilerplate as a required plugin when assembling a custom server, in order to get a working server. However, this working server isn't really working, as a user won't be able to start the server using gshell (see G4226). I am proposing to recommend users to pick the framework plugin group (org.apache.geronimo.plugingroups/framework/2.2-SNAPSHOT/car) as the required plugin when assembling a custom server, in order to get a working server.I don't think this is possible with 2.1.x releases as the framework plugin group doesn't exist there. Any issue with that? If no, I'll update our code and user docs. I agree, this was my (IIRC not expressed) intention when originally thinking about the framework plugin group. I think it's used this way in all our assemblies already. thanks for picking this up it fell off my radar. david jencks Lin
[jira] Commented: (GERONIMO-4226) GShell can not be started in a server assembly which only includes geronimo-boilerplate plugin
[
https://issues.apache.org/jira/browse/GERONIMO-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637992#action_12637992
]
Donald Woods commented on GERONIMO-4226:
Sounds good.
GShell can not be started in a server assembly which only includes
geronimo-boilerplate plugin
--
Key: GERONIMO-4226
URL: https://issues.apache.org/jira/browse/GERONIMO-4226
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: dependencies
Affects Versions: 2.1.2, 2.2
Reporter: YunFeng Ma
Assignee: Lin Sun
Priority: Minor
Fix For: 2.2
Assemble a server which only includes geronimo-boilerplate plugin, start gsh
and get the following error:
{noformat}
C:\gshell2-1.0\bingsh
java.io.FileNotFoundException:
C:\gshell2-1.0\repository\org\apache\ant\ant\1.7.0
at
org.codehaus.plexus.classworlds.launcher.Configurator.loadGlob(Configurator.java:484)
at
org.codehaus.plexus.classworlds.launcher.Configurator.loadGlob(Configurator.java:454)
at
org.codehaus.plexus.classworlds.launcher.Configurator.configure(Configurator.java:315)
at
org.codehaus.plexus.classworlds.launcher.Launcher.configure(Launcher.java:131)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:404)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
at
org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: An idea for defining custom valves in config.xml
On Oct 8, 2008, at 7:45 AM, Jason Warner wrote: David, Could you describe to me in a little more detail what you were thinking in regards to defining a new tomcat server in a child classloader? I'm still working on creating an example, but I found some documentation confirming tomcat's use of a TCCL in loading components and would like to continue the discussion. It seems you are proposing that a user create a plugin that defines a new tomcat instance that includes their custom valve. Am I understanding correctly? I've taken a look at the app-per-port sample you described and this does not seem like a trivial task. app-per-port is complicated by the additional features there of: - only one artifact (an ear) instead of 2 or 3 plugins - starting the connectors after the web app has started If neither of these features is needed you can just build a plugin with the tomcat server + custom valve. There are two strategies: 1. replace the tomcat6 plugin 2. use the (stopped) tomcat6 plugin as a parent for the new plugin. In either case I'd build the new plugin with maven and start by copying the tomcat6 plugin and renaming it appropriately. Then modify the plan to include the custom valve. for (1), you'd just add the jar with the custom valve as a pom dependency. Use an artifact-alias so your tomcat plugin will replace the usual tomcat6 plugin. for (2), you'd replace the pom dependencies with a dependency on the tomcat6 plugin, and add the custom valve jar dependency. In the c-m-p configuration you'll want to specify the import on the tomcat^ plugin as classes so it wont get started. An artifact alias won't work here so don't deploy things that depend on tomcat6 as that will result in the tomcat6 plugin starting and having port conflicts with your plugin. Building a custom server including your plugin or installing it on a framework server via gshell is likely to work better than trying to replace the tomcat6 plugin while it's running through the admin console. hope this helps david jencks Thanks, On Mon, Oct 6, 2008 at 3:08 PM, Jason Warner [EMAIL PROTECTED] wrote: On Mon, Oct 6, 2008 at 1:59 PM, David Jencks [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 10:35 AM, Jason Warner wrote: On Mon, Oct 6, 2008 at 11:56 AM, David Jencks [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 7:22 AM, Jason Warner wrote: On Fri, Oct 3, 2008 at 6:55 PM, David Jencks [EMAIL PROTECTED] wrote: On Oct 3, 2008, at 12:51 PM, Jason Warner wrote: Hey all. I'm working on an idea for allowing custom valves to be defined in config.xml. Currently this isn't possible since the tomcat classloader would not contain the custom classes for the valve. I've create a jira for tracking this issue [1] and it contains a few links to workarounds. IMHO, The solution we should be looking for is a way to add classes to a module without having to undeploy, modify the module config, and redeploying. People have suggested stuff like this before. IMO it pretty much goes against the fundamental idea of geronimo of having fairly fixed plugins with only a few knobs to turn to adjust things in config.xml and config-substitutions.properties. Why is changing the classloader contents in config.xml a good idea? What is so hard about redeploying the app if you want to change its classloader significantly? If you want to change a class in the app you have to redeploy it why is this situation different? The specific instance I have in mind for this change is using a custom valve for tomcat, so I think the scope really should be limited to just the tomcat module. I can't think of another instance where this would be useful, so it's probably not necessary or desirable to expand it further. I believe this situation is different because the structure of geronimo is causing a disconnect between the functionality of tomcat and the functionality of tomcat as it is embedded in geronimo. As Don just said in the middle of my typing this, I don't believe we should expect the average user to have to rebuild one of our modules to add something that can be added in a much simpler way within tomcat itself. Could you explain more about the circumstances for this custom valve? Is it intended to be for every app deployed on this tomcat server instance rather than for one particular app? Will it work if it is in a child classloader of the tomcat plugin classloader? When a valve is added to the tomcat valve chain, it becomes part of the request processing pipeline. Every request that is made to that tomcat server instance passes through this valve chain as it's processed regardless of whether the valve will act upon it or not. It's possible that a single web app will be the only app to use the valve, and for that instance it is already possible to define the valve in the context of the web app rather
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
It seems that most of the functionality now delivered in the profilegroups could have been implemented by just properly setting the plugin category attribute to a useful plugin group name and use the source repo for the plugin to denote they are base server plugins vs. Samples vs. a Console plugin from a third-party. For something like the activemq portlets, we'd just set category=Console. Then modifying the plugin installer to build a tree of plugin groups and allow the user to select one or more groups of plugins, like console, or choose specific plugins from within a group, like everything under console except the activemq portlets. (We would also add some logic to only select Tomcat or Jetty plugins based on which is already installed or prompt the user to choose.) That would allow us to have one set of plugins (the real ones) and only have LOGICAL groupings (instead of the physical ones now under plugingroups/) based on the defined category. The user would then see something like - - Apache Geronimo Server repository |--+ Console | |- ActiveMQ Console | |- Dojo | |- . . . | |--+ Web Container | |- Tomcat6 | |- Jetty6 | . . . There are still some cases where we'd want to use the new c-m-p support for not creating a classloader, like using it to generate a minimal web and full jee5 grouping/profile/template that users could rely on for creating their own custom assemblies with c-m-p without having to create a complete assembly build. -Donald Lin Sun wrote: These are the console plugin groups, basically it provides the required console function for the javaee5 assemblies. I think the list suggested the following profiles a while back ago: JMS EJB Web Services Admin Console ... Also, I need the console plugin group to construct the javaee5 plugin groups/assemblies. Regarding activemq-console-xxx, my initial thought was to include it in the JMS plugin group, but I realize that you are working on the optional console and people may not want the JMS console function when they want JMS function (for example, there is one user trying to add JMS on top of little G). When you have your optional console stuff in, you can remove the optional ones from the console plugin group. Plugin groups are basically groups of plugins for users to easily understand and consume them. They can be used in the following ways: 1. custom server assemblies 2. G server assemblies (framework, javaee5) 3. install plugin group as regular plugin. For example, a user should be able to install the JMS plugin group in little G to get little G + JMS environment. Lin On Tue, Oct 7, 2008 at 11:03 PM, Donald Woods [EMAIL PROTECTED] wrote: Why are we recreating the existing console-jetty and console-tomcat as yet another plugin? Also, why are you including optional console plugins like activemq-console-xxx, which should only be included if the ActiveMQ plugins are installed? By including it here, you're basically pulling in the JMS plugins. I'm starting to reconsider why we need plugingroups, if we're going to have to recreate dozens of existing plugins just in a slightly different format just so we can include them in a special view just for custom server assemblies -Donald [EMAIL PROTECTED] wrote: Author: linsun Date: Tue Oct 7 12:09:59 2008 New Revision: 702586 URL: http://svn.apache.org/viewvc?rev=702586view=rev Log: Add the console-jetty plugin group Added: geronimo/server/trunk/plugingroups/console-jetty/ geronimo/server/trunk/plugingroups/console-jetty/pom.xml (with props) geronimo/server/trunk/plugingroups/console-jetty/src/ geronimo/server/trunk/plugingroups/console-jetty/src/main/ geronimo/server/trunk/plugingroups/console-jetty/src/main/history/ geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml (with props) geronimo/server/trunk/plugingroups/console-jetty/src/main/plan/ Added: geronimo/server/trunk/plugingroups/console-jetty/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/pom.xml?rev=702586view=auto == --- geronimo/server/trunk/plugingroups/console-jetty/pom.xml (added) +++ geronimo/server/trunk/plugingroups/console-jetty/pom.xml Tue Oct 7 12:09:59 2008 @@ -0,0 +1,98 @@ +?xml version=1.0 encoding=ISO-8859-1? +!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +License); you may not use this file except in compliance +with the License. You may obtain a copy of the License at ++ http://www.apache.org/licenses/LICENSE-2.0 ++Unless required by applicable law or agreed to in writing, +software distributed under
Re: An idea for defining custom valves in config.xml
I'm not sure if these steps are reasonable from a purely user perspective. When using plain old tomcat, you can download a binary, add your custom valve jar, make a config change and then use your server with its custom valve. To accomplish the same task in geronimo, we are asking the user to download and install maven as well as grab source code for the tomcat plugin. I'd really like to have a way we can accomplish the same goal while allowing the users to maintain a user level of interaction with geronimo. On Wed, Oct 8, 2008 at 1:22 PM, David Jencks [EMAIL PROTECTED] wrote: On Oct 8, 2008, at 7:45 AM, Jason Warner wrote: David, Could you describe to me in a little more detail what you were thinking in regards to defining a new tomcat server in a child classloader? I'm still working on creating an example, but I found some documentation confirming tomcat's use of a TCCL in loading components and would like to continue the discussion. It seems you are proposing that a user create a plugin that defines a new tomcat instance that includes their custom valve. Am I understanding correctly? I've taken a look at the app-per-port sample you described and this does not seem like a trivial task. app-per-port is complicated by the additional features there of: - only one artifact (an ear) instead of 2 or 3 plugins - starting the connectors after the web app has started If neither of these features is needed you can just build a plugin with the tomcat server + custom valve. There are two strategies: 1. replace the tomcat6 plugin 2. use the (stopped) tomcat6 plugin as a parent for the new plugin. In either case I'd build the new plugin with maven and start by copying the tomcat6 plugin and renaming it appropriately. Then modify the plan to include the custom valve. for (1), you'd just add the jar with the custom valve as a pom dependency. Use an artifact-alias so your tomcat plugin will replace the usual tomcat6 plugin. for (2), you'd replace the pom dependencies with a dependency on the tomcat6 plugin, and add the custom valve jar dependency. In the c-m-p configuration you'll want to specify the import on the tomcat^ plugin as classes so it wont get started. An artifact alias won't work here so don't deploy things that depend on tomcat6 as that will result in the tomcat6 plugin starting and having port conflicts with your plugin. Building a custom server including your plugin or installing it on a framework server via gshell is likely to work better than trying to replace the tomcat6 plugin while it's running through the admin console. hope this helps david jencks Thanks, On Mon, Oct 6, 2008 at 3:08 PM, Jason Warner [EMAIL PROTECTED] wrote: On Mon, Oct 6, 2008 at 1:59 PM, David Jencks [EMAIL PROTECTED]wrote: On Oct 6, 2008, at 10:35 AM, Jason Warner wrote: On Mon, Oct 6, 2008 at 11:56 AM, David Jencks [EMAIL PROTECTED]wrote: On Oct 6, 2008, at 7:22 AM, Jason Warner wrote: On Fri, Oct 3, 2008 at 6:55 PM, David Jencks [EMAIL PROTECTED]wrote: On Oct 3, 2008, at 12:51 PM, Jason Warner wrote: Hey all. I'm working on an idea for allowing custom valves to be defined in config.xml. Currently this isn't possible since the tomcat classloader would not contain the custom classes for the valve. I've create a jira for tracking this issue [1] and it contains a few links to workarounds. IMHO, The solution we should be looking for is a way to add classes to a module without having to undeploy, modify the module config, and redeploying. People have suggested stuff like this before. IMO it pretty much goes against the fundamental idea of geronimo of having fairly fixed plugins with only a few knobs to turn to adjust things in config.xml and config-substitutions.properties. Why is changing the classloader contents in config.xml a good idea? What is so hard about redeploying the app if you want to change its classloader significantly? If you want to change a class in the app you have to redeploy it why is this situation different? The specific instance I have in mind for this change is using a custom valve for tomcat, so I think the scope really should be limited to just the tomcat module. I can't think of another instance where this would be useful, so it's probably not necessary or desirable to expand it further. I believe this situation is different because the structure of geronimo is causing a disconnect between the functionality of tomcat and the functionality of tomcat as it is embedded in geronimo. As Don just said in the middle of my typing this, I don't believe we should expect the average user to have to rebuild one of our modules to add something that can be added in a much simpler way within tomcat itself. Could you explain more about the circumstances for this custom valve? Is it intended to be for every app deployed on this tomcat server instance rather than for one particular
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
There is no doubt that framework is useful, but I think most of the other plugin groups are useful too (for example web-jetty, web-tomcat, or the javaee5-jetty, javaee5-tomcat). It is almost impossible to come up those quickly for a new geronimo user. With plugin groups, I can see users pick any of the plugin group(s) and plus their applications from their existing server to build a new working server easily. Some of the plugin groups may sound very simple and small and there doesn't seem to be a need for them, for example the jms or jsf plugin group. But for a new user (keep in mind that you guys are geronimo experts!!), it is not that obvious to them which modules can get them to the jms function. First, they need to understand activemq is the JMS impl in geronimo; Second they need to find out all the modules that are jms/activemq related and figure out which ones they need. By grouping them together, users can get the function with one click or command (specify the plugin group as the plugin to be installed via admin console or command line). Thus I think they add some convenience to the user. I think I am open to remove these type of plugin groups if you guys strongly prefer that. Lin On Wed, Oct 8, 2008 at 12:42 PM, David Jencks [EMAIL PROTECTED] wrote: I'm also getting worried that the plugin groups are starting to duplicate the plugins and wondering if the concept is providing significant value beyond the framework plugin group.
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Thanks for making the suggestions. It is always good to hear feedback and challenge our thinking! :) My initial thought of grouping the plugins together was by category, however I think it has the following limitations - 1. A user can specify his module to any category he likes too, thus it could interfere with the resulting tree. For example, a user has a module that is also categorized as console or development tools or administration. 2. group by category doesn't offer any integration into maven. As you know, we are using plugin groups for all of our G assemblies now. 3. group by category doesn't help with command line install-plugin command. Currently you can install a plugin group by using deploy install-plugin plugingroup id 4. group by category doesn't help with gshell deploy/assemble command. A user is unlikely to have some fancy GUI like tree in a command line env. With plugin groups, you can still group plugins by category. In fact, in the install plugin portlet that we allow users to sort plugins by category, name, etc. I disabled the sort function in assemble server portlet as it needs more work but the plugins are sorted by category right now. I think I agree with you that the console-xxx plugin group are not that useful and I think they can be removed after we make most of the console components optional. Currently, all these console components are under application plugins, and I 'm updating their names, desps, and categories to enable users to select them easily.For example, if a user wants little G tomcat + JMS, he can select web-tomcat, JMS plugin group, and Console: JMS from application plugins if he wants console support for JMS. Lin On Wed, Oct 8, 2008 at 1:48 PM, Donald Woods [EMAIL PROTECTED] wrote: It seems that most of the functionality now delivered in the profilegroups could have been implemented by just properly setting the plugin category attribute to a useful plugin group name and use the source repo for the plugin to denote they are base server plugins vs. Samples vs. a Console plugin from a third-party. For something like the activemq portlets, we'd just set category=Console. Then modifying the plugin installer to build a tree of plugin groups and allow the user to select one or more groups of plugins, like console, or choose specific plugins from within a group, like everything under console except the activemq portlets. (We would also add some logic to only select Tomcat or Jetty plugins based on which is already installed or prompt the user to choose.) That would allow us to have one set of plugins (the real ones) and only have LOGICAL groupings (instead of the physical ones now under plugingroups/) based on the defined category. The user would then see something like - - Apache Geronimo Server repository |--+ Console | |- ActiveMQ Console | |- Dojo | |- . . . | |--+ Web Container | |- Tomcat6 | |- Jetty6 | . . . There are still some cases where we'd want to use the new c-m-p support for not creating a classloader, like using it to generate a minimal web and full jee5 grouping/profile/template that users could rely on for creating their own custom assemblies with c-m-p without having to create a complete assembly build. -Donald Lin Sun wrote: These are the console plugin groups, basically it provides the required console function for the javaee5 assemblies. I think the list suggested the following profiles a while back ago: JMS EJB Web Services Admin Console ... Also, I need the console plugin group to construct the javaee5 plugin groups/assemblies. Regarding activemq-console-xxx, my initial thought was to include it in the JMS plugin group, but I realize that you are working on the optional console and people may not want the JMS console function when they want JMS function (for example, there is one user trying to add JMS on top of little G). When you have your optional console stuff in, you can remove the optional ones from the console plugin group. Plugin groups are basically groups of plugins for users to easily understand and consume them. They can be used in the following ways: 1. custom server assemblies 2. G server assemblies (framework, javaee5) 3. install plugin group as regular plugin. For example, a user should be able to install the JMS plugin group in little G to get little G + JMS environment. Lin On Tue, Oct 7, 2008 at 11:03 PM, Donald Woods [EMAIL PROTECTED] wrote: Why are we recreating the existing console-jetty and console-tomcat as yet another plugin? Also, why are you including optional console plugins like activemq-console-xxx, which should only be included if the ActiveMQ plugins are installed? By including it here, you're basically pulling in the JMS plugins. I'm starting to reconsider why we need plugingroups, if we're going to have to recreate dozens of existing plugins just in a slightly different format just so
[jira] Updated: (GERONIMO-4344) IMAPMessage#updateHeader updates header with wrong value
[ https://issues.apache.org/jira/browse/GERONIMO-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated GERONIMO-4344: -- Attachment: GERONIMO-4344.patch.txt IMAPMessage#updateHeader updates header with wrong value Key: GERONIMO-4344 URL: https://issues.apache.org/jira/browse/GERONIMO-4344 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Andreas Veithen Attachments: GERONIMO-4344.patch.txt IMAPMessage#updateHeader always updates the header with the value of envelope.from instead of the value passed as argument. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4344) IMAPMessage#updateHeader updates header with wrong value
IMAPMessage#updateHeader updates header with wrong value Key: GERONIMO-4344 URL: https://issues.apache.org/jira/browse/GERONIMO-4344 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: mail Reporter: Andreas Veithen Attachments: GERONIMO-4344.patch.txt IMAPMessage#updateHeader always updates the header with the value of envelope.from instead of the value passed as argument. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
In-line. Lin Sun wrote: Thanks for making the suggestions. It is always good to hear feedback and challenge our thinking! :) Yep, I wish we had more than 4 people actively looking/discussing this :-( My initial thought of grouping the plugins together was by category, however I think it has the following limitations - 1. A user can specify his module to any category he likes too, thus it could interfere with the resulting tree. For example, a user has a module that is also categorized as console or development tools or administration. Don't see this as an issue, since we control the default repository-list and what goes into the geronimo-plugins.xml for the server and samples. If a user created their own repo (like Liferay) then their plugins would be listed under the Liferay Repo instead of the Geronimo Server Repo and they could use whatever categories they want. 2. group by category doesn't offer any integration into maven. As you know, we are using plugin groups for all of our G assemblies now. I'm questioning if this maven integration is worth the added source complexity. I'm starting to lean heavily towards No and wondering if we should remove most of the pluginprofiles for 2.2 and only keep - framework, minimal and jee5. Once we get user feedback on what groupings are missing then we can consider adding more. 3. group by category doesn't help with command line install-plugin command. Currently you can install a plugin group by using deploy install-plugin plugingroup id It would have to be enhanced, which it greatly needs IMO. 4. group by category doesn't help with gshell deploy/assemble command. A user is unlikely to have some fancy GUI like tree in a command line env. If a user is trying to assemble from cmdline, then they will suffer and should either write a gsh script, use c-m-p or the console. With plugin groups, you can still group plugins by category. In fact, in the install plugin portlet that we allow users to sort plugins by category, name, etc. I disabled the sort function in assemble server portlet as it needs more work but the plugins are sorted by category right now. I think I agree with you that the console-xxx plugin group are not that useful and I think they can be removed after we make most of the console components optional. Currently, all these console components are under application plugins, and I 'm updating their names, desps, and categories to enable users to select them easily.For example, if a user wants little G tomcat + JMS, he can select web-tomcat, JMS plugin group, and Console: JMS from application plugins if he wants console support for JMS. Lin On Wed, Oct 8, 2008 at 1:48 PM, Donald Woods [EMAIL PROTECTED] wrote: It seems that most of the functionality now delivered in the profilegroups could have been implemented by just properly setting the plugin category attribute to a useful plugin group name and use the source repo for the plugin to denote they are base server plugins vs. Samples vs. a Console plugin from a third-party. For something like the activemq portlets, we'd just set category=Console. Then modifying the plugin installer to build a tree of plugin groups and allow the user to select one or more groups of plugins, like console, or choose specific plugins from within a group, like everything under console except the activemq portlets. (We would also add some logic to only select Tomcat or Jetty plugins based on which is already installed or prompt the user to choose.) That would allow us to have one set of plugins (the real ones) and only have LOGICAL groupings (instead of the physical ones now under plugingroups/) based on the defined category. The user would then see something like - - Apache Geronimo Server repository |--+ Console | |- ActiveMQ Console | |- Dojo | |- . . . | |--+ Web Container | |- Tomcat6 | |- Jetty6 | . . . There are still some cases where we'd want to use the new c-m-p support for not creating a classloader, like using it to generate a minimal web and full jee5 grouping/profile/template that users could rely on for creating their own custom assemblies with c-m-p without having to create a complete assembly build. -Donald Lin Sun wrote: These are the console plugin groups, basically it provides the required console function for the javaee5 assemblies. I think the list suggested the following profiles a while back ago: JMS EJB Web Services Admin Console ... Also, I need the console plugin group to construct the javaee5 plugin groups/assemblies. Regarding activemq-console-xxx, my initial thought was to include it in the JMS plugin group, but I realize that you are working on the optional console and people may not want the JMS console function when they want JMS function (for example, there is one user trying to add JMS on top of little G). When you have your optional console stuff in, you can remove the optional ones from the console plugin
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
I agree that groups of plugins are useful and perhaps necessary from a user perspective to help eliminate the clutter. However, there are several ways to provide for those groups. The way that has thus far been pursued has been creating a new module type (is that what you would call it?) of plugingroup. I had proposed earlier that we just use plugins for this purpose. We can create plugins that do nothing more than aggregate other more granular plugins. We could still keep the attribute of plugin-group around as a qualifier to filter out these special aggregate plugins from among all of the other plugins when necessary (such as when assembling a server or to present the user with a non-expert view of plugin management). When I proposed this earlier I was shot down because of the classloader creation. However, since David included a change to omit the classloader if there is no plan ... then perhaps there is no real inhibitor to this approach now since a plan is not needed for an aggregate plugin. I originally favored this approach because I felt it was the most intuitive approach, ensured that the groupings of plugins could participate in any scenario that a plugin can participate in today, and had the least code/maintenance impacts. I think those benefits still hold with the possible exception of the classloader change and what that may mean when an aggregate plugin is used as a dependency which might require a little more effort to resolve. Joe Lin Sun wrote: There is no doubt that framework is useful, but I think most of the other plugin groups are useful too (for example web-jetty, web-tomcat, or the javaee5-jetty, javaee5-tomcat). It is almost impossible to come up those quickly for a new geronimo user. With plugin groups, I can see users pick any of the plugin group(s) and plus their applications from their existing server to build a new working server easily. Some of the plugin groups may sound very simple and small and there doesn't seem to be a need for them, for example the jms or jsf plugin group. But for a new user (keep in mind that you guys are geronimo experts!!), it is not that obvious to them which modules can get them to the jms function. First, they need to understand activemq is the JMS impl in geronimo; Second they need to find out all the modules that are jms/activemq related and figure out which ones they need. By grouping them together, users can get the function with one click or command (specify the plugin group as the plugin to be installed via admin console or command line). Thus I think they add some convenience to the user. I think I am open to remove these type of plugin groups if you guys strongly prefer that. Lin On Wed, Oct 8, 2008 at 12:42 PM, David Jencks [EMAIL PROTECTED] wrote: I'm also getting worried that the plugin groups are starting to duplicate the plugins and wondering if the concept is providing significant value beyond the framework plugin group.
Re: An idea for defining custom valves in config.xml
Thanks for the explanation, David. I don't disagree with anything you've explained, but I'm not sure you've addressed my concern about the disparity in the effort required to deploy a custom valve on tomcat and on geronimo. Even with the a streamlined process involving a tomcat server portlet and using the tomcat6 plugin as a base, the user still has to become a plugin developer to deploy their valve on geronimo. If that's how it has to be, then I suppose that's how it has to be. I'm just concerned that it could turn off users that might have otherwise lived happily with geronimo. I'm not really sure how widespread the use of custom valves are, though, so maybe it's just a small minority this would even effect. I'd be curious to get some feedback from some other developers and see if they have any thoughts on the matter. Anyone else out there keeping an eye on this thread? On Wed, Oct 8, 2008 at 2:25 PM, David Jencks [EMAIL PROTECTED] wrote: On Oct 8, 2008, at 11:04 AM, Jason Warner wrote: I'm not sure if these steps are reasonable from a purely user perspective. When using plain old tomcat, you can download a binary, add your custom valve jar, make a config change and then use your server with its custom valve. To accomplish the same task in geronimo, we are asking the user to download and install maven as well as grab source code for the tomcat plugin. I'd really like to have a way we can accomplish the same goal while allowing the users to maintain a user level of interaction with geronimo. I think (1) is really a more realistic approach philosophically so I'll only discuss it more. Lets consider the results of the modifications on tomcat and geronimo. In tomcat, the user has modified their server installation and has no built-in record of what they did. If they install another server somewhere else they have to look in their notes or try to remember what they did or ??? to get the same result. In geronimo + maven they have a reproducible and automated way to generate the customization that is suitable for storing in scm, auditing, running through qa, etc etc. Its also possible to fish the plan out of the tomcat6 plugin, modify it a bit, and deploy it using gshell or (if you didn't start it) using the console. I think you could add the geronimo-plugin.xml using the admin console and add the artifact-aias. This on export would result in a reusable plugin. I'm not sure if you could turn around and install the plugin on the server it was generated on to install the artifact alias so on the next startup you'd get the new tomcat plugin. My philosophical objection to adding valves to the existing tomcat config is that you've changed it in a fundamental way so you should have a new, replacement, plugin instead. By this point you can add the extra jar(s) anyway as dependencies. Maybe we could have a tomcat server portlet that would help with generating tomcat server plans with custom valves and connectors and such stuff. I think that right now that is still the hardest part. thanks david jencks On Wed, Oct 8, 2008 at 1:22 PM, David Jencks [EMAIL PROTECTED]wrote: On Oct 8, 2008, at 7:45 AM, Jason Warner wrote: David, Could you describe to me in a little more detail what you were thinking in regards to defining a new tomcat server in a child classloader? I'm still working on creating an example, but I found some documentation confirming tomcat's use of a TCCL in loading components and would like to continue the discussion. It seems you are proposing that a user create a plugin that defines a new tomcat instance that includes their custom valve. Am I understanding correctly? I've taken a look at the app-per-port sample you described and this does not seem like a trivial task. app-per-port is complicated by the additional features there of: - only one artifact (an ear) instead of 2 or 3 plugins - starting the connectors after the web app has started If neither of these features is needed you can just build a plugin with the tomcat server + custom valve. There are two strategies: 1. replace the tomcat6 plugin 2. use the (stopped) tomcat6 plugin as a parent for the new plugin. In either case I'd build the new plugin with maven and start by copying the tomcat6 plugin and renaming it appropriately. Then modify the plan to include the custom valve. for (1), you'd just add the jar with the custom valve as a pom dependency. Use an artifact-alias so your tomcat plugin will replace the usual tomcat6 plugin. for (2), you'd replace the pom dependencies with a dependency on the tomcat6 plugin, and add the custom valve jar dependency. In the c-m-p configuration you'll want to specify the import on the tomcat^ plugin as classes so it wont get started. An artifact alias won't work here so don't deploy things that depend on tomcat6 as that will result in the tomcat6 plugin starting and having port conflicts with your
Re: Continuous TCK Testing
We had some suggestions earlier for some alternate means of implementing this (Hudson, Conitnuum, etc...). Now that we've had Jason Dillon provide an overview of what we had in place before, does anyone have thoughts on what we should go with? I'm thinking we should stick with the AHP based solution. It will need to be updated most likely, but it's been tried and tested and shown to meet our needs. I'm wondering, though, why we stopped using it before. Was there a specific issue we're going to have to deal with again? Thanks, On Wed, Oct 8, 2008 at 12:05 PM, Jason Warner [EMAIL PROTECTED] wrote: Here's a quick question. Where does AHP come from? On Mon, Oct 6, 2008 at 1:18 PM, Jason Dillon [EMAIL PROTECTED]wrote: Sure np, took me a while to get around to writing it too ;-) --jason On Oct 6, 2008, at 10:24 PM, Jason Warner wrote: Just got around to reading this. Thanks for the brain dump, Jason. No questions as of yet, but I'm sure I'll need a few more reads before I understand it all. On Thu, Oct 2, 2008 at 2:34 PM, Jason Dillon [EMAIL PROTECTED]wrote: On Oct 1, 2008, at 11:20 PM, Jason Warner wrote: Is the GBuild stuff in svn the same as the anthill-based code or is that something different? GBuild seems to have scripts for running tck and that leads me to think they're the same thing, but I see no mention of anthill in the code. The Anthill stuff is completely different than the GBuild stuff. I started out trying to get the TCK automated using GBuild, but decided that the system lacked too many features to perform as I desired, and went ahead with Anthill as it did pretty much everything, though had some stability problems. One of the main reasons why I choose Anthill (AHP, Anthill Pro that is) was its build agent and code repository systems. This allowed me to ensure that each build used exactly the desired artifacts. Another was the configurable workflow, which allowed me to create a custom chain of events to handle running builds on remote agents and control what data gets set to them, what it will collect and what logic to execute once all distributed work has been completed for a particular build. And the kicker which help facilitate bringing it all together was its concept of a build life. At the time I could find *no other* build tool which could meet all of these needs, and so I went with AHP instead of spending months building/testing features in GBuild. While AHP supports configuring a lot of stuff via its web-interface, I found that it was very cumbersome, so I opted to write some glue, which was stored in svn here: https://svn.apache.org/viewvc/geronimo/sandbox/build-support/?pathrev=632245 Its been a while, so I have to refresh my memory on how this stuff actually worked. First let me explain about the code repository (what it calls codestation) and why it was critical to the TCK testing IMO. When we use Maven normally, it pulls data from a set of external repositories, picks up more repositories from the stuff it downloads and quickly we loose control where stuff comes from. After it pulls down all that stuff, it churns though a build and spits out the stuff we care about, normally stuffing them (via mvn install) into the local repository. AHP supports by default tasks to publish artifacts (really just a set of files controlled by an Ant-like include/exclude path) from a build agent into Codestation, as well as tasks to resolve artifacts (ie. download them from Codestation to the local working directory on the build agents system). Each top-level build in AHP gets assigned a new (empty) build life. Artifacts are always published to/resolved from a build life, either that of the current build, or of a dependency build. So what I did was I setup builds for Geronimo Server (the normal server/trunk stuff), which did the normal mvn install thingy, but I always gave it a custom -Dmaven.local.repository which resolved to something inside the working directory for the running build. The build was still online, so it pulled down a bunch of stuff into an empty local repository (so it was a clean build wrt the repository, as well as the source code, which was always fetched for each new build). Once the build had finished, I used the artifact publisher task to push *all* of the stuff in the local repository into Codestation, labled as something like Maven repository artifacts for the current build life. Then I setup another build for Apache Geronimo CTS Server (the porting/branches/* stuff). This build was dependent upon the Maven repository artifacts of the Geronimo Server build, and I configured those artifacts to get installed on the build agents system in the same directory that I configured the CTS Server build to use for its local maven repository. So again the repo started out empty, then got populated with all of the outputs from the normal G build, and then the cts-server build
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Donald Woods wrote: In-line. Lin Sun wrote: Thanks for making the suggestions. It is always good to hear feedback and challenge our thinking! :) Yep, I wish we had more than 4 people actively looking/discussing this :-( Ok ... you asked for it ;-) ... Also see my response on the other branch of this thread. My initial thought of grouping the plugins together was by category, however I think it has the following limitations - 1. A user can specify his module to any category he likes too, thus it could interfere with the resulting tree. For example, a user has a module that is also categorized as console or development tools or administration. Don't see this as an issue, since we control the default repository-list and what goes into the geronimo-plugins.xml for the server and samples. If a user created their own repo (like Liferay) then their plugins would be listed under the Liferay Repo instead of the Geronimo Server Repo and they could use whatever categories they want. I see both points here. As Donald mentions, the repository should be in control of the namespace for the categories. However, that only works with an external repository. However, at the moment the assemble a server functions only work with the local, server repository which can include plugins from multiple external repositories. To have the assembly function with correctly to build up a server it will eventually have to let the user choose plugins and plugingroups from multiple external repositories. That should be interesting. 2. group by category doesn't offer any integration into maven. As you know, we are using plugin groups for all of our G assemblies now. I'm questioning if this maven integration is worth the added source complexity. I'm starting to lean heavily towards No and wondering if we should remove most of the pluginprofiles for 2.2 and only keep - framework, minimal and jee5. Once we get user feedback on what groupings are missing then we can consider adding more. I think this can be worth the effort if we keep things simple. Only create plugingroups when they are really necessary and leverage the groups consistently. I personally like the idea of the groups so that a user can incrementally grow function in a new or existing server in logical chunks without having to understand all of the detailed plugins that we generate. 3. group by category doesn't help with command line install-plugin command. Currently you can install a plugin group by using deploy install-plugin plugingroup id It would have to be enhanced, which it greatly needs IMO. 4. group by category doesn't help with gshell deploy/assemble command. A user is unlikely to have some fancy GUI like tree in a command line env. If a user is trying to assemble from cmdline, then they will suffer and should either write a gsh script, use c-m-p or the console. Alternatively, part of the enhancement of the command line could be to allow the user to filter the list of plugins returned by category. With plugin groups, you can still group plugins by category. In fact, in the install plugin portlet that we allow users to sort plugins by category, name, etc. I disabled the sort function in assemble server portlet as it needs more work but the plugins are sorted by category right now. I think I agree with you that the console-xxx plugin group are not that useful and I think they can be removed after we make most of the console components optional. Currently, all these console components are under application plugins, and I 'm updating their names, desps, and categories to enable users to select them easily.For example, if a user wants little G tomcat + JMS, he can select web-tomcat, JMS plugin group, and Console: JMS from application plugins if he wants console support for JMS. I think it would make sense to have several plugingroups (or aggregate plugins) when dealing with the console extensions. One possible pattern would be to create a plugingroup for the core function and then another plugingroup which includes the core function plugingroup and the console extension. For example (PG indicates a plugingroup, P just a plugin): PG - JMS + Console includes: PG - JMS P - JMS console PG - JMS includes: P - the JMS and associated plugins that are necessary. Here a user could choose to include the plugingroup for JMS + Console or just the plugingroup for JMS. Lin On Wed, Oct 8, 2008 at 1:48 PM, Donald Woods [EMAIL PROTECTED] wrote: It seems that most of the functionality now delivered in the profilegroups could have been implemented by just properly setting the plugin category attribute to a useful plugin group name and use the source repo for the plugin to denote they are base server plugins vs. Samples vs. a Console plugin from a third-party. For something like the activemq portlets, we'd just set category=Console. Then
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Hi Joe, I am having trouble to understand the difference between what you propose what has already been done. Basically, IIUC, you propose to use a plugin for plugin group, with the attribute of pluginGroup=true to indicate that is a plugin group. This is exactly what has been done today, as we don't differenriate plugin group any other way other than the attribute of pluginGroup. If I misunderstand you, could you please give a concrete example? P.S. I think you were shot down by David because of the complexity of having plugin groups listed as dependencies on the geronimo specific plans. Lin On Wed, Oct 8, 2008 at 4:10 PM, Joe Bohn [EMAIL PROTECTED] wrote: I agree that groups of plugins are useful and perhaps necessary from a user perspective to help eliminate the clutter. However, there are several ways to provide for those groups. The way that has thus far been pursued has been creating a new module type (is that what you would call it?) of plugingroup. I had proposed earlier that we just use plugins for this purpose. We can create plugins that do nothing more than aggregate other more granular plugins. We could still keep the attribute of plugin-group around as a qualifier to filter out these special aggregate plugins from among all of the other plugins when necessary (such as when assembling a server or to present the user with a non-expert view of plugin management). When I proposed this earlier I was shot down because of the classloader creation. However, since David included a change to omit the classloader if there is no plan ... then perhaps there is no real inhibitor to this approach now since a plan is not needed for an aggregate plugin. I originally favored this approach because I felt it was the most intuitive approach, ensured that the groupings of plugins could participate in any scenario that a plugin can participate in today, and had the least code/maintenance impacts. I think those benefits still hold with the possible exception of the classloader change and what that may mean when an aggregate plugin is used as a dependency which might require a little more effort to resolve. Joe
Re: An idea for defining custom valves in config.xml
Jason Warner wrote: Thanks for the explanation, David. I don't disagree with anything you've explained, but I'm not sure you've addressed my concern about the disparity in the effort required to deploy a custom valve on tomcat and on geronimo. Even with the a streamlined process involving a tomcat server portlet and using the tomcat6 plugin as a base, the user still has to become a plugin developer to deploy their valve on geronimo. If that's how it has to be, then I suppose that's how it has to be. I'm just concerned that it could turn off users that might have otherwise lived happily with geronimo. I'm not really sure how widespread the use of custom valves are, though, so maybe it's just a small minority this would even effect. I'd be curious to get some feedback from some other developers and see if they have any thoughts on the matter. Anyone else out there keeping an eye on this thread? I've been keeping an eye on it and I agree with you Jason that there is a disparity in the work required to add a valve to tomcat versus that required to add a valve to tomcat embedded in Geronimo. I also agree with David that the current Tomcat process does not lend itself to a reproducible configuration. In cases like this I tend to think like a politician and advocate a both/and rather than an either/or. I suspect that some users will want things in Geronimo to be as similar to Tomcat as possible ... and so will want a simple configuration solution. Doing so might convince them to move over to Geronimo and over time they may gain a greater appreciation for a more Geronimo like solution. Others might be coming in with more knowledge of Geronimo and expect something that is more consistent with Geronimo and can be reproduced. Can we give them both what they want? It seems like we could help the Tomcat centric folks with a simple configuration attribute that we can use to extend the classpath. For the more sophisticated Geronimo user we can direct them to rebuild/redeploy the Tomcat module with the additional dependency on the valve jar ... perhaps using c-m-p and then their own custom assembly. Even while providing the first approach we can highly recommend the second approach. It seems to me that the attribute/classpath extension is a simple thing to implement and will provide a high level of value to users that are accustomed to Tomcat. The Tomcat module rebuild/redeploy is just a matter of documentation ... correct? Joe On Wed, Oct 8, 2008 at 2:25 PM, David Jencks [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Oct 8, 2008, at 11:04 AM, Jason Warner wrote: I'm not sure if these steps are reasonable from a purely user perspective. When using plain old tomcat, you can download a binary, add your custom valve jar, make a config change and then use your server with its custom valve. To accomplish the same task in geronimo, we are asking the user to download and install maven as well as grab source code for the tomcat plugin. I'd really like to have a way we can accomplish the same goal while allowing the users to maintain a user level of interaction with geronimo. I think (1) is really a more realistic approach philosophically so I'll only discuss it more. Lets consider the results of the modifications on tomcat and geronimo. In tomcat, the user has modified their server installation and has no built-in record of what they did. If they install another server somewhere else they have to look in their notes or try to remember what they did or ??? to get the same result. In geronimo + maven they have a reproducible and automated way to generate the customization that is suitable for storing in scm, auditing, running through qa, etc etc. Its also possible to fish the plan out of the tomcat6 plugin, modify it a bit, and deploy it using gshell or (if you didn't start it) using the console. I think you could add the geronimo-plugin.xml using the admin console and add the artifact-aias. This on export would result in a reusable plugin. I'm not sure if you could turn around and install the plugin on the server it was generated on to install the artifact alias so on the next startup you'd get the new tomcat plugin. My philosophical objection to adding valves to the existing tomcat config is that you've changed it in a fundamental way so you should have a new, replacement, plugin instead. By this point you can add the extra jar(s) anyway as dependencies. Maybe we could have a tomcat server portlet that would help with generating tomcat server plans with custom valves and connectors and such stuff. I think that right now that is still the hardest part. thanks david jencks On Wed, Oct 8, 2008 at 1:22 PM, David Jencks [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On
[BUILD] trunk: Failed for Revision: 702970
Geronimo Revision: 702970 built with tests included
See the full build-1500.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081008/build-1500.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081008
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 41 minutes 26 seconds
[INFO] Finished at: Wed Oct 08 15:48:42 EDT 2008
[INFO] Final Memory: 380M/1016M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081008/logs-1500-tomcat/test.log
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:41.147
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 33 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:13.367)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:28.970)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.280)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:16.098)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:15.106)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:37.375)
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:45.241)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:43.576)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:59.857)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:44.742)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:30.352)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:27.229)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:29.063)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:40.773)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:46.200)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:52.835)
[INFO] enterprise-testsuite/sec-client RUNNING
[INFO] enterprise-testsuite/sec-client SUCCESS (0:00:25.422)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:49.783)
[INFO] security-testsuite/test-security RUNNING
[INFO] security
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
See in-line below... On Wed, Oct 8, 2008 at 4:37 PM, Joe Bohn [EMAIL PROTECTED] wrote: Thanks for making the suggestions. It is always good to hear feedback and challenge our thinking! :) Yep, I wish we had more than 4 people actively looking/discussing this :-( Ok ... you asked for it ;-) ... Also see my response on the other branch of this thread. We had over 4 people in the past... I am sure :) My initial thought of grouping the plugins together was by category, however I think it has the following limitations - 1. A user can specify his module to any category he likes too, thus it could interfere with the resulting tree. For example, a user has a module that is also categorized as console or development tools or administration. Don't see this as an issue, since we control the default repository-list and what goes into the geronimo-plugins.xml for the server and samples. If a user created their own repo (like Liferay) then their plugins would be listed under the Liferay Repo instead of the Geronimo Server Repo and they could use whatever categories they want. The user can grow the repo-list easily by deploying an app onto the local G server. There isn't a geronimo-plugins.xml for the local geronimo server repo, but the server is capable to build one on the fly. I see both points here. As Donald mentions, the repository should be in control of the namespace for the categories. However, that only works with an external repository. However, at the moment the assemble a server functions only work with the local, server repository which can include plugins from multiple external repositories. To have the assembly function with correctly to build up a server it will eventually have to let the user choose plugins and plugingroups from multiple external repositories. That should be interesting. I agree currently it is local server only, and the prob still exists with local server, as a user can install the plugin onto G server, which will make the user's plugin resides in our local repo. 2. group by category doesn't offer any integration into maven. As you know, we are using plugin groups for all of our G assemblies now. I'm questioning if this maven integration is worth the added source complexity. I'm starting to lean heavily towards No and wondering if we should remove most of the pluginprofiles for 2.2 and only keep - framework, minimal and jee5. Once we get user feedback on what groupings are missing then we can consider adding more. I am missing the added source complexity here. We only added very little code to support plugin group as David reminded me the function is already there. In fact, having functions divided by plugin groups allow me to clean up our long list of little G assemblies javaee5 assemblies (there are lots of unnecessary dependencies) and only use what is really needed (others can be pulled via transitive dependencies). I think we should keep most of them as they are today and revise them upon users' request. The only ones I had debating myself if I should create them are jms, jsf and console. jms and jsf plugin groups each contain only one plugin as the other plugins can be pulled via transitive dependencies. However, that doesn't mean users know which ones to pick easily. About console plugin group, I'd be totally ok removing it when we switch to optional console. I think this can be worth the effort if we keep things simple. Only create plugingroups when they are really necessary and leverage the groups consistently. I personally like the idea of the groups so that a user can incrementally grow function in a new or existing server in logical chunks without having to understand all of the detailed plugins that we generate. Me too. 3. group by category doesn't help with command line install-plugin command. Currently you can install a plugin group by using deploy install-plugin plugingroup id It would have to be enhanced, which it greatly needs IMO. 4. group by category doesn't help with gshell deploy/assemble command. A user is unlikely to have some fancy GUI like tree in a command line env. If a user is trying to assemble from cmdline, then they will suffer and should either write a gsh script, use c-m-p or the console. Alternatively, part of the enhancement of the command line could be to allow the user to filter the list of plugins returned by category. That is possible to enhance, IMO. With plugin groups, you can still group plugins by category. In fact, in the install plugin portlet that we allow users to sort plugins by category, name, etc. I disabled the sort function in assemble server portlet as it needs more work but the plugins are sorted by category right now. I think I agree with you that the console-xxx plugin group are not that useful and I think they can be removed after we make most of the console components optional. Currently, all these
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Here are my current thoughts not that they necessarily mean much. 1. whether plugingroups are in a special svn area (rather than in framework and plugins directly) we need the c-m-p functionality for at least the framework plugingroup. 2. IIUC Joe's idea was to make it so a dependency on a classloader- free plugin turned into dependencies on all its dependencies. I would like to see an extremely convincing and specific use case for this before we consider implementing it. I could easily be wrong but fear this would introduce hard-to-understand complexity with little gain. 3. I have a suspicion that many of the plugingroups will turn out to only have one plugin in them when all the irrelevant stuff is trimmed out and stuff brought in by transitive dependencies is not listed explicitly. If this turns out to be true then having more than the framework plugingroup may not add much usefulness. We'll have to see. 4. As soon as we have numerous plugin groups, we'll have the same problem we do now in that it will be hard to find the plugingroups you want. 5. I think I argued against it in the past but I'm starting to think that perhaps including a list of tags with a plugin and having the select-a-plugin functionality organized by queries on these tags might be worth investigating. You'd pick say ejb and see all the ejb related plugins -- openejb, openejb-builder, openejb-console-jetty/ tomcat, cxf-ejb, etc etc. 6. It might be worth displaying plugin dependencies in the select-a- plugin functionality. thanks david jencks On Oct 8, 2008, at 2:13 PM, Lin Sun wrote: See in-line below... On Wed, Oct 8, 2008 at 4:37 PM, Joe Bohn [EMAIL PROTECTED] wrote: Thanks for making the suggestions. It is always good to hear feedback and challenge our thinking! :) Yep, I wish we had more than 4 people actively looking/discussing this :-( Ok ... you asked for it ;-) ... Also see my response on the other branch of this thread. We had over 4 people in the past... I am sure :) My initial thought of grouping the plugins together was by category, however I think it has the following limitations - 1. A user can specify his module to any category he likes too, thus it could interfere with the resulting tree. For example, a user has a module that is also categorized as console or development tools or administration. Don't see this as an issue, since we control the default repository-list and what goes into the geronimo-plugins.xml for the server and samples. If a user created their own repo (like Liferay) then their plugins would be listed under the Liferay Repo instead of the Geronimo Server Repo and they could use whatever categories they want. The user can grow the repo-list easily by deploying an app onto the local G server. There isn't a geronimo-plugins.xml for the local geronimo server repo, but the server is capable to build one on the fly. I see both points here. As Donald mentions, the repository should be in control of the namespace for the categories. However, that only works with an external repository. However, at the moment the assemble a server functions only work with the local, server repository which can include plugins from multiple external repositories. To have the assembly function with correctly to build up a server it will eventually have to let the user choose plugins and plugingroups from multiple external repositories. That should be interesting. I agree currently it is local server only, and the prob still exists with local server, as a user can install the plugin onto G server, which will make the user's plugin resides in our local repo. 2. group by category doesn't offer any integration into maven. As you know, we are using plugin groups for all of our G assemblies now. I'm questioning if this maven integration is worth the added source complexity. I'm starting to lean heavily towards No and wondering if we should remove most of the pluginprofiles for 2.2 and only keep - framework, minimal and jee5. Once we get user feedback on what groupings are missing then we can consider adding more. I am missing the added source complexity here. We only added very little code to support plugin group as David reminded me the function is already there. In fact, having functions divided by plugin groups allow me to clean up our long list of little G assemblies javaee5 assemblies (there are lots of unnecessary dependencies) and only use what is really needed (others can be pulled via transitive dependencies). I think we should keep most of them as they are today and revise them upon users' request. The only ones I had debating myself if I should create them are jms, jsf and console. jms and jsf plugin groups each contain only one plugin as the other plugins can be pulled via transitive dependencies. However, that doesn't mean users know which ones to pick
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Lin Sun wrote: Hi Joe, I am having trouble to understand the difference between what you propose what has already been done. Basically, IIUC, you propose to use a plugin for plugin group, with the attribute of pluginGroup=true to indicate that is a plugin group. This is exactly what has been done today, as we don't differenriate plugin group any other way other than the attribute of pluginGroup. If I misunderstand you, could you please give a concrete example? Sorry ... it had been a while since I last looked at this. I was erroneously thinking that there were still fundamental differences between plugins and plugingroups (such as when plugingroups were jars rather than cars and as a result weren't included in the plugin catalog) ... but these differences have been eliminated. The only significant difference now is the lack of a classloader (which is really controlled by the lack of the plan rather than the presence of the plugingroup attribute) and potential dependency issue when a classloader isn't present. P.S. I think you were shot down by David because of the complexity of having plugin groups listed as dependencies on the geronimo specific plans. Lin On Wed, Oct 8, 2008 at 4:10 PM, Joe Bohn [EMAIL PROTECTED] wrote: I agree that groups of plugins are useful and perhaps necessary from a user perspective to help eliminate the clutter. However, there are several ways to provide for those groups. The way that has thus far been pursued has been creating a new module type (is that what you would call it?) of plugingroup. I had proposed earlier that we just use plugins for this purpose. We can create plugins that do nothing more than aggregate other more granular plugins. We could still keep the attribute of plugin-group around as a qualifier to filter out these special aggregate plugins from among all of the other plugins when necessary (such as when assembling a server or to present the user with a non-expert view of plugin management). When I proposed this earlier I was shot down because of the classloader creation. However, since David included a change to omit the classloader if there is no plan ... then perhaps there is no real inhibitor to this approach now since a plan is not needed for an aggregate plugin. I originally favored this approach because I felt it was the most intuitive approach, ensured that the groupings of plugins could participate in any scenario that a plugin can participate in today, and had the least code/maintenance impacts. I think those benefits still hold with the possible exception of the classloader change and what that may mean when an aggregate plugin is used as a dependency which might require a little more effort to resolve. Joe
[BUILD] trunk: Failed for Revision: 703040
Geronimo Revision: 703040 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081008/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081008
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 27 seconds
[INFO] Finished at: Wed Oct 08 21:42:26 EDT 2008
[INFO] Final Memory: 380M/1016M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081008/logs-2100-tomcat/test.log
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:40.507
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 33 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:09.453)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:30.258)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.140)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:16.283)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:14.816)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:36.472)
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:43.527)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:46.281)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:55.261)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:43.565)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:29.888)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:33.212)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:28.635)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:42.572)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:47.045)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:52.218)
[INFO] enterprise-testsuite/sec-client RUNNING
[INFO] enterprise-testsuite/sec-client SUCCESS (0:00:25.264)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.219)
[INFO] security-testsuite/test-security RUNNING
[INFO] security
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
See in line below. On Wed, Oct 8, 2008 at 6:41 PM, David Jencks [EMAIL PROTECTED] wrote: Here are my current thoughts not that they necessarily mean much. 1. whether plugingroups are in a special svn area (rather than in framework and plugins directly) we need the c-m-p functionality for at least the framework plugingroup. I agree. I think it is also agreed (from Donald and me) that besides framework, web-tomcat, web-jetty and javaee5-tomcat and javaee5-jetty are very useful. That leaves us to the few other plugin groups - clustering-tomcat/jetty ejb webservices-axis2/cxf persistence client jms jsf console-tomcat/jetty (to be removed when optional console is in place) And I don't have any intention to create any other plugin groups. I have trimmed all the irrelevant stuff out and tried to bring stuff in by transitive dependencies as much as possible.Out of these plugins, only jms and jsf contain one plugin and I did question creating them as plugin groups myself when I created them. 3. I have a suspicion that many of the plugingroups will turn out to only have one plugin in them when all the irrelevant stuff is trimmed out and stuff brought in by transitive dependencies is not listed explicitly. If this turns out to be true then having more than the framework plugingroup may not add much usefulness. We'll have to see. 4. As soon as we have numerous plugin groups, we'll have the same problem we do now in that it will be hard to find the plugingroups you want. I don't plan to add any more plugin groups. 5. I think I argued against it in the past but I'm starting to think that perhaps including a list of tags with a plugin and having the select-a-plugin functionality organized by queries on these tags might be worth investigating. You'd pick say ejb and see all the ejb related plugins -- openejb, openejb-builder, openejb-console-jetty/tomcat, cxf-ejb, etc etc. I think this is similar as what Joe has been proposed, a filter function to allow you to see a subset of plugins (for example, tag stuff via categories). I agree this is worthy investigating and I can see both admin console and command tool benefit this. I'll take this as a TODO. 6. It might be worth displaying plugin dependencies in the select-a-plugin functionality. I think this is already there today in server assembly portlet. If you select a plugin to see the detail, you will get to see all its dependencies, along with name, desp, category, license. I use this a lot to figure out which plugins I can trim in a plugin group.Or are you suggesting something different? thanks david jencks
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
NP - comments are always welcomed! :) I agree with the difference you mentioned below and I think those are unresolved and no one is really working on it. Lin On Wed, Oct 8, 2008 at 10:19 PM, Joe Bohn [EMAIL PROTECTED] wrote: Lin Sun wrote: Sorry ... it had been a while since I last looked at this. I was erroneously thinking that there were still fundamental differences between plugins and plugingroups (such as when plugingroups were jars rather than cars and as a result weren't included in the plugin catalog) ... but these differences have been eliminated. The only significant difference now is the lack of a classloader (which is really controlled by the lack of the plan rather than the presence of the plugingroup attribute) and potential dependency issue when a classloader isn't present.
Re: Continuous TCK Testing
On Oct 8, 2008, at 4:31 PM, Jason Warner wrote: We had some suggestions earlier for some alternate means of implementing this (Hudson, Conitnuum, etc...). Now that we've had Jason Dillon provide an overview of what we had in place before, does anyone have thoughts on what we should go with? I'm thinking we should stick with the AHP based solution. It will need to be updated most likely, but it's been tried and tested and shown to meet our needs. I'm wondering, though, why we stopped using it before. Was there a specific issue we're going to have to deal with again? IIRC, the overwhelming reason we stopped using it before was because of hosting issues -- spotty networking, hardware failures, poor colo support, etc. We shouldn't have any of these problems, now. If we do run into problems, they should now be fixable. I have no reason to favor Hudson/Continuum over AHP. So, if we can get AHP running easily, I'm all for it. There's only one potential issue, that I'm aware of. We previously had an Open Source License issued for our use of Anthill. Here's some of the old discussion -- http://www.nabble.com/Geronimo-build-automation-status-(longish)-tt7649902.html#a7649902 Although the board was aware of our usage of AntHill, since we weren't running AntHill on ASF hardware, I'm not sure the license was fully vetted by Infra. I don't see any issues, but I'll want to run this by Infra. Jason D, will the existing license cover the version of AntHill that we'll want to use? I'll run the license by Infra and will also describe the issue for review by the Board, in our quarterly report. IMO, I'd proceed with the assumption that we'll be using AHP. Just don't install it on Apache hardware, yet. --kevan
