MIT courses for free...
FYI, a friend sent this to me a while ago... "a free and open educational resource (OER) for educators, students, and self-learners around the world." http://ocw.mit.edu/index.html * * * Have not actually looked into it too much, but it looks really cool. --jason
Re: GERONIMO-2816 patch
Tomcat enables resource injection by looking for annotations in servlets, filters, and listeners. It's pretty efficient because it already knows which classes implement those interfaces from processing web.xml. See http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java Best wishes, Paul On 2/10/07, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 2/10/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > Are you sure you must scan all classes in the web module for @EJB > annotations? I haven't checked the patch, but what Dain said made me think we could overdo the annotation processing. Not all classes might get annotated with @EJB(s). Perhaps there's a way to ask a web container for special classes and check them out whether they use annotation or not? Does Tomcat 6 provide a annotation processing facility? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Geronimo documentation architecture
cool..Thank you very much for your info.. Karthiga good news isn't it? Thanks Kanchana On Sat, 2007-02-10 at 21:11 -0800, Jason Dillon wrote: > FYI, more info on Giffy here: > > http://confluence.atlassian.com/display/CONFEXT/Gliffy+Plugin+for > +Confluence+-+Diagram+and+draw+in+Confluence > > and here: > > http://www.gliffy.com/ > > --jason > > > On Feb 10, 2007, at 9:04 PM, Jason Dillon wrote: > > > FYI, cwiki has Giffy installed on it... so you can use that to > > create diagrams too. See the "Add Diagram" link when looking at a > > page under http://cwiki.apache.org/confluence/... > > > > --jason > > > > > > On Feb 10, 2007, at 8:57 PM, Kanchana Welagedara wrote: > > > >> Hi Hernan > >> > >> Everything has nicely put together.Good content Hernan. > >> I think it would be useful for people who wants contribute in > >> writing > >> docs to know tips about drawing diagrams as well (in the section of > >> "Tips for Writing and formatting documentation").Most of the > >> diagrams in > >> Sample applications and deployment plans were used open office/ > >> eclipse > >> tools (Since we don't have license software) to draw diagrams.Also we > >> have used geronimo colors(Blue,Black). > >> > >> Regards > >> Kanchana > >> > >> On Fri, 2007-02-09 at 14:46 -0500, Hernan Cunico wrote: > >>> Hi All, > >>> I put together two documents explaining how Geronimo's wiki is > >>> organized, confluence spaces, HTML auto export plugins, etc. as > >>> well as some basic guidelines for formatting the content for the > >>> articles that make the actual Geronimo documentation. > >>> > >>> Documentation architecture: > >>> http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation- > >>> architecture.html > >>> > >>> Documentation guidelines: > >>> http://cwiki.apache.org/geronimo/tips-for-writing-and-formatting- > >>> documentation.html > >>> > >>> Pls let me know if any of these docs are not clear, there is a > >>> lot of room for improvement. > >>> > >>> The idea behind this is to: > >>> > >>> 1.- have documented how the Geronimo documentation is organized > >>> 2.- provide a standard way to reference specific pages/articles > >>> within the documentation > >>> 3.- provide text formatting guidelines for consistency all across > >>> the documentation. > >>> > >>> Your comments are very much appreciated. > >>> > >>> Cheers! > >>> Hernan > >> > > >
Re: svn commit: r505842 - /geronimo/server/trunk/configs/pom.xml
Not a big deal, just whacky indent makes my head explode upon
viewing ;-)
--jason
On Feb 10, 2007, at 9:51 PM, Davanum Srinivas wrote:
Sorry. i used another editor for find in files...and forgot to set the
spaces/tabs option.
-- dims
On 2/11/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
Please watch your indent... this (and last few commits) have had
invalid indentation.
Please configure your editor to use spaces instead of tabs.
:-)
--jason
On Feb 10, 2007, at 9:27 PM, [EMAIL PROTECTED] wrote:
> Author: dims
> Date: Sat Feb 10 21:27:19 2007
> New Revision: 505842
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=505842
> Log:
> switch order as per jarek's request
>
> Modified:
> geronimo/server/trunk/configs/pom.xml
>
> Modified: geronimo/server/trunk/configs/pom.xml
> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/
> pom.xml?view=diff&rev=505842&r1=505841&r2=505842
>
=
=
>
> --- geronimo/server/trunk/configs/pom.xml (original)
> +++ geronimo/server/trunk/configs/pom.xml Sat Feb 10 21:27:19 2007
> @@ -45,8 +45,8 @@
> org.apache.geronimo.configs/openejb-
> deployer/${version}/car
>
> org.apache.geronimo.configs/axis-deployer/$
> {version}/car
> + org.apache.geronimo.configs/cxf-
deployer/${version}/
> car
> org.apache.geronimo.configs/axis2-
deployer/$
> {version}/car
> -org.apache.geronimo.configs/cxf-deployer/$
> {version}/car
> org.apache.geronimo.configs/tomcat6-
> deployer/${version}/car
> org.apache.geronimo.configs/jetty6-
> deployer/${version}/car
>
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services
Developers
Re: svn commit: r505842 - /geronimo/server/trunk/configs/pom.xml
Sorry. i used another editor for find in files...and forgot to set the
spaces/tabs option.
-- dims
On 2/11/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
Please watch your indent... this (and last few commits) have had
invalid indentation.
Please configure your editor to use spaces instead of tabs.
:-)
--jason
On Feb 10, 2007, at 9:27 PM, [EMAIL PROTECTED] wrote:
> Author: dims
> Date: Sat Feb 10 21:27:19 2007
> New Revision: 505842
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=505842
> Log:
> switch order as per jarek's request
>
> Modified:
> geronimo/server/trunk/configs/pom.xml
>
> Modified: geronimo/server/trunk/configs/pom.xml
> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/
> pom.xml?view=diff&rev=505842&r1=505841&r2=505842
> ==
>
> --- geronimo/server/trunk/configs/pom.xml (original)
> +++ geronimo/server/trunk/configs/pom.xml Sat Feb 10 21:27:19 2007
> @@ -45,8 +45,8 @@
> org.apache.geronimo.configs/openejb-
> deployer/${version}/car
>
> org.apache.geronimo.configs/axis-deployer/$
> {version}/car
> +
org.apache.geronimo.configs/cxf-deployer/${version}/
> car
> org.apache.geronimo.configs/axis2-deployer/$
> {version}/car
> -org.apache.geronimo.configs/cxf-deployer/$
> {version}/car
> org.apache.geronimo.configs/tomcat6-
> deployer/${version}/car
> org.apache.geronimo.configs/jetty6-
> deployer/${version}/car
>
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: svn commit: r505842 - /geronimo/server/trunk/configs/pom.xml
Please watch your indent... this (and last few commits) have had
invalid indentation.
Please configure your editor to use spaces instead of tabs.
:-)
--jason
On Feb 10, 2007, at 9:27 PM, [EMAIL PROTECTED] wrote:
Author: dims
Date: Sat Feb 10 21:27:19 2007
New Revision: 505842
URL: http://svn.apache.org/viewvc?view=rev&rev=505842
Log:
switch order as per jarek's request
Modified:
geronimo/server/trunk/configs/pom.xml
Modified: geronimo/server/trunk/configs/pom.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/
pom.xml?view=diff&rev=505842&r1=505841&r2=505842
==
--- geronimo/server/trunk/configs/pom.xml (original)
+++ geronimo/server/trunk/configs/pom.xml Sat Feb 10 21:27:19 2007
@@ -45,8 +45,8 @@
org.apache.geronimo.configs/openejb-
deployer/${version}/car
org.apache.geronimo.configs/axis-deployer/$
{version}/car
+ org.apache.geronimo.configs/cxf-deployer/${version}/
car
org.apache.geronimo.configs/axis2-deployer/$
{version}/car
-org.apache.geronimo.configs/cxf-deployer/$
{version}/car
org.apache.geronimo.configs/tomcat6-
deployer/${version}/car
org.apache.geronimo.configs/jetty6-
deployer/${version}/car
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 10, 2007, at 9:25 PM, Paul McMahan wrote: I agree that this approach would avoid network dependency but I'm not as convinced that network access presents a problem. Most of the installers I've used lately depend on network access in one way or another. I also suspect that users will customize their server right after downloading it. Many installers I've seen allow for light version which rely on the network to fetch components, and have a complete version which includes all of the components. From an automation perspective it would be best not to add more network dependency, so that once we have a distro zip, we can assume that personality configuration will function with-out unexpected failures due to network issues. Besides a smaller download size, the plugin approach has the advantage that the CLI and admin console are already available for driving the server customization process. Should we invest additional effort in providing the user with another way to achieve effectively the same results? If so then will it be clear to users when to use the plugin installer vs. when to use this alternative mechanism? IMO, the personality bits are simply collections of plugins (perhaps a few non-plugin cars) to be applied to a base installation. I think the concept is complementary with what we have now. One other factor to consider is that the "one big assembly" approach would only deactivate components when they are replaced and not actually uninstall them (at least if I understand your proposal correctly). If the deactivated components were later reactivated from the admin console or from an environmental dependency then the server could enter an unusable state. Sure, that is a danger... though that danger exists today. I was not suggesting any specific implementation, but one solution would be to ship all of the extra components for personalities in a different repository dir, then the personality application tool would install from one repo to another. But, really, we probably need to create some mechanism to classify types of plugins, and then warn the user if they are attempting to enable/install a plugin which collides with another plugin already installed. For example, if there a Jetty plugin already installed, trying to install Tomcat would warn strongly that a duplicate "webcontainer" plugin was already installed (and let them install it if they know better than we do). RPMs do something similar with its 'provides' tag in spec files... so for example, the apache httpd RPM package might provide 'webserver', fnord (another light http server) might also provide 'webserver' and when apache httpd is already installed, attempts to install fnord will barf with a conflict (which can be forced to override). --jason
Re: svn commit: r505624 - in /geronimo/server/trunk: ./ assemblies/geronimo-jetty6-jee5/src/main/var/config/ assemblies/geronimo-tomcat6-jee5/src/main/var/config/ configs/axis-deployer/src/plan/ confi
Sorry, my mistake. I thought you changed jetty-deployer/tomcat-deployer plan.xml files. Jarek On 2/10/07, David Blevins <[EMAIL PROTECTED]> wrote: On Feb 9, 2007, at 8:25 PM, Jarek Gawor wrote: > David, > > Did you just disable support for Servlet-based WS? If so, why? No. Are they not working anymore? -David > > Jarek > > On 2/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> Author: dblevins >> Date: Fri Feb 9 19:52:38 2007 >> New Revision: 505624 >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=505624 >> Log: >> Ported Axis1 integration >> >> Added: >> geronimo/server/trunk/modules/geronimo-axis-builder/src/main/ >> java/org/apache/geronimo/axis/builder/AxisModuleBuilderExtension.java >> geronimo/server/trunk/modules/geronimo-axis/src/main/java/org/ >> apache/geronimo/axis/server/EjbWebServiceGBean.java >> geronimo/server/trunk/modules/geronimo-j2ee-builder/src/main/ >> java/org/apache/geronimo/j2ee/deployment/ModuleBuilderExtension.java >> Modified: >> geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/ >> var/config/config.xml >> geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/ >> main/var/config/config.xml >> geronimo/server/trunk/configs/axis-deployer/src/plan/plan.xml >> geronimo/server/trunk/configs/openejb-deployer/src/plan/plan.xml >> geronimo/server/trunk/configs/openejb/pom.xml >> geronimo/server/trunk/modules/geronimo-axis-builder/pom.xml >> geronimo/server/trunk/modules/geronimo-axis/pom.xml >> geronimo/server/trunk/modules/geronimo-axis/src/main/resources/ >> META-INF/geronimo-dependency.xml >> geronimo/server/trunk/modules/geronimo-openejb-builder/src/ >> main/java/org/apache/geronimo/openejb/deployment/ >> EjbModuleBuilder.java >> geronimo/server/trunk/modules/geronimo-openejb/src/main/java/ >> org/apache/geronimo/openejb/EjbDeployment.java >> geronimo/server/trunk/pom.xml >> >> Modified: geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/ >> src/main/var/config/config.xml >> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/ >> geronimo-jetty6-jee5/src/main/var/config/config.xml? >> view=diff&rev=505624&r1=505623&r2=505624 >> = >> = >> --- geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/ >> var/config/config.xml (original) >> +++ geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/ >> var/config/config.xml Fri Feb 9 19:52:38 2007 >> @@ -142,17 +142,6 @@ >> PersistenceUnitBuilder >> >> >> - >> - >> -CXFBuilder >> - >> - >> -Axis2Builder >> - >> - >> -WebServiceBuilder >> - >> - >> >> >> http://java.sun.com/ >> xml/ns/j2ee,http://java.sun.com/xml/ns/javaee >> >> Modified: geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/ >> src/main/var/config/config.xml >> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/ >> geronimo-tomcat6-jee5/src/main/var/config/config.xml? >> view=diff&rev=505624&r1=505623&r2=505624 >> = >> = >> --- geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/ >> main/var/config/config.xml (original) >> +++ geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/ >> main/var/config/config.xml Fri Feb 9 19:52:38 2007 >> @@ -149,17 +149,6 @@ >> PersistenceUnitBuilder >> >> >> - >> - >> -CXFBuilder >> - >> - >> -Axis2Builder >> - >> - >> -WebServiceBuilder >> - >> - >> >> >> http://java.sun.com/ >> xml/ns/j2ee,http://java.sun.com/xml/ns/javaee >> >> Modified: geronimo/server/trunk/configs/axis-deployer/src/plan/ >> plan.xml >> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ >> axis-deployer/src/plan/plan.xml? >> view=diff&rev=505624&r1=505623&r2=505624 >> >
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
I agree that this approach would avoid network dependency but I'm not as convinced that network access presents a problem. Most of the installers I've used lately depend on network access in one way or another. I also suspect that users will customize their server right after downloading it. Besides a smaller download size, the plugin approach has the advantage that the CLI and admin console are already available for driving the server customization process. Should we invest additional effort in providing the user with another way to achieve effectively the same results? If so then will it be clear to users when to use the plugin installer vs. when to use this alternative mechanism? One other factor to consider is that the "one big assembly" approach would only deactivate components when they are replaced and not actually uninstall them (at least if I understand your proposal correctly). If the deactivated components were later reactivated from the admin console or from an environmental dependency then the server could enter an unusable state. Best wishes, Paul On 2/10/07, Jason Dillon <[EMAIL PROTECTED]> wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: > On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: >> I'm definitely *NOT* in-favor of 8 assemblies. > > Ditto. Even if there was time and manpower to test every possible > assembly then I still don't think the end user would be prepared to > make an informed choice about which one to download. > >> On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: >> > If there is a plugin option then I think the TCK discussion becomes >> > simpler. Anyway, for those more skilled in that art than I what >> > are the community thoughts on how to address our expanding set of >> > pluggable components? > > I think that presenting the user with lots of choices is a good thing > if geronimo can : > 1.) provide a TCK tested default assembly > 2.) help users make informed decisions about changing the defaults > 3.) make it easy to enact their decisions > 4.) allow them to change their minds later > > With that in mind, I think the ideal scenario (from a user's > perspective) would be to provide one fully tested JEE5 assembly from > the download page and then make it easy to swap out components after > installation using plugins. Components that have passed the TCK in > any assembly can be marked as such in the plugin catalog, along with > any other useful information about that component such as which JEE > spec it implements, etc. Components that are mutually exclusive like > cxf and axis2, jetty and tomcat, etc can provide metadata that will > prompt the plugin system to uninstall the component that is being > replaced. > > There are lots of details and what-ifs that would need to be worked > out before this approach can be fully realized. But if there's > consensus around it then the next release could at least take a step > in the right direction. AFAIK most if not all of the necessary > functionality and infrastructure are already in place. > > Best wishes, > Paul
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 10, 2007, at 7:54 AM, Kevan Miller wrote: On Feb 10, 2007, at 3:55 AM, David Jencks wrote: I think this would be great, especially if we adapted the assembly stuff we have now so you could extract a server that had just what you wanted in it. Then we could supply just one download and let people simplify it themselves if they wanted to. I like it. The size delta would be a minor issue, IMO. I'd be in favor of this as a general approach. A few points: 1. I'd like to maintain two multi-personality distributions -- a minimal and Java EE distribution. Does minimal include a web-container? 2. IMO, the distributions must have a default configuration. Downloading and starting a server must be simple (i.e. no selection/ configuration is required). Yes, the server should check when bootstraping if it has been configured with a personality, if not, it will select the default and continue... so the user does not have to explicitly configure a personality. 3. I would not want this to be the cause of a significant delay in the 2.0 release Ya, hopefully not... else we can leave it for 2.1... I do think this is a good idea. --jason
Re: Geronimo documentation architecture
FYI, more info on Giffy here: http://confluence.atlassian.com/display/CONFEXT/Gliffy+Plugin+for +Confluence+-+Diagram+and+draw+in+Confluence and here: http://www.gliffy.com/ --jason On Feb 10, 2007, at 9:04 PM, Jason Dillon wrote: FYI, cwiki has Giffy installed on it... so you can use that to create diagrams too. See the "Add Diagram" link when looking at a page under http://cwiki.apache.org/confluence/... --jason On Feb 10, 2007, at 8:57 PM, Kanchana Welagedara wrote: Hi Hernan Everything has nicely put together.Good content Hernan. I think it would be useful for people who wants contribute in writing docs to know tips about drawing diagrams as well (in the section of "Tips for Writing and formatting documentation").Most of the diagrams in Sample applications and deployment plans were used open office/ eclipse tools (Since we don't have license software) to draw diagrams.Also we have used geronimo colors(Blue,Black). Regards Kanchana On Fri, 2007-02-09 at 14:46 -0500, Hernan Cunico wrote: Hi All, I put together two documents explaining how Geronimo's wiki is organized, confluence spaces, HTML auto export plugins, etc. as well as some basic guidelines for formatting the content for the articles that make the actual Geronimo documentation. Documentation architecture: http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation- architecture.html Documentation guidelines: http://cwiki.apache.org/geronimo/tips-for-writing-and-formatting- documentation.html Pls let me know if any of these docs are not clear, there is a lot of room for improvement. The idea behind this is to: 1.- have documented how the Geronimo documentation is organized 2.- provide a standard way to reference specific pages/articles within the documentation 3.- provide text formatting guidelines for consistency all across the documentation. Your comments are very much appreciated. Cheers! Hernan
Re: Geronimo documentation architecture
FYI, cwiki has Giffy installed on it... so you can use that to create diagrams too. See the "Add Diagram" link when looking at a page under http://cwiki.apache.org/confluence/... --jason On Feb 10, 2007, at 8:57 PM, Kanchana Welagedara wrote: Hi Hernan Everything has nicely put together.Good content Hernan. I think it would be useful for people who wants contribute in writing docs to know tips about drawing diagrams as well (in the section of "Tips for Writing and formatting documentation").Most of the diagrams in Sample applications and deployment plans were used open office/eclipse tools (Since we don't have license software) to draw diagrams.Also we have used geronimo colors(Blue,Black). Regards Kanchana On Fri, 2007-02-09 at 14:46 -0500, Hernan Cunico wrote: Hi All, I put together two documents explaining how Geronimo's wiki is organized, confluence spaces, HTML auto export plugins, etc. as well as some basic guidelines for formatting the content for the articles that make the actual Geronimo documentation. Documentation architecture: http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation- architecture.html Documentation guidelines: http://cwiki.apache.org/geronimo/tips-for-writing-and-formatting- documentation.html Pls let me know if any of these docs are not clear, there is a lot of room for improvement. The idea behind this is to: 1.- have documented how the Geronimo documentation is organized 2.- provide a standard way to reference specific pages/articles within the documentation 3.- provide text formatting guidelines for consistency all across the documentation. Your comments are very much appreciated. Cheers! Hernan
Re: Daytrader: Closing out open JIRAs with patch3s
Matt, If you are a moderator for that list, you can add chri's apache email to the allow list. [EMAIL PROTECTED] where xyz is the mailing list. Alternatively, when you get the moderator message, make sure you click on reply all (and then ensure that the mail id with "allow" in it) and send it. thanks, dims On 2/10/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Anyone know what the magic that needs to be done is? I'm happy to do it but not sure which bit needs to be twiddled. On Feb 10, 2007, at 11:55 AM, Kevan Miller wrote: > I suspect that Chris's commit messages are not showing up in our > SCM list. > > As I recall, we have to explicitly grant him access and we often > forget to do this with new committers... > > Can someone with necessary karma address? > > --kevan > > > On Feb 7, 2007, at 1:54 PM, Christopher Blythe wrote: > >> All, >> >> In an effort to close out Daytrader 1.2 (branches/1.2) and and >> sync up any unwanted deltas between 1.2 and trunk, I am working my >> way through the open JIRAs and applying those with outstanding >> patches. >> >> Yesterday, I applied updates for the following JIRAs to trunk >> (since they had already been committed to 1.2). >> - DAYTRADER-17: Dojo UI >> - DAYTRADER-22: Config flag for publishQuotePrices >> >> When applying the changes for DAYTRADER-17 in truck, I forgot to >> update the pom.xml files with the correct Daytrader snapshot >> version. Matt took care of that, earlier this morning (DAYTRADER-34). >> >> In addition to these items, I would like to go ahead and apply >> patches that have been submitted for the following JIRAs... >> - DAYTRADER-25: DDL updates for indexes and decimal precision and >> an update to the quote price change logic >> - DAYTRADER-29: Remove Async 1-Phase mode >> - DAYTRADER-33: Add JMS close connection to TradeDirect.queueOrder >> >> Any objections, concerns, or comments? >> >> Thanks... >> >> Chris >> >> -- >> "I say never be complete, I say stop being perfect, I say let... >> lets evolve, let the chips fall where they may." - Tyler Durden > > -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: Geronimo documentation architecture
Hi Hernan Everything has nicely put together.Good content Hernan. I think it would be useful for people who wants contribute in writing docs to know tips about drawing diagrams as well (in the section of "Tips for Writing and formatting documentation").Most of the diagrams in Sample applications and deployment plans were used open office/eclipse tools (Since we don't have license software) to draw diagrams.Also we have used geronimo colors(Blue,Black). Regards Kanchana On Fri, 2007-02-09 at 14:46 -0500, Hernan Cunico wrote: > Hi All, > I put together two documents explaining how Geronimo's wiki is organized, > confluence spaces, HTML auto export plugins, etc. as well as some basic > guidelines for formatting the content for the articles that make the actual > Geronimo documentation. > > Documentation architecture: > http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-architecture.html > > Documentation guidelines: > http://cwiki.apache.org/geronimo/tips-for-writing-and-formatting-documentation.html > > Pls let me know if any of these docs are not clear, there is a lot of room > for improvement. > > The idea behind this is to: > > 1.- have documented how the Geronimo documentation is organized > 2.- provide a standard way to reference specific pages/articles within the > documentation > 3.- provide text formatting guidelines for consistency all across the > documentation. > > Your comments are very much appreciated. > > Cheers! > Hernan
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 10, 2007, at 8:40 PM, Matt Hogstrom wrote: On Feb 10, 2007, at 5:59 PM, Jason Dillon wrote: Aye... on each personality switch I would expect a big warning about "things might not work afterwards", just like any other brain surgery, there are going to be some risks. But if we had a simple way to switch, then we could probably help ensure that each component behaved well with the others. Unlike brain surgery though... hopefully if something does break, switching back to the previous personality would work. It would be pretty nice to be able to switch. I'm wondering how many people would be doing this though. It might be like trying to change your spark plugs while driving down the highway at 75 miles an hour :) I'd imagine that most people would just use it once to configure the personality of the server they wanted/needed. Sure, some would switch back and forth, but they would be in the minority I'd expect. Many would not care at all and would use the default personality which would get applied automatically the first time the server started. Switching between would probably be used mostly by automated tests to help ensure component interop. But... really, the point is to reduce assemblies and distributions which we build, but still allowing folks a choice of what components are actually getting used for their applications. --jason
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 10, 2007, at 5:59 PM, Jason Dillon wrote: Aye... on each personality switch I would expect a big warning about "things might not work afterwards", just like any other brain surgery, there are going to be some risks. But if we had a simple way to switch, then we could probably help ensure that each component behaved well with the others. Unlike brain surgery though... hopefully if something does break, switching back to the previous personality would work. It would be pretty nice to be able to switch. I'm wondering how many people would be doing this though. It might be like trying to change your spark plugs while driving down the highway at 75 miles an hour :) --jason
Re: Daytrader: Closing out open JIRAs with patch3s
Anyone know what the magic that needs to be done is? I'm happy to do it but not sure which bit needs to be twiddled. On Feb 10, 2007, at 11:55 AM, Kevan Miller wrote: I suspect that Chris's commit messages are not showing up in our SCM list. As I recall, we have to explicitly grant him access and we often forget to do this with new committers... Can someone with necessary karma address? --kevan On Feb 7, 2007, at 1:54 PM, Christopher Blythe wrote: All, In an effort to close out Daytrader 1.2 (branches/1.2) and and sync up any unwanted deltas between 1.2 and trunk, I am working my way through the open JIRAs and applying those with outstanding patches. Yesterday, I applied updates for the following JIRAs to trunk (since they had already been committed to 1.2). - DAYTRADER-17: Dojo UI - DAYTRADER-22: Config flag for publishQuotePrices When applying the changes for DAYTRADER-17 in truck, I forgot to update the pom.xml files with the correct Daytrader snapshot version. Matt took care of that, earlier this morning (DAYTRADER-34). In addition to these items, I would like to go ahead and apply patches that have been submitted for the following JIRAs... - DAYTRADER-25: DDL updates for indexes and decimal precision and an update to the quote price change logic - DAYTRADER-29: Remove Async 1-Phase mode - DAYTRADER-33: Add JMS close connection to TradeDirect.queueOrder Any objections, concerns, or comments? Thanks... Chris -- "I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may." - Tyler Durden
Re: svn commit: r505826 - in /geronimo/server/trunk: assemblies/geronimo-jetty6-jee5/src/main/var/config/ assemblies/geronimo-tomcat6-jee5/src/main/var/config/ configs/ configs/jetty6-deployer/src/pla
Jarek, [CC'ing the dev@ list] Sorry about the order of deployers. that was a mistake since i tested Axis2 last. I'll roll that back. I thought we had agreed to share the same tests for both stacks no? I can try to port your changes to the new test when you submit the patch or Please submit the original test as another separate test if you wish. BTW, am looking into the annotation and service-ref stuff next, so will touch related code in jaxws/cxf/axis2. thanks, dims On 2/10/07, Jarek Gawor <[EMAIL PROTECTED]> wrote: Dims, Can you tell me please why you changed the order of the deployers? At this point CXF should be first and Axis2 should be second. Also, can you commit the test changes you made as a separate test? That is, reverse the changes you made to tests and recommit them as a separate test? I'm using the original test for experimenting with stuff I don't want to have it changed now. Thanks, Jarek On 2/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: dims > Date: Sat Feb 10 18:39:49 2007 > New Revision: 505826 > > URL: http://svn.apache.org/viewvc?view=rev&rev=505826 > Log: > Make the test case reflect the wsdl being used by adding other methods mentioned in the wsdl. added a xjc task in the pom.xml to generate the types needed for the fault. Ran the existing tests with both axis2 and cxf. Need to add more tests for the newly added methods. > > Added: > geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-war/src/main/java/org/apache/greeter_control/ > geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-war/src/main/java/org/apache/greeter_control/Greeter.java > geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-war/src/main/java/org/apache/greeter_control/GreeterHandler.java > geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-war/src/main/java/org/apache/greeter_control/GreeterImpl.java > geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-war/src/main/java/org/apache/greeter_control/PingMeFault.java > geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-war/src/main/java/org/apache/greeter_control/handlers.xml > Removed: > geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-war/src/main/java/org/apache/hello_world_soap_http/ > Modified: > geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/var/config/config.xml > geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/main/var/config/config.xml > geronimo/server/trunk/configs/jetty6-deployer/src/plan/plan.xml > geronimo/server/trunk/configs/pom.xml > geronimo/server/trunk/configs/tomcat6-deployer/src/plan/plan.xml > geronimo/server/trunk/modules/geronimo-webservices-builder/src/test/resources/webservices-jee5.xml > geronimo/server/trunk/modules/pom.xml > geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-war/pom.xml > geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-war/src/main/webapp/WEB-INF/web.xml > geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-war/src/main/webapp/WEB-INF/webservices.xml > geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-war/src/test/java/org/apache/geronimo/testsuite/testset/JaxWSTest.java > > Modified: geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/var/config/config.xml > URL: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/var/config/config.xml?view=diff&rev=505826&r1=505825&r2=505826 > == > --- geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/var/config/config.xml (original) > +++ geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/var/config/config.xml Sat Feb 10 18:39:49 2007 > @@ -155,15 +155,15 @@ > > > > - > + > > - > > - > + > > - > > > Modified: geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/main/var/config/config.xml > URL: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/main/var/config/config.xml?view=diff&rev=505826&r1=505825&r2=505826 > == > --- geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/main/var/config/config.xml (original) > +++ geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/main/var/config/config.xml Sat Feb 10 18:39:49 2007 > @@ -162,17 +162,17 @@ > > > > - > - > - > > > > > + > + > + > > > http://java.sun.com/xml/ns/j2ee,http://java.sun.com/xml/ns/javaee > > Modified: geronimo/server/trunk/configs/jetty6-deployer/src/plan/plan.xml > UR
[jira] Created: (GERONIMO-2818) In-Place deployment does not interpret Manifest Class-Path entries correctly in JAR files
In-Place deployment does not interpret Manifest Class-Path entries correctly in JAR files - Key: GERONIMO-2818 URL: https://issues.apache.org/jira/browse/GERONIMO-2818 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 1.2 Environment: Windows XP SP2 Reporter: Aman Nanner Fix For: 1.2 >From the mailing list regarding deployment of EARs that contain JARS with a >Class-Path entry in their Manifest files: It seems like the behaviour is different depending on whether I deploy the EAR as "inPlace" or not. I was deploying an expanded EAR "inPlace" and it seems that I needed the "../" prefix before each JAR in my Manifest classpath. I tried deploying an EAR containing actual JAR archives without the "inPlace" attribute, and I had to change my Manifest classpath references by removing the "../" prefix to make it work. My guess is that the deployer creates a different folder hiearchy when deploying an application without the "inPlace" attribute. To review, using "inPlace" deployment requires that a "../" prefix be used in Manifest class-path entries to reference library JARs relative to the EAR root. This is a bug, and it should be the same as non-inPlace deployment, where library JARs are already relative to the EAR root. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2454) Upgrade xerces to version 2.8.1
[ https://issues.apache.org/jira/browse/GERONIMO-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472059 ] Anita Kulshreshtha commented on GERONIMO-2454: -- xalan was removed please see : https://issues.apache.org/jira/browse/GERONIMO-2594#action_12455365 > Upgrade xerces to version 2.8.1 > --- > > Key: GERONIMO-2454 > URL: https://issues.apache.org/jira/browse/GERONIMO-2454 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: common >Affects Versions: 1.2 > Environment: All >Reporter: Heinz Drews > Assigned To: David Jencks >Priority: Minor > Fix For: 1.2, 2.0-beta1 > > Attachments: xercesupgrade.diff, xercesupgrade2.diff, > xercesupgrade3.diff > > > Upgrade xerces to version 2.8.1. > Consolidate to use xml-apis instead of xmlParserAPIs. > I'll attach a path for several pom.xml. > It would be necessary to upload the xerces and xml-apis to the repository -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New openejb deployer has very different assumptions than the rest of the deployment system-- not compatible with offline deployment
On Feb 10, 2007, at 3:02 PM, David Jencks wrote: The new trunk openejb-deployer module requires the openejb module to be running (started) due to a reference from the deployer gbean to the OpenEjbSystem gbean. This means that you need an entirely started geronimo server to deploy any ejbs. In particular this is inconsistent with the idea of the offline deployer, which we need to assume won't open any ports. Previously we went to a lot of trouble to make sure that every bit of deployment code ran without any runtime components started. I would like to know if this new dependency is intentional, and essential. I don't think we should introduce such a very large change in philosophy about the geronimo server architecture without discussion. Should be easy to fix. Is there an offline deployer somewhere I can update? -David
[jira] Closed: (GERONIMO-2454) Upgrade xerces to version 2.8.1
[ https://issues.apache.org/jira/browse/GERONIMO-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2454. -- Resolution: Fixed Fix Version/s: 2.0-beta1 1.2 Finished fixing in trunk rev 505819. Looks like xalan wasn't previously included I'm not sure why. I haven't seen problems from this. > Upgrade xerces to version 2.8.1 > --- > > Key: GERONIMO-2454 > URL: https://issues.apache.org/jira/browse/GERONIMO-2454 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: common >Affects Versions: 1.2 > Environment: All >Reporter: Heinz Drews > Assigned To: David Jencks >Priority: Minor > Fix For: 1.2, 2.0-beta1 > > Attachments: xercesupgrade.diff, xercesupgrade2.diff, > xercesupgrade3.diff > > > Upgrade xerces to version 2.8.1. > Consolidate to use xml-apis instead of xmlParserAPIs. > I'll attach a path for several pom.xml. > It would be necessary to upload the xerces and xml-apis to the repository -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2814) Add a second repository to Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472054 ] David Jencks commented on GERONIMO-2814: applied the J2EEServerImpl patch to trunk. Still should expose the collection of PluginInstallers, not just the first one. rev 505822 > Add a second repository to Geronimo > --- > > Key: GERONIMO-2814 > URL: https://issues.apache.org/jira/browse/GERONIMO-2814 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.1.x, 2.0-M2 >Reporter: Ted Kirby >Priority: Minor > Fix For: 1.1.x, 2.0-M2 > > Attachments: GERONIMO-2814-J2EEServerImpl.patch, JIRA-2814-2.0.patch, > repo2-1.2-plan.xml, repo2-111-plan.xml, repo2-ag20-plan.xml, > repo2-ag20-plan2.xml > > > It would be nice to allow for a second repository for applications separate > from the default repository used by geronimo. > One use case would be for multiple server instances where the geronimo > repository would be read-only, and each server instance would have its own > read-write repository. > I have attached a 2.0 plan for a second repository, called repo2.xml. > Here is how to use it: > mkdir /repo2 > deploy repo2.xml > The target names are long and cumbersome: > >java deployer.jar list-targets > Available Targets: > > org.example.configs/myrepo/2.0-SNAPSHOT/car?ServiceModule=org.example.configs/myrepo/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local2 > > org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local > Use of environment variables recommended for command-line use. > To deploy to the new repo, use: > deploy --targets %REPO2% sample.war > deploy list-modules also gives those long target names on each module. > However, deploy list-modules %REPO2% gives the accustomed short output. > >java deployer.jar undeploy "%REPO2%|geronimo/jsp-examples/1.1.1/war" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Another build error :(
Can you publish new openejb artifacts please? --jason On Feb 10, 2007, at 5:30 PM, David Jencks wrote: I think I fixed this too by updating the amq version in openejb. You'll need to rebuild openejb, then g. thanks david jencks On Feb 10, 2007, at 4:28 PM, Sachin Patel wrote: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Unable to create configuration for deployment Unable to resolve dependency org.apache.activemq/activemq-ra//jar -sachin
Re: Another build error :(
I think I fixed this too by updating the amq version in openejb. You'll need to rebuild openejb, then g. thanks david jencks On Feb 10, 2007, at 4:28 PM, Sachin Patel wrote: [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Unable to create configuration for deployment Unable to resolve dependency org.apache.activemq/activemq-ra//jar -sachin
Another build error :(
[INFO] [ERROR] BUILD ERROR [INFO] [INFO] Unable to create configuration for deployment Unable to resolve dependency org.apache.activemq/activemq-ra//jar -sachin
Re: [BUILD] Failed for Revision: 505776
no, that was what I assume was a mistake by dblevins that I already
fixed. The problem I'm talking about is that the dependency from
openejb-deployer to openejb modules should be "runtime" scope which
translates into "openejb module has to be there but doesn't have to
be started" in geronimo. This makes offline deployment possible.
thanks
david jencks
On Feb 10, 2007, at 3:43 PM, Prasad Kashyap wrote:
Is this what David Jencks is talking about in the following thread ?
http://www.nabble.com/New-openejb-deployer-has-very-different-
assumptions-than-the-rest-of-the-deployment-system---not-compatible-
with-offline-deployment-tf3207032.html
Cheers
Prasad
On 10 Feb 2007 22:19:24 -, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Revision: 505776 built with tests skipped
See the full build-170034.log file at http://people.apache.org/
~prasad/binaries/20070210/build-170034.log
[INFO] Building Geronimo Configs :: Tomcat
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [tools:require-java-version {execution: validate-java-
version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /home/prasad/geronimo/trunk/configs/tomcat6/
target/classes/META-INF
[INFO] Copying 2 files to /home/prasad/geronimo/trunk/configs/
tomcat6/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /home/prasad/geronimo/trunk/configs/tomcat6/
target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration: /home/prasad/geronimo/trunk/
configs/tomcat6/target/plan/plan.xml
[INFO] snapshot org.apache.geronimo.modules:geronimo-tomcat6:2.0-
SNAPSHOT: checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-tomcat6:2.0-
SNAPSHOT: checking for updates from axis2-m2-repo
[INFO] snapshot org.apache.geronimo.modules:geronimo-tomcat6:2.0-
SNAPSHOT: checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-tomcat6:2.0-
SNAPSHOT: checking for updates from apache.snapshots
[INFO] Building jar: /home/prasad/geronimo/trunk/configs/tomcat6/
target/tomcat6-2.0-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing /home/prasad/geronimo/trunk/configs/tomcat6/
target/tomcat6-2.0-SNAPSHOT.car to /home/prasad/.m2/repository/org/
apache/geronimo/configs/tomcat6/2.0-SNAPSHOT/tomcat6-2.0-SNAPSHOT.car
[INFO]
-
---
[INFO] Building Geronimo Configs :: Tomcat 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] Created dir: /home/prasad/geronimo/trunk/configs/tomcat6-
deployer/target/classes/META-INF
[INFO] Copying 2 files to /home/prasad/geronimo/trunk/configs/
tomcat6-deployer/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /home/prasad/geronimo/trunk/configs/tomcat6-
deployer/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration: /home/prasad/geronimo/trunk/
configs/tomcat6-deployer/target/plan/plan.xml
[INFO] snapshot org.apache.geronimo.modules:geronimo-tomcat6-
builder:2.0-SNAPSHOT: checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-tomcat6-
builder:2.0-SNAPSHOT: checking for updates from axis2-m2-repo
[INFO] snapshot org.apache.geronimo.modules:geronimo-tomcat6-
builder:2.0-SNAPSHOT: checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-tomcat6-
builder:2.0-SNAPSHOT: checking for updates from apache.snapshots
[INFO] snapshot org.apache.geronimo.configs:tomcat6:2.0-SNAPSHOT:
checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.configs:tomcat6:2.0-SNAPSHOT:
checking for updates from axis2-m2-repo
[INFO] snapshot org.apache.geronimo.configs:tomcat6:2.0-SNAPSHOT:
checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.configs:tomcat6:2.0-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] Building jar: /home/prasad/geronimo/trunk/configs/tomcat6-
deployer/target/tomcat6-deployer-2.0-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing /home/prasad/geronimo/trunk/configs/tomcat6-
deployer/target/tomcat6-deployer-2.0-SNAPSHOT.car to /home/
prasad/.m2/repository/org/apache/geronimo/configs/tomcat6-deployer/
2.0-SNAPSHOT/tomcat6-deployer-2.0-SNAPSHOT.car
[INFO]
-
---
[INFO] Building Geronimo Configs :: JSP Ex
Re: [BUILD] Failed for Revision: 505776
Is this what David Jencks is talking about in the following thread ?
http://www.nabble.com/New-openejb-deployer-has-very-different-assumptions-than-the-rest-of-the-deployment-system---not-compatible-with-offline-deployment-tf3207032.html
Cheers
Prasad
On 10 Feb 2007 22:19:24 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Revision: 505776 built with tests skipped
See the full build-170034.log file at
http://people.apache.org/~prasad/binaries/20070210/build-170034.log
[INFO] Building Geronimo Configs :: Tomcat
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/configs/tomcat6/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/configs/tomcat6/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
/home/prasad/geronimo/trunk/configs/tomcat6/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration:
/home/prasad/geronimo/trunk/configs/tomcat6/target/plan/plan.xml
[INFO] snapshot org.apache.geronimo.modules:geronimo-tomcat6:2.0-SNAPSHOT:
checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-tomcat6:2.0-SNAPSHOT:
checking for updates from axis2-m2-repo
[INFO] snapshot org.apache.geronimo.modules:geronimo-tomcat6:2.0-SNAPSHOT:
checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-tomcat6:2.0-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] Building jar:
/home/prasad/geronimo/trunk/configs/tomcat6/target/tomcat6-2.0-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/trunk/configs/tomcat6/target/tomcat6-2.0-SNAPSHOT.car to
/home/prasad/.m2/repository/org/apache/geronimo/configs/tomcat6/2.0-SNAPSHOT/tomcat6-2.0-SNAPSHOT.car
[INFO]
[INFO] Building Geronimo Configs :: Tomcat 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] Created dir:
/home/prasad/geronimo/trunk/configs/tomcat6-deployer/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/configs/tomcat6-deployer/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
/home/prasad/geronimo/trunk/configs/tomcat6-deployer/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration:
/home/prasad/geronimo/trunk/configs/tomcat6-deployer/target/plan/plan.xml
[INFO] snapshot
org.apache.geronimo.modules:geronimo-tomcat6-builder:2.0-SNAPSHOT: checking for
updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-tomcat6-builder:2.0-SNAPSHOT: checking for
updates from axis2-m2-repo
[INFO] snapshot
org.apache.geronimo.modules:geronimo-tomcat6-builder:2.0-SNAPSHOT: checking for
updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-tomcat6-builder:2.0-SNAPSHOT: checking for
updates from apache.snapshots
[INFO] snapshot org.apache.geronimo.configs:tomcat6:2.0-SNAPSHOT: checking for
updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.configs:tomcat6:2.0-SNAPSHOT: checking for
updates from axis2-m2-repo
[INFO] snapshot org.apache.geronimo.configs:tomcat6:2.0-SNAPSHOT: checking for
updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.configs:tomcat6:2.0-SNAPSHOT: checking for
updates from apache.snapshots
[INFO] Building jar:
/home/prasad/geronimo/trunk/configs/tomcat6-deployer/target/tomcat6-deployer-2.0-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/trunk/configs/tomcat6-deployer/target/tomcat6-deployer-2.0-SNAPSHOT.car
to
/home/prasad/.m2/repository/org/apache/geronimo/configs/tomcat6-deployer/2.0-SNAPSHOT/tomcat6-deployer-2.0-SNAPSHOT.car
[INFO]
[INFO] Building Geronimo Configs :: JSP Examples Tomcat
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/configs/jsp-examples-tomcat/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/configs/jsp-examples-tomcat/target/classes/META-INF
[INFO] [resources:resources]
[INFO]
Re: Removing "Geronimo RTC Workflow Scheme" in JIRA
IMO, should have never been there... and removed ass soon as CTR was back... so lets drop it. --jason On Feb 10, 2007, at 8:12 AM, Kevan Miller wrote: On Feb 9, 2007, at 9:12 AM, Matt Hogstrom wrote: Since we're not in RTC anymore (and hope to not return) Anyone opposed? I agree it should be removed. --kevan
New openejb deployer has very different assumptions than the rest of the deployment system-- not compatible with offline deployment
The new trunk openejb-deployer module requires the openejb module to be running (started) due to a reference from the deployer gbean to the OpenEjbSystem gbean. This means that you need an entirely started geronimo server to deploy any ejbs. In particular this is inconsistent with the idea of the offline deployer, which we need to assume won't open any ports. Previously we went to a lot of trouble to make sure that every bit of deployment code ran without any runtime components started. I would like to know if this new dependency is intentional, and essential. I don't think we should introduce such a very large change in philosophy about the geronimo server architecture without discussion. thanks david jencks
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
Yup, one assembly to build, one download (er 2 I guess zip + tgz)... geronimo--bin.. --jason On Feb 10, 2007, at 12:55 AM, David Jencks wrote: I think this would be great, especially if we adapted the assembly stuff we have now so you could extract a server that had just what you wanted in it. Then we could supply just one download and let people simplify it themselves if they wanted to. thanks david jencks On Feb 9, 2007, at 11:09 PM, Jason Dillon wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 10, 2007, at 11:24 AM, Joe Bohn wrote: I like the idea but I wonder how practical it will be and if users could get themselves in trouble. For example, what would happen if a set of applications was deployed using tomcat & cxf and then the user attempted to switch to jetty & axis? Granted, with the plugin approach they could create similar problems but since it's a little more difficult to install/uninstall a plugin which might provide some more safeguards. Um... well, plugins should not be difficult to install... and neither should it be difficult to switch personalities. Both *should* be ridiculously simple. If something dangerous might happen, then issue a warning and get a confirm prompt from the user. But just because it might mess something up does not mean that we should not provide it as a feature. Hiding or omitting dangerous (or potentially dangerous) features from users is a very bad practice IMO. We can provide some safeguards (ie. confirm prompt), but we need to empower users to make those decisions, and well... if they muck it up, they muck it up. Not like installing a bunk CAR or poorly crafted plugin won't do the same thing now. I guess we could always keep track of the previous state and warn the user if they are attempting to change the configuration on a subsequent restart when applications are deployed that have been configured for the prior configuration. Aye... on each personality switch I would expect a big warning about "things might not work afterwards", just like any other brain surgery, there are going to be some risks. But if we had a simple way to switch, then we could probably help ensure that each component behaved well with the others. Unlike brain surgery though... hopefully if something does break, switching back to the previous personality would work. --jason
Re: [jira] Commented: (GERONIMO-2800) Connector Lazy Activation leaks managed connections
On Feb 5, 2007, at 10:47 PM, Dain Sundstrom (JIRA) wrote: [ https://issues.apache.org/jira/browse/GERONIMO-2800? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12470441 ] Dain Sundstrom commented on GERONIMO-2800: -- I think I have fixed this problem in revision 503969. When connections are closed or destroyed do not reassociate the connection again or throw an exception. Instead simply invoke the handle and let the handle throw the exception. Please verify. Dain, Thanks for fixing this. I'd like to point out some things that I think could have been done better... When I pinned down the cause of this problem on the lazy connection support, I had no motivation to actually try and fix the lazy connection support. It appeared to be an optional feature and few, if anyone, understood why it had been added to Connector. My bad for not asking for information on your initial commit. It would be really useful to provide some of this information in the form of dev list discussion, code comments, and/or svn commit messages. I'll note that even with this fix, we still don't have a context for why lazy connections are needed (any info I have was obtained via IRC). IIUC, you did not want to use the ConnectionTracking mechanism for OpenEJB 3 connectors. So, you created a proxy-based approach, instead. So, we are dependent on this feature for OpenEJB support. --kevan
Re: [vote] Release geronimo-j2ee-connector_1.5_spec-1.1.1
;-) --kevan On Jan 31, 2007, at 10:48 PM, David Blevins wrote: All, I've updated the pom of this spec to be compiled with jdk 1.3 as requested by a project in jakarta commons that needs them. I hereby propose we release this branch and it's binaries as final. Release Branch: http://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-j2ee-connector_1.5_spec-1.1.1 Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/ apache/geronimo/specs/geronimo-j2ee-connector_1.5_spec/1.1.1/ Here's my +1 -David
Re: Daytrader: Closing out open JIRAs with patch3s
I suspect that Chris's commit messages are not showing up in our SCM list. As I recall, we have to explicitly grant him access and we often forget to do this with new committers... Can someone with necessary karma address? --kevan On Feb 7, 2007, at 1:54 PM, Christopher Blythe wrote: All, In an effort to close out Daytrader 1.2 (branches/1.2) and and sync up any unwanted deltas between 1.2 and trunk, I am working my way through the open JIRAs and applying those with outstanding patches. Yesterday, I applied updates for the following JIRAs to trunk (since they had already been committed to 1.2). - DAYTRADER-17: Dojo UI - DAYTRADER-22: Config flag for publishQuotePrices When applying the changes for DAYTRADER-17 in truck, I forgot to update the pom.xml files with the correct Daytrader snapshot version. Matt took care of that, earlier this morning (DAYTRADER-34). In addition to these items, I would like to go ahead and apply patches that have been submitted for the following JIRAs... - DAYTRADER-25: DDL updates for indexes and decimal precision and an update to the quote price change logic - DAYTRADER-29: Remove Async 1-Phase mode - DAYTRADER-33: Add JMS close connection to TradeDirect.queueOrder Any objections, concerns, or comments? Thanks... Chris -- "I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may." - Tyler Durden
Re: Removing "Geronimo RTC Workflow Scheme" in JIRA
On Feb 9, 2007, at 9:12 AM, Matt Hogstrom wrote: Since we're not in RTC anymore (and hope to not return) Anyone opposed? I agree it should be removed. --kevan
Re: WS build broken again
On Feb 9, 2007, at 12:20 PM, Matt Hogstrom wrote: On Feb 9, 2007, at 11:52 AM, Dain Sundstrom wrote: I deleted the axis repo, rebuilt and it worked. Does this jar corruption happen for other people, because this is the second time in 2 days? Is there something wrong with the axis build, or geronimo, or am I just lucky? I've had this problem periodically and its not limited to WS. I think there is an issue with Maven but I can't identify how it gets hosed up. Yup. I've had the same problem. Each time, whacking axis2 from my repo has fixed the problem. Something's not right... --kevan
Re: svn commit: r505518 - /geronimo/server/trunk/testsuite/enterprise-testsuite/jpa-tests/jpa-war/src/main/webapp/WEB-INF/web.xml
On Feb 9, 2007, at 5:09 PM, Prasad Kashyap wrote: On 2/9/07, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 2/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: prasad > Date: Fri Feb 9 13:52:23 2007 > New Revision: 505518 > > URL: http://svn.apache.org/viewvc?view=rev&rev=505518 > Log: > * removed persistence-context-type. transaction is implied Did it cause any troubles? I wonder whether it could or not and don't mind it's removed. Well, I got a deployment exception when it was there. Apparently, in the new schema, "Transactional" is not one of the enumeration elements. Also, if the value is not "extended", then transaction is implied. So after I removed it, the deployment went further ahead. It failed later with the OutOfMemoryError, a different problem all together. A general note about OOME's. Sun's JRE had a problem with leaking ClassLoaders. The problem is fixed in the 1.5.0_10 version of the JRE. In versions prior to this, you'll leak a ClassLoader and associated Classes on every undeploy. Eventually, you'll run out of PermGen space. --kevan
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 10, 2007, at 3:55 AM, David Jencks wrote: I think this would be great, especially if we adapted the assembly stuff we have now so you could extract a server that had just what you wanted in it. Then we could supply just one download and let people simplify it themselves if they wanted to. I like it. The size delta would be a minor issue, IMO. I'd be in favor of this as a general approach. A few points: 1. I'd like to maintain two multi-personality distributions -- a minimal and Java EE distribution. 2. IMO, the distributions must have a default configuration. Downloading and starting a server must be simple (i.e. no selection/ configuration is required). 3. I would not want this to be the cause of a significant delay in the 2.0 release --kevan
Re: [mojo-dev] VOTE: Release rat-maven-plugin 0.1
On Feb 9, 2007, at 8:46 PM, Jason Dillon wrote: FYI... I didn't realize they made a maven plugin for this guy. Dunno if it works well or not... having never used RAT before. Kevan, should we try to hook this up? Maybe as an optional profile to be run for release prep fluff? I didn't know about the plugin, either. Yes, I think it would be useful. The last time I tried a recent version of RAT, it wasn't able to run against Geronimo -- it wasn't able to parse an XML file and blew up. The offending file wasn't obvious, and I haven't had time to track it down... So, there's a bit of work... --kevan
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
Ya, I'm aware of this... but I hope that if I can get vmware instances running on 2 of our big gbuild.org hosts (which might give us 14 - 30) more agents, then we might be able to manage running all those tests in a reasonable amount of time. --jason On Feb 10, 2007, at 8:23 AM, Dain Sundstrom wrote: You would still have to test all combinations of the plugins. The TCJ says something to the effect of "all modes" must be tested and certified. -dain On Feb 9, 2007, at 11:09 PM, Jason Dillon wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
Re: GERONIMO-2816 patch
On 2/10/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Are you sure you must scan all classes in the web module for @EJB annotations? I haven't checked the patch, but what Dain said made me think we could overdo the annotation processing. Not all classes might get annotated with @EJB(s). Perhaps there's a way to ask a web container for special classes and check them out whether they use annotation or not? Does Tomcat 6 provide a annotation processing facility? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: GERONIMO-2816 patch
Are you sure you must scan all classes in the web module for @EJB annotations? I don't think it is necessary or what you want to do. I believe that you should only be checking specific classes for the annotation such as all known servlets. This is how we process annotations for EJBs. First we find all EJBs, either listed in the ejb-jar.xml or found by scanning for @Stateless, @Stateful and @MessageDriven. Once we have the list of EJBs we check each class for the presence of the @EJB annotation. In your case, I believe you are scanning for all classes that have the @EJB annotation which will be a much larger number of classes then just the servlets. This over processing of classes can easily lead to naming conflicts. Also, I do not believe that servlet 2.5 has an @Servlet annotation, so I don't think you have to do any general purpose scanning like EJB module must do, which should make web deployment much more efficient. Other than that, the patches look good :) One minor thing to note is we don't use prefixes such as "m_" for variables. Good job, -dain On Feb 10, 2007, at 1:23 AM, Tim McConnell wrote: Hi, I've attached a patch and two new classes to the GERONIMO-2816 JIRA that provides support for the @EJB and @EJBs annotations if anyone would like to review. The intent is to demonstrate a final/permanent technique that can be extended and used throughout Geronimo to support annotations for JSR-88. This patch and new code works for Tomcat and circumvents the annotation processing that is currently in EjbRefBuilder (which did not update the deployment descriptor with the discovered annotations, but only updated the JNDI references). I'd appreciate some feedback before I start propagating this technique to the other module builders to support the remainder of the annotations. I already have another subclass ready to support the @Resource annotations but I didn't want to include it in this example since it doesn't demonstrate anything different than the EJBAnnotationHelper subclass, and I'd like to get some feedback first on the the technique. The general technique, which we've discussed before, is pretty straightforward and is summarized here for reference: 1 -- Discover the annotations: I had hoped that we could centralize the discovery of annotations in the Deployer class prior to the createModule phase of deployment, but as David Blevins pointed out this is almost impossible. So it has to be pushed down into the installModule phase of deployment after the necessary classloader (s) and module context(s) have been established (see the changes for AbstractWebModuleBuilder for an example). 2 -- Process the annotations: This just means to update the existing deployment descriptor (or create a new one) with the discovered annotations. 3 -- Set metadata-complete in the deployment descriptor to prevent repeated processing of annotations (see the EjbRefBuilder changes for an example) 4 -- Update the deployment descriptor in the module so that it can flow through the remainder of the deployment process much as before (for JNDI naming and resolution, and to remain with module in support of the JSR-77 requirements for management). -- Thanks, Tim McConnell
Re: GERONIMO-2816 patch
On Feb 10, 2007, at 1:23 AM, Tim McConnell wrote: Hi, I've attached a patch and two new classes to the GERONIMO-2816 JIRA that provides support for the @EJB and @EJBs annotations if anyone would like to review. The intent is to demonstrate a final/permanent technique that can be extended and used throughout Geronimo to support annotations for JSR-88. This patch and new code works for Tomcat and circumvents the annotation processing that is currently in EjbRefBuilder (which did not update the deployment descriptor with the discovered annotations, but only updated the JNDI references). I'd appreciate some feedback before I start propagating this technique to the other module builders to support the remainder of the annotations. I already have another subclass ready to support the @Resource annotations but I didn't want to include it in this example since it doesn't demonstrate anything different than the EJBAnnotationHelper subclass, and I'd like to get some feedback first on the the technique. The general technique, which we've discussed before, is pretty straightforward and is summarized here for reference: 1 -- Discover the annotations: I had hoped that we could centralize the discovery of annotations in the Deployer class prior to the createModule phase of deployment, but as David Blevins pointed out this is almost impossible. So it has to be pushed down into the installModule phase of deployment after the necessary classloader (s) and module context(s) have been established (see the changes for AbstractWebModuleBuilder for an example). 2 -- Process the annotations: This just means to update the existing deployment descriptor (or create a new one) with the discovered annotations. 3 -- Set metadata-complete in the deployment descriptor to prevent repeated processing of annotations (see the EjbRefBuilder changes for an example) 4 -- Update the deployment descriptor in the module so that it can flow through the remainder of the deployment process much as before (for JNDI naming and resolution, and to remain with module in support of the JSR-77 requirements for management). Hey Tim, very clean and well documented code. I think we'll have to strip out all the documentation to comply with Geronimo's strict no javadoc policy ;) Couple notes. We should be able to get rid of the @EJB for Web processing in the EjbRefBuilder, no? That was there as temporary hack and wasn't meant to last. You definitely have all the right code in the EJBAnnotationHelper for Web/@EJB processsing. Other note is you definitely want to construct the ClassFinder exactly once for a module as each time it's constructed we'll have to reparse all the class definitions in the entire module which is especially nasty for web modules as there tend to be a lot of libraries in WEB-INF/lib and WEB-INF/classes. I mention that as a cautionary note as from the looks of where you're going each AnnotationHelper would create it's own finder in it's constructor. We may want to create the ClassFinder and pass it into the AnnotationHelpers and/or put it in the Module somewhere for all to use if they need it. -David -- Thanks, Tim McConnell
Re: [BUILD] Failed for Revision: 505629
I'm still having issues, the snapshot seems to be picked up but the
build is failing with the following.
[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] Created dir: /Users/sppatel/svk/server/trunk/configs/openejb-
deployer/target/classes/META-INF
[INFO] Copying 2 files to /Users/sppatel/svk/server/trunk/configs/
openejb-deployer/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /Users/sppatel/svk/server/trunk/configs/openejb-
deployer/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration: /Users/sppatel/svk/server/
trunk/configs/openejb-deployer/target/plan/plan.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Unable to create configuration for deployment
Cound not find parent configuration: org.apache.geronimo.configs/
openejb/2.0-20070124.044558-4/car
-sachin
On Feb 10, 2007, at 2:44 PM, Jacek Laskowski wrote:
On 2/10/07, Sachin Patel <[EMAIL PROTECTED]> wrote:
I'm hitting this as well. Could someone publish a openejb snapshot?
Published. Let me know how it works as publish finished with an error
due to (mis)configuration of examples. It shouldn't cause any
troubles, though.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: [BUILD] Failed for Revision: 505629
On 2/10/07, Sachin Patel <[EMAIL PROTECTED]> wrote: I'm hitting this as well. Could someone publish a openejb snapshot? Published. Let me know how it works as publish finished with an error due to (mis)configuration of examples. It shouldn't cause any troubles, though. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
I like the idea but I wonder how practical it will be and if users could get themselves in trouble. For example, what would happen if a set of applications was deployed using tomcat & cxf and then the user attempted to switch to jetty & axis? Granted, with the plugin approach they could create similar problems but since it's a little more difficult to install/uninstall a plugin which might provide some more safeguards. I guess we could always keep track of the previous state and warn the user if they are attempting to change the configuration on a subsequent restart when applications are deployed that have been configured for the prior configuration. Joe Jason Dillon wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
Re: [BUILD] Failed for Revision: 505629
On 2/10/07, Sachin Patel <[EMAIL PROTECTED]> wrote: I'm hitting this as well. Could someone publish a openejb snapshot? Doing mvn deploy now... Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Updated: (SM-830) Replace System.out printing with logger
[ https://issues.apache.org/activemq/browse/SM-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie Goodyear updated SM-830: -- Attachment: smx830_logging.patch Patch Contents: File: org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescriptorMojo Now uses getLog().debug. File: org.apache.servicemix.maven.plugin.jbi.XmlDescriptorHelper Added private log and switched 'system.out.print' to use log.debug. > Replace System.out printing with logger > --- > > Key: SM-830 > URL: https://issues.apache.org/activemq/browse/SM-830 > Project: ServiceMix > Issue Type: Improvement > Components: tooling >Affects Versions: 3.1 > Environment: n/a >Reporter: Anders Hammar >Priority: Trivial > Attachments: smx830_logging.patch > > > In some files, System.out.println is used for (debug) logging. This should be > changed to using the Maven logger (getLog().debug). > These classes are affected: > org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescriptorMojo > (1 occurence) > org.apache.servicemix.maven.plugin.jbi.XmlDescriptorHelper (3 occurences) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [BUILD] Failed for Revision: 505629
I suspect that you will need to build OpenEJB locally, until David wakes up and publishes new jars. -dain On Feb 10, 2007, at 8:24 AM, Sachin Patel wrote: I'm hitting this as well. Could someone publish a openejb snapshot? -sachin On Feb 9, 2007, at 11:07 PM, [EMAIL PROTECTED] wrote: [INFO] - --- [ERROR] BUILD FAILURE [INFO] - --- [INFO] Compilation failure /home/prasad/geronimo/trunk/modules/geronimo-openejb/src/main/java/ org/apache/geronimo/openejb/EjbDeployment.java:[233,29] cannot find symbol symbol : method getServiceEndpointInterface() location: class org.apache.openejb.core.CoreDeploymentInfo
Re: [BUILD] Failed for Revision: 505629
I'm hitting this as well. Could someone publish a openejb snapshot? -sachin On Feb 9, 2007, at 11:07 PM, [EMAIL PROTECTED] wrote: [INFO] -- -- [ERROR] BUILD FAILURE [INFO] -- -- [INFO] Compilation failure /home/prasad/geronimo/trunk/modules/geronimo-openejb/src/main/java/ org/apache/geronimo/openejb/EjbDeployment.java:[233,29] cannot find symbol symbol : method getServiceEndpointInterface() location: class org.apache.openejb.core.CoreDeploymentInfo
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
You would still have to test all combinations of the plugins. The TCJ says something to the effect of "all modes" must be tested and certified. -dain On Feb 9, 2007, at 11:09 PM, Jason Dillon wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
Error when configuring JMS through Geronimo console
Hi All, I'm working on Configuring JMS document for v1.2 of Geronimo. I noticed an error when I try to deploy the JMS Resources or when I try to view its deployment plan. I tried on both Linux and Windows environments. Please find the error below: - 16:01:24,343 ERROR [AbstractHandler] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.create Configuration(JMXDeploymentManager.java:299) at org.apache.geronimo.console.jmsmanager.wizard.AbstractHandler.save(Ab stractHandler.java:471) at org.apache.geronimo.console.jmsmanager.wizard.DeployHandler.actionBef oreView(DeployHandler.java:40) at org.apache.geronimo.console.MultiPagePortlet.processAction (MultiPageP ortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java :163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java :690) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java :153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java :428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde r.java:103) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch (WebApplicati onHandler.java :471) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch (JettyWe bApplicationHandler.java:58) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java :283) at org.mortbay.jetty.servlet.Dispatcher.include (Dispatcher.java :163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke (PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action (PortletInvoke rImpl.java :68) at org.apache.pluto.PortletContainerImpl.processPortletAction (PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java :82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java :617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java :428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde r.java:103) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch (WebApplicati onHandler.java :471) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch (JettyWe bApplicationHandler.java:58) at org.mortbay.jetty.servlet.ServletHandler.handle( ServletHandler.java:5 68) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle (WebApplication Context.java:633) at org.apache.geronimo.jetty.JettyWebAppContext.handle(JettyWebAppContex t.java:329) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.apache.geronimo.jetty.JettyWebAppContext.handle (JettyWebAppContex t.java:313) at org.mortbay.http.HttpServer.service (HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:820) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java :986) at org.mortbay.http.HttpConnection.handle (HttpConnection.java:837) at org.mortbay.http.SocketListener.handleConnection( SocketListener.java: 245) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run (ThreadPool.java:534) Thanks Karthiga
GERONIMO-2816 patch
Hi, I've attached a patch and two new classes to the GERONIMO-2816 JIRA that provides support for the @EJB and @EJBs annotations if anyone would like to review. The intent is to demonstrate a final/permanent technique that can be extended and used throughout Geronimo to support annotations for JSR-88. This patch and new code works for Tomcat and circumvents the annotation processing that is currently in EjbRefBuilder (which did not update the deployment descriptor with the discovered annotations, but only updated the JNDI references). I'd appreciate some feedback before I start propagating this technique to the other module builders to support the remainder of the annotations. I already have another subclass ready to support the @Resource annotations but I didn't want to include it in this example since it doesn't demonstrate anything different than the EJBAnnotationHelper subclass, and I'd like to get some feedback first on the the technique. The general technique, which we've discussed before, is pretty straightforward and is summarized here for reference: 1 -- Discover the annotations: I had hoped that we could centralize the discovery of annotations in the Deployer class prior to the createModule phase of deployment, but as David Blevins pointed out this is almost impossible. So it has to be pushed down into the installModule phase of deployment after the necessary classloader(s) and module context(s) have been established (see the changes for AbstractWebModuleBuilder for an example). 2 -- Process the annotations: This just means to update the existing deployment descriptor (or create a new one) with the discovered annotations. 3 -- Set metadata-complete in the deployment descriptor to prevent repeated processing of annotations (see the EjbRefBuilder changes for an example) 4 -- Update the deployment descriptor in the module so that it can flow through the remainder of the deployment process much as before (for JNDI naming and resolution, and to remain with module in support of the JSR-77 requirements for management). -- Thanks, Tim McConnell
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
I think this would be great, especially if we adapted the assembly stuff we have now so you could extract a server that had just what you wanted in it. Then we could supply just one download and let people simplify it themselves if they wanted to. thanks david jencks On Feb 9, 2007, at 11:09 PM, Jason Dillon wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
[jira] Updated: (GERONIMO-2816) @EJB/@EJBs annotation support
[ https://issues.apache.org/jira/browse/GERONIMO-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMO-2816: Attachment: EJBAnnotationHelper.java AnnotationHelper.java GERONIMO-2816.patch Patch and two new classes ready for review for @EJB and @EJBs annotation support > @EJB/@EJBs annotation support > - > > Key: GERONIMO-2816 > URL: https://issues.apache.org/jira/browse/GERONIMO-2816 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0 >Reporter: Tim McConnell > Assigned To: Tim McConnell > Fix For: 2.0 > > Attachments: AnnotationHelper.java, EJBAnnotationHelper.java, > GERONIMO-2816.patch > > > Code and patches to support the @EJB and @EJBs annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CORBA ported from OpenEJB 2
On Feb 9, 2007, at 10:26 PM, Dain Sundstrom wrote: On Feb 9, 2007, at 2:32 PM, Rick McGuire wrote: Dain Sundstrom wrote: I have ported the OpenEJB 2 CORBA code and updated it to the OpenEJB 3 APIs. The code is contained in three new modules geronimo-corba, geronimo-corba-builder and geronimo-yoko. The CORBA code is highly coupled to Geronimo so I put it in Geronimo. In the future, I would like to split this code into OpenEJB specific code and Geronimo specific code, but that will take a lot of effort that is currently better spent on Jee5. Hopefully, later this year I'll get time to split the code, but CORBA typically has a really low priority. Lastly, the code is ported, but not hooked up. So, it isn't going to work yet for the thousands of you that use CORBA :) For the one person here who does, what does "not hooked up" actually mean? In other words, how an I going to be spending my time in the near future :-) I figured you would be asking me that :) All of the GBeans, interceptors, delegates, adapters, etc have been ported over and I believe make the correct calls to the OpenEJB 3 deployments and containers. The piece that is not hooked up is deployment. You'll need to hook the EjbModuleBuilder and add the TSS link GBeans. You will also need to enable the CSS naming builder. To do that part just implement the ModuleBuilderExtension interface and you can hook into all phases of the EjbModuleBuilder. -David I'm sure there are other things I missed, but that should be the bulk of the work to hook it up. Of course then there is the TCK to contend with :) -dain`
Re: svn commit: r505624 - in /geronimo/server/trunk: ./ assemblies/geronimo-jetty6-jee5/src/main/var/config/ assemblies/geronimo-tomcat6-jee5/src/main/var/config/ configs/axis-deployer/src/plan/ confi
On Feb 9, 2007, at 8:25 PM, Jarek Gawor wrote: David, Did you just disable support for Servlet-based WS? If so, why? No. Are they not working anymore? -David Jarek On 2/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: dblevins Date: Fri Feb 9 19:52:38 2007 New Revision: 505624 URL: http://svn.apache.org/viewvc?view=rev&rev=505624 Log: Ported Axis1 integration Added: geronimo/server/trunk/modules/geronimo-axis-builder/src/main/ java/org/apache/geronimo/axis/builder/AxisModuleBuilderExtension.java geronimo/server/trunk/modules/geronimo-axis/src/main/java/org/ apache/geronimo/axis/server/EjbWebServiceGBean.java geronimo/server/trunk/modules/geronimo-j2ee-builder/src/main/ java/org/apache/geronimo/j2ee/deployment/ModuleBuilderExtension.java Modified: geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/ var/config/config.xml geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/ main/var/config/config.xml geronimo/server/trunk/configs/axis-deployer/src/plan/plan.xml geronimo/server/trunk/configs/openejb-deployer/src/plan/plan.xml geronimo/server/trunk/configs/openejb/pom.xml geronimo/server/trunk/modules/geronimo-axis-builder/pom.xml geronimo/server/trunk/modules/geronimo-axis/pom.xml geronimo/server/trunk/modules/geronimo-axis/src/main/resources/ META-INF/geronimo-dependency.xml geronimo/server/trunk/modules/geronimo-openejb-builder/src/ main/java/org/apache/geronimo/openejb/deployment/ EjbModuleBuilder.java geronimo/server/trunk/modules/geronimo-openejb/src/main/java/ org/apache/geronimo/openejb/EjbDeployment.java geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/ src/main/var/config/config.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/ geronimo-jetty6-jee5/src/main/var/config/config.xml? view=diff&rev=505624&r1=505623&r2=505624 = = --- geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/ var/config/config.xml (original) +++ geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/ var/config/config.xml Fri Feb 9 19:52:38 2007 @@ -142,17 +142,6 @@ PersistenceUnitBuilder - - -CXFBuilder - - -Axis2Builder - - -WebServiceBuilder - - http://java.sun.com/ xml/ns/j2ee,http://java.sun.com/xml/ns/javaee Modified: geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/ src/main/var/config/config.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/ geronimo-tomcat6-jee5/src/main/var/config/config.xml? view=diff&rev=505624&r1=505623&r2=505624 = = --- geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/ main/var/config/config.xml (original) +++ geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/ main/var/config/config.xml Fri Feb 9 19:52:38 2007 @@ -149,17 +149,6 @@ PersistenceUnitBuilder - - -CXFBuilder - - -Axis2Builder - - -WebServiceBuilder - - http://java.sun.com/ xml/ns/j2ee,http://java.sun.com/xml/ns/javaee Modified: geronimo/server/trunk/configs/axis-deployer/src/plan/ plan.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ axis-deployer/src/plan/plan.xml? view=diff&rev=505624&r1=505623&r2=505624
