[jira] [Commented] (GERONIMO-6429) CLONE - Problem with attribute manager
[ https://issues.apache.org/jira/browse/GERONIMO-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13549399#comment-13549399 ] John Sisson commented on GERONIMO-6429: --- This was a very long time ago... Did a bit of googling for GERONIMO-2095 and found this: http://mail-archives.apache.org/mod_mbox/geronimo-scm/200606.mbox/%3c20060609052636.267f41a9...@eris.apache.org%3E The changes seem to be related to ensuring the file is properly closed when exceptions occur. Sorry, I don't have the time to investigate further. I haven't looked at the code, but might be worth investigating whether there could be anything else running on the system opening files that may cause it to be in use and prevent it from being renamed (e.g. antivirus, file indexer, backup). CLONE - Problem with attribute manager -- Key: GERONIMO-6429 URL: https://issues.apache.org/jira/browse/GERONIMO-6429 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Environment: http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz Windows XP, cygwin Command line: java -jar bin/server.jar Free disk space: 3 Gb Reporter: Amit S Assignee: John Sisson Priority: Critical gnodet@guillaumes /cygdrive/c/tmp/geronimo-1.1-20060607 $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.5.0_06)... Starting Geronimo Application Server v1.1-20060607 [** ] 30% 21s Starting geronimo/system-database...20:32:49,484 ERROR [LocalAttributeManager] Error saving attributes java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable attributes working file to proper file name! Configuration will revert to defaults unless t his is manually corrected! (could not rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to C:\tmp\geronimo-1.1-20060607\var\config\config.xml) at org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449) at org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) [** ] 84% 39s Starting geronimo/webconsole-jett...20:33:07,890 ERROR [LocalAttributeManager] Error saving attributes java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable attributes working file to proper file name! Configuration will revert to defaults unless t his is manually corrected! (could not rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to C:\tmp\geronimo-1.1-20060607\var\config\config.xml) at org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449) at org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) [**] 100% 45s Startup complete Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 0.0.0.0 Remote Login Listener 8009 0.0.0.0 Jetty Connector AJP13 8080 0.0.0.0 Jetty Connector HTTP 8443 0.0.0.0 Jetty Connector HTTPS 0.0.0.0 JMX Remoting Connector 61616 0.0.0.0 ActiveMQ Message Broker Connector Started Application Modules: EAR: geronimo/webconsole-jetty/1.1-20060607/car RAR: geronimo/activemq/1.1-20060607/car RAR: geronimo/system-database/1.1-20060607/car WAR: geronimo/remote-deploy-jetty/1.1-20060607/car WAR: geronimo/welcome-jetty/1.1-20060607/car Web Applications: http://guillaumes:8080/ http://guillaumes:8080/console http://guillaumes:8080/console-standard http://guillaumes:8080/remote-deploy Geronimo Application Server started 20:33:18,718 ERROR [LocalAttributeManager] Error saving attributes java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable attributes working file to proper file name! Configuration will revert to defaults unless t his is manually corrected! (could not rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to C:\tmp\geronimo-1.1-20060607\var\config\config.xml) at org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449) at org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) -- This message
[jira] Updated: (GERONIMO-4475) Improve JMS portlet for AMQ 5.3 Broker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Sisson updated GERONIMO-4475: -- Summary: Improve JMS portlet for AMQ 5.3 Broker configuration (was: Improve JMS portlet for AMQ 5.3 Borker configuration) Corrected description Improve JMS portlet for AMQ 5.3 Broker configuration Key: GERONIMO-4475 URL: https://issues.apache.org/jira/browse/GERONIMO-4475 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Ivan Assignee: Ivan Fix For: 2.2 Attachments: G4475-activemq-broker-00.patch, G4475-activemq-broker.patch, G4475-activemq-portlet-update-02.patch, G4475-geronimo-activemq.patch, G4475-geronimo-management.patch Currently in the administrator console, the users could not add another embed broker. Also, they could not edit the broker through administrator console. I list the features that I could see : 1. While creating the broker, let the use upload a configuration file. 2. While editing the broker, show a text area, so that the user could edit the spring XML file in it. Shall we give the user a more friendly interface, so that they do not need the edit the XML file directly. I am not sure how it should look like. 3. Update the connector port let, so that while creating a new connector, the user could specify the broker that it belongs to. Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 John Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
Re: [DISCUSS] Monitoring Client may need a new graphing engine
Erik B. Craig wrote: All, Currently the monitoring client is using Dojo 0.4.3 charting, which does not necessarily behave as expected on Firefox/Safari on a mac, or on IE6 on Windows. I consider this to be a shortcoming, and given the new version of Dojo available (1.0.1), began investigating migrating the monitoring client over to the new version of Dojo, only to find that the new version of dojo appears to be a significant rewrite of the old code base, leaving out some features that I consider to be very visually pleasing and important for statistics viewing. While rummaging through the Dojo forums, I stumbled upon another Javascript graphing framework called Timeplot, which is part of the SIMILE project at MIT, and while this has it's own set of limitations... I'm trying to figure out the lesser of three evils before it comes a time that this monitoring plugin will be released, so that I have enough time (read: 3-5 days) to migrate the javascript generation over to something new if necessary. I have created a small demonstration page that shows all three options graphed with the same data series, as well as weighing some of the advantages/disadvantages I could come up with, Please have a look, and let me know your thoughts. http://people.apache.org/~ecraig/graphdemo/ Personally, I think it would be really cool if we could use the Timeplot graphing libraries, as it is all BSD licensed and therefore friendly I believe (right, Kevan?)... and also EXTREMELY cool for showing multiple data series in one chart. IMHO, as much as I dislike saying this.. IE support should be mandatory considering the number of users who use it. The disadvantages of Dojo 1.0.1 sound pretty minor compared the other options not supporting browsers. Regards, John
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Congratulations Jay! Regards, John Kevan Miller wrote: All, Please join us in congratulating Jay McHugh as the newest member of the Geronimo PMC. It's been great to have Jay working with us as a committer on Geronimo. Even better to have him join us in providing oversight of the Geronimo project. Way to go Jay!!! The Apache Geronimo PMC --kevan
Re: project involvement
Congratulations on the wedding new Job Sachin! Regards, John Sachin Patel wrote: Hello community members... I'd thought I'd shoot of a note to explain my limited involvement in the project as of recent. As some have you may have known, I've taken a new job thats taken has taken away from the Java enterprise space. As we all know what starting a new job is like, I've had very limited time with following the progress of Geronimo 2.0 and keeping up with the Geronimo Eclipse Plugin. I ask that the community see to it that they continue their involvement in providing Geronimo best Java EE tooling and once things aren't so hectic with my life (a new job getting married in 3 weeks!) I'll continue to be involved as I can. - sachin
Re: ClassLoading information
Just some thoughts between nappy changes :-) I seem to remember seeing the actual exception creation time being an issue when profiling the code a while ago. I think it may be due to the generation of the stack trace. It would be interesting to see how much of a performance improvement you would get if you reused exception objects rather than creating a new exception object each time a class is not found. The problem with reusing exceptions is that the stack trace isn't going to be correct. Maybe we could have an optimization that doesn't have the stack trace or some partial stack information by instantiating a subclass of the ClassNotFoundException that overrides the fillInStackTrace() method (which is called by the Throwable constructor) and possibly calls the setStackTrace method. You would want the ability to turn this optimization on or off. I the optimization should be off by default, as it should be up to the user to decide whether they want to live with less information to debug the exception. Regards, John Matt Hogstrom wrote: I did some profiling of DayTrader deploy (which takes almost 60 seconds) to understand what is taking so long. It appears that we spend a significant amount of time MultiParentClassLoader.loadClass(). We've been in here before and added some code to direct requests for specific class types to the SystemClassLoader (like java., double, int, etc.). This help performance a lot. But that's old news. I've been gathering some information on where we are spending the time and it appears that the single item that hurts us the most is classes that are not being found. I add some code to cache the classes that are known to not exist in a hierarchy and the results were fairly impressive. Startup time on my Mac goes from about 19 seconds to 15 seconds. That is just about a 20% improvement in startup time. Deploy time for DayTrader goes from 62 seconds to 36 seconds (about 1/2 the time). I talked to Dain about this and its not really clear how to handle this. One option is to implement the cache of classes that have not been found. However, for entries in the ClassPath that are a directory its possible that a user might drop a class in and we would never find it once we failed. We could put some kind of timer mechanism in to throw out entries that have not been referenced in some time interval. I wanted to solicit some input on alternatives. For those interested in how many times a loadClass fails with a CNFE I captured each failure by classloader and appended a number of times the class was looked for. This can be found at http://people.apache.org/~hogstrom/classNotFoundList.txt (It's about 2MB) or you can grab a zip file if you prefer. http://people.apache.org/~hogstrom/classNotFoundList.zip
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
Great to see you back Dain. Congrats! John Matt Hogstrom wrote: The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has accepted an invitation to join the PMC. Nuf 'said. Welcome :-0
Re: [ANNOUNCE] Please welcome Rakesh Midha as a new Geronimo committer
Welcome Congrats Rakesh! Regards, John Hernan Cunico wrote: Congrats Rakesh!!! Cheers! Hernan Kevan Miller wrote: All, The Geronimo PMC is pleased to announce that Rakesh Midha has recently accepted our invitation to become an Apache Geronimo committer. Rakesh has contributed a number of significant enhancements to our Admin Console and deployment code. We're looking forward to Rakesh joining our project. Congratulations and welcome to Rakesh! --kevan
Re: [ANNOUNCE] Please welcome Donald Woods as a new Geronimo committer
Welcome and Congrats Donald! Regards, John Hernan Cunico wrote: Congrats Donald!!! Cheers! Hernan Kevan Miller wrote: All, The Geronimo PMC is pleased to announce that Donald Woods has recently accepted our invitation to become an Apache Geronimo committer. Donald has been a long-term contributor to the Geronimo project and has provided valuable fixes and enhancements in a number of areas. We're looking forward to Donald joining our project. Congratulations and welcome to Donald! --kevan
I'm now a dad !
On Tuesday 27th of March at 11am I became the proud father of our first child, a baby girl, Jasmine Mae Sisson, weighing 3.6 kilos ( 7.92 pounds). Lisa and Jasmine are doing well, although now very tired. http://www.youtube.com/watch?v=T_F14GWYzZs Regards, John
Re: [ANNOUNCE] Welcome Jarek Gawor as our newest committer
Conrgratulations Jarek! Regrards, John Davanum Srinivas wrote: All, Sorry Jarek! Mea Culpa! Folks, We're pleased to let you know that we have a new committer in our midst. Jarek Gawor has been active on the Web Services integration for Geronimo for quite some time and has recently accepted an invitation to join the Geronimo project as a committer. Welcome Jarek! thanks, dims
Re: [VOTE] Release ActiveMQ-CPP 1.1
Nathan Mittler wrote: Also, does anyone have an example of a LICENSE.txt that includes multiple licenses ... not sure what this should look like? See LICENSE.txt and NOTICE.txt in http://svn.apache.org/viewvc/geronimo/server/trunk/ for an example. Regards, John Thanks, Nate On 1/15/07, Kevan Miller [EMAIL PROTECTED] wrote: On Jan 14, 2007, at 11:07 AM, Nathan Mittler wrote: Hi everyone, Several bug fixes as well as a few new features have been incorporated into ActiveMQ-CPP - worthy of a 1.1 release, before we go for full openwire support in 2.0. The source bundle for the release candidate can be found here: http://people.apache.org/~nmittler/incubator-activemq-cpp-1.1-src.zip http://people.apache.org/%7Etabish/activemq-cpp-1.0.zip And here's the wiki page for the release: http://www.activemq.org/site/activemq-cpp-11-release.html http://www.activemq.org/site/activemq-cpp-10-release.html Please cast your votes: [ ] +1 Release the source as Apache ActiveMQ CPP 1.1 [ ] -1 Veto the release (provide specific comments) The following file in your distribution seems to be licensed under the same license as Autoconf. I don't know what that license is. I assume it's compatible with the ASF. The license needs to be included in your LICENSE.txt file. === ==./m4/ac_doxygen.m4 === # This file is part of Autoconf. -*- Autoconf -*- # Copyright (C) 2004 Oren Ben-Kiki # This file is distributed under the same terms as the Autoconf macro files. ... --kevan
Re: Geronimo build automation status (longish)
Hi Jason, I had a quick look at the AntHill console and it looked pretty cool. My initial thought was whether we would be discouraging potential ISVs to use Geronimo as a basis of their solutions by requiring them to license AntHill if they want to do their own automated builds/testing of Geronimo (e.g. so they can build and ship their own fix releases outside the Apache process). The AntHill site does not list prices, so I can't comment on what licensing of AntHill for a non-open source version of Geronimo would cost. If we are always going to be able to build Geronimo and test it manually (without AntHill), then maybe it isn't such a biggie. Thought I'd raise it for discussion anyway. Regards, John Jason Dillon wrote: Sorry, this has been long overdue. I've been working on some automation systems for Geronimo builds, including the basic server assemblies, cts assemblies, tck testsuite execution as well as soon to run our own testsuite. I have used many different build automation platforms in the past... but IMO they all have some deficiency. Anyways, I elected to implement a solution using AntHill, who's publisher, Urbancode, has a policy to allow free usage for open-source projects (just like Atlassian's JIRA Confluence). I've set up the latest version of AntHill 3 on our gbuild hosts, and have been working on a configuration to allow reliable builds of Geronimo. One of the nice aspects of AntHill3 is its distributed agent system, which allows workload to be split up over a set of nodes. A downside to this is that it becomes more difficult to link Maven builds, as Maven uses a local repository cache for all integration points. But, I have gotten around this issue by having AH include all of the artifacts downloaded and produced by a build into a clean local repo by the target project which is building. A nice side effect of this is that there is direct correlation between one build to another. And aside from any mystical SNAPSHOT mismatches (which I hope to get fixed soon with my mvn patch http://jira.codehaus.org/browse/MNG-2681) it is fairly safe to say that artifacts generated/downloaded by one build will be used by a dependent build. The down side to this is that sometimes we have to ship about ~512mb of dependencies for larger builds (like the cts-server builds for the TCK which depend on all of the outputs of the server builds, which is a local repo cache of ~512mb). An even nicer side effect to all of this, now that each build has a set of artifacts which can be retrieved by another process... we can then take a successful build of Geronimo and run our testsuite on it... either automatically or manually. And when the testsuite gets bigger and bigger, we can split up each of the suites and run each one a different system... or even on a different operating system or architecture. Anyways... the options ahead of us are really interesting... and I believe that right now that AntHill3 is the best tool available to our community to build a really rich and powerful build automation system. I am however still working out some of the kinks... For example, to run our console-testsuite automatically on gbuild hosts, we need to setup a virtual X server for Firefox to connect to, which means we need to setup some tasks to execute Xfvb before tests and shut it down afterwards, as well as put firefox-bin on the path, etc. Minor issues, but still work left to be done. If you'd like to take a peek, you can log into the AntHill console here: https://gbuild.org:9443 Username: guest Password: gbuild (NOTE: This user will not be able to see any of the CTS or TCK related projects due to NDA mucky muck) I hope to have this wrapped up for the main G server builds over the next few days, at which point I will enable the build status notifications to be sent to dev@ But right now since I am testing its probably not meaningful to send out those notifications. But, I have found several build related issues from testing this system, which is usually performed off of a clean svn co with a clean mvn repo... so I'm confident that once its going that we will catch more errors faster, which will hopefully reduce build related errors for the masses. * * * Anyways, right now I have builds setup for: Genesis - trunk Specs - trunk Geronimo Components (stage=bootstrap) - trunk 1.2 OpenEJB 2 - trunk 2.2 Geronimo Server (stage=assemble) - trunk 1.2 Geronimo CTS 1.2 As noted above, these builds use the exact outputs from one build in another, not using a shared local repo, so there is less chance that other builds will cause mvn to behave strangely (or stranger than it already does). I have started working on a workflow to run the server/testsuite/* modules on Geronimo Server outputs, which should be closer to being finished early next week. Some of these projects, those that generate Surefire
Re: Geronimo build automation status (longish)
Jason Dillon wrote: On Dec 4, 2006, at 3:45 AM, John Sisson wrote: I had a quick look at the AntHill console and it looked pretty cool. My initial thought was whether we would be discouraging potential ISVs to use Geronimo as a basis of their solutions by requiring them to license AntHill if they want to do their own automated builds/testing of Geronimo (e.g. so they can build and ship their own fix releases outside the Apache process). The AntHill site does not list prices, so I can't comment on what licensing of AntHill for a non-open source version of Geronimo would cost. What? How did you get the idea that everyone has to use AntHill to build Geronimo? I didn't have the idea that everyone has to use AntHill to build Geronimo. In my first paragraph I was only talking about automated building/testing. I just put my ASF hat on and asked myself who is our community? AFAIK our community includes Geronimo users (both individuals and companies), Geronimo developers and software vendors that repackage the code and/or provide support ). I don't currently work for a company that builds or sells support for Geronimo, so my only motivation here is to ensure there is community discussion about this proposed move. I think my last paragraph was confusing. When I wrote it, I was wondering whether some time in the future, proper releases would only be built, tested and packaged from automated builds and whether it is realistic for someone to do a full build, test, package manually. Has Geronimo's building and testing and release packaging has become complex enough that for an ISV to realistically provide support for Geronimo they would pretty much need a build and testing automation setup like you are suggesting? If we tell them they have to license AntHill is that reasonable? What does the community think? For example, if a developer without commit access wanted to do automated builds and testing of modifications to Geronimo on their home PC or at their company (then is the AntHill license flexible enough to let them do that, or is the license limited to Apache hardware or individual Apache committers? Regards, John
Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congratulations Chris! Regards, John Gianny Damour wrote: Hi, The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others. Congratulations and Welcome Christopher!
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congratulations Vamsi! Regards, John Alan Cabrera wrote: The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security. Congratulations and welcome Vamsi! Regards, Alan -- Apache Geronimo - http://geronimo.apache.org Apache Yoko - http://incubator.apache.org/yoko LiveTribe - http://www.livetribe.org
Re: [ANNOUNCE] Welcom Prasad Kashyap as our newest committer
Congratulations Prasad! Regards, John Matt Hogstrom wrote: All, We're pleased to let you know that we have a new committer in our midst. Prasad Kashyap has recently accepted an invitation to join the Geronimo project. Prasad has been active on Geronimo for quite some time and has provided numerous patches for the Maven2 build as well as automated testing. He has been very helpful to users and developers, alike. We're confident that Prasad will be a great addition to the project. Welcome Prasad! Matt Hogstrom [EMAIL PROTECTED]
Re: [ANNOUNCE] Welcome Bruce Snyder as the newest member of the Geronimo PMC
Congratulations Bruce! Regards, John Kevan Miller wrote: All, The Geronimo PMC is pleased to welcome Bruce Snyder as the newest member of the Geronimo PMC. We're very happy to have Bruce joining us to help with the oversight of the Geronimo project. Well done, Bruce! The Apache Geronimo PMC --kevan
Re: Priorities for 1.2
Global JNDI Yoko ORB support Full Java 5 support More out of the box samples Console usability improvements OpenEJB 3.0 integration with @Stateless EJBs support OpenJPA integration More server modularization via plugins Console extensibility Jetspeed integration CMP improvements GShell integration JAF 1.1 Geronimo OSGi bundle John Dain Sundstrom wrote: We have collected 14 features for 1.2 and now we need to prioritize them. The sorted list of features will help guide us in determining when to release based on how many high priority features we have completed. Please, sort the following list according to what *you* believe are the most important features to include in 1.2. It will help me tally the list if you simply reorder the list instead of putting numbers next to the features. Also, please *do not* attempt to give more than one feature the same priority. In such a case, I will give priority to the highest left-most item in your list. I will tally the results on Friday, October 6th. -dain OpenJPA integration Global JNDI Yoko ORB support Full Java 5 support JAF 1.1 GShell integration CMP improvements Console usability improvements Jetspeed integration More server modularization via plugins Console extensibility More out of the box samples OpenEJB 3.0 integration with @Stateless EJBs support Geronimo OSGi bundle
Re: [ANNOUNCE] Welcome Jason Dillon as the newest member of the Geronimo PMC
Congratulations! Regards, John Kevan Miller wrote: All, The Geronimo PMC is pleased to welcome Jason Dillon as the newest member of the Geronimo PMC. We're very happy to have Jason joining us to help with the oversight of the Geronimo project. Well done, Jason! The Apache Geronimo PMC --kevan
Re: [ANNOUNCE] Welcome James Strachan as the newest member of the Geronimo PMC
Congratulations and welcome James! Regards, John Kevan Miller wrote: All, The Geronimo PMC is pleased to welcome James Strachan as the newest member of the Geronimo PMC. We're very happy to have James joining us to help with the oversight of the Geronimo project. Well done, James! The Apache Geronimo PMC --kevan
Re: [ANNOUNCE] Welcome Hiram Chirino as the newest member of the Geronimo PMC
Great to have you on board Hiram! Regards, John Kevan Miller wrote: All, The Geronimo PMC is pleased to welcome Hiram Chirino as the newest member of the Geronimo PMC. We're very happy to have Hiram joining us to help with the oversight of the Geronimo project. Well done, Hiram! The Apache Geronimo PMC --kevan
Re: Board Report - Comments please
Moved Geronimo's Wiki from Moin Moin to Confluence. Inter-project relationship status: * Yoko (CORBA orb) integration work in Geronimo under way. * Changed Geronimo trunk build to maven 2. * Future versions of Geronimo (2.x) will use the ActiveMQ and OpenEJB projects currently in the incubator instead of the versions of these projects from Codehaus. John Matt Hogstrom wrote: Hi everyone, We have a board report due and it appears that the RoUS is a tad busy at the moment. I pulled the following from STATUS and added my recollections and musings. Please add your comments to this thread and I'll happily roll them up into a big bushel of information to the board. We need to get this pulled together for Wednesday morning. Thanks! This report is for the last two months (let's say August - September): *Community* - Voted in 1 new committer which brings us to 32 committers - Voted in 7 new PMC members. PMC currently at 19 members - Community voted to return to CTR from RTC starting on September 18th *Releases* Geronimo - Version 1.1.1 was approved for release and the jars were made available on Monday, September 18th. Xbean Devtools DayTrader - Version 1.1.1 is ready to start the release process. It includes minor tweaks and a few bug fixes. Nothing major. *Development* Geronimo - Dain and Alan were voted in as release managers for 1.2. - Content being defined by the community. Xbean DayTrader - Bug fixes for 1.1.1. - Some POCs on new Ajax interfaces DevTools *Other Stuff* Matt Hogstrom [EMAIL PROTECTED]
Re: [DISCUSS] 1.2 Release Manager
+1 John Matt Hogstrom wrote: Folks, Dain has volunteered to be the 1.2 release manager and Alan has also volunteered to be the co-pilot. I have not seen a formal discussion or vote on this. I don't know that we have a policy on this so I'm starting the discuss thread. At some point in the past Aaron volunteered to do 1.2 as well but I don't recall closure on his volunteering. Also, note that only PMC members have binding votes on the release of Apache software. Matt Hogstrom [EMAIL PROTECTED]
Re: [ANNOUNCE] Welcome Hernan Cunico as the newest member of the Geronimo PMC
Congratulations Hernan! Regards, John
Re: [ANNOUNCE] Welcome Rick McGuire as the newest member of the Geronimo PMC
Congratulations Rick! Regards, John
Re: [VOTE] Geronimo Development Process
[X] +1 CTR with documentation guidelines I agree with Joe that we need to work hard at this for it to work and should review its effectiveness in a few months. Regards, John Joe Bohn wrote: [X] +1 CTR with documentation guidelines We'll have to work extra hard to ensure that we hold each other to the communication standard ... but I think if we are diligent then this makes the most sense. If the change is approved, I also recommend that we hold a public review of how we feel it is working after some reasonable amount of time (perhaps 2-3 months) to ensure that we're not drifting back into old habits. Joe Kevan Miller wrote: This is a vote to determine the development process the Geronimo community wishes to use for trunk development. If any modifications are needed for a branch development process, then a separate vote will be held. All votes are important. This is a community-wide issue. Please let your voice be heard... Choose the development process which you think will best serve the Geronimo community. I'd like to limit voting to a single process, rather than using a poll/ranking system (i.e. 1,2,3). If a clear consensus does not emerge, then we'll need to refine and hold another vote. [ ] +1 Relaxed RTC [ ] +1 RTC with Lazy Consensus [ ] +1 CTR with documentation guidelines These development processes are summarized below: 1. Relaxed RTC Geronimo follows a Review-Then-Commit (RTC) model. Patches for new function are provided by developers for review and comment by their peers. Feedback is conducted through JIRA comments. The goal of this interaction is to solicit suggestions from the community and incorporate their feedback as appropriate. In order for a patch to be accepted it requires the following: * Needs to be reviewed by committers on the project. Others may comment but their comments are not binding. The review may, but does not have to, include application and testing. The goal of the review is to understand the technical attributes of the change as well as the assess other impacts to the project as a whole. * 3 +1 votes from committers on the project with no outstanding -1 votes. * Any -1 votes need to be accompanied by a reason (the parties should then attempt to reach a mutually agreed upon solution to the issue raised). * If the issues can't be resolved then the PMC can be called upon to settle the dispute and make a recommendation. * Issues are generally of a technical nature. However, issues may include other items like usability, project cohesiveness or other issues that impact the project as a whole. The goal of these guidelines is to facilitate timely communication as well as the fostering of ideas and collaboration as well as innovation. 2. RTC with Lazy Consensus Geronimo follows a Review-Then-Commit model with Lazy consensus. Patches for new function are provided by developers for review and comment by their peers. Feedback is conducted through JIRA comments. The goal of this interaction is to solicit suggestions from the community and incorporate their feedback as appropriate. A patch is accepted if: * 3 +1 votes from committers on the project with no outstanding -1 votes and no significant, ongoing discussion * 72 hours pass with no outstanding -1 votes and no significant, ongoing discussion. A 24 hour warning should be sent to the dev list. 3. CTR with documentation guidelines Geronimo follows a Commit-Then-Review model. There should be an emphasis of community communication. Community-based policing and persuasion will be used to remedy any problem areas. Guidelines are not strict dogma -- common sense should prevail. Community communication is the key, not a process. General guidelines are: * Non-trivial changes (and certainly potentially controversial changes) should be announced on the dev list. This announcement should be well in advance of the change being committed. The community should be given the opportunity to understand and discuss the proposal. * Concurrent with the commit of a significant change, the committer should document the change on the dev list. You should describe what you are doing, describe why you are doing it, and provide an overview of how you implemented it. --kevan
[jira] Updated: (GERONIMO-1786) JMS Listeners for protocols activeio, peer and openwire fail to start
[ http://issues.apache.org/jira/browse/GERONIMO-1786?page=all ] John Sisson updated GERONIMO-1786: -- Affects Version/s: 1.1.1 Updated version to include 1.1.1 ( problem still exists in 1.1.1-rc3). JMS Listeners for protocols activeio, peer and openwire fail to start - Key: GERONIMO-1786 URL: http://issues.apache.org/jira/browse/GERONIMO-1786 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, console Affects Versions: 1.0, 1.2, 1.1, 1.1.1 Environment: Geronimo 1.0.0 Reporter: Donald Woods Fix For: 1.2 Even though addition of JMS Listeners for activeio, peer and openwire protocols is successful, the listeners fail to start with the following exceptions. activeio --- java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found openwire --- javax.jms.JMSException: Could not load protocol: openwire. Reason: java.lang.ClassNotFoundException: org.activemq.transport.openwire.OpenWireTransportServerChannelFactory peer --- javax.jms.JMSException: Could not load protocol: peer. Reason: java.lang.ClassNotFoundException: org.activemq.transport.peer.PeerTransportServerChannelFactory Stack trace of the same. 192: 14:17:49,499 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.0/car,J2EEServer=geronimo,br oker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.12340-aio 193: java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found 194: at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTranspo rtServerChannelFactory.java:60) 195: at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFact ory.java:49) 196: at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) 197: at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) 198: at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) 199: at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:161) 200: at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:129) 201: at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java(Compiled Code)) 202: at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) 203: at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) 204: at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) 205: at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) 206: at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) 207: at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java :365) 208: at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) 209: at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$2b4c85ae.startRecursive(generated) 210: at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:79) 211: at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) 212: at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) 213: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) 214: at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) 215: at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) 216: at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) 217: at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) 218: at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) 219: at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) 220: at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) 221: at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) 222: at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) 223
plugin-repository-list URL in config.xml
I noticed that config.xml's DownloadedPluginRepos gbean points to a file in Aaron's home directory. gbean name=DownloadedPluginRepos attribute name=repositoryListhttp://people.apache.org/~ammulder/plugin-repository-list-1.1.txt/attribute attribute name=userRepositories[]/attribute /gbean Should we be looking at moving this to a more formal location? I'll create a JIRA if others agree. Thanks, John
Re: Release Early, Release Often
Hernan Cunico wrote: We already have some structure for monitoring (or better trying to monitor) the project development status http://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Development+Status Any ideas how we could reuse this info/templates? Would it be better to have the Apache Geronimo Development Status moved under Apache Geronimo Development? What would help us to stay on track I agree it would be helpful to track progress using the report card and package tracking wiki pages from the link above, possibly updated with links to the appropriate JIRAs. John Cheers! Hernan Bruce Snyder wrote: On 9/7/06, Hiram Chirino [EMAIL PROTECTED] wrote: I'm a big believer that 1.3 will have a ton of nice features! If you release it, users will use it :) I don't think we need to feature pack every release. It seems to me we spent a bunch of time feature packing a 1.1.x release. If we would do that to trunk instead, our 1.n releases would be more impressive. Agreed - forward progress and a visible roadmap are what users want to see. Right now Geronimo is headed pretty squarely down the path of updates every six months. IMO, we need to change that and feature packing every release is only going to keep things on that track. Bruce
Re: [VOTE] 1.1.1-rc3 (incorporates all recent comments and issues, you need to vote again)
+1 Looks good to me. John
Re: How do swing apps work?
David Jencks wrote: I fiddled around a bit and got the daytrader streamer app client to work on trunk (except I might have broker the update timer). However, to do this I had to add code so the main method doesn't return until the app exits: otherwise it returns and our app client container shuts down the kernel. How do standalone swing apps work? Do the main methods return more or less immediately or do they block somehow or get used somehow until the app is ready to close? If they return immediately can anyone suggest a way to detect that the app has exited so we can stop the kernel and exit the container? hoping someone somewhere has written a swing app :-) david jencks You probably want call jframe.addWindowListener(WindowListener l) and clean up when you get a java.awt.event.WindowEvent.WINDOW_CLOSED event. John
Re: [WELCOME] Please welcome Joe Bohn as the newest member of the Geronimo PMC
Congratulations Joe! Regards, John
Re: [PROPOSAL] Modified RTC
Matt Hogstrom wrote: *** Begin Proposal *** SNIP * Any -1 votes need to be accompanied by a reason and a mutually agreed upon solution to the issue raised. I'm not sure how the and a mutually agreed upon solution to the issue raised would work. I agree a -1 should be accompanied by a reason, but I would imagine that it could take some time for a solution to be determined and possibly longer to get mutual agreement on it. I don't think it should be be the responsibility of the person who raises the -1's to come up with a solution? For example, you test my change and find that it breaks the server, should you really be expected to debug it and come up with a solution before you can vote? I would have thought that would be responsibility of the author of the change with the help of the community. Suggesting that a solution needs to be determined and agreed upon before one can raise the -1, that seems overly restrictive to me, but maybe I'm misinterpreting your thinking. SNIP Please provide your input for this proposal. I'd like to bring this to the community for a vote this week. I agree with Kevan's later comment in this thread that we should put a summary of the three different options up for discussion and then for a vote. Regards, John
m2 bootstrap problem on trunkd
I haven't got trunk built in a while. I did an svn update and ran the
bootstrap script in cygwin and having a problem with the
openejb-builder-2.2-SNAPSHOT.jar not being found. Any ideas why this
jar isn't being published?
Thanks,
John
[INFO]
[INFO] Building Geronimo Configs :: OpenEJB Deployer
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [mkdir] Created dir:
R:\g\configs\openejb-deployer\target\classes\META-INF
[INFO] [copy] Copying 2 files to
R:\g\configs\openejb-deployer\target\classes\META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: R:\g\configs\openejb-deployer\target\plan\plan.xml
[INFO] snapshot org.openejb:openejb-builder:2.2-SNAPSHOT: checking for
updates from apache-snapshots-m1
[INFO] snapshot org.openejb:openejb-builder:2.2-SNAPSHOT: checking for
updates from apache-snapshots
[INFO] snapshot org.openejb:openejb-builder:2.2-SNAPSHOT: checking for
updates from codehaus-snapshots
[INFO] snapshot org.openejb:openejb-builder:2.2-SNAPSHOT: checking for
updates from apache.snapshots
Downloading:
http://people.apache.org/repo/m1-snapshot-repository/org.openejb/poms/openejb-builder-2.2-SNAPSHOT.pom
[WARNING] Unable to get resource from repository apache-snapshots-m1
(http://people.apache.org/repo/m1-snapshot-repository)
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPS
HOT.pom
[WARNING] Unable to get resource from repository apache-snapshots
(http://people.apache.org/repo/m2-snapshot-repository)
Downloading:
http://snapshots.repository.codehaus.org/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.pom
[WARNING] Unable to get resource from repository codehaus-snapshots
(http://snapshots.repository.codehaus.org)
Downloading:
http://people.apache.org/maven-snapshot-repository/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHO
T.pom
[WARNING] Unable to get resource from repository apache.snapshots
(http://people.apache.org/maven-snapshot-repository)
Downloading:
http://people.apache.org/repo/m1-snapshot-repository/geronimo-spec/poms/geronimo-spec-corba-1.0.pom
[WARNING] Unable to get resource from repository apache-snapshots-m1
(http://people.apache.org/repo/m1-snapshot-repository)
Downloading:
http://repository.codehaus.org/geronimo-spec/geronimo-spec-corba/1.0/geronimo-spec-corba-1.0.pom
[WARNING] Unable to get resource from repository codehaus
(http://repository.codehaus.org)
Downloading:
http://repo1.maven.org/maven2/geronimo-spec/geronimo-spec-corba/1.0/geronimo-spec-corba-1.0.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] snapshot org.openejb:openejb-pkgen-builder:2.2-SNAPSHOT: checking
for updates from apache-snapshots-m1
[INFO] snapshot org.openejb:openejb-pkgen-builder:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot org.openejb:openejb-pkgen-builder:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot org.openejb:openejb-pkgen-builder:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] snapshot org.openejb:modules:2.2-SNAPSHOT: checking for updates
from apache-snapshots-m1
[INFO] snapshot org.openejb:modules:2.2-SNAPSHOT: checking for updates
from apache-snapshots
[INFO] snapshot org.openejb:modules:2.2-SNAPSHOT: checking for updates
from codehaus-snapshots
[INFO] snapshot org.openejb:modules:2.2-SNAPSHOT: checking for updates
from apache.snapshots
[INFO] snapshot org.openejb:openejb:2.2-SNAPSHOT: checking for updates
from apache-snapshots-m1
[INFO] snapshot org.openejb:openejb:2.2-SNAPSHOT: checking for updates
from apache-snapshots
[INFO] snapshot org.openejb:openejb:2.2-SNAPSHOT: checking for updates
from codehaus-snapshots
[INFO] snapshot org.openejb:openejb:2.2-SNAPSHOT: checking for updates
from apache.snapshots
[INFO] snapshot org.openejb:openejb-core:2.2-SNAPSHOT: checking for
updates from apache-snapshots-m1
[INFO] snapshot org.openejb:openejb-core:2.2-SNAPSHOT: checking for
updates from apache-snapshots
[INFO] snapshot org.openejb:openejb-core:2.2-SNAPSHOT: checking for
updates from codehaus-snapshots
[INFO] snapshot org.openejb:openejb-core:2.2-SNAPSHOT: checking for
updates from apache.snapshots
[INFO] snapshot activecluster:activecluster:1.1-SNAPSHOT: checking for
updates from apache-snapshots-m1
[INFO] snapshot activecluster:activecluster:1.1-SNAPSHOT: checking for
updates from apache-snapshots
[INFO] snapshot activecluster:activecluster:1.1-SNAPSHOT: checking for
updates from apache.snapshots
[WARNING] POM for
Re: Upgrade Derby to 10.1.3.1?
Jacek Laskowski wrote: On 8/30/06, Jason Dillon [EMAIL PROTECTED] wrote: The latest release appears to run fine... any objections to updating server/trunk to use it? Which JIRA issue is this? Jacek See GERONIMO-2155 - but it covers also moving to the debug version of the library. John
Re: [ANNOUNCE] Welcome David Blevins as the newest member of the Geronimo PMC
Congratulations David! Regards, John Matt Hogstrom wrote: Please welcome David Blevins as the newest member of the Geronimo PMC. David recently accepted the invitation to join the PMC. David is part of the OpenEJB project that we depend on so heavily and that is joining Apache as an Incubator project. David is also a great mentor and community builder. Give it up for David :-0
Re: [VOTE] Drop the M1 build artifacts in Trunk
+1 John Matt Hogstrom wrote: Given that we are close to completing the M2 conversion and have some disruptive changes to make to trunk this vote is to capture the communities input on the structure of the Geronimo repository. Given that this is about our build environment and development structure for purposes of this vote all votes are binding. The vote is to remove Maven 1 build artificats from trunk and allow directory reoganizations starting on Wednesday August 23. Jason to notify dev list about pending changes. JIRA http://issues.apache.org/jira/browse/GERONIMO-2331 created to track issue. [ ] +1 Allow changes [ ] 0 No opinion [ ] -1 Keep M1 artifacts in place (provide rationale)
Re: wiki.apache.org/geronimo going out of production
+1 to removing both. I verified that the old wiki pages in the backup gtar.zip that Hernan produced are readable in a text editor (in case we need to take some content from it after the wiki is removed). Thanks for driving this Hernan. Regards, John Jason Dillon wrote: I think its fine to go ahead with the shutdown of out moinmoin wiki, as well as removing the old GERONIMO space at atlassian. --jason On Aug 18, 2006, at 9:02 AM, Matt Hogstrom wrote: I think Hernan was told the PMC needed to close this. I think there was some discussion on dev. No reason other than someone on the PMC needs to do this. Re-posting to dev. Anyone else have input on this? Alan D. Cabrera wrote: Is there a reason for this being in private? Sorry, I know that I'm jumping into the middle of this conversation. Regards, Alan Sent from my Verizon Wireless BlackBerry -Original Message- From: Matt Hogstrom [EMAIL PROTECTED] Date: Fri, 18 Aug 2006 11:40:22 To:[EMAIL PROTECTED] Subject: Re: Fw: wiki.apache.org/geronimo going out of production I'm in favor of this. Do we need to vote or what is the procedure for bringing this to a close? We have people updating the wrong Wiki despite some warnings. Hernan Cunico wrote: It seems like a formal request from Geronimo's PMC to the infrastructure team is in order to officially remove the previous Moin Moin wiki (wiki.apache.org/geronimo). The content from the Moin Moin wiki that was still valid and/or relevant has been migrated and integrated to the new cwiki. Outdated, duplicated or non-relevant content has not been migrated. To date, there has not been any objections about how or what content was migrated. The original Moin Moin content has been backed up and it is available for download as a gtar from the new cwiki (http://cwiki.apache.org/confluence/display/GMOxSBOX). The partially migrated Moin Moin wiki is available at http://cwiki.apache.org/confluence/display/GMOxMoinMoin . Once this process is over we should remove this confluence space. It has been a long way since we voted to move over our Moin Moin wiki to the confluence based cwiki. Taking wiki.apache.org/geronimo out of production should be the last step and will provide the proper closure to this journey. Let me know if there is any additional information I may provide to assist you with the process. Thanks in advance. Cheers! Hernan Hernan Cunico wrote: Hi guys, We have the Geronimo's wiki fully operational in confluence and would like to take the Geronimo's Moin Moin wiki configuration down. What do we need to do to remove wiki.apache.org/geronimo? Can we set a redirect pointing to the new cwiki.apache.org/geronimo? Thanks in advance. Cheers! Hernan
[jira] Commented: (GERONIMO-2332) RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all
[
http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429261
]
John Sisson commented on GERONIMO-2332:
---
Agree with Alan's objection that it should be placed elsewhere.
I tested applying it to 1.1.1 and openejb/branches/v2_1_1/openejb2 and did a
build. I had to manually apply the changes to openejb's etc/project.properties
due to a conflict with the geronimo_dependency_plugin_version that is two lines
above the change.
Assuming Alan's argument is addressed *and* the new schema jar is fixed to
contain LICENSE.txt and NOTICE.txt files under META-INF, *then I'm +1*.
One other minor point is that if one builds the schema jar with just the
{{mvn}} command instead of {{mvn -o clean install -Pgenerate-source}} they will
get a BUILD SUCCESSFUL but the JAR won't contain any classes. The only other
hint of a problem is that there is the line {{[WARNING] JAR will be empty - no
content was marked for inclusion!}}. Is there something we can do to fail the
build?
RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a
spec module so we don't need the schemas in svn at all
Key: GERONIMO-2332
URL: http://issues.apache.org/jira/browse/GERONIMO-2332
Project: Geronimo
Issue Type: RTC
Security Level: public(Regular issues)
Components: specs
Affects Versions: 1.2, 1.1.1, 1.1.2
Reporter: David Jencks
Assigned To: David Jencks
Fix For: 1.2, 1.1.1, 1.1.2
Attachments: GERONIMO-2332-1.1.patch,
GERONIMO-2332-openejb-2.1.patch, GERONIMO-2332-trunk.patch,
geronimo-schema_1.4_spec-generated-src.zip, geronimo-schema_1.4_spec-src.zip
See GERONIMO-2307. It seems that the option with the least legal exposure is
to not distribute and sun schema files and not have any in our svn. This is
a proposed spec module that uses a m2 profile to pull the schemas from suns
website (where they are freely available), run xmlbeans on them, and remove
the copies of the schemas that xmlbeasn helpfully tries to include in the
output. We can then check this stuff into svn.
A normal non-profile build then just builds these sources into a jar. We can
replace the xmlbeans step in j2ee-schema with a geronimo dependency on this
new spec jar.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congratulations Alan! Regards, John Matt Hogstrom wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC
Re: [WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
Congratulations Guillaume! Regards, John Matt Hogstrom wrote: All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. The Apache Geronimo PMC
[jira] Commented: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=comments#action_12428914 ] John Sisson commented on GERONIMO-2307: --- Where does it say that they are under the Berkley license? We should document the source of this information if this is the case. I just looked at j2ee-schema\src\resources\schemaorg_apache_xmlbeans\src\modules\j2ee-schema\src\j2ee_1_2dtd\application_1_2.dtd and it has similar wording to the schemas regarding written authorization. Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: Geir Magnusson Jr Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application-client_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/connector_1_5.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/ejb-jar_2_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_jaxrpc_mapping_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_client_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/jsp_2_0.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/web-app_2_4.xsd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application-client_1_2.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application_1_2.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/ejb-jar_1_1.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-app_2_2.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-jsptaglibrary_1_1.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application-client_1_3.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application_1_3.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/connector_1_0.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/ejb-jar_2_0.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-app_2_3.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-jsptaglibrary_1_2.dtd|| -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Build error on 1.1.1 branch geronimo rev 430687, openejb rev 2844?
Anyone know of any changes that could have broken it? I have tried the build on windows and solaris and get the same error. John + | configurations openejb Configuration for performing J2EE deployments | Memory: 49M/78M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download openejb-builder-2.1.1-SNAPSHOT.jar. build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory R:\1.1.1\configs\openejb-deployer\target\repository [mkdir] Created dir: R:\1.1.1\configs\openejb-deployer\target\repository Packaging configuration R:\1.1.1\configs\openejb-deployer\target\plan\plan.xml 13:26:47,140 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$2dd00db1.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:472) at org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:332) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.plugin.packaging.PackageBuilderShell.execute(PackageBuilderShell.java:291) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:180) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:102) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at
Re: Build error on 1.1.1 branch geronimo rev 430687, openejb rev 2844?
I cheated - I wasn't running tests :-) John Kevan Miller wrote: I'm not getting that far... I'm getting a test failure in modules/activation: test:test: [junit] Running org.apache.geronimo.activation.handlers.MailcapTest [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.237 sec [junit] [ERROR] Test org.apache.geronimo.activation.handlers.MailcapTest FAILED [junit] Running org.apache.geronimo.activation.handlers.TextHtmlTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.026 sec [junit] Running org.apache.geronimo.activation.handlers.TextPlainTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.03 sec [junit] Running org.apache.geronimo.activation.handlers.TextXmlTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.011 sec --kevan On Aug 11, 2006, at 2:33 AM, John Sisson wrote: Anyone know of any changes that could have broken it? I have tried the build on windows and solaris and get the same error. John + | configurations openejb Configuration for performing J2EE deployments | Memory: 49M/78M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download openejb-builder-2.1.1-SNAPSHOT.jar. build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory R:\1.1.1\configs\openejb-deployer\target\repository [mkdir] Created dir: R:\1.1.1\configs\openejb-deployer\target\repository Packaging configuration R:\1.1.1\configs\openejb-deployer\target\plan\plan.xml 13:26:47,140 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$2dd00db1.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:472) at org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:332) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method
[jira] Created: (GERONIMO-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file -- Key: GERONIMO-2308 URL: http://issues.apache.org/jira/browse/GERONIMO-2308 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.1, 1.0 Reporter: John Sisson Assigned To: John Sisson Priority: Blocker Fix For: 1.1.1 Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) applications\console-core (x) applications\console-ear (x) applications\console-framework (x) applications\console-standard (x) applications\daytrader (x) applications\demo (x) applications\ldap-realm-demo (x) applications\magicGball (x) applications\project.properties (x) applications\remote-deploy (x) applications\remote-deploy-lib (x) applications\uddi-db (x) applications\uddi-server (x) applications\welcome (x) modules\activation (x) modules\activemq-embedded-rar (x) modules\axis (x) modules\axis-builder (x) modules\client (x) modules\client-builder (x) modules\common (x) modules\connector (x) modules\connector-builder (x) modules\console-web (x) modules\converter (x) modules\core (x) modules\deploy-config (x) modules\deploy-jsr88 (x) modules\deploy-tool (x) modules\deployment (x) modules\derby (x) modules\directory (x) modules\hot-deploy (x) modules\installer-processing (x) modules\installer-support (x) modules\j2ee (x) modules\j2ee-builder (x) modules\j2ee-schema (x) modules\javamail-transport (x) modules\jetty (x) modules\jetty-builder (x) modules\jmx-remoting (x) modules\kernel (x) modules\mail (x) modules\management (x) modules\naming (x) modules\naming-builder (x) modules\project.properties (x) modules\scripts (x) modules\security (x) modules\security-builder (x) modules\service-builder (x) modules\system (x) modules\test-ddbean (x) modules\timer (x) modules\tomcat (x) modules\tomcat-builder (x) modules\transaction (x) modules\upgrade (x) modules\util (x) modules\web-builder (x) modules\webservices -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Daytrader config exceptions in 1.1.1 branch
Does anyone else get this problem or is it just me ? John + | configurations Daytrader using derby deployed on jetty | Memory: 47M/60M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download geronimo-daytrader-derby-db-1.1.1-SNAPSHOT.jar. Attempting to download openejb-1.1.1-SNAPSHOT.car. build:start: multiproject:install-callback: [echo] Running car:install for Daytrader using derby deployed on jetty car:prepare-plan: car:package: [mkdir] Created dir: R:\dev\g-br-1.1.1\configs\daytrader-jetty\target\repository Packaging configuration R:\dev\g-br-1.1.1\configs\daytrader-jetty\target\plan\plan.xml Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. 22:04:03,140 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 22:04:03,937 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geroni mo.apache.org 22:04:04,078 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 22:04:04,171 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 22:04:04,265 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geroni mo.apache.org 22:04:04,359 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 22:04:04,453 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.g eronimo.apache.org 22:04:04,531 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.g eronimo.apache.org 22:04:04,625 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples .geronimo.apache.org 22:04:05,750 ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: Could not load servlet class org.apache.geronimo .samples.daytrader.web.prims.PingServlet2Session2EntityCollection org.apache.geronimo.common.DeploymentException: Could not load servlet class org.apache.geronimo.samples.daytrader.web.prims.PingSer vlet2Session2EntityCollection at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addServlet(JettyModuleBuilder.java:830) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addServlets(JettyModuleBuilder.java:790) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:697) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder$$FastClassByCGLIB$$b30bba8a.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$8ebe45b4.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:162) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$8ebe45b4.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:562) at
[jira] Commented: (GERONIMO-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[
http://issues.apache.org/jira/browse/GERONIMO-2308?page=comments#action_12427183
]
John Sisson commented on GERONIMO-2308:
---
The issue in 1.1 ( I haven't checked trunk yet) is that although the files may
be there, only the NOTICE.txt file is included in the jar. It appears the
LICENSE.txt file is automatically included by the JAR plugin.
The NOTICE.txt file can be included in JARs by making the following changes to
the project.xml files:
{noformat}
+resources
+ resource
+directory${basedir}/directory
+ includes
+includeNOTICE.txt/include
+ /includes
+ targetPathMETA-INF/targetPath
+ /resource
+/resources
{noformat}
All Geronimo JARs should include a NOTICE.txt file in addition to the
LICENSE.txt file
--
Key: GERONIMO-2308
URL: http://issues.apache.org/jira/browse/GERONIMO-2308
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.0, 1.1
Reporter: John Sisson
Assigned To: John Sisson
Priority: Blocker
Fix For: 1.1.1
Currently Geronimo jars (e.g. the JARs for each application/module) do not
contain a NOTICE.txt file under the META-INF directory.
The NOTICE.txt files in modules needs to contain attributions that are
relevant for that module (not Geronimo as a whole). For example, if the
module has a dependency on a library that has a license requiring
attributions upon use of the library (e.g. it has wording Redistribution and
use of this software in the library license) then the module using the
library should contain the attribution in the NOTICE.txt file.
Whilst reviewing attributions, the LICENSE.txt files for the modules and
applications should also be updated to include the relevant licenses.
The following is a checklist to help track what has been done, in case
someone wants to help out :-)
(x) applications\console-core
(x) applications\console-ear
(x) applications\console-framework
(x) applications\console-standard
(x) applications\daytrader
(x) applications\demo
(x) applications\ldap-realm-demo
(x) applications\magicGball
(x) applications\project.properties
(x) applications\remote-deploy
(x) applications\remote-deploy-lib
(x) applications\uddi-db
(x) applications\uddi-server
(x) applications\welcome
(x) modules\activation
(x) modules\activemq-embedded-rar
(x) modules\axis
(x) modules\axis-builder
(x) modules\client
(x) modules\client-builder
(x) modules\common
(x) modules\connector
(x) modules\connector-builder
(x) modules\console-web
(x) modules\converter
(x) modules\core
(x) modules\deploy-config
(x) modules\deploy-jsr88
(x) modules\deploy-tool
(x) modules\deployment
(x) modules\derby
(x) modules\directory
(x) modules\hot-deploy
(x) modules\installer-processing
(x) modules\installer-support
(x) modules\j2ee
(x) modules\j2ee-builder
(x) modules\j2ee-schema
(x) modules\javamail-transport
(x) modules\jetty
(x) modules\jetty-builder
(x) modules\jmx-remoting
(x) modules\kernel
(x) modules\mail
(x) modules\management
(x) modules\naming
(x) modules\naming-builder
(x) modules\project.properties
(x) modules\scripts
(x) modules\security
(x) modules\security-builder
(x) modules\service-builder
(x) modules\system
(x) modules\test-ddbean
(x) modules\timer
(x) modules\tomcat
(x) modules\tomcat-builder
(x) modules\transaction
(x) modules\upgrade
(x) modules\util
(x) modules\web-builder
(x) modules\webservices
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2308?page=comments#action_12427184 ] John Sisson commented on GERONIMO-2308: --- Correction to previous comment... only the LICENCE.txt file is included in the jar. All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file -- Key: GERONIMO-2308 URL: http://issues.apache.org/jira/browse/GERONIMO-2308 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: John Sisson Priority: Blocker Fix For: 1.1.1 Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) applications\console-core (x) applications\console-ear (x) applications\console-framework (x) applications\console-standard (x) applications\daytrader (x) applications\demo (x) applications\ldap-realm-demo (x) applications\magicGball (x) applications\project.properties (x) applications\remote-deploy (x) applications\remote-deploy-lib (x) applications\uddi-db (x) applications\uddi-server (x) applications\welcome (x) modules\activation (x) modules\activemq-embedded-rar (x) modules\axis (x) modules\axis-builder (x) modules\client (x) modules\client-builder (x) modules\common (x) modules\connector (x) modules\connector-builder (x) modules\console-web (x) modules\converter (x) modules\core (x) modules\deploy-config (x) modules\deploy-jsr88 (x) modules\deploy-tool (x) modules\deployment (x) modules\derby (x) modules\directory (x) modules\hot-deploy (x) modules\installer-processing (x) modules\installer-support (x) modules\j2ee (x) modules\j2ee-builder (x) modules\j2ee-schema (x) modules\javamail-transport (x) modules\jetty (x) modules\jetty-builder (x) modules\jmx-remoting (x) modules\kernel (x) modules\mail (x) modules\management (x) modules\naming (x) modules\naming-builder (x) modules\project.properties (x) modules\scripts (x) modules\security (x) modules\security-builder (x) modules\service-builder (x) modules\system (x) modules\test-ddbean (x) modules\timer (x) modules\tomcat (x) modules\tomcat-builder (x) modules\transaction (x) modules\upgrade (x) modules\util (x) modules\web-builder (x) modules\webservices -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2308?page=all ] John Sisson updated GERONIMO-2308: -- Description: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(x)|(x)|applications\console-core| | |(x)|(x)|(x)|applications\console-ear|Include concurrent license| |(x)|(x)|(x)|applications\console-framework| | |(x)|(x)|(x)|applications\console-standard| | |(x)|(x)|(x)|applications\daytrader| | |(x)|(x)|(x)|applications\demo| | |(x)|(x)|(x)|applications\ldap-realm-demo| | |(x)|(x)|(x)|applications\magicGball| | |(x)|(x)|(x)|applications\project.properties| | |(x)|(x)|(x)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(x)|(x)|applications\uddi-db| | |(x)|(x)|(x)|applications\uddi-server| | |(x)|(x)|(x)|applications\welcome| | |(x)|(x)|(x)|modules\activation| | |(x)|(x)|(x)|modules\activemq-embedded-rar| | |(x)|(x)|(x)|modules\axis| | |(x)|(x)|(x)|modules\axis-builder| | |(x)|(x)|(x)|modules\client| | |(x)|(x)|(x)|modules\client-builder| | |(x)|(x)|(x)|modules\common| | |(x)|(x)|(x)|modules\connector| | |(x)|(x)|(x)|modules\connector-builder| | |(x)|(x)|(x)|modules\console-web| | |(x)|(x)|(x)|modules\converter| | |(x)|(x)|(x)|modules\core| | |(x)|(x)|(x)|modules\deploy-config| | |(x)|(x)|(x)|modules\deploy-jsr88| | |(x)|(x)|(x)|modules\deploy-tool| | |(x)|(x)|(x)|modules\deployment| | |(x)|(x)|(x)|modules\derby| | |(x)|(x)|(x)|modules\directory| | |(x)|(x)|(x)|modules\hot-deploy| | |(x)|(x)|(x)|modules\installer-processing| | |(x)|(x)|(x)|modules\installer-support| | |(x)|(x)|(x)|modules\j2ee| | |(x)|(x)|(x)|modules\j2ee-builder| | |(x)|(x)|(x)|modules\j2ee-schema| | |(x)|(x)|(x)|modules\javamail-transport| | |(x)|(x)|(x)|modules\jetty| | |(x)|(x)|(x)|modules\jetty-builder| | |(x)|(x)|(x)|modules\jmx-remoting| | |(x)|(x)|(x)|modules\kernel| | |(x)|(x)|(x)|modules\mail| | |(x)|(x)|(x)|modules\management| | |(x)|(x)|(x)|modules\naming| | |(x)|(x)|(x)|modules\naming-builder| | |(x)|(x)|(x)|modules\project.properties| | |(x)|(x)|(x)|modules\scripts| | |(x)|(x)|(x)|modules\security| | |(x)|(x)|(x)|modules\security-builder| | |(x)|(x)|(x)|modules\service-builder| | |(x)|(x)|(x)|modules\system| | |(x)|(x)|(x)|modules\test-ddbean| | |(x)|(x)|(x)|modules\timer| | |(x)|(x)|(x)|modules\tomcat| | |(x)|(x)|(x)|modules\tomcat-builder| | |(x)|(x)|(x)|modules\transaction| | |(x)|(x)|(x)|modules\upgrade| | |(x)|(x)|(x)|modules\util| | |(x)|(x)|(x)|modules\web-builder| | |(x)|(x)|(x)|modules\webservices| | was: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(x)|applications\console-core| | |(x)|(x)|applications\console-ear|Include concurrent license| |(x)|(x)|applications\console-framework| | |(x)|(x)|applications\console-standard| | |(x)|(x)|applications\daytrader| | |(x)|(x)|applications\demo| | |(x)|(x)|applications\ldap-realm-demo| | |(x)|(x)|applications\magicGball| | |(x)|(x)|applications\project.properties| | |(x)|(x)|applications\remote-deploy| | |(x)|(x)|applications\remote-deploy-lib| | |(x)|(x)|applications\uddi-db| | |(x)|(x)|applications\uddi-server| | |(x)|(x)|applications\welcome| | |(x)|(x)|modules\activation| | |(x)|(x)|modules\activemq-embedded-rar| | |(x)|(x)|modules\axis| | |(x)|(x)|modules\axis-builder| | |(x)|(x)|modules\client| | |(x)|(x)|modules\client-builder| | |(x
[jira] Updated: (GERONIMO-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2308?page=all ] John Sisson updated GERONIMO-2308: -- Description: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(/)|(/)|applications\console-core| | |(x)|(/)|(/)|applications\console-ear|Include concurrent license| |(x)|(x)|(x)|applications\console-framework| | |(x)|(x)|(x)|applications\console-standard| | |(x)|(x)|(x)|applications\daytrader| | |(x)|(x)|(x)|applications\demo| | |(x)|(x)|(x)|applications\ldap-realm-demo| | |(x)|(x)|(x)|applications\magicGball| | |(x)|(x)|(x)|applications\project.properties| | |(x)|(x)|(x)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(x)|(x)|applications\uddi-db| | |(x)|(x)|(x)|applications\uddi-server| | |(x)|(x)|(x)|applications\welcome| | |(x)|(x)|(x)|modules\activation| | |(x)|(x)|(x)|modules\activemq-embedded-rar| | |(x)|(x)|(x)|modules\axis| | |(x)|(x)|(x)|modules\axis-builder| | |(x)|(x)|(x)|modules\client| | |(x)|(x)|(x)|modules\client-builder| | |(x)|(x)|(x)|modules\common| | |(x)|(x)|(x)|modules\connector| | |(x)|(x)|(x)|modules\connector-builder| | |(x)|(x)|(x)|modules\console-web| | |(x)|(x)|(x)|modules\converter| | |(x)|(x)|(x)|modules\core| | |(x)|(x)|(x)|modules\deploy-config| | |(x)|(x)|(x)|modules\deploy-jsr88| | |(x)|(x)|(x)|modules\deploy-tool| | |(x)|(x)|(x)|modules\deployment| | |(x)|(x)|(x)|modules\derby| | |(x)|(x)|(x)|modules\directory| | |(x)|(x)|(x)|modules\hot-deploy| | |(x)|(x)|(x)|modules\installer-processing| | |(x)|(x)|(x)|modules\installer-support| | |(x)|(x)|(x)|modules\j2ee| | |(x)|(x)|(x)|modules\j2ee-builder| | |(x)|(x)|(x)|modules\j2ee-schema| | |(x)|(x)|(x)|modules\javamail-transport| | |(x)|(x)|(x)|modules\jetty| | |(x)|(x)|(x)|modules\jetty-builder| | |(x)|(x)|(x)|modules\jmx-remoting| | |(x)|(x)|(x)|modules\kernel| | |(x)|(x)|(x)|modules\mail| | |(x)|(x)|(x)|modules\management| | |(x)|(x)|(x)|modules\naming| | |(x)|(x)|(x)|modules\naming-builder| | |(x)|(x)|(x)|modules\project.properties| | |(x)|(x)|(x)|modules\scripts| | |(x)|(x)|(x)|modules\security| | |(x)|(x)|(x)|modules\security-builder| | |(x)|(x)|(x)|modules\service-builder| | |(x)|(x)|(x)|modules\system| | |(x)|(x)|(x)|modules\test-ddbean| | |(x)|(x)|(x)|modules\timer| | |(x)|(x)|(x)|modules\tomcat| | |(x)|(x)|(x)|modules\tomcat-builder| | |(x)|(x)|(x)|modules\transaction| | |(x)|(x)|(x)|modules\upgrade| | |(x)|(x)|(x)|modules\util| | |(x)|(x)|(x)|modules\web-builder| | |(x)|(x)|(x)|modules\webservices| | was: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(x)|(x)|applications\console-core| | |(x)|(x)|(x)|applications\console-ear|Include concurrent license| |(x)|(x)|(x)|applications\console-framework| | |(x)|(x)|(x)|applications\console-standard| | |(x)|(x)|(x)|applications\daytrader| | |(x)|(x)|(x)|applications\demo| | |(x)|(x)|(x)|applications\ldap-realm-demo| | |(x)|(x)|(x)|applications\magicGball| | |(x)|(x)|(x)|applications\project.properties| | |(x)|(x)|(x)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(x)|(x)|applications\uddi-db| | |(x)|(x)|(x)|applications\uddi-server| | |(x)|(x)|(x)|applications\welcome| | |(x)|(x)|(x)|modules\activation| | |(x)|(x)|(x)|modules\activemq-embedded-rar| | |(x)|(x)|(x)|modules\axis| | |(x)|(x)|(x)|modules\axis
[jira] Updated: (GERONIMO-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2308?page=all ] John Sisson updated GERONIMO-2308: -- Description: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(?)|(?)|applications\console-core| Notice needs IBM attribution| |(x)|(?)|(?)|applications\console-ear|Notice needs IBM attribution| |(x)|(?)|(?)|applications\console-framework|Notice needs IBM attribution| |(x)|(?)|(?)|applications\console-standard|Notice needs IBM attribution| |(x)|(/)|(/)|applications\daytrader| | |(x)|(x)|(x)|applications\demo| | |(x)|(x)|(x)|applications\ldap-realm-demo| | |(x)|(x)|(x)|applications\magicGball| | |(x)|(x)|(x)|applications\project.properties| | |(x)|(x)|(x)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(x)|(x)|applications\uddi-db| | |(x)|(x)|(x)|applications\uddi-server| | |(x)|(x)|(x)|applications\welcome| | |(x)|(x)|(x)|modules\activation| | |(x)|(x)|(x)|modules\activemq-embedded-rar| | |(x)|(x)|(x)|modules\axis| | |(x)|(x)|(x)|modules\axis-builder| | |(x)|(x)|(x)|modules\client| | |(x)|(x)|(x)|modules\client-builder| | |(x)|(x)|(x)|modules\common| | |(x)|(x)|(x)|modules\connector| | |(x)|(x)|(x)|modules\connector-builder| | |(x)|(x)|(x)|modules\console-web| | |(x)|(x)|(x)|modules\converter| | |(x)|(x)|(x)|modules\core| | |(x)|(x)|(x)|modules\deploy-config| | |(x)|(x)|(x)|modules\deploy-jsr88| | |(x)|(x)|(x)|modules\deploy-tool| | |(x)|(x)|(x)|modules\deployment| | |(x)|(x)|(x)|modules\derby| | |(x)|(x)|(x)|modules\directory| | |(x)|(x)|(x)|modules\hot-deploy| | |(x)|(x)|(x)|modules\installer-processing| | |(x)|(x)|(x)|modules\installer-support| | |(x)|(x)|(x)|modules\j2ee| | |(x)|(x)|(x)|modules\j2ee-builder| | |(x)|(x)|(x)|modules\j2ee-schema| | |(x)|(x)|(x)|modules\javamail-transport| | |(x)|(x)|(x)|modules\jetty| | |(x)|(x)|(x)|modules\jetty-builder| | |(x)|(x)|(x)|modules\jmx-remoting| | |(x)|(x)|(x)|modules\kernel| | |(x)|(x)|(x)|modules\mail| | |(x)|(x)|(x)|modules\management| | |(x)|(x)|(x)|modules\naming| | |(x)|(x)|(x)|modules\naming-builder| | |(x)|(x)|(x)|modules\project.properties| | |(x)|(x)|(x)|modules\scripts| | |(x)|(x)|(x)|modules\security| | |(x)|(x)|(x)|modules\security-builder| | |(x)|(x)|(x)|modules\service-builder| | |(x)|(x)|(x)|modules\system| | |(x)|(x)|(x)|modules\test-ddbean| | |(x)|(x)|(x)|modules\timer| | |(x)|(x)|(x)|modules\tomcat| | |(x)|(x)|(x)|modules\tomcat-builder| | |(x)|(x)|(x)|modules\transaction| | |(x)|(x)|(x)|modules\upgrade| | |(x)|(x)|(x)|modules\util| | |(x)|(x)|(x)|modules\web-builder| | |(x)|(x)|(x)|modules\webservices| | was: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(/)|(/)|applications\console-core| | |(x)|(/)|(/)|applications\console-ear|Include concurrent license| |(x)|(x)|(x)|applications\console-framework| | |(x)|(x)|(x)|applications\console-standard| | |(x)|(x)|(x)|applications\daytrader| | |(x)|(x)|(x)|applications\demo| | |(x)|(x)|(x)|applications\ldap-realm-demo| | |(x)|(x)|(x)|applications\magicGball| | |(x)|(x)|(x)|applications\project.properties| | |(x)|(x)|(x)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(x)|(x)|applications\uddi-db| | |(x)|(x)|(x)|applications\uddi-server| | |(x)|(x)|(x)|applications\welcome| | |(x)|(x)|(x)|modules\activation| | |(x)|(x)|(x)|modules
[jira] Updated: (GERONIMO-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2308?page=all ] John Sisson updated GERONIMO-2308: -- Description: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(?)|(?)|applications\console-core| Notice needs IBM attribution| |(x)|(?)|(?)|applications\console-ear|Notice needs IBM attribution| |(x)|(x)|(x)|applications\console-framework|Notice needs IBM attribution| |(x)|(x)|(x)|applications\console-standard|Notice needs IBM attribution| |(x)|(/)|(/)|applications\daytrader| | |(x)|(x)|(x)|applications\demo| | |(x)|(x)|(x)|applications\ldap-realm-demo| | |(x)|(x)|(x)|applications\magicGball| | |(x)|(x)|(x)|applications\project.properties| | |(x)|(x)|(x)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(x)|(x)|applications\uddi-db| | |(x)|(x)|(x)|applications\uddi-server| | |(x)|(x)|(x)|applications\welcome| | |(x)|(x)|(x)|modules\activation| | |(x)|(x)|(x)|modules\activemq-embedded-rar| | |(x)|(x)|(x)|modules\axis| | |(x)|(x)|(x)|modules\axis-builder| | |(x)|(x)|(x)|modules\client| | |(x)|(x)|(x)|modules\client-builder| | |(x)|(x)|(x)|modules\common| | |(x)|(x)|(x)|modules\connector| | |(x)|(x)|(x)|modules\connector-builder| | |(x)|(x)|(x)|modules\console-web| | |(x)|(x)|(x)|modules\converter| | |(x)|(x)|(x)|modules\core| | |(x)|(x)|(x)|modules\deploy-config| | |(x)|(x)|(x)|modules\deploy-jsr88| | |(x)|(x)|(x)|modules\deploy-tool| | |(x)|(x)|(x)|modules\deployment| | |(x)|(x)|(x)|modules\derby| | |(x)|(x)|(x)|modules\directory| | |(x)|(x)|(x)|modules\hot-deploy| | |(x)|(x)|(x)|modules\installer-processing| | |(x)|(x)|(x)|modules\installer-support| | |(x)|(x)|(x)|modules\j2ee| | |(x)|(x)|(x)|modules\j2ee-builder| | |(x)|(x)|(x)|modules\j2ee-schema| | |(x)|(x)|(x)|modules\javamail-transport| | |(x)|(x)|(x)|modules\jetty| | |(x)|(x)|(x)|modules\jetty-builder| | |(x)|(x)|(x)|modules\jmx-remoting| | |(x)|(x)|(x)|modules\kernel| | |(x)|(x)|(x)|modules\mail| | |(x)|(x)|(x)|modules\management| | |(x)|(x)|(x)|modules\naming| | |(x)|(x)|(x)|modules\naming-builder| | |(x)|(x)|(x)|modules\project.properties| | |(x)|(x)|(x)|modules\scripts| | |(x)|(x)|(x)|modules\security| | |(x)|(x)|(x)|modules\security-builder| | |(x)|(x)|(x)|modules\service-builder| | |(x)|(x)|(x)|modules\system| | |(x)|(x)|(x)|modules\test-ddbean| | |(x)|(x)|(x)|modules\timer| | |(x)|(x)|(x)|modules\tomcat| | |(x)|(x)|(x)|modules\tomcat-builder| | |(x)|(x)|(x)|modules\transaction| | |(x)|(x)|(x)|modules\upgrade| | |(x)|(x)|(x)|modules\util| | |(x)|(x)|(x)|modules\web-builder| | |(x)|(x)|(x)|modules\webservices| | was: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(?)|(?)|applications\console-core| Notice needs IBM attribution| |(x)|(?)|(?)|applications\console-ear|Notice needs IBM attribution| |(x)|(?)|(?)|applications\console-framework|Notice needs IBM attribution| |(x)|(?)|(?)|applications\console-standard|Notice needs IBM attribution| |(x)|(/)|(/)|applications\daytrader| | |(x)|(x)|(x)|applications\demo| | |(x)|(x)|(x)|applications\ldap-realm-demo| | |(x)|(x)|(x)|applications\magicGball| | |(x)|(x)|(x)|applications\project.properties| | |(x)|(x)|(x)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(x)|(x)|applications\uddi-db| | |(x)|(x)|(x)|applications\uddi-server| | |(x)|(x)|(x
[jira] Updated: (GERONIMO-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2308?page=all ] John Sisson updated GERONIMO-2308: -- Description: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(/)|(/)|applications\console-core| Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-ear|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-framework|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-standard|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\daytrader| | |(x)|(/)|(/)|applications\demo| | |(x)|(/)|(/)|applications\ldap-realm-demo| | |(x)|(/)|(/)|applications\magicGball| | |(x)|(/)|(/)|applications\project.properties| | |(x)|(/)|(/)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(/)|(/)|applications\uddi-db| | |(x)|(/)|(/)|applications\uddi-server| | |(x)|(/)|(/)|applications\welcome| | |(?)|(x)|(x)|modules\activation| | |(x)|(x)|(x)|modules\activemq-embedded-rar| | |(?)|(x)|(x)|modules\axis| | |(?)|(x)|(x)|modules\axis-builder| | |(?)|(x)|(x)|modules\client| | |(?)|(x)|(x)|modules\client-builder| | |(?)|(x)|(x)|modules\common| | |(?)|(x)|(x)|modules\connector| | |(?)|(x)|(x)|modules\connector-builder| | |(/)|(x)|(x)|modules\console-web| (Won't fix in trunk) | |(?)|(x)|(x)|modules\converter| | |(?)|(x)|(x)|modules\core| | |(?)|(x)|(x)|modules\deploy-config| | |(?)|(x)|(x)|modules\deploy-jsr88| | |(?)|(x)|(x)|modules\deploy-tool| | |(?)|(x)|(x)|modules\deployment| | |(?)|(x)|(x)|modules\derby| | |(?)|(x)|(x)|modules\directory| | |(?)|(x)|(x)|modules\hot-deploy| | |(?)|(x)|(x)|modules\installer-processing| | |(?)|(x)|(x)|modules\installer-support| | |(?)|(x)|(x)|modules\j2ee| | |(?)|(x)|(x)|modules\j2ee-builder| | |(?)|(x)|(x)|modules\j2ee-schema| | |(/)|(x)|(x)|modules\javamail-transport| (No longer in trunk) | |(?)|(x)|(x)|modules\jetty| | |(?)|(x)|(x)|modules\jetty-builder| | |(?)|(x)|(x)|modules\jmx-remoting| | |(?)|(x)|(x)|modules\kernel| | |(?)|(x)|(x)|modules\mail| | |(?)|(x)|(x)|modules\management| | |(?)|(x)|(x)|modules\naming| | |(?)|(x)|(x)|modules\naming-builder| | |(/)|(x)|(x)|modules\scripts| (Not distributed) | |(?)|(x)|(x)|modules\security| | |(?)|(x)|(x)|modules\security-builder| | |(?)|(x)|(x)|modules\service-builder| | |(?)|(x)|(x)|modules\system| | |(?)|(x)|(x)|modules\test-ddbean| | |(?)|(x)|(x)|modules\timer| | |(?)|(x)|(x)|modules\tomcat| | |(?)|(x)|(x)|modules\tomcat-builder| | |(?)|(x)|(x)|modules\transaction| | |(?)|(x)|(x)|modules\upgrade| | |(?)|(x)|(x)|modules\util| | |(?)|(x)|(x)|modules\web-builder| | |(?)|(x)|(x)|modules\webservices| | was: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(?)|(?)|applications\console-core| Notice needs IBM attribution| |(x)|(?)|(?)|applications\console-ear|Notice needs IBM attribution| |(x)|(x)|(x)|applications\console-framework|Notice needs IBM attribution| |(x)|(x)|(x)|applications\console-standard|Notice needs IBM attribution| |(x)|(/)|(/)|applications\daytrader| | |(x)|(x)|(x)|applications\demo| | |(x)|(x)|(x)|applications\ldap-realm-demo| | |(x)|(x)|(x)|applications\magicGball| | |(x)|(x)|(x)|applications\project.properties| | |(x)|(x)|(x)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(x)|(x)|applications\uddi-db| | |(x)|(x)|(x)|applications\uddi
Re: Merge fix for GERONIMO-2305 into 1.1.1?
I think we should have it in 1.1.1 - seems to fit the blocker category to me. John David Jencks wrote: I'm not quite sure where the 1.1.1 release is, so I'm asking if we should merge in dain's fix for g-2305. The problem is that if you get a resource url from our classloader for something in the app URL url = cl.getResource(file1.xml); and then try to use that url to construct a related url: URL url2 = new URL(url, somethingelse.xml); the second url doesn't work because we put a UrlStreamHandler in the first url that only works with that first url, and the url constructor used for url2 uses that same UrlStreamHandler. The fix is to make the UrlStreamHandler work for any path into the same jar, and use normal mechanisms for paths outside the jar. This breaks trinidad (part of myfaces IIUC) and seems like a fairly serious error. IMO there is extremely little danger of the fix breaking anything that used to work, since the code path that is changed used to throw an exception. The fix does allow the user's sample app to work. I'm leaning towards recommending adding it to 1.1.1. thanks david jencks
Re: maven m:eclipse issue on 1.1 in OpenEJB itests
I worked out that this zip wasn't in the local repository because my build script was specifying -Dgeronimo.assembly.zip=false, Doh! Thanks for your help Kevan. John Kevan Miller wrote: On Aug 9, 2006, at 10:04 PM, John Sisson wrote: I am trying to build the eclipse project files for a clean 1.1 build. I did the following: * svn co https://svn.apache.org/repos/asf/geronimo/branches/1.1 * cd 1.1 * maven m:fresh-checkout * maven new * maven m:eclipse -o The m:eclipse processing fails in OpenEJB itests. How do I get the geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip file to be placed in my local repository as part of the build so it doesn't fail? Sorry to ask the obvious, but are you sure 'maven new' completed successfully? I end up with the zip file in .maven/repository/geronimo/distributions/ One additional note, I have to run 'maven m:eclipse' online the first time. Otherwise, there's a missing dependency for maven-itest-plugin-1.0.jar. Since we don't currently run itests, 'maven new' doesn't download the dependency. Suppose we could figure out how to exclude OpenEJB itest from the m:eclipse goal... --kevan Thanks, John SNIP [echo] Place java sources for xstream at R:\.geronimo-1.1.x-maven\repository\xstream\java-sources\xstream-1.1.3-sources.jar for javadoc and debugging support in Eclipse [echo] Place java sources for xpp3 at R:\.geronimo-1.1.x-maven\repository\xpp3\java-sources\xpp3-1.1.3.3-sources.jar for javadoc and debugging support in Eclipse [echo] Place java sources for commons-jelly-tags-velocity at R:\.geronimo-1.1.x-maven\repository\commons-jelly\java-sources\comm ons-jelly-tags-velocity-1.0-sources.jar for javadoc and debugging support in Eclipse [echo] Place java sources for velocity at R:\.geronimo-1.1.x-maven\repository\velocity\java-sources\velocity-1.4-sources.jar for javadoc and debugging support in Eclipse [echo] Setting default output directory to target/classes [echo] Now refresh your project in Eclipse (right click on the project and select Refresh) + | Executing eclipse OpenEJB :: Integration Tests | Memory: 27M/32M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml eclipse: build:end: You are working offline so the build will continue, but openejb-builder-2.1.2-SNAPSHOT.jar may be out of date! BUILD FAILED File.. R:\.geronimo-1.1.x-maven\cache\maven-multiproject-plugin-1.4.1\plugin.jelly Element... maven:reactor Line.. 218 Column -1 The build cannot continue because of the following unsatisfied dependency: geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip Total time : 6 minutes 37 seconds Finished at : Thursday, 10 August 2006 10:33:27
Re: Accessing the openejb code?
It appears https access for OpenEJB non-committers isn't available any more. AFAIK the maven build scripts have been updated to take this into account, but to be able to use them you will need to do an svn update manually, delete the openejb directory and then try a maven m:fresh-checkout . Regards, John Rick McGuire wrote: I just got back from a 2 week vacation and am trying to get caught back up again. When I do a maven m:update on my working build from 2 weeks ago, I'm getting the following message followed by a hang: m:update: [exec] At revision 430039. [exec] Authentication realm: https://svn.codehaus.org:443 openejb Repo I get similar behavior when I checkout out a fresh build and do a maven m:fresh-checkout. Is this a glitch with the codehaus svn or should I be using something else now to access a build? Rick
Re: Accessing the openejb code?
Sorry, wasn't completely clear. If you didn't have changes in openejb to preserve then the following should work: 1. do an svn update of geronimo (not openejb) so you get the updated maven.xml file 2. delete the openejb folder under geronimo 3. do a maven m:fresh-checkout in the geronimo directory - this will then check out openejb using http instead of https. But since you do have updates to preserve you could try using the svn switch command, e.g. ( I haven't tested this..) svn switch --relocate https://svn.codehaus.org/openejb/branches/v2_1/openejb2 http://svn.codehaus.org/openejb/branches/v2_1/openejb2 John Rick McGuire wrote: John Sisson wrote: It appears https access for OpenEJB non-committers isn't available any more. AFAIK the maven build scripts have been updated to take this into account, but to be able to use them you will need to do an svn update manually, delete the openejb directory and then try a maven m:fresh-checkout . I'm not sure I understand this. If I try to do a svn update manually, it still requests authenticationand I certainly don't want to delete the openejb dir, because I've got working updates I need to preserve. I also would have thought that checking out a fresh copy would do the correct thing, but that's causing me problems too. Rick Regards, John Rick McGuire wrote: I just got back from a 2 week vacation and am trying to get caught back up again. When I do a maven m:update on my working build from 2 weeks ago, I'm getting the following message followed by a hang: m:update: [exec] At revision 430039. [exec] Authentication realm: https://svn.codehaus.org:443 openejb Repo I get similar behavior when I checkout out a fresh build and do a maven m:fresh-checkout. Is this a glitch with the codehaus svn or should I be using something else now to access a build? Rick
[jira] Created: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.1, 1.0 Reporter: John Sisson Assigned To: John Sisson Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=all ] John Sisson reassigned GERONIMO-2307: - Assignee: Geir Magnusson Jr (was: John Sisson) Geir said he will follow this up. Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: Geir Magnusson Jr Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
maven m:eclipse issue on 1.1 in OpenEJB itests
I am trying to build the eclipse project files for a clean 1.1 build. I did the following: * svn co https://svn.apache.org/repos/asf/geronimo/branches/1.1 * cd 1.1 * maven m:fresh-checkout * maven new * maven m:eclipse -o The m:eclipse processing fails in OpenEJB itests. How do I get the geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip file to be placed in my local repository as part of the build so it doesn't fail? Thanks, John SNIP [echo] Place java sources for xstream at R:\.geronimo-1.1.x-maven\repository\xstream\java-sources\xstream-1.1.3-sources.jar for javadoc and debugging support in Eclipse [echo] Place java sources for xpp3 at R:\.geronimo-1.1.x-maven\repository\xpp3\java-sources\xpp3-1.1.3.3-sources.jar for javadoc and debugging support in Eclipse [echo] Place java sources for commons-jelly-tags-velocity at R:\.geronimo-1.1.x-maven\repository\commons-jelly\java-sources\comm ons-jelly-tags-velocity-1.0-sources.jar for javadoc and debugging support in Eclipse [echo] Place java sources for velocity at R:\.geronimo-1.1.x-maven\repository\velocity\java-sources\velocity-1.4-sources.jar for javadoc and debugging support in Eclipse [echo] Setting default output directory to target/classes [echo] Now refresh your project in Eclipse (right click on the project and select Refresh) + | Executing eclipse OpenEJB :: Integration Tests | Memory: 27M/32M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml eclipse: build:end: You are working offline so the build will continue, but openejb-builder-2.1.2-SNAPSHOT.jar may be out of date! BUILD FAILED File.. R:\.geronimo-1.1.x-maven\cache\maven-multiproject-plugin-1.4.1\plugin.jelly Element... maven:reactor Line.. 218 Column -1 The build cannot continue because of the following unsatisfied dependency: geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip Total time : 6 minutes 37 seconds Finished at : Thursday, 10 August 2006 10:33:27
Re: [ANNOUNCE] Welcome Kevan Miller to the Geronimo PMC
Congratulations Kevan! John Matt Hogstrom wrote: Please welcome Kevan Miller as the newest member of the Geronimo PMC. Kevan recently accepted the invitation to join the PMC. As such we now have an additional set of eyes to help with reviews as well as other PMC oversight responsibilities. Kevan has shown that he is not only a valuable member of the technical community but also spends much of his time helping others as well as making sure those pesky LICENSE files make it into every jar we ship. Give it up for Kevan :-0
Re: [ANNOUNCE] Welcome Paul McMahan as our newest committer
Congratulations Paul! John Matt Hogstrom wrote: All, We're pleased to let you know that we have a new committer in our midst. Paul McMahan has recently accepted an invitation to join the Geronimo project. Paul has been active on Geronimo for several months and has provided numerous patches for the console and related areas. He has been very helpful to users and recently worked with Genender and the Liferay folks to bring together a ifeRay plugin. We're anxious to see the kind of damage he can do to us now directly than through all those patches :) Welcome Paul!
Re: 1.1.1 - Ready or not ? Soliciting input
Kevan Miller wrote: On Aug 8, 2006, at 12:42 PM, Aaron Mulder wrote: On 8/8/06, Kevan Miller [EMAIL PROTECTED] wrote: Inline... On Aug 8, 2006, at 12:08 PM, Aaron Mulder wrote: Here are the issues that bother me most in 1.1.1. I believe they are all also issues in 1.1. DEPLOYMENT http://issues.apache.org/jira/browse/GERONIMO-2270 - Redeploy broken when module ID does not include a type (patch available) http://issues.apache.org/jira/browse/GERONIMO-2269 - Redeploy broken when module ID does not include a version and app uses JNDI (patch available) I also just found a deploy problem with web apps with a plan with no environment, but I haven't investigated much yet. Why haven't the patches been committed? They need a Release Manager go ahead? I certainly wouldn't classify either problem as a BLOCKER. They could be fixed in 1.1.x. They haven't been committed to 1.1.1 because the release manager nixed it. They'll be in 1.1.2 no matter what. In any case, we clearly need to standardize our definition of blocker. I think that quality issues can be blockers, and it sounds like you don't. Which is OK, I guess we just need some way to decide what we're willing to ship with, whether that's a vote or the decision of the release manager or whatever. Probably more responses to this thread would help. Yes, I've noted a difference in our definitions for some time. Here are some definitions from the Jira system -- http://issues.apache.org/jira/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels I find the Priority Level definitions to be reasonably close to my own. I also would prefer we stick to the JIRA definitions of priority, otherwise it will be too confusing. Quality issues can be blockers, but your redeploy problems are not. I'd put them as Major or Minor. By the Jira definitions, they are Minor. Users have a pretty reasonable work-around (Redeploy fails, Users can easily undeploy, then deploy). I put some SECURITY issues in the BLOCKER category. If a user has followed the rules and believes that he/she has properly secured some resource and Geronimo permits unauthorized/unauthenticated access to that resource, then that's a BLOCKER... Agree. There are some users who are waiting for the 1.1.1 release to fix bugs they have run into in 1.1. Instead of making them wait longer, I would prefer we aim to get 1.1.1 out with blockers fixed and no regressions or compliance issues. Releasing often enables our user base to start using our code (as they may have had been unable to do so in a previous release due to issues they hit) and possibly get more up to date feedback from the users for the next release. These are only my views and it is the community that will decide. Regards, John --kevan SECURITY http://issues.apache.org/jira/browse/GERONIMO-2294 - For a security realm with multiple login modules, we do not handle the JAAS Control Flags correctly (e.g. we do not call the login modules using the correct logic). Code to reproduce available. Alan had claimed a predecessor to this issue; I'm not sure if he's planning on working on this one. Does this problem allow unauthorized/unauthenticated access to secured resources? If not, then I wouldn't categorize it as a BLOCKER. http://issues.apache.org/jira/browse/GERONIMO-2295 - For a web app, if the security url-patterns don't exactly match the servlet-mapping url-patterns, we apply no security at all. Code to reproduce available. Alan has claimed this issue. That certainly seems like a must-fix BLOCKER to me... http://issues.apache.org/jira/browse/GERONIMO-1053 - Likely not still a problem (reported against M5), but if it is, it sounds serious. Even if it does still exist, doesn't seem like a BLOCKER. There are a large number of other issues out there in the security category, but I don't think they're all as urgent (e.g. GEORNIMO-1747, GERONIMO-2274, GERONIMO-2275, and GERONIMO-2279 probably ought to be addressed in 1.1.2 but I don't think need to hold up 1.1.1). Thanks, Aaron On 8/8/06, Matt Hogstrom [EMAIL PROTECTED] wrote: 1.1.1 is in a form that we can get ready to release it. I was talking with Aaron and he mentioned that there were some security issues he was concerned about. I would like to use this thread to identify any issues that should be considered show stoppers and make the decision on how to move forward. Please use this thread to provide that information. What I think we'll need to make an appropriate assessement is: Issue Description How long have we had it? (has it existed in earlier releases and we knew it) Exposure JIRA issue number tracking the issue. Please provide your input as quickly as possible so we can assess how to proceed with 1.1.1. Thanks.
[jira] Closed: (XBEAN-37) Compile error in QdoxMappingLoader introduced in XBEAN-27
[ http://issues.apache.org/jira/browse/XBEAN-37?page=all ] John Sisson closed XBEAN-37. Resolution: Fixed Compile error in QdoxMappingLoader introduced in XBEAN-27 - Key: XBEAN-37 URL: http://issues.apache.org/jira/browse/XBEAN-37 Project: XBean Issue Type: Bug Components: spring Reporter: John Sisson Assigned To: John Sisson Priority: Blocker Fix For: 2.6 Seems this compile error slipped through the RTC on the XBEAN-27 patch! C:\dev\geronimo\xbean\trunkmvn install SNIP [INFO] [INFO] Building XBean :: Spring :: Common [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 42 source files to C:\dev\geronimo\xbean\trunk\xbean-spring-common\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\dev\geronimo\xbean\trunk\xbean-spring-common\src\main\java\org\apache\xbean\spring\generator\QdoxMappingLoader.java:[507,29] repl ace(char,char) in java.lang.String cannot be applied to (java.lang.String,java.lang.String) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (XBEAN-37) Compile error in QdoxMappingLoader introduced in XBEAN-27
Compile error in QdoxMappingLoader introduced in XBEAN-27 - Key: XBEAN-37 URL: http://issues.apache.org/jira/browse/XBEAN-37 Project: XBean Issue Type: Bug Components: spring Reporter: John Sisson Assigned To: John Sisson Priority: Blocker Fix For: 2.6 Seems this compile error slipped through the RTC on the XBEAN-27 patch! C:\dev\geronimo\xbean\trunkmvn install SNIP [INFO] [INFO] Building XBean :: Spring :: Common [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 42 source files to C:\dev\geronimo\xbean\trunk\xbean-spring-common\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\dev\geronimo\xbean\trunk\xbean-spring-common\src\main\java\org\apache\xbean\spring\generator\QdoxMappingLoader.java:[507,29] repl ace(char,char) in java.lang.String cannot be applied to (java.lang.String,java.lang.String) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Wiki migration
I noticed that there are lines in the pages that you have to scroll right to read. For example, open http://cwiki.apache.org/confluence/display/GMOxMoinMoin/Advanced_Plugin_Sample and look at the bullet points after the words Here are some things to note. Any idea what is happening there? John Hernan Cunico wrote: Hi All, I've been reviewing the content we have in the Moin Moin wiki and it is way more out of date than I thought it would be. I initially thought that it would be easier to do the housekeeping once we had the content migrated to Confluence but after a more detailed analysis of the actual content to migrate I found out that there is really little content to move over. This is either because we already have that content categorized and up to date or the Moin Moin content is so out of date that is not relevant anymore. So, did some cleaning and detailed review of the Moin Moin content ( thanks Jason for helping with Moin Moin ;-) ), ran the migration again (thanks Don for providing the migration tools and continuous support) and came up with a very reduced list of pages that, IMHO, should actually be migrated and integrated to the current cwiki. These pages are listed in the yellow box at the top of the front page, here is the link to the partially migrated space. http://cwiki.apache.org/confluence/display/GMOxMoinMoin I know we all focused on getting v1.1.1 out of the door now so how about time to review it untill next Friday Aug 11. Not sure if this calls for a vote ( we kinda did that already) but if there are not -1/negative comments I would propose to give wiki.apache.org/geronimo a proper burial and get it out of production. If anybody thinks that any other page should be included pls send me the page name (and link) and we'll review it. Thanks Cheers! Hernan
[jira] Commented: (GERONIMO-1939) Server Info portlet doesn't display the 'Server Memory Usage' live graph on Internet Explorer
[ http://issues.apache.org/jira/browse/GERONIMO-1939?page=comments#action_12424762 ] John Sisson commented on GERONIMO-1939: --- Do the scripts available from Adobe help? http://www.adobe.com/svg/workflow/autoinstall.html The license for the script files says: // Copyright 2000 Adobe Systems Incorporated. All rights reserved. Permission // to use, modify, distribute, and publicly display this file is hereby // granted. This file is provided AS-IS with absolutely no warranties of any // kind. Portions (C) Netscape Communications 1999. // If you modify this file, please share your changes with Adobe and other SVG // developers at http://www.adobe.com/svg/. Server Info portlet doesn't display the 'Server Memory Usage' live graph on Internet Explorer - Key: GERONIMO-1939 URL: http://issues.apache.org/jira/browse/GERONIMO-1939 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: Chris Cardona I've tested it to work on Firefox v1.5.0.2 but the graph doesn't show up on IE v6.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1939) Server Info portlet doesn't display the 'Server Memory Usage' live graph on Internet Explorer
[ http://issues.apache.org/jira/browse/GERONIMO-1939?page=comments#action_12424766 ] John Sisson commented on GERONIMO-1939: --- I tried using FireFox 1.0.7 on windows (latest currently available) and if I click on the image click here to download plugin I get the Plugin finder service dialog box that just sits there seeming to do nothing. Do others have this problem? Server Info portlet doesn't display the 'Server Memory Usage' live graph on Internet Explorer - Key: GERONIMO-1939 URL: http://issues.apache.org/jira/browse/GERONIMO-1939 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: Chris Cardona I've tested it to work on Firefox v1.5.0.2 but the graph doesn't show up on IE v6.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1939) Server Info portlet doesn't display the 'Server Memory Usage' live graph on Internet Explorer
[ http://issues.apache.org/jira/browse/GERONIMO-1939?page=comments#action_12424778 ] John Sisson commented on GERONIMO-1939: --- Sorry, my comment about firefox 1.0.7 is incorrect. I just assumed that since that version said it had no updates available it was the latest. I confirmed that 1.5.0.5 works. Server Info portlet doesn't display the 'Server Memory Usage' live graph on Internet Explorer - Key: GERONIMO-1939 URL: http://issues.apache.org/jira/browse/GERONIMO-1939 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: Chris Cardona Attachments: embedSVG.js I've tested it to work on Firefox v1.5.0.2 but the graph doesn't show up on IE v6.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2136) Remove About icon and about page from console
[ http://issues.apache.org/jira/browse/GERONIMO-2136?page=all ] John Sisson closed GERONIMO-2136. - Fix Version/s: 1.2 Resolution: Fixed Remove About icon and about page from console - Key: GERONIMO-2136 URL: http://issues.apache.org/jira/browse/GERONIMO-2136 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: John Sisson Assigned To: John Sisson Priority: Trivial Fix For: 1.1.1, 1.2 h1. Problem The licenses displayed in the console in the about page ( http://localhost:8080/console/about.jsp ) are a subset of those in Geronimo's LICENSE.txt file and may be misleading. See mail thread. http://www.mail-archive.com/dev%40geronimo.apache.org/msg24852.html h1. Solution The about icon and about page will be removed from the Geronimo console. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1996) Serialization failure during deployment leaves a config.ser in the repository but doesn't write a config.info causing problems later.
[ http://issues.apache.org/jira/browse/GERONIMO-1996?page=all ]
John Sisson updated GERONIMO-1996:
--
Fix Version/s: 1.2
Description:
h1. Problem
If an Error (java.lang.Error and its subclasses) occurs during deployment and
the deployment operation fails it may not be possible to redeploy.
h1. Symptom
Example of exception during serialization phase of deployment:
{code}
java.lang.ClassCastException
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at com.foo.common.xml.XMLNode.loadXML(XMLNode.java:534)
at com.foo.common.xml.XMLNode.loadXML(XMLNode.java:520)
SNIP
at com.foo.server.ejb.Bar.clinit(FooBean.java:104)
at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
at
java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1557)
at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:47)
SNIP
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at org.apache.geronimo.gbean.GBeanData.writeExternal(GBeanData.java:186)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.storeGBeans(SerializedGBeanState.java:139)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.writeObject(SerializedGBeanState.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
org.apache.geronimo.kernel.config.SerializedConfigurationMarshaler.writeConfigurationData(SerializedConfigurationMarshale
r.java:66)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.writeConfigurationData(ConfigurationUtil.java:163)
at
org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(ExecutableConfigurationUtil.java:
149)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryConfigurationStore.java:318)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:308)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:119)
{code}
When restarting Geronimo after a deployment that failed during serialization
you may see the following exception:
{code}
ERROR [RepositoryConfigurationStore] Unable to load ConfigurationInfo for
com.acme.foo/foo-server-plus/3.4.060322-SNAPSHOT/ear
java.io.FileNotFoundException:
C:\test\geronimo-1.1-SNAPSHOT\repository\com\acme\foo\foo-server-plus\3.4.060322-SNAPSHOT\
foo-server-plus-3.4.060322-SNAPSHOT.ear\META-INF\config.info (The system cannot
find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:106)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.loadConfigurationInfo(RepositoryConfigurationStore.
java:401)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.listConfigurations(RepositoryConfigurationStore.jav
a:375)
{code}
Error if you attempt to undeploy the configuration you get:
{code}
11:04:27,699 ERROR [RepositoryConfigurationStore] Unable to load
ConfigurationInfo for com.acme.foo/foo-server-plus/3.4.0
60322-SNAPSHOT/ear
java.io.FileNotFoundException:
C:\test\geronimo-1.1-SNAPSHOT\repository\com\acme\foo\foo-server-plus\3.4.060322-SNAPSHOT\
foo-server-plus-3.4.060322-SNAPSHOT.ear\META-INF\config.info (The system cannot
find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:106)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.loadConfigurationInfo(RepositoryConfigurationStore.
java:401)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.listConfigurations(RepositoryConfigurationStore.jav
a:375
[jira] Updated: (GERONIMO-1996) Error during deployment may result in files not being cleaned up properly
[ http://issues.apache.org/jira/browse/GERONIMO-1996?page=all ]
John Sisson updated GERONIMO-1996:
--
Summary: Error during deployment may result in files not being cleaned up
properly (was: Serialization failure during deployment leaves a config.ser in
the repository but doesn't write a config.info causing problems later.)
Error during deployment may result in files not being cleaned up properly
-
Key: GERONIMO-1996
URL: http://issues.apache.org/jira/browse/GERONIMO-1996
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 1.1
Reporter: John Sisson
Assigned To: John Sisson
Fix For: 1.2, 1.1.1
Attachments: jira-g-1996.zip
h1. Problem
If an Error (java.lang.Error and its subclasses) occurs during deployment and
the deployment operation fails it may not be possible to redeploy.
h1. Symptom
Example of exception during serialization phase of deployment:
{code}
java.lang.ClassCastException
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at com.foo.common.xml.XMLNode.loadXML(XMLNode.java:534)
at com.foo.common.xml.XMLNode.loadXML(XMLNode.java:520)
SNIP
at com.foo.server.ejb.Bar.clinit(FooBean.java:104)
at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
at
java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1557)
at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:47)
SNIP
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
org.apache.geronimo.gbean.GBeanData.writeExternal(GBeanData.java:186)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.storeGBeans(SerializedGBeanState.java:139)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.writeObject(SerializedGBeanState.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
org.apache.geronimo.kernel.config.SerializedConfigurationMarshaler.writeConfigurationData(SerializedConfigurationMarshale
r.java:66)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.writeConfigurationData(ConfigurationUtil.java:163)
at
org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(ExecutableConfigurationUtil.java:
149)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryConfigurationStore.java:318)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:308)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:119)
{code}
When restarting Geronimo after a deployment that failed during serialization
you may see the following exception:
{code}
ERROR [RepositoryConfigurationStore] Unable to load ConfigurationInfo for
com.acme.foo/foo-server-plus/3.4.060322-SNAPSHOT/ear
java.io.FileNotFoundException:
C:\test\geronimo-1.1-SNAPSHOT\repository\com\acme\foo\foo-server-plus\3.4.060322-SNAPSHOT\
foo-server-plus-3.4.060322-SNAPSHOT.ear\META-INF\config.info (The system
cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:106)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.loadConfigurationInfo(RepositoryConfigurationStore.
java:401)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.listConfigurations(RepositoryConfigurationStore.jav
a:375)
{code}
Error if you attempt to undeploy the configuration you get:
{code}
11:04:27,699
[jira] Closed: (GERONIMO-1996) Error during deployment may result in files not being cleaned up properly
[ http://issues.apache.org/jira/browse/GERONIMO-1996?page=all ]
John Sisson closed GERONIMO-1996.
-
Resolution: Fixed
Error during deployment may result in files not being cleaned up properly
-
Key: GERONIMO-1996
URL: http://issues.apache.org/jira/browse/GERONIMO-1996
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 1.1
Reporter: John Sisson
Assigned To: John Sisson
Fix For: 1.1.1, 1.2
Attachments: jira-g-1996.zip
h1. Problem
If an Error (java.lang.Error and its subclasses) occurs during deployment and
the deployment operation fails it may not be possible to redeploy.
h1. Symptom
Example of exception during serialization phase of deployment:
{code}
java.lang.ClassCastException
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at com.foo.common.xml.XMLNode.loadXML(XMLNode.java:534)
at com.foo.common.xml.XMLNode.loadXML(XMLNode.java:520)
SNIP
at com.foo.server.ejb.Bar.clinit(FooBean.java:104)
at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
at
java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1557)
at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:47)
SNIP
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
org.apache.geronimo.gbean.GBeanData.writeExternal(GBeanData.java:186)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.storeGBeans(SerializedGBeanState.java:139)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.writeObject(SerializedGBeanState.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
org.apache.geronimo.kernel.config.SerializedConfigurationMarshaler.writeConfigurationData(SerializedConfigurationMarshale
r.java:66)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.writeConfigurationData(ConfigurationUtil.java:163)
at
org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(ExecutableConfigurationUtil.java:
149)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryConfigurationStore.java:318)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:308)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:119)
{code}
When restarting Geronimo after a deployment that failed during serialization
you may see the following exception:
{code}
ERROR [RepositoryConfigurationStore] Unable to load ConfigurationInfo for
com.acme.foo/foo-server-plus/3.4.060322-SNAPSHOT/ear
java.io.FileNotFoundException:
C:\test\geronimo-1.1-SNAPSHOT\repository\com\acme\foo\foo-server-plus\3.4.060322-SNAPSHOT\
foo-server-plus-3.4.060322-SNAPSHOT.ear\META-INF\config.info (The system
cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:106)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.loadConfigurationInfo(RepositoryConfigurationStore.
java:401)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.listConfigurations(RepositoryConfigurationStore.jav
a:375)
{code}
Error if you attempt to undeploy the configuration you get:
{code}
11:04:27,699 ERROR [RepositoryConfigurationStore] Unable to load
ConfigurationInfo for com.acme.foo/foo-server-plus/3.4.0
60322-SNAPSHOT/ear
java.io.FileNotFoundException:
C:\test\geronimo-1.1-SNAPSHOT\repository\com\acme
[jira] Closed: (GERONIMO-1810) Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message
[ http://issues.apache.org/jira/browse/GERONIMO-1810?page=all ] John Sisson closed GERONIMO-1810. - Resolution: Duplicate This has already been fixed by Erin's patch in GERONIMO-1360 (rev 399082). Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message - Key: GERONIMO-1810 URL: http://issues.apache.org/jira/browse/GERONIMO-1810 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.0 Reporter: John Sisson Assigned To: John Sisson Priority: Trivial Fix For: 1.1.1 Need to provide more information in the following error message, giving the user a bit more of a hint as to what the problem may be. C:\testgeronimo-1.0.1-SNAPSHOT\bin\deploy --user system --password manager deploy jstest.ear jstest.xml Using GERONIMO_BASE: C:\test\geronimo-1.0.1-SNAPSHOT Using GERONIMO_HOME: C:\test\geronimo-1.0.1-SNAPSHOT Using GERONIMO_TMPDIR: C:\test\geronimo-1.0.1-SNAPSHOT\var\temp Using JRE_HOME:C:\j2sdk1.4.2_10 Error: Unable to distribute jstest.ear: Cannot deploy the requested application module (planFile=C:\test\jstest.xml, moduleFile=C:\test\geronimo-1.0.1-SNAPSHOT\var\temp\geronimo-deployer59948.tmpdir\jstest.ear) In the case above it was due to my ear file accidentially having all the files under a directory. I propose we add the following to the end of the message: Check that the module file contains the expected deployment files and directory structure. If problems persist, ensure the appropriate module builder is running. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1810) Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message
[ http://issues.apache.org/jira/browse/GERONIMO-1810?page=all ] John Sisson closed GERONIMO-1810. - Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message - Key: GERONIMO-1810 URL: http://issues.apache.org/jira/browse/GERONIMO-1810 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.0 Reporter: John Sisson Assigned To: John Sisson Priority: Trivial Fix For: 1.1 Need to provide more information in the following error message, giving the user a bit more of a hint as to what the problem may be. C:\testgeronimo-1.0.1-SNAPSHOT\bin\deploy --user system --password manager deploy jstest.ear jstest.xml Using GERONIMO_BASE: C:\test\geronimo-1.0.1-SNAPSHOT Using GERONIMO_HOME: C:\test\geronimo-1.0.1-SNAPSHOT Using GERONIMO_TMPDIR: C:\test\geronimo-1.0.1-SNAPSHOT\var\temp Using JRE_HOME:C:\j2sdk1.4.2_10 Error: Unable to distribute jstest.ear: Cannot deploy the requested application module (planFile=C:\test\jstest.xml, moduleFile=C:\test\geronimo-1.0.1-SNAPSHOT\var\temp\geronimo-deployer59948.tmpdir\jstest.ear) In the case above it was due to my ear file accidentially having all the files under a directory. I propose we add the following to the end of the message: Check that the module file contains the expected deployment files and directory structure. If problems persist, ensure the appropriate module builder is running. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2250) Error rather than exception from server whilst deploying causes deployer to hang (not end)
Error rather than exception from server whilst deploying causes deployer to hang (not end) -- Key: GERONIMO-2250 URL: http://issues.apache.org/jira/browse/GERONIMO-2250 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 1.1, 1.0 Reporter: John Sisson Priority: Minor Fix For: 1.x Whilst using the test application attached to GERONIMO-1996 I found that the Error from the server (e.g. java.lang.ExceptionInInitializerError ) caused the thread (see Thread-2 below) to end and the deploy command does not return. It appears that the run() methods for commands need to catch Throwable rather than Exception so that it can end more gracefully. Debugger output: Java HotSpot(TM) Client VM[localhost:8001] Thread [main] (Suspended) org.apache.geronimo.deployment.plugin.jmx.RemoteDeploymentManager(org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager).distribute(javax.enterprise.deploy.spi.Target[], java.io.File, java.io.File) line: 176 org.apache.geronimo.deployment.cli.CommandDeploy(org.apache.geronimo.deployment.cli.CommandDistribute).runCommand(javax.enterprise.deploy.spi.DeploymentManager, java.io.PrintWriter, boolean, javax.enterprise.deploy.spi.Target[], java.io.File, java.io.File) line: 75 org.apache.geronimo.deployment.cli.CommandDeploy.runCommand(javax.enterprise.deploy.spi.DeploymentManager, java.io.PrintWriter, boolean, javax.enterprise.deploy.spi.Target[], java.io.File, java.io.File) line: 51 org.apache.geronimo.deployment.cli.CommandDeploy(org.apache.geronimo.deployment.cli.CommandDistribute).executeOnline(org.apache.geronimo.deployment.cli.ServerConnection, boolean, java.util.List, java.io.PrintWriter, java.io.File, java.io.File) line: 148 org.apache.geronimo.deployment.cli.CommandDeploy(org.apache.geronimo.deployment.cli.CommandDistribute).execute(java.io.PrintWriter, org.apache.geronimo.deployment.cli.ServerConnection, java.lang.String[]) line: 132 org.apache.geronimo.deployment.cli.CommandDeploy.execute(java.io.PrintWriter, org.apache.geronimo.deployment.cli.ServerConnection, java.lang.String[]) line: 60 org.apache.geronimo.deployment.cli.DeployTool.execute(java.lang.String[]) line: 159 org.apache.geronimo.deployment.cli.DeployTool.main(java.lang.String[]) line: 313 Thread [Thread-1] (Running) Thread [Connection HeartBeat] (Running) Thread [Notification Deliverer #1] (Running) Thread [Notification Fetcher #1] (Running) Thread [Thread-2] (Suspended (exception java.lang.ExceptionInInitializerError)) org.apache.geronimo.deployment.plugin.local.DistributeCommand.run() line: 65 java.lang.Thread.run() line: not available -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.1.1 Status
Any objections to removing the licenses from the about page in the console. See GERONIMO-2136 (listed below) FYI, I was originally planning on upgrading Derby (*GERONIMO-2155 https://issues.apache.org/jira/browse/GERONIMO-2155)*, but the debug versions of the derby libraries aren't in the maven repos and I'm running out of time, so will leave as targeted for 1.x. Thanks, John Matt Hogstrom wrote: There has been a lot of progress on 1.1.1. We started with 61 issues and we're down to 21 left. Originally I suggested that we branch on Friday. I'd like to give a little more time and would like to revise the branch to a freeze state on Tuesday, August 1 at 0500 PT. At that time I'll spin off branches/1.1.1 and update branches/1.1 to be 1.1.2-SNAPSHOT. We'll do performance regression and TCK work during the next week and shoot for an official release within two weeks. If anyone is opposed to this plan let me know. Also, please review the JIRA's below. If you don't think you can get thte ones done with your name please unassign yourself and hopefully someone else will pick them up. Thanks. *Outstanding Issues* GERONIMO- Open John Sisson Application errors in static initialization blocks during serialization of configuration during deployment due to incorrect TCCL GERONIMO-2218 Open Unassigned KeyStore portlet: Functionality missing from 1.0 GERONIMO-1906 Reopened Sachin Patel Cannot add a new connector using ActiveMQManagerGBean GERONIMO-1917 Open David Jencks repository doesn't deal well with case insensitive file systems GERONIMO-1996 Open John Sisson Serialization failure during deployment leaves a config.ser in the repository but doesn't write a config.info causing problems later. GERONIMO-2080 Open John Sisson Create a Geronimo Bug Guidelines Page GERONIMO-2169 Open Kevan Miller Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch) GERONIMO-2170 Open Kevan Miller Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories GERONIMO-2167 Open Kevan Miller deployer.jar not cleaning up properly during redeploy and undeploy GERONIMO-2202 Open Kevan Miller Move to new Apache Maven 1 repo (repo/m1-snapshot-repository 1.2 GERONIMO-2030 Open Unassigned Allow WebServiceBuilder determine if there are WebServices to be deployed GERONIMO-1476 Open Unassigned Changes to default log4j.rootCategory are not dynamic GERONIMO-2228 Open Unassigned GeronimoAsMavenServlet.java generates wrong default-repository element GERONIMO-2230 Open Aaron Mulder No cleanup after DeploymentWatcher exception GERONIMO-2142 Open David Jencks EJB Refs to EJB in parent module often fail GERONIMO-2227 Open David Jencks ENC Lookup Fix (include parent modules) GERONIMO-1557 Open David Jencks When you enter the url of a web service in the console You should get a page showing the service name GERONIMO-1531 Open Unassigned KeyStore portlet should support deletion of certificates and private keys GERONIMO-1716 Open Donald Woods Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console GERONIMO-2204 Open David Jencks ProxyMethodInterceptor doesn't handle finalize appropriately GERONIMO-2136 Open John Sisson Remove/Update licenses displayed in about page of console GERONIMO-1810 Open John Sisson Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
Congratulations David! Regards, John Matt Hogstrom wrote: The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt
Re: wiki migration
Hernan Cunico wrote: John Sisson wrote: Hernan Cunico wrote: Hi All, this is a friendly reminder that the Moin Moin wiki ( namely wiki.apache.org/geronimo ) is being migrated to the confluence based http://cwiki.apache.org/geronimo Great! Please refrain from continuing updating content to the Moin Moin wiki. The current migration status can me seen at http://cwiki.apache.org/confluence/display//Home I tried looking at the status and got a page not found. I also tried http://cwiki.apache.org/confluence/display/GMOxMoinMoin and got a Not Permitted page. Not sure what the problem is, I just clicked those two links and both worked without logging in. Does anyone else have this problem? Hmm, I logged out and logged back in and it worked. When I was logged in if I went to http://cwiki.apache.org/confluence/dashboard.action where it lists the spaces, the GMOxMoinMoin space is not listed. After I logged out and logged back in again it was listed and I could access the link above. Thanks, John This is the raw content migrated so far from the Moin Moin wiki has not been edited yet, this is a temporary space while migrating. This is the first step of several, later this content will be evaluated for accuracy and then incorporated to one of the cwiki.apache.org/geronimo sub-structures. Comments, suggestions and HELP! are very much welcomed. Will information be moved to space for a particular release? E.G. the build instructions for 1.1.x will differ to 1.2? Yes but first thing first, we need to totally move the Moin Moin content to confluence, get rid of the duplicated/obsolete information (do some housekeeping) and then get the good stuff reorganized into confluence structure. We may potentially need to create additional spaces. Looking at the current organization we have we already have the content organized according to Geronimo versions, we may need to do some reorganization within those spaces (maybe consolidating user's and developer's guide into just user's guide for simplicity). As soon as we have some material to put out for v1.2 we will create a new Apache Geronimo v1.2 space with version specific info. Cheers! Hernan Thanks, John Cheers! Hernan
[jira] Commented: (GERONIMO-2146) GBeanOverride ignores reference name when saving if artifact is not set
[ http://issues.apache.org/jira/browse/GERONIMO-2146?page=comments#action_12424749 ] John Sisson commented on GERONIMO-2146: --- Aaron checked in fix to 1.1 branch in http://svn.apache.org/viewvc?rev=425429view=rev GBeanOverride ignores reference name when saving if artifact is not set --- Key: GERONIMO-2146 URL: http://issues.apache.org/jira/browse/GERONIMO-2146 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.1.1 In writeXml the writing of name and module should be outside the if(artifact != null) block -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Should we allow more ejb-links than j2ee specifies?
Dain Sundstrom wrote: On Jul 27, 2006, at 7:29 PM, Matt Hogstrom wrote: Aaron Mulder wrote: On 7/27/06, John Sisson [EMAIL PROTECTED] wrote: I think this would simplify configuration for users. Could we log a warning (that can be enabled/disabled) at deploy time identifying extended features are being utilised? Putting myself in users shoes, I would like to use these extensions, but would like a way of identifying which apps are using them and what extended features are being used in case I need to migrate my apps to another server, but don't wan't to see warning messages day to day during normal operation. I'm not really in favor of the log messages -- we have too many extensions. I am in favor of keeping the feature as presently implemented. +1 +1 -dain It was just an idea.. I'm happy keeping the feature as is. John
[jira] Updated: (GERONIMO-2233) Deployment fails with InvalidConfigException: Unable to deserialize GBeanState when Sun JMX RI JAR is on classpath in EAR
[ http://issues.apache.org/jira/browse/GERONIMO-2233?page=all ]
John Sisson updated GERONIMO-2233:
--
Description:
h1. Problem
Deployment of an EAR that contains the Sun JMX RI 1.2 JAR in the classpath set
in the META-INF/MANIFEST.MF file of the JAR in the EAR fails. An EAR may
include a JMX implementation library so that it can run on J2EE 1.3 servers.
h1. Symptoms
The following error is seen on the server console:
{code}
23:58:47,831 ERROR [GBeanInstanceState] Error while starting; GBean is now in
the FAILED state: abstractName=geronimo-test/jira-g-n
nnn/1.0-SNAPSHOT/ear?configurationName=geronimo-test/jira-g-/1.0-SNAPSHOT/ear
org.apache.geronimo.kernel.config.InvalidConfigException: Unable to deserialize
GBeanState
at
org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:120)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:65)
at
org.apache.geronimo.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:171)
at
org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:277)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526)
at
org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:161)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:292)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:260)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:235)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:338)
at
org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at
org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168)
at
mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:221)
at
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120)
at
mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:84)
at
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120)
at
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120)
at
mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerInterceptor.java:203
)
at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1043)
at
mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219)
at sun.reflect.GeneratedMethodAccessor347.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25
Re: wiki migration
Hernan Cunico wrote: Hi All, this is a friendly reminder that the Moin Moin wiki ( namely wiki.apache.org/geronimo ) is being migrated to the confluence based http://cwiki.apache.org/geronimo Great! Please refrain from continuing updating content to the Moin Moin wiki. The current migration status can me seen at http://cwiki.apache.org/confluence/display/GMOxMoinMoin/Home I tried looking at the status and got a page not found. I also tried http://cwiki.apache.org/confluence/display/GMOxMoinMoin and got a Not Permitted page. This is the raw content migrated so far from the Moin Moin wiki has not been edited yet, this is a temporary space while migrating. This is the first step of several, later this content will be evaluated for accuracy and then incorporated to one of the cwiki.apache.org/geronimo sub-structures. Comments, suggestions and HELP! are very much welcomed. Will information be moved to space for a particular release? E.G. the build instructions for 1.1.x will differ to 1.2? Thanks, John Cheers! Hernan
[jira] Created: (GERONIMO-2233) Deployment fails with InvalidConfigException: Unable to deserialize GBeanState when Sun JMX RI JAR is on classpath in EAR
Deployment fails with InvalidConfigException: Unable to deserialize GBeanState
when Sun JMX RI JAR is on classpath in EAR
-
Key: GERONIMO-2233
URL: http://issues.apache.org/jira/browse/GERONIMO-2233
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: deployment
Affects Versions: 1.1, 1.0
Reporter: John Sisson
Priority: Minor
Fix For: 1.1.x
h1. Problem
Deployment of an EAR that contains the Sun JMX RI 1.2 JAR in the classpath set
in the META-INF/MANIFEST.MF file of the JAR in the EAR fails.
h1. Symptoms
The following error is seen on the server console:
{code}
23:58:47,831 ERROR [GBeanInstanceState] Error while starting; GBean is now in
the FAILED state: abstractName=geronimo-test/jira-g-n
nnn/1.0-SNAPSHOT/ear?configurationName=geronimo-test/jira-g-/1.0-SNAPSHOT/ear
org.apache.geronimo.kernel.config.InvalidConfigException: Unable to deserialize
GBeanState
at
org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:120)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:65)
at
org.apache.geronimo.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:171)
at
org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:277)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526)
at
org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:161)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:292)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:260)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:235)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:338)
at
org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at
org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168)
at
mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:221)
at
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120)
at
mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:84)
at
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120)
at
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120)
at
mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke
Attn: Aaron - Re: svn commit: r425429 - /geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Altered the subject, hopefully won't go unnoticed this time :-)
John
John Sisson wrote:
Reposting.. probably got lost in all the email traffic.
John
John Sisson wrote:
Aaron,
What JIRA is associated with this change?
Thanks,
John
[EMAIL PROTECTED] wrote:
Author: ammulder
Date: Tue Jul 25 08:55:34 2006
New Revision: 425429
URL: http://svn.apache.org/viewvc?rev=425429view=rev
Log:
Module and name are independent of artifact
Modified:
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Modified:
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
URL:
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java?rev=425429r1=425428r2=425429view=diff
==
---
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
(original)
+++
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Tue Jul 25 08:55:34 2006
@@ -459,17 +459,17 @@
type.appendChild(doc.createTextNode(artifact.getType()));
pat.appendChild(type);
}
-Map nameMap = pattern.getName();
-if (nameMap.get(module) != null) {
-Element module = doc.createElement(module);
-
module.appendChild(doc.createTextNode(nameMap.get(module).toString()));
-pat.appendChild(module);
-}
-if (nameMap.get(name) != null) {
-Element patName = doc.createElement(name);
-
patName.appendChild(doc.createTextNode(nameMap.get(name).toString()));
-pat.appendChild(patName);
-}
+}
+Map nameMap = pattern.getName();
+if (nameMap.get(module) != null) {
+Element module = doc.createElement(module);
+
module.appendChild(doc.createTextNode(nameMap.get(module).toString()));
+pat.appendChild(module);
+}
+if (nameMap.get(name) != null) {
+Element patName = doc.createElement(name);
+
patName.appendChild(doc.createTextNode(nameMap.get(name).toString()));
+pat.appendChild(patName);
}
//out.print(pattern.toString());
}
[jira] Closed: (GERONIMO-2222) Application errors in static initialization blocks during serialization of configuration during deployment due to incorrect TCCL
[ http://issues.apache.org/jira/browse/GERONIMO-?page=all ]
John Sisson closed GERONIMO-.
-
Fix Version/s: 1.2
Resolution: Fixed
Application errors in static initialization blocks during serialization of
configuration during deployment due to incorrect TCCL
-
Key: GERONIMO-
URL: http://issues.apache.org/jira/browse/GERONIMO-
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 1.1, 1.0
Reporter: John Sisson
Assigned To: John Sisson
Priority: Blocker
Fix For: 1.1.1, 1.2
Attachments: GERONIMO--v1.patch, jira-g--xerces-test.zip,
jira-g-.zip
h1. Problem
Exceptions and/or errors may occur in static initialization blocks invoked
whilst loading classes when serializing a configuration during deployment.
These same exceptions/errors don't occur when starting the configuration.
h1. Symptoms
Deployment of an EAR that has dependencies on its own copy of Xerces will
cause an exception similar to the following if Xerces is initialised in a
static block.
{code}
java.lang.ClassCastException
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at com.foo.server.ejb.MyEJB.clinit
at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
at
java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1557)
at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:47)
at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:173)
at java.security.AccessController.doPrivileged(Native Method)
at
java.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:170)
at java.io.ObjectStreamClass.writeNonProxy(ObjectStreamClass.java:557)
at
java.io.ObjectOutputStream.writeClassDescriptor(ObjectOutputStream.java:591)
at
java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1142)
at
java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1100)
at java.io.ObjectOutputStream.writeClass(ObjectOutputStream.java:1082)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:996)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
org.apache.geronimo.gbean.GBeanData.writeExternal(GBeanData.java:187)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.storeGBeans(SerializedGBeanState.java:139)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.writeObject(SerializedGBeanState.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247
Re: Geronimo site POC using Confluence Autoexport
I think it would be worthwhile continuing to work on this but I think we need to sort out some of the issues mentioned below before we switch over so any committer can update the site without requiring assistance from Infra or yourself. I also agree with Matt's comment about it being preferable to be able to make changes to the site but not have the changes go live instantly. A bit off topic, do you know of any tools to edit pages offline (where you can have a WYSIWYG view of the page) other than installing a confluence server on my notebook? Thanks, John Jason Dillon wrote: On Jul 26, 2006, at 8:52 AM, Hernan Cunico wrote: Confluence uses it's own versioning to manage the history changes to confluence pages, AFAIK confluence does not support SVN yet. For the cwiki we use the autoexport plugin to get the confluence content automatically exported into HTML format and via a template we customize the look feel of those exported pages. I believe it to be highly unlikely that Confluence will natively support SVN for versioning... ever. I did however implement a prototype of a plugin that would commit changes to wiki pages to SVN... but never really finished it. The exported pages are independent from confluence version control, if we use a different version control we will not get the exported HTML in sync with the actual (and versioned) confluence content. Rolling back changes will be a nightmare. We need to find out a way to get those two in sync. I believe we can solve this problem easily. First, when you rollback a page in Confluence, then AutoExport will rebuild the static page based on the new version... so they are in sync in some degree. For most types of rollbacks the Confluence mechanism should be used. Probably we want to include some comments in the generated pages (via the vsl template) to include the path in Confluence, the page version number and who changed it. Then, if we did rsync to SVN to publish then we have the required details to know how to roll the change back from Confluence. This should be trivial. We could also implement a SVN tag for each push, which would make it easier to quickly rollback the site if something major happened... granted it would be a bit of work to get Confluence back in sync. But, with the above comments, and the tag, we could easily disable the automatic sync and revert pages to the correct version (based on the comments in last known good tag). Or, if I finish my SVN plugin, then we could just re-import the entire space from a specific revision number. Lots of options. The plugin has some issues/limitations that still need to be addressed, it even has it's own JIRA (http://could.it/autoexport/index.html). Some of those issues will not let us serve the HTML from a different location, well at least not totally. We may want to add an additional massaging of the content, where we can fix any limitations that AutoExport has... Or we could fix AutoExport to better suite our needs. Or both. Security seems to be an easy thing to manage as we can restrict access by users and groups in terms of confluence, but we will not have access to the actual autoexported HTML content. If we need to delete any content from the autoexported directories we will not be able to do it ourselves, just the infrastructure folks have access to the FS. I'm going to see if infra@ will let a few of us have access to it, so that I can better help admin the Confluence install. But... the AutoExport plugin should really have a mechanism to clean + publish... which should be easy to add. --jason
Re: svn commit: r425429 - /geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Aaron,
What JIRA is associated with this change?
Thanks,
John
[EMAIL PROTECTED] wrote:
Author: ammulder
Date: Tue Jul 25 08:55:34 2006
New Revision: 425429
URL: http://svn.apache.org/viewvc?rev=425429view=rev
Log:
Module and name are independent of artifact
Modified:
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Modified:
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
URL:
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java?rev=425429r1=425428r2=425429view=diff
==
---
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
(original)
+++
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Tue Jul 25 08:55:34 2006
@@ -459,17 +459,17 @@
type.appendChild(doc.createTextNode(artifact.getType()));
pat.appendChild(type);
}
-Map nameMap = pattern.getName();
-if (nameMap.get(module) != null) {
-Element module = doc.createElement(module);
-
module.appendChild(doc.createTextNode(nameMap.get(module).toString()));
-pat.appendChild(module);
-}
-if (nameMap.get(name) != null) {
-Element patName = doc.createElement(name);
-
patName.appendChild(doc.createTextNode(nameMap.get(name).toString()));
-pat.appendChild(patName);
-}
+}
+Map nameMap = pattern.getName();
+if (nameMap.get(module) != null) {
+Element module = doc.createElement(module);
+
module.appendChild(doc.createTextNode(nameMap.get(module).toString()));
+pat.appendChild(module);
+}
+if (nameMap.get(name) != null) {
+Element patName = doc.createElement(name);
+
patName.appendChild(doc.createTextNode(nameMap.get(name).toString()));
+pat.appendChild(patName);
}
//out.print(pattern.toString());
}
Re: svn commit: r425429 - /geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Reposting.. probably got lost in all the email traffic.
John
John Sisson wrote:
Aaron,
What JIRA is associated with this change?
Thanks,
John
[EMAIL PROTECTED] wrote:
Author: ammulder
Date: Tue Jul 25 08:55:34 2006
New Revision: 425429
URL: http://svn.apache.org/viewvc?rev=425429view=rev
Log:
Module and name are independent of artifact
Modified:
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Modified:
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
URL:
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java?rev=425429r1=425428r2=425429view=diff
==
---
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
(original)
+++
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Tue Jul 25 08:55:34 2006
@@ -459,17 +459,17 @@
type.appendChild(doc.createTextNode(artifact.getType()));
pat.appendChild(type);
}
-Map nameMap = pattern.getName();
-if (nameMap.get(module) != null) {
-Element module = doc.createElement(module);
-
module.appendChild(doc.createTextNode(nameMap.get(module).toString()));
-pat.appendChild(module);
-}
-if (nameMap.get(name) != null) {
-Element patName = doc.createElement(name);
-
patName.appendChild(doc.createTextNode(nameMap.get(name).toString()));
-pat.appendChild(patName);
-}
+}
+Map nameMap = pattern.getName();
+if (nameMap.get(module) != null) {
+Element module = doc.createElement(module);
+
module.appendChild(doc.createTextNode(nameMap.get(module).toString()));
+pat.appendChild(module);
+}
+if (nameMap.get(name) != null) {
+Element patName = doc.createElement(name);
+
patName.appendChild(doc.createTextNode(nameMap.get(name).toString()));
+pat.appendChild(patName);
}
//out.print(pattern.toString());
}
[jira] Updated: (GERONIMO-2222) Application errors in static initialization blocks during serialization of configuration during deployment due to incorrect TCCL
[ http://issues.apache.org/jira/browse/GERONIMO-?page=all ]
John Sisson updated GERONIMO-:
--
Attachment: jira-g-.zip
Test application attached that prints out the TCCL during static initialization
in an EJB. If you deploy the EAR you will see the following messages (when
this bug exists). The static initializer gets called twice (once during
serialization during deployment and the 2nd time when the configuration is
started). Notice that the TCCL differs between the two.
BugReproBean static initializer called
Thread.currentThread().getContextClassLoader() =
[org.apache.geronimo.kernel.classloader.JarFileClassLoader
id=geronimo/j2ee-security/1.1.1-SNAPSHOT/car]
BugReproBean.class.getClassLoader( =
[org.apache.geronimo.kernel.classloader.JarFileClassLoader
id=geronimo-test/jira-g-/1.0-SNAPSHOT/ear]
BugReproBean static initializer finished
BugReproBean static initializer called
Thread.currentThread().getContextClassLoader() =
[org.apache.geronimo.kernel.classloader.JarFileClassLoader
id=geronimo-test/jira-g-/1.0-SNAPSHOT/ear]
BugReproBean.class.getClassLoader( =
[org.apache.geronimo.kernel.classloader.JarFileClassLoader
id=geronimo-test/jira-g-/1.0-SNAPSHOT/ear]
BugReproBean static initializer finished
Application errors in static initialization blocks during serialization of
configuration during deployment due to incorrect TCCL
-
Key: GERONIMO-
URL: http://issues.apache.org/jira/browse/GERONIMO-
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 1.0, 1.1
Reporter: John Sisson
Assigned To: John Sisson
Priority: Blocker
Fix For: 1.1.1
Attachments: jira-g-.zip
h1. Problem
Exceptions and/or errors may occur in static initialization blocks invoked
whilst loading classes when serializing a configuration during deployment.
These same exceptions/errors don't occur when starting the configuration.
h1. Symptoms
Deployment of an EAR that has dependencies on its own copy of Xerces will
cause an exception similar to the following if Xerces is initialised in a
static block.
{code}
java.lang.ClassCastException
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at com.foo.server.ejb.MyEJB.clinit
at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
at
java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1557)
at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:47)
at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:173)
at java.security.AccessController.doPrivileged(Native Method)
at
java.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:170)
at java.io.ObjectStreamClass.writeNonProxy(ObjectStreamClass.java:557)
at
java.io.ObjectOutputStream.writeClassDescriptor(ObjectOutputStream.java:591)
at
java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1142)
at
java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1100)
at java.io.ObjectOutputStream.writeClass(ObjectOutputStream.java:1082)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:996)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247
[jira] Updated: (GERONIMO-2222) Application errors in static initialization blocks during serialization of configuration during deployment due to incorrect TCCL
[ http://issues.apache.org/jira/browse/GERONIMO-?page=all ]
John Sisson updated GERONIMO-:
--
Attachment: GERONIMO--v1.patch
Proposed patch attached. Has been tested using the application previously
attached to this JIRA.
Application errors in static initialization blocks during serialization of
configuration during deployment due to incorrect TCCL
-
Key: GERONIMO-
URL: http://issues.apache.org/jira/browse/GERONIMO-
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 1.0, 1.1
Reporter: John Sisson
Assigned To: John Sisson
Priority: Blocker
Fix For: 1.1.1
Attachments: GERONIMO--v1.patch, jira-g-.zip
h1. Problem
Exceptions and/or errors may occur in static initialization blocks invoked
whilst loading classes when serializing a configuration during deployment.
These same exceptions/errors don't occur when starting the configuration.
h1. Symptoms
Deployment of an EAR that has dependencies on its own copy of Xerces will
cause an exception similar to the following if Xerces is initialised in a
static block.
{code}
java.lang.ClassCastException
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at com.foo.server.ejb.MyEJB.clinit
at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
at
java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1557)
at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:47)
at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:173)
at java.security.AccessController.doPrivileged(Native Method)
at
java.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:170)
at java.io.ObjectStreamClass.writeNonProxy(ObjectStreamClass.java:557)
at
java.io.ObjectOutputStream.writeClassDescriptor(ObjectOutputStream.java:591)
at
java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1142)
at
java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1100)
at java.io.ObjectOutputStream.writeClass(ObjectOutputStream.java:1082)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:996)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
org.apache.geronimo.gbean.GBeanData.writeExternal(GBeanData.java:187)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.storeGBeans(SerializedGBeanState.java:139)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.writeObject(SerializedGBeanState.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296)
at
java.io.ObjectOutputStream.writeOrdinaryObject
Re: [jira] Created: (GERONIMO-2222) Application errors in static initialization blocks during serialization of configuration during deployment due to incorrect TCCL
I plan to commit the patch attached to this JIRA soon for 1.1.1, as it
is a bug fix and trunk if there aren't any objections.
Regards,
John
John Sisson (JIRA) wrote:
Application errors in static initialization blocks during serialization of
configuration during deployment due to incorrect TCCL
-
Key: GERONIMO-
URL: http://issues.apache.org/jira/browse/GERONIMO-
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: deployment
Affects Versions: 1.1, 1.0
Reporter: John Sisson
Assigned To: John Sisson
Priority: Blocker
Fix For: 1.1.1
h1. Problem
Exceptions and/or errors may occur in static initialization blocks invoked whilst loading classes when serializing a configuration during deployment.
These same exceptions/errors don't occur when starting the configuration.
h1. Symptoms
Deployment of an EAR that has dependencies on its own copy of Xerces will cause
an exception similar to the following if Xerces is initialised in a static
block.
{code}
java.lang.ClassCastException
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at org.apache.xerces.parsers.DOMParser.init(Unknown Source)
at com.foo.server.ejb.MyEJB.clinit
at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
at
java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1557)
at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:47)
at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:173)
at java.security.AccessController.doPrivileged(Native Method)
at
java.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:170)
at java.io.ObjectStreamClass.writeNonProxy(ObjectStreamClass.java:557)
at
java.io.ObjectOutputStream.writeClassDescriptor(ObjectOutputStream.java:591)
at
java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1142)
at
java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1100)
at java.io.ObjectOutputStream.writeClass(ObjectOutputStream.java:1082)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:996)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at org.apache.geronimo.gbean.GBeanData.writeExternal(GBeanData.java:187)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.storeGBeans(SerializedGBeanState.java:139)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.writeObject(SerializedGBeanState.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData
Re: Link to Xbean site
FYI: There is a JIRA for XBean link, currently assigned to Dain: http://issues.apache.org/jira/browse/GERONIMO-2215 John Hernan Cunico wrote: Jacek, I added those entries there and commented them as we still don't have the final text to describe those subprojects. I personally could not find the right wording but hope somebody else can :) Pls feel free to update the text and uncomment that entry. Make sure you add the link in the xdocs\stylesheets\project.xml too. (there should be three updates, one to the subprojects, one to the stylesheets\project and one to the XBean page itself). Cheers! Hernan Jacek Laskowski wrote: On 7/20/06, John Sisson [EMAIL PROTECTED] wrote: Should a link be added on the http://geronimo.apache.org/subprojects.html page to the http://geronimo.apache.org/xbean/ site? Currently I don't think there are any links to XBean from the Geronimo site. The XBean poms also need to be updated with the new website address instead of http://xbean.org I've taken a look at xdocs/subprojects.xml and noticed this: !--subsection name=GBuild p The aim of this subproject is to provide sample_sample_sample_sample_sample_sample_sample_. More details about this subproject are available at the a href=gbuild.htmlGBuild Subproject/a page. /p /subsection subsection name=XBean p The aim of this subproject is to provide sample_sample_sample_sample_sample_sample_sample_. More details about this subproject are available at the a href=xbean.htmlXBean Subproject/a page. /p /subsection -- Why have these bits been commented out? If they were uncommented, it'd do the trick, wouldn't it? I'm going to revert it to the uncommented state, unless someone objects. Jacek
[jira] Commented: (GERONIMO-2208) bad classpath in geronimo-deploy-jsr88-1.1.jar
[
http://issues.apache.org/jira/browse/GERONIMO-2208?page=comments#action_12423200
]
John Sisson commented on GERONIMO-2208:
---
Could you please provide some more information on the steps to reproduce this
problem, along with a stackstrace of the ClassNotFoundException to aid
understanding of the issue and to help others searching JIRAs for similar
symptoms.
Thanks,
John
bad classpath in geronimo-deploy-jsr88-1.1.jar
--
Key: GERONIMO-2208
URL: http://issues.apache.org/jira/browse/GERONIMO-2208
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 1.1.x
Reporter: Ted Kirby
Fix For: 1.1.x, 1.2
When trying to do a remote deploy using geronimo-deploy-jsr88-1.1.jar, got a
class not found exception on org.apache.geronimo.util.encoders.Base64. This
class is packaged in geronimo-util-1.1.jar. The classpath in
geronimo-deploy-jsr88-1.1.jar is suspect. First, it does not include the
required geronimo-util-1.1.jar. Second, it includes itself, which I think is
unnecessary.
My change is to geronimo\modules\deploy-jsr88\src\conf\manifest.mf.
In the classpath, I changed:
../lib/geronimo-deploy-jsr88-${geronimo_version}.jar
---
../lib/geronimo-util-${geronimo_version}.jar
With that change, my remote deploy was successful.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2226) Site migration to m2 build
Site migration to m2 build -- Key: GERONIMO-2226 URL: http://issues.apache.org/jira/browse/GERONIMO-2226 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: website Reporter: John Sisson Priority: Trivial Currently the Geronimo site is build using Ant. The Ant build has been recently updated to use Velocity to 1.5-dev (I built from svn rev 386004) to fix issue where generated html files have inconsistent line endings when building the site on Windows ( see http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg11613.html ) See http://svn.apache.org/viewcvs?rev=386059view=rev A conversion to Maven 2 needs to use a version of velocity that has this fix. You can test whether the version of velocity has the fix by: * running touch * in cygwin in the geronimo\site\xdocs directory * build the site * attempt to check in the generated site files under geronimo\site\docs - if you don't get any errors about inconsistent line endings then you are using the fixed version of velocity. For a list of dependencies required by velocity see the doco at http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/xdocs/jar-dependencies.xml . FYI, the current Ant build loads the jars in the geronimo\site\lib dir onto the classpath. I don't know if velocity's project.xml file is up to date as they aren't doing builds with maven yet AFAIK.. http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/project.xml Looks like we should wait until velocity 1.5 is released as we are currently running from a velocity 1.5 development build to get around some bugs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1748) Site migration to Maven 2
[ http://issues.apache.org/jira/browse/GERONIMO-1748?page=all ] John Sisson closed GERONIMO-1748. - Fix Version/s: (was: 1.2) Resolution: Duplicate Assignee: John Sisson I seem to remember Jacek saying (a while ago..) we should replace the ant code with maven and this could be done as part of the m2 migration work. Anyway, it looks like we should wait until velocity 1.5 is released as we are currently running from a 1.5 development build to get around some bugs. Closing this JIRA and have created GERONIMO-2226 . John Site migration to Maven 2 - Key: GERONIMO-1748 URL: http://issues.apache.org/jira/browse/GERONIMO-1748 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: website Affects Versions: 1.2 Reporter: John Sisson Assigned To: John Sisson Priority: Minor Currently the Geronimo site is build using Ant. The Ant build has been recently updated to use Velocity to 1.5-dev (I built from svn rev 386004) to fix issue where generated html files have inconsistent line endings when building the site on Windows ( see http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg11613.html ) See http://svn.apache.org/viewcvs?rev=386059view=rev A conversion to Maven 2 needs to use a version of velocity that has this fix. You can test whether the version of velocity has the fix by: * running touch * in cygwin in the geronimo\site\xdocs directory * build the site * attempt to check in the generated site files under geronimo\site\docs - if you don't get any errors about inconsistent line endings then you are using the fixed version of velocity. For a list of dependencies required by velocity see the doco at http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/xdocs/jar-dependencies.xml . FYI, the current Ant build loads the jars in the geronimo\site\lib dir onto the classpath. I don't know if velocity's project.xml file is up to date as they aren't doing builds with maven yet AFAIK.. http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/project.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-1748) Site migration to Maven 2
FYI, closed this JIRA and created GERONIMO-2226. John Jason Dillon (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1748?page=comments#action_12423146 ] Jason Dillon commented on GERONIMO-1748: Why... how is this related to 1.2... why does this need to use m2? Site migration to Maven 2 - Key: GERONIMO-1748 URL: http://issues.apache.org/jira/browse/GERONIMO-1748 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: website Affects Versions: 1.2 Reporter: John Sisson Priority: Minor Fix For: 1.2 Currently the Geronimo site is build using Ant. The Ant build has been recently updated to use Velocity to 1.5-dev (I built from svn rev 386004) to fix issue where generated html files have inconsistent line endings when building the site on Windows ( see http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg11613.html ) See http://svn.apache.org/viewcvs?rev=386059view=rev A conversion to Maven 2 needs to use a version of velocity that has this fix. You can test whether the version of velocity has the fix by: * running touch * in cygwin in the geronimo\site\xdocs directory * build the site * attempt to check in the generated site files under geronimo\site\docs - if you don't get any errors about inconsistent line endings then you are using the fixed version of velocity. For a list of dependencies required by velocity see the doco at http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/xdocs/jar-dependencies.xml . FYI, the current Ant build loads the jars in the geronimo\site\lib dir onto the classpath. I don't know if velocity's project.xml file is up to date as they aren't doing builds with maven yet AFAIK.. http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/project.xml
Is SingleFileHotDeployer still used?
Is 1.1\modules\deployment\src\java\org\apache\geronimo\deployment\SingleFileHotDeployer.java still used? I can see anything referencing it except for some tests. It was added in April 2006 by Dain in http://svn.apache.org/viewcvs?rev=397307view=rev What is its relationship to the org.apache.geronimo.deployment.hot.DirectoryHotDeployer used in the hot-deployer-config? There were a number of issues with a fix version of 1.1 referencing the SingleFileHotDeployer so it seems like it is/was used: http://issues.apache.org/jira/browse/GERONIMO-1946 http://issues.apache.org/jira/browse/GERONIMO-1962 http://issues.apache.org/jira/browse/GERONIMO-2036 Thanks, John
