Re: rfc66 update
It's really great news! But I have some questions about current implementation.Just want to learn more from it. 1) I found only active and starting bundles are taken into account in current implementation. What about resolved bundles? 2) For lazy activiated bundles, only starting bundles will be deployed.But in RFC 66, it said A bundle that has a lazy activation policy should not be transitioned to the STARTING state by the web extender unless a request is made that requires a class to be loaded. Does the implementation violate the document? 3) In RFC 66, static content can be requested without starting a WAB. It's not in the TODO file. Do you have any idea for it? I'm not sure if configuration of WAB can become accessible before actually it's started. Thanks! 2010/1/24 David Jencks david_jen...@yahoo.com great news! congratulations! david jencks On Jan 23, 2010, at 6:55 PM, Jarek Gawor wrote: Hi all, Today I checked in an initial version of the rfc66 extender that can actually deploy WABs with simple servlets and jsps. There is still much work to be done (for example updating the Jasper module builder to work with Bundles) but simple stuff seems to be working. In fact with David's recent JNDI (rfc142) integration work I was able to deploy the Aries blog sample in Geronimo. Here are the steps I took to run the sample: 1) Build latest blog sample in Aries 2) Build latest Geronimo trunk 3) cd plugins/wab/web-tomcat-server/target/assembly (or web-jetty-server if you prefer) 4) Create database for blog sample using blogDB.sql from blog sample: java -cp repository/org/apache/geronimo/bundles/derby-all/10.4.2.0-SNAPSHOT/derby-all-10.4.2.0-SNAPSHOT.jar org.apache.derby.tools.ij aries/samples/blog-sample/blog-assembly/target/blogDB.sql 5) Move created blogDB directory to plugins/wab/web-tomcat-server/target/assembly/var/derby 6) Start server: ./bin/geronimo -l 7) Install and start all the blog sample bundles (blog-api-1.0.0.jar, blog-persistence-1.0.0.jar, blog-1.0.0.jar, blog-servlet-1.0.0.jar) using the karaf console. 8) Once you start the blog-servlet-1.0.0.jar bundle, the WAB will be deployed and you should be able to access http://localhost:8080/blog. And if everything is running right you should be able to add new blog entries, etc. Enjoy, Jarek -- Best Regards, Delos
[VOTE]- Geronimo Samples 2.2
Hi All, Forrest and I work together and prepared a release candidate of Geronimo Samples 2.2 for your review and vote. This is the second independent release of samples for Geronimo. Besides some bug fixes, in this release, there are two new samples added: 1. DataCDInfo -- demo a popular web application framework Struts1 in geronimo. User can use it as a struts1 app template to start their own development. In the same time, it also demos how to use JPA with a JTA underlying. Compared with daytrader, this sample is simpler to understand; Of cause, this sample also includes some code to demo security annotations usage. 2. csa-activemq -- demo how to use car-maven-plugin to build a custom server assembly. This sample assembles geronimo integrated ActiveMQ modules(including the new geronimo plugin activemq-webconsole), so that user can use it as standalone JMS server with user-friendly web interfaces to manage JMS objects. We did some testing on the built artifacts and everything seems well. For most of samples, they can be installed on either Geronimo 2.2 or Geronimo 2.1.4. All of the samples are available for installation as plugins on Geronimo 2.2. We have created a plugin catalog for your convenience. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-060/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-2.2/ Repository for plugin install: http://geronimo.apache.org/plugins/samples-2.2/ When the release vote is approved, the maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. Vote will be open for 72 hours until Jan. 27, 2010. [ ] +1 Release Geronimo Samples 2.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo Samples 2.2 (please provide rationale) Thanks very much for Forrest's great work! -- Best Regards, Delos
[VOTE]- Geronimo Eclipse Plugins 2.2 - RC3 (3rd try)
Hi everyone, Please review and vote on the release of the Geronimo Eclipse Plugin 2.2 * RC3*. Compared to RC2, RC3 contains source code packages, checksum and signature files for you to review. You can verify the integrity of the files with KEYS from http://www.apache.org/dist/geronimo/KEYS The source code packages are here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2-source-release.tar.gz http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2-source-release.zip The deployable binary zip file is here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2.0-deployable.zip The update site binary zip file is here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2.0-updatesite.zip The current svn location is here (revision number 897748): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.2 The future svn location will be here (when approved): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.2 If you would like to review and/or comment on the release notes, they are here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/PLUGIN_RELEASE-NOTES-2.2.0.txt There is a rudimentary set of install instructions available at the URL below that will hopefully describe the necessary prereq(s) and steps required to install and run the GEP: http://cwiki.apache.org/GMOxDOC22/how-to-install-geronimo-eclipse-plugin.html In an effort to get more people to review and vote I'd recommend going through this quick but useful tutorial demonstrating some of the capabilities of the GEP: http://cwiki.apache.org/GMOxDOC22/5-minute-tutorial-on-enterprise-application-development-with-eclipse-and-geronimo.html Finally, I've created a Staging Site that can be used to test the update manager functions (i.e., p2 in Ganymede or Galileo) of Eclipse for downloading the GEP itself. This is also documented in the instructions, but you must use the staging site created for this vote at: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/updates/ Please let me know if there are any questions and/or problems. The vote is open for 72 hours. [ ] +1 Release Geronimo Eclipse Plugin 2.2 [ ] +0 No opinion [ ] -1 Don't release Geronimo Eclipse Plugin 2.2 Thanks in advance! -- Best Regards, Delos
Re: rfc66 update
On 1/25/2010 8:06 AM, Delos wrote: It's really great news! But I have some questions about current implementation.Just want to learn more from it. 1) I found only active and starting bundles are taken into account in current implementation. What about resolved bundles? That's the requirement of the RFC66 specification. Resolution is a requirement for a bundle to transition to the active or starting states, but the extender is not supposed to take action until one of those states is seen. It's the same way with Blueprint. 2) For lazy activiated bundles, only starting bundles will be deployed.But in RFC 66, it said A bundle that has a lazy activation policy should not be transitioned to the STARTING state by the web extender unless a request is made that requires a class to be loaded. Does the implementation violate the document? This is a statement that the extender should not explicitly force the bundle into a started state, but rather should leave that transition to one triggered by a class load. If the processing the extender needs to perform in processing the bundle results in a triggering class load, that's ok. 3) In RFC 66, static content can be requested without starting a WAB. It's not in the TODO file. Do you have any idea for it? I'm not sure if configuration of WAB can become accessible before actually it's started. The note about static content is marked as an optional feature. For a lot of processing, it would not be possible to achieve deployment without performing a classload. Thanks! 2010/1/24 David Jencks david_jen...@yahoo.com mailto:david_jen...@yahoo.com great news! congratulations! david jencks On Jan 23, 2010, at 6:55 PM, Jarek Gawor wrote: Hi all, Today I checked in an initial version of the rfc66 extender that can actually deploy WABs with simple servlets and jsps. There is still much work to be done (for example updating the Jasper module builder to work with Bundles) but simple stuff seems to be working. In fact with David's recent JNDI (rfc142) integration work I was able to deploy the Aries blog sample in Geronimo. Here are the steps I took to run the sample: 1) Build latest blog sample in Aries 2) Build latest Geronimo trunk 3) cd plugins/wab/web-tomcat-server/target/assembly (or web-jetty-server if you prefer) 4) Create database for blog sample using blogDB.sql from blog sample: java -cp repository/org/apache/geronimo/bundles/derby-all/10.4.2.0-SNAPSHOT/derby-all-10.4.2.0-SNAPSHOT.jar org.apache.derby.tools.ij aries/samples/blog-sample/blog-assembly/target/blogDB.sql 5) Move created blogDB directory to plugins/wab/web-tomcat-server/target/assembly/var/derby 6) Start server: ./bin/geronimo -l 7) Install and start all the blog sample bundles (blog-api-1.0.0.jar, blog-persistence-1.0.0.jar, blog-1.0.0.jar, blog-servlet-1.0.0.jar) using the karaf console. 8) Once you start the blog-servlet-1.0.0.jar bundle, the WAB will be deployed and you should be able to access http://localhost:8080/blog. And if everything is running right you should be able to add new blog entries, etc. Enjoy, Jarek -- Best Regards, Delos
[jira] Commented: (GERONIMO-5040) PermGenSpace Problems and shut-down issues when using the Apache Commons Daemon under Windows
[ https://issues.apache.org/jira/browse/GERONIMO-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12804545#action_12804545 ] Jack Cai commented on GERONIMO-5040: If I rememer correctly, the reason that I didn't use the java mode is because there is a defect in Apache Commons Daemon to detect the java.exe location in some cases. See https://issues.apache.org/jira/browse/DAEMON-112. So to minimize the code difference between the geronimo version and the commons version, I falled back to use the exe mode, which should work. You can add the parameters to set the permgenspace if you want. For the missing timeout setting, I didn't find that geronimo is killed before it stops gracefully. Maybe there are two few apps on my server. Anyway, we are expecting that Apache Commons Daemon would do a new release which shall include all the pending patches. So hopefully after that we can update the batch file to use the Java mode. PermGenSpace Problems and shut-down issues when using the Apache Commons Daemon under Windows --- Key: GERONIMO-5040 URL: https://issues.apache.org/jira/browse/GERONIMO-5040 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1.4, 2.2 Reporter: Johannes Weberhofer Attachments: GERONIMO-5040-service_pr.bat.diff Geronimo should - in my optinion - be started in Java-Mode. In Java (and the currently used exe-Mode) it is necessary to add all important options directly into the startup-arguments fields before the -jar line, which should be noticed in the Wiki. The issue is related to DAEMON-119. At the shutdown page, it is necessary to explicitly select the Java-Mode and set a timeout (30 seconds or so); otherwise the geronimo server will simply be killed without any chance to terminate gracefully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5040) PermGenSpace Problems and shut-down issues when using the Apache Commons Daemon under Windows
[ https://issues.apache.org/jira/browse/GERONIMO-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12804553#action_12804553 ] Johannes Weberhofer commented on GERONIMO-5040: --- I had the impression, there is no much movement on Apache Commons Daemon. Do you think, they will release a new version? PermGenSpace Problems and shut-down issues when using the Apache Commons Daemon under Windows --- Key: GERONIMO-5040 URL: https://issues.apache.org/jira/browse/GERONIMO-5040 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1.4, 2.2 Reporter: Johannes Weberhofer Attachments: GERONIMO-5040-service_pr.bat.diff Geronimo should - in my optinion - be started in Java-Mode. In Java (and the currently used exe-Mode) it is necessary to add all important options directly into the startup-arguments fields before the -jar line, which should be noticed in the Wiki. The issue is related to DAEMON-119. At the shutdown page, it is necessary to explicitly select the Java-Mode and set a timeout (30 seconds or so); otherwise the geronimo server will simply be killed without any chance to terminate gracefully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
How to handle the Web Profile subset
We should be putting some thought on what the Geronimo deliverables are in the web profile world. I think for the most part, this should be just a different assembly that assembles a smaller set of components. The one additional configuration that is probably going to be needed is an EJB Lite configuration that would be used by the Web Profile assembly. This should not be a big delta over what we have, but it does increase the number of assemblies that we end up releasing. Are there other options we should be working at? Rick
[jira] Created: (GERONIMO-5047) Create javaee5 Tomcat assemblies and plugin groups.
Create javaee5 Tomcat assemblies and plugin groups. Key: GERONIMO-5047 URL: https://issues.apache.org/jira/browse/GERONIMO-5047 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: Tomcat Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 javaee6 versions of the assemblies and plugin groups have been created for jetty in trunk, but the similar changes have not been made for Tomcat. I suspect this ends up just being a series of renames, since we're already building with Tomcat 7 versions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5048) Create an EJB Lite plugin for 3.0 Web Profile usage.
Create an EJB Lite plugin for 3.0 Web Profile usage. - Key: GERONIMO-5048 URL: https://issues.apache.org/jira/browse/GERONIMO-5048 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 Currently, the Geronimo OpenEJB plugin is an all or nothing configuration that brings in all of OpenEJB. There should also be a plugin that only pulls in the features required for the Java EE6 web profile. It might also be nice if additional EJB features could be added to the profile via custom assemblies, but that might require a larger refactoring of the openejb plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-601) Module config Id not found for undeployment
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Kirby updated GERONIMODEVTOOLS-601: --- Attachment: GetnStarted3AG.tar.gz :-( Thanks for trying. Here is my latest project. Can you try it? I am changing jsp and java classes, not geronimo-web.xml or web.xml. If you don't see problem on this latest project version, then I guess it's just my environment. :-( I'll have to see if I can get further info. Thanks. Module config Id not found for undeployment --- Key: GERONIMODEVTOOLS-601 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-601 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: MacOS eclipse, Galileo SR1, Eclipse Java EE IDE for Web Developers, Build id: 20090902-1017 I am running in a Mac with this java: java -version java version 1.6.0_17 Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-9M3125) Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode) Reporter: Ted Kirby Assignee: Delos Dai Priority: Minor Attachments: GetnStarted3AG.tar.gz, GetnStarted3AG.zip I have created a dynamic web project and it seems to work fine. I can deploy and use the war file, and it gets republished if I change source. However, on every deploy/republish, I get this error in eclipse: Module config Id not found for undeployment java.lang.NullPointerException at org.apache.geronimo.st.core.jaxb.JAXBUtils.unmarshalFilterDeploymentPlan(JAXBUtils.java:126) at org.apache.geronimo.st.v21.core.GeronimoV21Utils.getWebDeploymentPlan(GeronimoV21Utils.java:236) at org.apache.geronimo.st.v21.core.GeronimoV21Utils.getWebDeploymentPlan(GeronimoV21Utils.java:199) at org.apache.geronimo.st.v21.core.GeronimoV21Utils.getWebDeploymentPlan(GeronimoV21Utils.java:179) at org.apache.geronimo.st.v21.core.GeronimoV21Utils.getConfigId(GeronimoV21Utils.java:119) at org.apache.geronimo.st.v21.core.GeronimoV21VersionHandler.getConfigID(GeronimoV21VersionHandler.java:36) at org.apache.geronimo.st.core.commands.UndeployCommand.execute(UndeployCommand.java:53) at org.apache.geronimo.st.core.commands.SynchronizedDeploymentOp.run(SynchronizedDeploymentOp.java:84) at org.apache.geronimo.st.core.commands.SynchronizedDeploymentOp.execute(SynchronizedDeploymentOp.java:76) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.unDeploy(GeronimoServerBehaviourDelegate.java:740) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.doRemoved(GeronimoServerBehaviourDelegate.java:666) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.invokeCommand(GeronimoServerBehaviourDelegate.java:451) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.publishModule(GeronimoServerBehaviourDelegate.java:318) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:948) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.publishModules(GeronimoServerBehaviourDelegate.java:273) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:872) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:708) at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:2690) at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:272) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) If I export the project as a war file, and deploy it to geronimo, I don't get the error, so I suspect it's a GEP problem. Here is my geronimo-web.xml file: ?xml version=1.0 encoding=UTF-8? web:web-app xmlns:app=http://geronimo.apache.org/xml/ns/j2ee/application-2.0; xmlns:client=http://geronimo.apache.org/xml/ns/j2ee/application-client-2.0; xmlns:conn=http://geronimo.apache.org/xml/ns/j2ee/connector-1.2; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:ejb=http://openejb.apache.org/xml/ns/openejb-jar-2.2; xmlns:log=http://geronimo.apache.org/xml/ns/loginconfig-2.0; xmlns:name=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:pers=http://java.sun.com/xml/ns/persistence; xmlns:pkgen=http://openejb.apache.org/xml/ns/pkgen-2.1; xmlns:sec=http://geronimo.apache.org/xml/ns/security-2.0; xmlns:web=http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1; dep:environment dep:moduleId dep:groupIdcom.ibm.websphere.xs.sample/dep:groupId dep:artifactIdGettnStarted3/dep:artifactId dep:version1.0/dep:version dep:typejar/dep:type
[jira] Resolved: (GERONIMO-5018) Remove -EA- versioning from the JEE6 spec versions.
[ https://issues.apache.org/jira/browse/GERONIMO-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved GERONIMO-5018. Resolution: Fixed Remove -EA- versioning from the JEE6 spec versions. Key: GERONIMO-5018 URL: https://issues.apache.org/jira/browse/GERONIMO-5018 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: specs Affects Versions: 3.0 Reporter: Rick McGuire Assignee: Rick McGuire Fix For: 3.0 Now that the JEE6 specs have gone final, the -EA- version identifiers used in the early spec versions should be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Web Annotation and web fragment support in Geronimo 3.0
Hi, Recently, I am looking at the annoation and web fragment in Servlet 3.0. After checking some integration codes, it seems that we have different strategy for Tomcat and Jetty, in Tomcat plugin, after doing some verification and web service process work, Geronimo will pass the web.xml file directly to Tomcat, and then Tomcat will parse the web.xml file and call the addChild method to register all the servlets to context. While in Jetty plugin, all the work is done in Servlet GBean and Jetty will not check the web.xml file (At least for servlet configurations). So in Geronimo 3.0, who will be resposible for the annotation and web fragment scanning. For Tomcat, one way is still to let Tomcat does it, actually I found some related codes are added in ContextConfig class. Although I found some errors while trying it, it should be easy to solve. Another way is to scan by Geronimo, then create a gbean for each servlet like Jetty, or just generate a full web.xml file. Personally, I wish to do it by Geronimo, so that Geronimo could have a full control of it, which keeps the same way with Jetty. Also, I have another idea about improving the class scanning, IIRC, many builders require annoation scanning or file scanning, like web-builder, webservice-builder, etc. I am thinking that whether we could do all the scanning work in one round, not a new round search would be triggered by each builder. Maybe, we could add some methods like registerScanningHandler in the DeploymentContext, and once the temp bundle is installed, all the scanning work be will done in one round. Any comment ? Thanks ! Ivan
[jira] Created: (GERONIMO-5049) Add bean validation (JSR 302) to Geronimo 3.0
Add bean validation (JSR 302) to Geronimo 3.0 - Key: GERONIMO-5049 URL: https://issues.apache.org/jira/browse/GERONIMO-5049 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5050) Integrate OpenWebBeans into Geronimo 3.0.
Integrate OpenWebBeans into Geronimo 3.0. -- Key: GERONIMO-5050 URL: https://issues.apache.org/jira/browse/GERONIMO-5050 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 A JSR 299 and 330 implementation is required for Java EE6 and the Java EE 6 web profile. OpenWebBeans is the most feasible candidate for providing these features. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-5014) JSR-303 api needs to update the ElementDescriptor section to fit the latest spec
[ https://issues.apache.org/jira/browse/GERONIMO-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reopened GERONIMO-5014: Assignee: Donald Woods (was: Kevan Miller) These API changes were not in the original validation 1.0.0-ga release of the apis, so I'm going to back it out of our 1.0 release for now. The changes were checked into the unreleased 1.0.1-SNAPSHOT version of the RI API using BVAL-196 on 20100104. JSR-303 api needs to update the ElementDescriptor section to fit the latest spec Key: GERONIMO-5014 URL: https://issues.apache.org/jira/browse/GERONIMO-5014 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Reporter: Mark Struberg Assignee: Donald Woods Attachments: GERONIMO-5014.patch there have been a few changes in the spec. I made all changes to make agimatec-validator (which currently uses the RI) compile against our spec api. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-5014) JSR-303 api needs to update the ElementDescriptor section to fit the latest spec
[ https://issues.apache.org/jira/browse/GERONIMO-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMO-5014. Resolution: Fixed reapplied patch, as it was needed inorder to pass the TCK JSR-303 api needs to update the ElementDescriptor section to fit the latest spec Key: GERONIMO-5014 URL: https://issues.apache.org/jira/browse/GERONIMO-5014 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Reporter: Mark Struberg Assignee: Donald Woods Attachments: GERONIMO-5014.patch there have been a few changes in the spec. I made all changes to make agimatec-validator (which currently uses the RI) compile against our spec api. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5049) Add bean validation (JSR 303) to Geronimo 3.0
[ https://issues.apache.org/jira/browse/GERONIMO-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-5049: --- Summary: Add bean validation (JSR 303) to Geronimo 3.0 (was: Add bean validation (JSR 302) to Geronimo 3.0) Add bean validation (JSR 303) to Geronimo 3.0 - Key: GERONIMO-5049 URL: https://issues.apache.org/jira/browse/GERONIMO-5049 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Release geronimo-validation_1.0_spec-1.0
Hi, I'd like to release v1.0 of the Bean Validation Spec API, now that we have it passing the Bean Validation 1.0 TCK signature tests. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-065/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-validation_1.0_spec-1.0/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Donald
Re: [VOTE] Release geronimo-validation_1.0_spec-1.0
+1 Passed mvn rat:check. Passed Bean Validation 1.0 TCK signature tests. Notice file in source was updated to include 2010 copyright year. OpenJPA tests using the API against the RI implementation passed. -Donald On 1/25/10 12:52 PM, Donald Woods wrote: Hi, I'd like to release v1.0 of the Bean Validation Spec API, now that we have it passing the Bean Validation 1.0 TCK signature tests. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-065/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-validation_1.0_spec-1.0/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Donald
Re: Web Annotation and web fragment support in Geronimo 3.0
On Jan 25, 2010, at 7:20 AM, Ivan wrote: Hi, Recently, I am looking at the annoation and web fragment in Servlet 3.0. After checking some integration codes, it seems that we have different strategy for Tomcat and Jetty, in Tomcat plugin, after doing some verification and web service process work, Geronimo will pass the web.xml file directly to Tomcat, and then Tomcat will parse the web.xml file and call the addChild method to register all the servlets to context. While in Jetty plugin, all the work is done in Servlet GBean and Jetty will not check the web.xml file (At least for servlet configurations). So in Geronimo 3.0, who will be resposible for the annotation and web fragment scanning. For Tomcat, one way is still to let Tomcat does it, actually I found some related codes are added in ContextConfig class. Although I found some errors while trying it, it should be easy to solve. Another way is to scan by Geronimo, then create a gbean for each servlet like Jetty, or just generate a full web.xml file. Personally, I wish to do it by Geronimo, so that Geronimo could have a full control of it, which keeps the same way with Jetty. Also, I have another idea about improving the class scanning, IIRC, many builders require annoation scanning or file scanning, like web- builder, webservice-builder, etc. I am thinking that whether we could do all the scanning work in one round, not a new round search would be triggered by each builder. Maybe, we could add some methods like registerScanningHandler in the DeploymentContext, and once the temp bundle is installed, all the scanning work be will done in one round. Any comment ? Thanks ! In tomcat, I think we have to let tomcat create the servlet wrapper objects. Several people have tried to turn them into gbeans but it conflicts with tomcat's attempt to manage the component lifecycle. I think we could write a jaxb-based processor to replace the tomcat digester one and this might simplify our code. I would prefer that geronimo scan for annotations and construct a complete web.xml from them and then process the web.xml either through our code (like in jetty) or through the web containers code (like in tomcat). Another possibility would be to use the new servlet 3.0 apis for adding servlets etc to a web app. We might be able to write a single processor to read through the metadata-complete web.xml and call the appropriate methods to construct the web app. At the moment I don't recall any geronimo-specific configuration that applies to specific servlets, filters, or listeners so this code might not need to look in geronimo plans very much. I like your idea of combining the annotation scanning. thanks david jencks Ivan
Re: How to handle the Web Profile subset
On Jan 25, 2010, at 6:41 AM, Rick McGuire wrote: We should be putting some thought on what the Geronimo deliverables are in the web profile world. I think for the most part, this should be just a different assembly that assembles a smaller set of components. The one additional configuration that is probably going to be needed is an EJB Lite configuration that would be used by the Web Profile assembly. This should not be a big delta over what we have, but it does increase the number of assemblies that we end up releasing. Are there other options we should be working at? I think we might already have too many assemblies :-) Ideally when the osgi integration settles down we will have an even better way than in 2.2 for extending a framework server or assembling custom servers. I'm cautiously in favor of making the minimal tomcat and jetty servers support the web profile and having smaller servers be custom assemblies or based on the framework server. thanks david jencks Rick
Re: [VOTE] Release geronimo-validation_1.0_spec-1.0
+1 Built successfully and verified that rat:check passes. Jay Donald Woods wrote: Hi, I'd like to release v1.0 of the Bean Validation Spec API, now that we have it passing the Bean Validation 1.0 TCK signature tests. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-065/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-validation_1.0_spec-1.0/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Donald
[jira] Commented: (GERONIMO-5030) Implement web container extender (RFC 66)
[ https://issues.apache.org/jira/browse/GERONIMO-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12804652#action_12804652 ] Jarek Gawor commented on GERONIMO-5030: --- In revision 902507 committed a web extender that can actually deploy web application bundles with simple servlets and jsps. In revision 902923 updated Tomcat and Jetty containers to register ServletContext into service registry for the WAB as mandated by the spec. Implement web container extender (RFC 66) - Key: GERONIMO-5030 URL: https://issues.apache.org/jira/browse/GERONIMO-5030 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: osgi Affects Versions: 3.0 Reporter: Jarek Gawor Assignee: Jarek Gawor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: about daytrader-web-jpa
Forrest Xia wrote: After some tries, finally I made daytrader-web-jpa works, see jira https://issues.apache.org/jira/browse/DAYTRADER-74. Joe, your version of TradeJPADirect has a small bug in completeOrder method, see the patch code, I think it could be back port to the blueprint one :-) Thanks Forrest. I think the line that you removed from createHolding was not in my sandbox version - so I think we're ok. I assume that is the change you intended since I didn't see any change in completeOrder. Please let me know if I'm missing something. Thanks, Joe Donald, in the web jpa assembly pom, there are some dependencies are of provided scope, I think if we need to make them packaged into the war directly, so that user can easily install the war into Tomcat without any advanced libraries installation. Does it make sense to make the assembly ease of use? However, in my tries, I ever want to use application managed persistence context with JTA underlying on geronimo javaee assembly, but failed always. So I want to ask a question: Can user use application-managed persistence context with JTA underlying in a non-container managed object? for example, in a POJO class? Seems to me, the answer is NO. As to whether or not work if using app-managed PC with JTA underlying in a container-managed object, for example, stateless session bean, servlet, etc. I will find time later to verify. However, if anyone has similar experience, pls kindly let me know. Forrest
Re: How to handle the Web Profile subset
On Jan 25, 2010, at 1:35 PM, David Jencks wrote: On Jan 25, 2010, at 6:41 AM, Rick McGuire wrote: We should be putting some thought on what the Geronimo deliverables are in the web profile world. I think for the most part, this should be just a different assembly that assembles a smaller set of components. The one additional configuration that is probably going to be needed is an EJB Lite configuration that would be used by the Web Profile assembly. This should not be a big delta over what we have, but it does increase the number of assemblies that we end up releasing. Are there other options we should be working at? I think we might already have too many assemblies :-) Ideally when the osgi integration settles down we will have an even better way than in 2.2 for extending a framework server or assembling custom servers. I'm cautiously in favor of making the minimal tomcat and jetty servers support the web profile and having smaller servers be custom assemblies or based on the framework server. Agreed that we don't want 2 additional assemblies. Replacing the minimal servers with web profile equivalents seems reasonable to me. I think users would find it convenient if an assembly could contain multiple configuration files. A full EE6 assembly could be invoked with a framework, minimal, web profile, or full EE6 configuration. Similarly, a web profile could contain framework and minimal configurations, also. --kevan
Re: Web Annotation and web fragment support in Geronimo 3.0
I agree. I think it would good for Geronimo to construct the metadata-complete web.xml and pass it to Tomcat to handle the rest. Btw, in TomcatModuleBuilder.addGBeans() there is a bit of code that (re)writes a web.xml. Does anybody know why is that (still) needed? The comment above that bit of code talks about when web.xml is missing (in jaxws case) but the code seems to be writing an empty web.xml even if web.xml is present and has Java EE namespace. Jarek On Mon, Jan 25, 2010 at 1:31 PM, David Jencks david_jen...@yahoo.com wrote: On Jan 25, 2010, at 7:20 AM, Ivan wrote: Hi, Recently, I am looking at the annoation and web fragment in Servlet 3.0. After checking some integration codes, it seems that we have different strategy for Tomcat and Jetty, in Tomcat plugin, after doing some verification and web service process work, Geronimo will pass the web.xml file directly to Tomcat, and then Tomcat will parse the web.xml file and call the addChild method to register all the servlets to context. While in Jetty plugin, all the work is done in Servlet GBean and Jetty will not check the web.xml file (At least for servlet configurations). So in Geronimo 3.0, who will be resposible for the annotation and web fragment scanning. For Tomcat, one way is still to let Tomcat does it, actually I found some related codes are added in ContextConfig class. Although I found some errors while trying it, it should be easy to solve. Another way is to scan by Geronimo, then create a gbean for each servlet like Jetty, or just generate a full web.xml file. Personally, I wish to do it by Geronimo, so that Geronimo could have a full control of it, which keeps the same way with Jetty. Also, I have another idea about improving the class scanning, IIRC, many builders require annoation scanning or file scanning, like web-builder, webservice-builder, etc. I am thinking that whether we could do all the scanning work in one round, not a new round search would be triggered by each builder. Maybe, we could add some methods like registerScanningHandler in the DeploymentContext, and once the temp bundle is installed, all the scanning work be will done in one round. Any comment ? Thanks ! In tomcat, I think we have to let tomcat create the servlet wrapper objects. Several people have tried to turn them into gbeans but it conflicts with tomcat's attempt to manage the component lifecycle. I think we could write a jaxb-based processor to replace the tomcat digester one and this might simplify our code. I would prefer that geronimo scan for annotations and construct a complete web.xml from them and then process the web.xml either through our code (like in jetty) or through the web containers code (like in tomcat). Another possibility would be to use the new servlet 3.0 apis for adding servlets etc to a web app. We might be able to write a single processor to read through the metadata-complete web.xml and call the appropriate methods to construct the web app. At the moment I don't recall any geronimo-specific configuration that applies to specific servlets, filters, or listeners so this code might not need to look in geronimo plans very much. I like your idea of combining the annotation scanning. thanks david jencks Ivan
Re: Web Annotation and web fragment support in Geronimo 3.0
On Jan 25, 2010, at 2:51 PM, Jarek Gawor wrote: I agree. I think it would good for Geronimo to construct the metadata-complete web.xml and pass it to Tomcat to handle the rest. Btw, in TomcatModuleBuilder.addGBeans() there is a bit of code that (re)writes a web.xml. Does anybody know why is that (still) needed? The comment above that bit of code talks about when web.xml is missing (in jaxws case) but the code seems to be writing an empty web.xml even if web.xml is present and has Java EE namespace. The only way to be sure is to take it out and see what happens :-) IIRC the main purpose is to write the metada-complete web.xml out for tomcat to find... but I may not RC. thanks david jencks Jarek On Mon, Jan 25, 2010 at 1:31 PM, David Jencks david_jen...@yahoo.com wrote: On Jan 25, 2010, at 7:20 AM, Ivan wrote: Hi, Recently, I am looking at the annoation and web fragment in Servlet 3.0. After checking some integration codes, it seems that we have different strategy for Tomcat and Jetty, in Tomcat plugin, after doing some verification and web service process work, Geronimo will pass the web.xml file directly to Tomcat, and then Tomcat will parse the web.xml file and call the addChild method to register all the servlets to context. While in Jetty plugin, all the work is done in Servlet GBean and Jetty will not check the web.xml file (At least for servlet configurations). So in Geronimo 3.0, who will be resposible for the annotation and web fragment scanning. For Tomcat, one way is still to let Tomcat does it, actually I found some related codes are added in ContextConfig class. Although I found some errors while trying it, it should be easy to solve. Another way is to scan by Geronimo, then create a gbean for each servlet like Jetty, or just generate a full web.xml file. Personally, I wish to do it by Geronimo, so that Geronimo could have a full control of it, which keeps the same way with Jetty. Also, I have another idea about improving the class scanning, IIRC, many builders require annoation scanning or file scanning, like web-builder, webservice- builder, etc. I am thinking that whether we could do all the scanning work in one round, not a new round search would be triggered by each builder. Maybe, we could add some methods like registerScanningHandler in the DeploymentContext, and once the temp bundle is installed, all the scanning work be will done in one round. Any comment ? Thanks ! In tomcat, I think we have to let tomcat create the servlet wrapper objects. Several people have tried to turn them into gbeans but it conflicts with tomcat's attempt to manage the component lifecycle. I think we could write a jaxb-based processor to replace the tomcat digester one and this might simplify our code. I would prefer that geronimo scan for annotations and construct a complete web.xml from them and then process the web.xml either through our code (like in jetty) or through the web containers code (like in tomcat). Another possibility would be to use the new servlet 3.0 apis for adding servlets etc to a web app. We might be able to write a single processor to read through the metadata-complete web.xml and call the appropriate methods to construct the web app. At the moment I don't recall any geronimo-specific configuration that applies to specific servlets, filters, or listeners so this code might not need to look in geronimo plans very much. I like your idea of combining the annotation scanning. thanks david jencks Ivan
[jira] Commented: (GERONIMO-5041) Use Aries InitialContextFactoryBuilder
[ https://issues.apache.org/jira/browse/GERONIMO-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12804831#action_12804831 ] David Jencks commented on GERONIMO-5041: rev 903036 disables a ger: binding of javamail session in plugins/javamail/javamail/src/main/plan/plan.xml this needs to be fixed. Use Aries InitialContextFactoryBuilder -- Key: GERONIMO-5041 URL: https://issues.apache.org/jira/browse/GERONIMO-5041 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming, osgi Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Aries has a partial implementation of the osgi frc 142 jndi stuff. We should integrate it. One of the bits is an InitaliContextFactoryBuilder that uses the service registry to find appropriate url context factories rather than the unfortunate scheme envisaged by the jndi spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Web Annotation and web fragment support in Geronimo 3.0
1. I saw the empty web.xml file also, I would suggest that even if we really need that file, it should be added by DeploymentContext, not directly write to repository. 2. Thanks for the suggest of using JAXB, I am sure that it would be easy to parse/generate xml file. But how about generating a full jaxb classes for Java EE deployment descriptors. I knew that we have had a XMLBeans version, but I wish that we should replace it in the future. Anyway, I would first try to generate the jaxb classes for web-3.0/web-fragment/web-common and the required reference types from javaee schema, so that it would keep the effect in the web-builder module. 2010/1/26 David Jencks david_jen...@yahoo.com On Jan 25, 2010, at 2:51 PM, Jarek Gawor wrote: I agree. I think it would good for Geronimo to construct the metadata-complete web.xml and pass it to Tomcat to handle the rest. Btw, in TomcatModuleBuilder.addGBeans() there is a bit of code that (re)writes a web.xml. Does anybody know why is that (still) needed? The comment above that bit of code talks about when web.xml is missing (in jaxws case) but the code seems to be writing an empty web.xml even if web.xml is present and has Java EE namespace. The only way to be sure is to take it out and see what happens :-) IIRC the main purpose is to write the metada-complete web.xml out for tomcat to find... but I may not RC. thanks david jencks Jarek On Mon, Jan 25, 2010 at 1:31 PM, David Jencks david_jen...@yahoo.com wrote: On Jan 25, 2010, at 7:20 AM, Ivan wrote: Hi, Recently, I am looking at the annoation and web fragment in Servlet 3.0. After checking some integration codes, it seems that we have different strategy for Tomcat and Jetty, in Tomcat plugin, after doing some verification and web service process work, Geronimo will pass the web.xml file directly to Tomcat, and then Tomcat will parse the web.xml file and call the addChild method to register all the servlets to context. While in Jetty plugin, all the work is done in Servlet GBean and Jetty will not check the web.xml file (At least for servlet configurations). So in Geronimo 3.0, who will be resposible for the annotation and web fragment scanning. For Tomcat, one way is still to let Tomcat does it, actually I found some related codes are added in ContextConfig class. Although I found some errors while trying it, it should be easy to solve. Another way is to scan by Geronimo, then create a gbean for each servlet like Jetty, or just generate a full web.xml file. Personally, I wish to do it by Geronimo, so that Geronimo could have a full control of it, which keeps the same way with Jetty. Also, I have another idea about improving the class scanning, IIRC, many builders require annoation scanning or file scanning, like web-builder, webservice-builder, etc. I am thinking that whether we could do all the scanning work in one round, not a new round search would be triggered by each builder. Maybe, we could add some methods like registerScanningHandler in the DeploymentContext, and once the temp bundle is installed, all the scanning work be will done in one round. Any comment ? Thanks ! In tomcat, I think we have to let tomcat create the servlet wrapper objects. Several people have tried to turn them into gbeans but it conflicts with tomcat's attempt to manage the component lifecycle. I think we could write a jaxb-based processor to replace the tomcat digester one and this might simplify our code. I would prefer that geronimo scan for annotations and construct a complete web.xml from them and then process the web.xml either through our code (like in jetty) or through the web containers code (like in tomcat). Another possibility would be to use the new servlet 3.0 apis for adding servlets etc to a web app. We might be able to write a single processor to read through the metadata-complete web.xml and call the appropriate methods to construct the web app. At the moment I don't recall any geronimo-specific configuration that applies to specific servlets, filters, or listeners so this code might not need to look in geronimo plans very much. I like your idea of combining the annotation scanning. thanks david jencks Ivan -- Ivan
Re: Web Annotation and web fragment support in Geronimo 3.0
On Jan 25, 2010, at 6:30 PM, Ivan wrote: 1. I saw the empty web.xml file also, I would suggest that even if we really need that file, it should be added by DeploymentContext, not directly write to repository. 2. Thanks for the suggest of using JAXB, I am sure that it would be easy to parse/generate xml file. But how about generating a full jaxb classes for Java EE deployment descriptors. I knew that we have had a XMLBeans version, but I wish that we should replace it in the future. Anyway, I would first try to generate the jaxb classes for web-3.0/ web-fragment/web-common and the required reference types from javaee schema, so that it would keep the effect in the web-builder module. According to David Blevins you'll want to tweak the generated jaxb classes to get more reasonable classes. Openejb has all of this done for ee5 xsds. I would start with those and see how to update for the schema additions. Also, we'll need 2 versions of all the naming builders, one for jaxb and one for xmlbeans, until we get everything converted. I was thinking of doing the same for connectors which have the advantage that they don't call any naming builders. thanks david jencks 2010/1/26 David Jencks david_jen...@yahoo.com On Jan 25, 2010, at 2:51 PM, Jarek Gawor wrote: I agree. I think it would good for Geronimo to construct the metadata-complete web.xml and pass it to Tomcat to handle the rest. Btw, in TomcatModuleBuilder.addGBeans() there is a bit of code that (re)writes a web.xml. Does anybody know why is that (still) needed? The comment above that bit of code talks about when web.xml is missing (in jaxws case) but the code seems to be writing an empty web.xml even if web.xml is present and has Java EE namespace. The only way to be sure is to take it out and see what happens :-) IIRC the main purpose is to write the metada-complete web.xml out for tomcat to find... but I may not RC. thanks david jencks Jarek On Mon, Jan 25, 2010 at 1:31 PM, David Jencks david_jen...@yahoo.com wrote: On Jan 25, 2010, at 7:20 AM, Ivan wrote: Hi, Recently, I am looking at the annoation and web fragment in Servlet 3.0. After checking some integration codes, it seems that we have different strategy for Tomcat and Jetty, in Tomcat plugin, after doing some verification and web service process work, Geronimo will pass the web.xml file directly to Tomcat, and then Tomcat will parse the web.xml file and call the addChild method to register all the servlets to context. While in Jetty plugin, all the work is done in Servlet GBean and Jetty will not check the web.xml file (At least for servlet configurations). So in Geronimo 3.0, who will be resposible for the annotation and web fragment scanning. For Tomcat, one way is still to let Tomcat does it, actually I found some related codes are added in ContextConfig class. Although I found some errors while trying it, it should be easy to solve. Another way is to scan by Geronimo, then create a gbean for each servlet like Jetty, or just generate a full web.xml file. Personally, I wish to do it by Geronimo, so that Geronimo could have a full control of it, which keeps the same way with Jetty. Also, I have another idea about improving the class scanning, IIRC, many builders require annoation scanning or file scanning, like web-builder, webservice- builder, etc. I am thinking that whether we could do all the scanning work in one round, not a new round search would be triggered by each builder. Maybe, we could add some methods like registerScanningHandler in the DeploymentContext, and once the temp bundle is installed, all the scanning work be will done in one round. Any comment ? Thanks ! In tomcat, I think we have to let tomcat create the servlet wrapper objects. Several people have tried to turn them into gbeans but it conflicts with tomcat's attempt to manage the component lifecycle. I think we could write a jaxb-based processor to replace the tomcat digester one and this might simplify our code. I would prefer that geronimo scan for annotations and construct a complete web.xml from them and then process the web.xml either through our code (like in jetty) or through the web containers code (like in tomcat). Another possibility would be to use the new servlet 3.0 apis for adding servlets etc to a web app. We might be able to write a single processor to read through the metadata-complete web.xml and call the appropriate methods to construct the web app. At the moment I don't recall any geronimo-specific configuration that applies to specific servlets, filters, or listeners so this code might not need to look in geronimo plans very much. I like your idea of combining the annotation scanning. thanks david jencks Ivan -- Ivan
[jira] Commented: (GERONIMODEVTOOLS-601) Module config Id not found for undeployment
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12804865#action_12804865 ] Delos Dai commented on GERONIMODEVTOOLS-601: I tried the new package, still no problem. I think the only different between us is the OS. If possible, could you try it on a non-Mac OS? I don't have any Mac OS at hand -:). From the error message, seems the exception is caused by missing server runtime or facet in WTP. Since you have deploy the WAR successfully, both server runtime and facet should have been provided. So I'm very curious to the root cause. Did you see the exception in console or error log view? If possible, could you attach the file .log in your workspace? Module config Id not found for undeployment --- Key: GERONIMODEVTOOLS-601 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-601 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: MacOS eclipse, Galileo SR1, Eclipse Java EE IDE for Web Developers, Build id: 20090902-1017 I am running in a Mac with this java: java -version java version 1.6.0_17 Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-9M3125) Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode) Reporter: Ted Kirby Assignee: Delos Dai Priority: Minor Attachments: GetnStarted3AG.tar.gz, GetnStarted3AG.zip I have created a dynamic web project and it seems to work fine. I can deploy and use the war file, and it gets republished if I change source. However, on every deploy/republish, I get this error in eclipse: Module config Id not found for undeployment java.lang.NullPointerException at org.apache.geronimo.st.core.jaxb.JAXBUtils.unmarshalFilterDeploymentPlan(JAXBUtils.java:126) at org.apache.geronimo.st.v21.core.GeronimoV21Utils.getWebDeploymentPlan(GeronimoV21Utils.java:236) at org.apache.geronimo.st.v21.core.GeronimoV21Utils.getWebDeploymentPlan(GeronimoV21Utils.java:199) at org.apache.geronimo.st.v21.core.GeronimoV21Utils.getWebDeploymentPlan(GeronimoV21Utils.java:179) at org.apache.geronimo.st.v21.core.GeronimoV21Utils.getConfigId(GeronimoV21Utils.java:119) at org.apache.geronimo.st.v21.core.GeronimoV21VersionHandler.getConfigID(GeronimoV21VersionHandler.java:36) at org.apache.geronimo.st.core.commands.UndeployCommand.execute(UndeployCommand.java:53) at org.apache.geronimo.st.core.commands.SynchronizedDeploymentOp.run(SynchronizedDeploymentOp.java:84) at org.apache.geronimo.st.core.commands.SynchronizedDeploymentOp.execute(SynchronizedDeploymentOp.java:76) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.unDeploy(GeronimoServerBehaviourDelegate.java:740) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.doRemoved(GeronimoServerBehaviourDelegate.java:666) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.invokeCommand(GeronimoServerBehaviourDelegate.java:451) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.publishModule(GeronimoServerBehaviourDelegate.java:318) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:948) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.publishModules(GeronimoServerBehaviourDelegate.java:273) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:872) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:708) at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:2690) at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:272) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) If I export the project as a war file, and deploy it to geronimo, I don't get the error, so I suspect it's a GEP problem. Here is my geronimo-web.xml file: ?xml version=1.0 encoding=UTF-8? web:web-app xmlns:app=http://geronimo.apache.org/xml/ns/j2ee/application-2.0; xmlns:client=http://geronimo.apache.org/xml/ns/j2ee/application-client-2.0; xmlns:conn=http://geronimo.apache.org/xml/ns/j2ee/connector-1.2; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:ejb=http://openejb.apache.org/xml/ns/openejb-jar-2.2; xmlns:log=http://geronimo.apache.org/xml/ns/loginconfig-2.0; xmlns:name=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:pers=http://java.sun.com/xml/ns/persistence; xmlns:pkgen=http://openejb.apache.org/xml/ns/pkgen-2.1; xmlns:sec=http://geronimo.apache.org/xml/ns/security-2.0; xmlns:web=http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1; dep:environment dep:moduleId
Re: Web Annotation and web fragment support in Geronimo 3.0
Great, looking forward it ! 2010/1/26 David Jencks david_jen...@yahoo.com On Jan 25, 2010, at 6:30 PM, Ivan wrote: 1. I saw the empty web.xml file also, I would suggest that even if we really need that file, it should be added by DeploymentContext, not directly write to repository. 2. Thanks for the suggest of using JAXB, I am sure that it would be easy to parse/generate xml file. But how about generating a full jaxb classes for Java EE deployment descriptors. I knew that we have had a XMLBeans version, but I wish that we should replace it in the future. Anyway, I would first try to generate the jaxb classes for web-3.0/web-fragment/web-common and the required reference types from javaee schema, so that it would keep the effect in the web-builder module. According to David Blevins you'll want to tweak the generated jaxb classes to get more reasonable classes. Openejb has all of this done for ee5 xsds. I would start with those and see how to update for the schema additions. Also, we'll need 2 versions of all the naming builders, one for jaxb and one for xmlbeans, until we get everything converted. I was thinking of doing the same for connectors which have the advantage that they don't call any naming builders. thanks david jencks 2010/1/26 David Jencks david_jen...@yahoo.com On Jan 25, 2010, at 2:51 PM, Jarek Gawor wrote: I agree. I think it would good for Geronimo to construct the metadata-complete web.xml and pass it to Tomcat to handle the rest. Btw, in TomcatModuleBuilder.addGBeans() there is a bit of code that (re)writes a web.xml. Does anybody know why is that (still) needed? The comment above that bit of code talks about when web.xml is missing (in jaxws case) but the code seems to be writing an empty web.xml even if web.xml is present and has Java EE namespace. The only way to be sure is to take it out and see what happens :-) IIRC the main purpose is to write the metada-complete web.xml out for tomcat to find... but I may not RC. thanks david jencks Jarek On Mon, Jan 25, 2010 at 1:31 PM, David Jencks david_jen...@yahoo.com wrote: On Jan 25, 2010, at 7:20 AM, Ivan wrote: Hi, Recently, I am looking at the annoation and web fragment in Servlet 3.0. After checking some integration codes, it seems that we have different strategy for Tomcat and Jetty, in Tomcat plugin, after doing some verification and web service process work, Geronimo will pass the web.xml file directly to Tomcat, and then Tomcat will parse the web.xml file and call the addChild method to register all the servlets to context. While in Jetty plugin, all the work is done in Servlet GBean and Jetty will not check the web.xml file (At least for servlet configurations). So in Geronimo 3.0, who will be resposible for the annotation and web fragment scanning. For Tomcat, one way is still to let Tomcat does it, actually I found some related codes are added in ContextConfig class. Although I found some errors while trying it, it should be easy to solve. Another way is to scan by Geronimo, then create a gbean for each servlet like Jetty, or just generate a full web.xml file. Personally, I wish to do it by Geronimo, so that Geronimo could have a full control of it, which keeps the same way with Jetty. Also, I have another idea about improving the class scanning, IIRC, many builders require annoation scanning or file scanning, like web-builder, webservice-builder, etc. I am thinking that whether we could do all the scanning work in one round, not a new round search would be triggered by each builder. Maybe, we could add some methods like registerScanningHandler in the DeploymentContext, and once the temp bundle is installed, all the scanning work be will done in one round. Any comment ? Thanks ! In tomcat, I think we have to let tomcat create the servlet wrapper objects. Several people have tried to turn them into gbeans but it conflicts with tomcat's attempt to manage the component lifecycle. I think we could write a jaxb-based processor to replace the tomcat digester one and this might simplify our code. I would prefer that geronimo scan for annotations and construct a complete web.xml from them and then process the web.xml either through our code (like in jetty) or through the web containers code (like in tomcat). Another possibility would be to use the new servlet 3.0 apis for adding servlets etc to a web app. We might be able to write a single processor to read through the metadata-complete web.xml and call the appropriate methods to construct the web app. At the moment I don't recall any geronimo-specific configuration that applies to specific servlets, filters, or listeners so this code might not need to look in geronimo plans very much. I like your idea of combining the annotation scanning. thanks david jencks Ivan -- Ivan -- Ivan
Re: Web Annotation and web fragment support in Geronimo 3.0
IMHO, I don't think we should worry about the JAXB conversion now unless there is no other way to fix the given problem. It might help things in long long term but right now I think it is important to get things running first. I especially don't want to debug 2 versions of all the builders. Jarek On Mon, Jan 25, 2010 at 9:42 PM, David Jencks david_jen...@yahoo.com wrote: On Jan 25, 2010, at 6:30 PM, Ivan wrote: 1. I saw the empty web.xml file also, I would suggest that even if we really need that file, it should be added by DeploymentContext, not directly write to repository. 2. Thanks for the suggest of using JAXB, I am sure that it would be easy to parse/generate xml file. But how about generating a full jaxb classes for Java EE deployment descriptors. I knew that we have had a XMLBeans version, but I wish that we should replace it in the future. Anyway, I would first try to generate the jaxb classes for web-3.0/web-fragment/web-common and the required reference types from javaee schema, so that it would keep the effect in the web-builder module. According to David Blevins you'll want to tweak the generated jaxb classes to get more reasonable classes. Openejb has all of this done for ee5 xsds. I would start with those and see how to update for the schema additions. Also, we'll need 2 versions of all the naming builders, one for jaxb and one for xmlbeans, until we get everything converted. I was thinking of doing the same for connectors which have the advantage that they don't call any naming builders. thanks david jencks 2010/1/26 David Jencks david_jen...@yahoo.com On Jan 25, 2010, at 2:51 PM, Jarek Gawor wrote: I agree. I think it would good for Geronimo to construct the metadata-complete web.xml and pass it to Tomcat to handle the rest. Btw, in TomcatModuleBuilder.addGBeans() there is a bit of code that (re)writes a web.xml. Does anybody know why is that (still) needed? The comment above that bit of code talks about when web.xml is missing (in jaxws case) but the code seems to be writing an empty web.xml even if web.xml is present and has Java EE namespace. The only way to be sure is to take it out and see what happens :-) IIRC the main purpose is to write the metada-complete web.xml out for tomcat to find... but I may not RC. thanks david jencks Jarek On Mon, Jan 25, 2010 at 1:31 PM, David Jencks david_jen...@yahoo.com wrote: On Jan 25, 2010, at 7:20 AM, Ivan wrote: Hi, Recently, I am looking at the annoation and web fragment in Servlet 3.0. After checking some integration codes, it seems that we have different strategy for Tomcat and Jetty, in Tomcat plugin, after doing some verification and web service process work, Geronimo will pass the web.xml file directly to Tomcat, and then Tomcat will parse the web.xml file and call the addChild method to register all the servlets to context. While in Jetty plugin, all the work is done in Servlet GBean and Jetty will not check the web.xml file (At least for servlet configurations). So in Geronimo 3.0, who will be resposible for the annotation and web fragment scanning. For Tomcat, one way is still to let Tomcat does it, actually I found some related codes are added in ContextConfig class. Although I found some errors while trying it, it should be easy to solve. Another way is to scan by Geronimo, then create a gbean for each servlet like Jetty, or just generate a full web.xml file. Personally, I wish to do it by Geronimo, so that Geronimo could have a full control of it, which keeps the same way with Jetty. Also, I have another idea about improving the class scanning, IIRC, many builders require annoation scanning or file scanning, like web-builder, webservice-builder, etc. I am thinking that whether we could do all the scanning work in one round, not a new round search would be triggered by each builder. Maybe, we could add some methods like registerScanningHandler in the DeploymentContext, and once the temp bundle is installed, all the scanning work be will done in one round. Any comment ? Thanks ! In tomcat, I think we have to let tomcat create the servlet wrapper objects. Several people have tried to turn them into gbeans but it conflicts with tomcat's attempt to manage the component lifecycle. I think we could write a jaxb-based processor to replace the tomcat digester one and this might simplify our code. I would prefer that geronimo scan for annotations and construct a complete web.xml from them and then process the web.xml either through our code (like in jetty) or through the web containers code (like in tomcat). Another possibility would be to use the new servlet 3.0 apis for adding servlets etc to a web app. We might be able to write a single processor to read through the metadata-complete web.xml and call the appropriate methods to construct the web app. At the moment I don't recall any geronimo-specific
NPE on Jetty
Hi, While testing some web applications on Jetty very quickly I ran into the following NPE (while accessing some jsps): java.lang.NullPointerException at java.util.zip.Inflater.ensureOpen(Inflater.java:336) at java.util.zip.Inflater.getBytesWritten(Inflater.java:296) at java.util.zip.ZipFile$1.available(ZipFile.java:243) at org.apache.felix.framework.URLHandlersBundleURLConnection.connect(URLHandlersBundleURLConnection.java:125) at org.apache.felix.framework.URLHandlersBundleURLConnection.getInputStream(URLHandlersBundleURLConnection.java:134) at org.eclipse.jetty.util.resource.URLResource.exists(URLResource.java:102) at org.eclipse.jetty.server.handler.ContextHandler$Context.getResource(ContextHandler.java:1623) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:306) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:532) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:454) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.server.session.SessionHandler.handle(SessionHandler.java:186) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:942) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:389) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:876) at org.apache.geronimo.jetty8.handler.GeronimoWebAppContext.doScope(GeronimoWebAppContext.java:115) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.Dispatcher.include(Dispatcher.java:172) After googling a bit I found the following bug reports: https://bugs.eclipse.org/bugs/show_bug.cgi?id=193269 and https://issues.apache.org/jira/browse/FELIX-1032. Looks like a JRE bug but maybe we can prevent this problem by patching Jetty (by closing the inputstreams) ? Jarek
Re: NPE on Jetty
Seems like the problem might be caused by URLResource.exists() calls as the change in revision 903093 makes these NPEs disappear. Jarek On Tue, Jan 26, 2010 at 12:35 AM, Jarek Gawor jga...@gmail.com wrote: Hi, While testing some web applications on Jetty very quickly I ran into the following NPE (while accessing some jsps): java.lang.NullPointerException at java.util.zip.Inflater.ensureOpen(Inflater.java:336) at java.util.zip.Inflater.getBytesWritten(Inflater.java:296) at java.util.zip.ZipFile$1.available(ZipFile.java:243) at org.apache.felix.framework.URLHandlersBundleURLConnection.connect(URLHandlersBundleURLConnection.java:125) at org.apache.felix.framework.URLHandlersBundleURLConnection.getInputStream(URLHandlersBundleURLConnection.java:134) at org.eclipse.jetty.util.resource.URLResource.exists(URLResource.java:102) at org.eclipse.jetty.server.handler.ContextHandler$Context.getResource(ContextHandler.java:1623) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:306) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:532) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:454) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.server.session.SessionHandler.handle(SessionHandler.java:186) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:942) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:389) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:876) at org.apache.geronimo.jetty8.handler.GeronimoWebAppContext.doScope(GeronimoWebAppContext.java:115) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.Dispatcher.include(Dispatcher.java:172) After googling a bit I found the following bug reports: https://bugs.eclipse.org/bugs/show_bug.cgi?id=193269 and https://issues.apache.org/jira/browse/FELIX-1032. Looks like a JRE bug but maybe we can prevent this problem by patching Jetty (by closing the inputstreams) ? Jarek
