Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Welcome to the world of breaking the build and release frenzy! ;) Congrats, Rick! -David On Apr 21, 2006, at 11:59 AM, Geir Magnusson Jr wrote: In recognition of his contributions and participation in the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Rick McGuire. Rick has contributed in many places, and is a pleasure to work with, and we look forward to his continued involvement as a committer. Please join us in congratulating Rick. The Apache Geronimo PMC
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Congrats Rick!! -VamsiOn 4/22/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: In recognition of his contributions and participation in the ApacheGeronimo community, the Geronimo PMC is proud to announce thecommittership of Rick McGuire.Rick has contributed in many places, and is a pleasure to work with, and we look forward to his continued involvement as a committer.Please join us in congratulating Rick.The Apache Geronimo PMC
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
hey , Thats a greate News , Congrats Rick for joining AG group as a committer !!! On 4/24/06, ReghuRam Rajakumar Vasanthakumari <[EMAIL PROTECTED]> wrote: Congrats!!! RickReghu On 4/22/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: In recognition of his contributions and participation in the ApacheGeronimo community, the Geronimo PMC is proud to announce the committership of Rick McGuire.Rick has contributed in many places, and is a pleasure to work with, and we look forward to his continued involvement as a committer.Please join us in congratulating Rick. The Apache Geronimo PMC
[jira] Closed: (GERONIMO-1898) Console JVM statistics break b/c can't cast JVM to StatisticsProvider
[ http://issues.apache.org/jira/browse/GERONIMO-1898?page=all ] Dain Sundstrom closed GERONIMO-1898: Resolution: Fixed > Console JVM statistics break b/c can't cast JVM to StatisticsProvider > - > > Key: GERONIMO-1898 > URL: http://issues.apache.org/jira/browse/GERONIMO-1898 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: core, console > Versions: 1.1 > Reporter: Aaron Mulder > Assignee: Dain Sundstrom > Priority: Blocker > Fix For: 1.1 > > Right now the results of navigation methods backed by reference lookups only > implement the interface required by the reference. We need them to implement > their auxilliary interfaces too (e.g. reference type JVM but must also > implement StatisticsProvider). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Directory Update (Jeff?)
Jeff Genender wrote: If the changes are not huge, I can probably do it. Alex, are the updates significant? Since 0.9.2 I'd say RC1 is a significant update. There are package name changes to comply with Directory's TLP domain name which are perhaps the most significant changes. There are changes to a couple dependencies. For the most part the code has been cleaned up and several *severe* bugs have been corrected and tested. RC1 is also an order of magnitude faster. We plan to get another 1.0 release candidate (RC2) out soon perhaps by the end of this week coming week or week there after. But looking at emails out there from Dain and Aaron it sounds to me like the update to G can take place any time after the 1.1 release. Let us know if you have any problems or need a hand while performing an upgrade either to RC1 or RC2 when it comes out. Regards, Alex
Re: SUMMARY OF: Change "configuration" to "module"
I would need to agree with Alan and Matt on this... -1 for 1.1 +1 for 1.2 Alan D. Cabrera wrote: Matt Hogstrom wrote: I'm for the change but as I ponder the ramifications to 1.1 I'm afraid the scope of this modification is too large. The TCK needs to be updated, lots of hard references, etc. I vote that we change this in 1.2 and leave them as configId for now. If we take this on I'm confident that we'll miss Java One. -1 for 1.1 +1 for 1.2 Thoughts? -1 1.1 +1 1.2 Regards, Alan
Re: SUMMARY OF: Change "configuration" to "module"
Matt Hogstrom wrote: I'm for the change but as I ponder the ramifications to 1.1 I'm afraid the scope of this modification is too large. The TCK needs to be updated, lots of hard references, etc. I vote that we change this in 1.2 and leave them as configId for now. If we take this on I'm confident that we'll miss Java One. -1 for 1.1 +1 for 1.2 Thoughts? -1 1.1 +1 1.2 Regards, Alan
Apache Geronimo Principles & Goals
All, Here's a little something I've been assembling to help as we move past certification and look for what's next. I'd like to post this (or something like it) to the web site, ideally for the 1.1 release so it'll be there for people wondering (at a high level) where we're going from here. Thanks, Aaron Apache Geronimo Principles & Goals === Principles === * Be competitive with other application servers * Be flexible to include exactly what a user wants (lightweight, heavyweight, product integration, customized admin tools, etc.). Make it easy to get there from the initial download. * Be the IntelliJ of app servers (it thinks like you do, works like you expect, etc.) -- alternately, be the OS X of app servers (easy to use and even the hard stuff "just works") === Goals === Flexibility --- Geronimo should meet anyone's needs from very lightweight to very heavyweight. Generally, the distribution option should be: 1) Minimal -- kernel and command-line/script administration tools only 2) Web -- web container and web admin tools 3) J2EE -- certified J2EE stack with web admin tools The included tools must make it extremely easy to download and install additional features (e.g. plugins) to add on to the basic distribution. And, of course, anyone is free to create more comprehensive distributions by bundling plugins and distributing the resulting package. It should be possible to get an app running and then have "1-click" options to strip down the server to only what that application requires. It should also be possible to easily replicate a Geronimo installation to another machine (or to another existing Geronimo installation). It should also be possible to export an environment to run a J2EE application client in (ideally, export it as a dynamic Java Web Start configuration so you can just run it on your local PC by clicking a link in the console). Performance & Scalability - Performance must be comparable to other application servers in key areas. Geronimo should support clustering of web and EJB components for scalability and fail-over fault tolerance. Geronimo should work with common hardware load-balancers. Benchmarks should be made available with clear instructions for users to configure and run them on Geronimo as well as on other application servers. There should be clear performance tuning guidelines, and the performance tuning options should be extremely accessible (e.g. provide a dashboard- style page with all the settings to tune a web application in one place along with recommendations for the various settings). Application Portability --- It should be as easy as possible to port applications to Geronimo, meaning: - reduce the need for Geronimo-specific XML configuration files - simplify and minimize required settings in Geronimo-specific XML configuration files (e.g. eliminate nested namespaces, provide optimized file formats for common things like database pools, eliminate target names in references) - Isolate the application classpath from Server internals (Spring, logging) - Make common but non-standard code work (global JNDI lookups, etc.) - Support file layouts, config files, scripts, termininology from other popular application servers (or stay as similar as possible) - Provide conversion tools to import configurations from other app servers Some popular J2EE applications should be ported to Geronimo to confirm that the process is as painless as possible. Administration & Management --- Geronimo should provide command-line, Ant, Maven, and web versions of all key tools. This includes tools to: - get a list of available plugins - download and install plugins - deploy/redeploy applications - start and stop the server - export an application client wrapped in Java Web Start, even including auto-generated SSL keys/certs for mutual authentication. The web console should be at least as function as the BEA WebLogic web console. It should make it easy to both configure the server and gather runtime statistics. It should make it easy to run a second Geronimo instance on the same machine (using different network ports). It should be possible to rearrange the console content to suit the user's needs/style, or at least provide breadcrumb-type access to frequently used functions. It should be possible to set up several Geronimo configurations that share the same core installation files but have their own configuration files, deployments, etc. similar to WebLogic domains (but not like JBoss which copies too many JARs into each configuration). Geronimo should include a Windows Service to run the server. Ideally, it would also have a service like BEA Node Manager to start and stop servers on remote machines. Geronimo should include scripts or command-line tools that make it easy to perform and/or automate common tasks such as deploying a new database
Daytrader added to gbuild
Matt, Just added Daytrader to our continuum install on gbuild. Was going to have you do it, but eh who cares Anyway, all I did was this: 1. Login 2. Click "Add Maven 2.0+ Project" 3. Pasted "http://svn.apache.org/repos/asf/geronimo/daytrader/trunk/ pom.xml" 4. Clicked "Sumbit" And everything was peachy. Your layout is still very m1, so I took the liberty of fixing all your old m1-isms in this branch here: http://svn.apache.org/repos/asf/geronimo/daytrader/branches/m2standard/ If you use that, it'll save you from having to update 12 different svn urls everytime you branch or tag. -David
Re: Directory Update (Jeff?)
On 4/23/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > Are we including ldap in the main distro, or shipping it as a > plugin? If it is the latter, we can ship it late if needed. Great point! We can even post what we've got today as the 0.92 plugin and then post a new plugin version later. (In fact the 0.92 plugin is on the plugin site already, though we'll want to rebuild it against the final 1.1 G code when that comes out.) I guess this means we need to start moving things like directory out of our main tree so they can be versioned separately. Thanks, Aaron > On Apr 23, 2006, at 7:15 PM, Jeff Genender wrote: > > > If the changes are not huge, I can probably do it. Alex, are the > > updates significant? > > > > Matt Hogstrom wrote: > >> Depends. Since we're focusing on getting the 1.1 release out I'm > >> not sure we'll have time. Jeff would have to comment on his > >> availability to test, etc. > >> Alex Karasulu wrote: > >>> You guys have time for the latest RC2 release of Directory? We > >>> could push this release for G to get a bunch of fixes and > >>> performance enhancements in there. > >>> > >>> Alex > >>> > >>> Jeff Genender wrote: > >>> > Yeah, I can take a look. > > Jeff > > Aaron Mulder wrote: > > > All, > > > > While working on the plugins I found that our Directory is out > > of date > > (0.9.2 vs latest 0.9.3 on iBiblio). I also found that if we just > > "take the latest of everything Directory-related" it blows up (in > > particular, mina 0.9.0 doesn't work, but 0.8.2 appears to). > > > > Can someone test a good combination of all the Directory- > > related libs > > and update our etc/project.properties accordingly? > > > > Jeff, I think you did the original Directory integration, I'm > > not sure > > if you want to bite on this. > > > > It's not a huge deal if we ship G 1.1 a point release of Directory > > behind, but it would be nice if we could update. > > > > Thanks, > > Aaron > > > >>> > >>> > >>> > >>> > >
Re: Directory Update (Jeff?)
Are we including ldap in the main distro, or shipping it as a plugin? If it is the latter, we can ship it late if needed. -dain On Apr 23, 2006, at 7:15 PM, Jeff Genender wrote: If the changes are not huge, I can probably do it. Alex, are the updates significant? Matt Hogstrom wrote: Depends. Since we're focusing on getting the 1.1 release out I'm not sure we'll have time. Jeff would have to comment on his availability to test, etc. Alex Karasulu wrote: You guys have time for the latest RC2 release of Directory? We could push this release for G to get a bunch of fixes and performance enhancements in there. Alex Jeff Genender wrote: Yeah, I can take a look. Jeff Aaron Mulder wrote: All, While working on the plugins I found that our Directory is out of date (0.9.2 vs latest 0.9.3 on iBiblio). I also found that if we just "take the latest of everything Directory-related" it blows up (in particular, mina 0.9.0 doesn't work, but 0.8.2 appears to). Can someone test a good combination of all the Directory- related libs and update our etc/project.properties accordingly? Jeff, I think you did the original Directory integration, I'm not sure if you want to bite on this. It's not a huge deal if we ship G 1.1 a point release of Directory behind, but it would be nice if we could update. Thanks, Aaron
[jira] Updated: (GERONIMO-1875) More work to port little-g to 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1875?page=all ] Joe Bohn updated GERONIMO-1875: --- Attachment: 1875_RemoveDeps.patch Dave, As we discussed, here is the patch with the changes that I currently have. I'm still working on several problems. The first one you'll notice is a an error building the config for client-corba: 40266 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment failed due to java.lang.NoClassDefFoundError: org/omg/CSI/IdentityToken I need to find which package contains this class and get it in the path. > More work to port little-g to 1.1 > - > > Key: GERONIMO-1875 > URL: http://issues.apache.org/jira/browse/GERONIMO-1875 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Versions: 1.1 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.1 > Attachments: 1875_RemoveDeps.patch, 1875_axis+builder+clientDeploy.patch, > 1875_axis+builder.patch, 1875_littleg.patch, 1875_openejb-deployer.diff > > This issue will be used to hold more patches for little-g modularization of > geronimo 1.1. Some pieces: > - additional plans for new configs > - turning single valued references to ejb builder, axis builder, client > builder, connector builder etc into something that will work. The problem is > that all these builders can't be in the ancestor tree of j2ee-deployer, or > we'd always be pulling them into the server. Therefore they need to be > collection valued references. We can make a collection wrapper that returns > a single element or null, or objects to the presence of more than one > element, and use this to hold many of these 0..1 valued references. Both > EarConfigBuilder and ClientModuleBuilder need this modification. > - modify existing plans to remove gbeans now in the new plans. Be sure to > update the defaultEnvironments as appropriate. > - modify the assemblies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SUMMARY OF: Change "configuration" to "module"
Aaron Mulder wrote: On 4/23/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Will there be an impact on existing users who have their web/applications using configId? If so will/can we accept both? I would hate to break backwards compatibility on this. Well, we've changed the syntax dramatically between 1.0 and 1.1 (e.g. the configId used to be a single XML attribute and now it's 4 separate elements, the parents and imports are handled differently, etc.). Are you worried about users who have 1.0 plans, or users who have pre-1.1 plans? Yep, I know a couple of companies that are using G in production and are concerned in particular about this. I'm sure we're planning to auto-convert 1.0 plans to the 1.1 syntax whatever it ends up being. Do you think we need to support the older 1.1 syntax if we adopt the newer 1.1 syntax? Probably, and unfortunately yes. However, if we are going to make a clean break, can we bridge like we did with the geronimo-jetty.xml/geronimo-web.xml? i.e. accept the old with a stern warning? We do have a few core early adopters that will be impacted. OLD CURRENT-PRE-1.1 ... ... ... ... ... PROPOSED-PRE-1.1 ... ... ... ... ... Thanks, Aaron Aaron Mulder wrote: I think we can do it in a night. All we need is a sed script -- the syntax isn't changing other than literally replacing all occurances of "configId" with "moduleId" in *.xml files. Thanks, Aaron On 4/23/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I'm for the change but as I ponder the ramifications to 1.1 I'm afraid the scope of this modification is too large. The TCK needs to be updated, lots of hard references, etc. I vote that we change this in 1.2 and leave them as configId for now. If we take this on I'm confident that we'll miss Java One. -1 for 1.1 +1 for 1.2 Thoughts? Matt Aaron Mulder wrote: So everyone seems to be in favor. I'm 100% in favor of making this change in our documentation and presentations and so on. I'm 95% in favor of changing "configId" to "moduleId" in our plans -- just need to find the time to do it and it'll be an extensive change to the current plans in Geronimo and the TCK. Even if we silently upgrade plans using "configId" during deployment I think we want the plans distributed with the server to use the recommended syntax wherever possible. Any volunteers? I'm not necessarily in favor of changing CAR to MAR. That's used so infrequently (and saying "just apply this MAR to your server" sounds so dubious) that I think we can just say "it's a just a CAR; it doesn't stand for anything". Or call them plugins instead. :) And while it might be nice to change the names of some of the server guts dealing with configurations (ConfigurationInfo, ConfigurationData, etc.) I don't feel the urge to do that myself -- if someone else wants to take a swing at it, be my guest. Thanks, Aaron On 4/23/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: +1 Aaron Mulder wrote: All, How would you feel about referring to configurations (e.g. a group of GBeans with own ID and classloader) as a "module" instead? It seems like "configuration" can be confusing, as it more traditionally refers to a larger scope like an entire installation. For example, if you say you have two different WebLogic configurations or two different Apache (HTTP) configurations, you're saying either you have two installations, or you have two totally separate product configurations available for the same product installation. You're not saying you have an app and a database pool within one runtime, but that's what "two different configurations" presently would mean in relation to Geronimo. It seems like it would be clearer to say that a Geronimo installation loads many modules, and each module includes many components (GBeans). I'm not proposing that we go changing class names and stuff, but I'm proposing that we make a concerted effort in our documentation and presentations to present the name of the "unit with an ID and classloader holding many components" as a "module". What do you think? Thanks, Aaron
Re: Stomp and Message Types
How about we make that an optional extensible header that defaults to "binary" if not set. All stomp implementations should at least support text and binary. Something like: message-type:text And activemq would also support some other types such as: activemq-map, activemq-stream, and activemq-object where ActiveMQ would define the expected body encoding for those types. Regards, Hiram On 4/23/06, Brian McCallister <[EMAIL PROTECTED]> wrote: > I want to correct a design wart in ActiveMQ's Stomp implementation -- > originally Stomp only supported text and I implemented messages as > text messages. Later I caved and changed stomp to handle arbitrary > byte bodies, and used byte messages to handle this. > > The difference, according to ActiveMQ, is whether the content-length > header is specified (if it is not, it goes into text mode and scans > for a null byte). > > I'd like to change activemq to *always* use byte messages. > > -Brian > -- Regards, Hiram
Re: Directory Update (Jeff?)
If the changes are not huge, I can probably do it. Alex, are the updates significant? Matt Hogstrom wrote: Depends. Since we're focusing on getting the 1.1 release out I'm not sure we'll have time. Jeff would have to comment on his availability to test, etc. Alex Karasulu wrote: You guys have time for the latest RC2 release of Directory? We could push this release for G to get a bunch of fixes and performance enhancements in there. Alex Jeff Genender wrote: Yeah, I can take a look. Jeff Aaron Mulder wrote: All, While working on the plugins I found that our Directory is out of date (0.9.2 vs latest 0.9.3 on iBiblio). I also found that if we just "take the latest of everything Directory-related" it blows up (in particular, mina 0.9.0 doesn't work, but 0.8.2 appears to). Can someone test a good combination of all the Directory-related libs and update our etc/project.properties accordingly? Jeff, I think you did the original Directory integration, I'm not sure if you want to bite on this. It's not a huge deal if we ship G 1.1 a point release of Directory behind, but it would be nice if we could update. Thanks, Aaron
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Congrats!!! Rick ReghuOn 4/22/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: In recognition of his contributions and participation in the ApacheGeronimo community, the Geronimo PMC is proud to announce thecommittership of Rick McGuire.Rick has contributed in many places, and is a pleasure to work with, and we look forward to his continued involvement as a committer.Please join us in congratulating Rick.The Apache Geronimo PMC
Re: Directory Update (Jeff?)
Depends. Since we're focusing on getting the 1.1 release out I'm not sure we'll have time. Jeff would have to comment on his availability to test, etc. Alex Karasulu wrote: You guys have time for the latest RC2 release of Directory? We could push this release for G to get a bunch of fixes and performance enhancements in there. Alex Jeff Genender wrote: Yeah, I can take a look. Jeff Aaron Mulder wrote: All, While working on the plugins I found that our Directory is out of date (0.9.2 vs latest 0.9.3 on iBiblio). I also found that if we just "take the latest of everything Directory-related" it blows up (in particular, mina 0.9.0 doesn't work, but 0.8.2 appears to). Can someone test a good combination of all the Directory-related libs and update our etc/project.properties accordingly? Jeff, I think you did the original Directory integration, I'm not sure if you want to bite on this. It's not a huge deal if we ship G 1.1 a point release of Directory behind, but it would be nice if we could update. Thanks, Aaron
Re: Directory Update (Jeff?)
You guys have time for the latest RC2 release of Directory? We could push this release for G to get a bunch of fixes and performance enhancements in there. Alex Jeff Genender wrote: Yeah, I can take a look. Jeff Aaron Mulder wrote: All, While working on the plugins I found that our Directory is out of date (0.9.2 vs latest 0.9.3 on iBiblio). I also found that if we just "take the latest of everything Directory-related" it blows up (in particular, mina 0.9.0 doesn't work, but 0.8.2 appears to). Can someone test a good combination of all the Directory-related libs and update our etc/project.properties accordingly? Jeff, I think you did the original Directory integration, I'm not sure if you want to bite on this. It's not a huge deal if we ship G 1.1 a point release of Directory behind, but it would be nice if we could update. Thanks, Aaron
Re: SUMMARY OF: Change "configuration" to "module"
On 4/23/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > Will there be an impact on existing users who have their > web/applications using configId? If so will/can we accept both? I > would hate to break backwards compatibility on this. Well, we've changed the syntax dramatically between 1.0 and 1.1 (e.g. the configId used to be a single XML attribute and now it's 4 separate elements, the parents and imports are handled differently, etc.). Are you worried about users who have 1.0 plans, or users who have pre-1.1 plans? I'm sure we're planning to auto-convert 1.0 plans to the 1.1 syntax whatever it ends up being. Do you think we need to support the older 1.1 syntax if we adopt the newer 1.1 syntax? OLD CURRENT-PRE-1.1 ... ... ... ... ... PROPOSED-PRE-1.1 ... ... ... ... ... Thanks, Aaron > Aaron Mulder wrote: > > I think we can do it in a night. All we need is a sed script -- the > > syntax isn't changing other than literally replacing all occurances of > > "configId" with "moduleId" in *.xml files. > > > > Thanks, > > Aaron > > > > On 4/23/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > >> I'm for the change but as I ponder the ramifications to 1.1 I'm afraid the > >> scope of this > >> modification is too large. The TCK needs to be updated, lots of hard > >> references, etc. > >> > >> I vote that we change this in 1.2 and leave them as configId for now. If > >> we take this on I'm > >> confident that we'll miss Java One. > >> > >> -1 for 1.1 > >> +1 for 1.2 > >> > >> Thoughts? > >> > >> Matt > >> > >> Aaron Mulder wrote: > >>> So everyone seems to be in favor. > >>> > >>> I'm 100% in favor of making this change in our documentation and > >>> presentations and so on. > >>> > >>> I'm 95% in favor of changing "configId" to "moduleId" in our plans -- > >>> just need to find the time to do it and it'll be an extensive change > >>> to the current plans in Geronimo and the TCK. Even if we silently > >>> upgrade plans using "configId" during deployment I think we want the > >>> plans distributed with the server to use the recommended syntax > >>> wherever possible. Any volunteers? > >>> > >>> I'm not necessarily in favor of changing CAR to MAR. That's used so > >>> infrequently (and saying "just apply this MAR to your server" sounds > >>> so dubious) that I think we can just say "it's a just a CAR; it > >>> doesn't stand for anything". Or call them plugins instead. :) > >>> > >>> And while it might be nice to change the names of some of the server > >>> guts dealing with configurations (ConfigurationInfo, > >>> ConfigurationData, etc.) I don't feel the urge to do that myself -- if > >>> someone else wants to take a swing at it, be my guest. > >>> > >>> Thanks, > >>> Aaron > >>> > >>> On 4/23/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > >>> > +1 > > Aaron Mulder wrote: > > > All, > > > > How would you feel about referring to configurations (e.g. a group of > > GBeans with own ID and classloader) as a "module" instead? It seems > > like "configuration" can be confusing, as it more traditionally refers > > to a larger scope like an entire installation. For example, if you > > say you have two different WebLogic configurations or two different > > Apache (HTTP) configurations, you're saying either you have two > > installations, or you have two totally separate product configurations > > available for the same product installation. You're not saying you > > have an app and a database pool within one runtime, but that's what > > "two different configurations" presently would mean in relation to > > Geronimo. > > > > It seems like it would be clearer to say that a Geronimo installation > > loads many modules, and each module includes many components (GBeans). > > > > I'm not proposing that we go changing class names and stuff, but I'm > > proposing that we make a concerted effort in our documentation and > > presentations to present the name of the "unit with an ID and > > classloader holding many components" as a "module". > > > > What do you think? > > > > Thanks, > >Aaron > > > > > > > >>> > >>> >
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Congrats Rick ! Cheers Prasad On 4/23/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > I'll double that...welcome aboard Rick! > > Kevan Miller wrote: > > Congratulations Rick! > > --kevan > > On Apr 21, 2006, at 2:59 PM, Geir Magnusson Jr wrote: > > > >> In recognition of his contributions and participation in the Apache > >> Geronimo community, the Geronimo PMC is proud to announce the > >> committership of Rick McGuire. > >> > >> Rick has contributed in many places, and is a pleasure to work with, > >> and we look forward to his continued involvement as a committer. > >> > >> Please join us in congratulating Rick. > >> > >> The Apache Geronimo PMC >
Re: SUMMARY OF: Change "configuration" to "module"
Will there be an impact on existing users who have their web/applications using configId? If so will/can we accept both? I would hate to break backwards compatibility on this. Jeff Aaron Mulder wrote: I think we can do it in a night. All we need is a sed script -- the syntax isn't changing other than literally replacing all occurances of "configId" with "moduleId" in *.xml files. Thanks, Aaron On 4/23/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I'm for the change but as I ponder the ramifications to 1.1 I'm afraid the scope of this modification is too large. The TCK needs to be updated, lots of hard references, etc. I vote that we change this in 1.2 and leave them as configId for now. If we take this on I'm confident that we'll miss Java One. -1 for 1.1 +1 for 1.2 Thoughts? Matt Aaron Mulder wrote: So everyone seems to be in favor. I'm 100% in favor of making this change in our documentation and presentations and so on. I'm 95% in favor of changing "configId" to "moduleId" in our plans -- just need to find the time to do it and it'll be an extensive change to the current plans in Geronimo and the TCK. Even if we silently upgrade plans using "configId" during deployment I think we want the plans distributed with the server to use the recommended syntax wherever possible. Any volunteers? I'm not necessarily in favor of changing CAR to MAR. That's used so infrequently (and saying "just apply this MAR to your server" sounds so dubious) that I think we can just say "it's a just a CAR; it doesn't stand for anything". Or call them plugins instead. :) And while it might be nice to change the names of some of the server guts dealing with configurations (ConfigurationInfo, ConfigurationData, etc.) I don't feel the urge to do that myself -- if someone else wants to take a swing at it, be my guest. Thanks, Aaron On 4/23/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: +1 Aaron Mulder wrote: All, How would you feel about referring to configurations (e.g. a group of GBeans with own ID and classloader) as a "module" instead? It seems like "configuration" can be confusing, as it more traditionally refers to a larger scope like an entire installation. For example, if you say you have two different WebLogic configurations or two different Apache (HTTP) configurations, you're saying either you have two installations, or you have two totally separate product configurations available for the same product installation. You're not saying you have an app and a database pool within one runtime, but that's what "two different configurations" presently would mean in relation to Geronimo. It seems like it would be clearer to say that a Geronimo installation loads many modules, and each module includes many components (GBeans). I'm not proposing that we go changing class names and stuff, but I'm proposing that we make a concerted effort in our documentation and presentations to present the name of the "unit with an ID and classloader holding many components" as a "module". What do you think? Thanks, Aaron
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
I'll double that...welcome aboard Rick! Kevan Miller wrote: Congratulations Rick! --kevan On Apr 21, 2006, at 2:59 PM, Geir Magnusson Jr wrote: In recognition of his contributions and participation in the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Rick McGuire. Rick has contributed in many places, and is a pleasure to work with, and we look forward to his continued involvement as a committer. Please join us in congratulating Rick. The Apache Geronimo PMC
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Congratulations Rick! --kevan On Apr 21, 2006, at 2:59 PM, Geir Magnusson Jr wrote: In recognition of his contributions and participation in the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Rick McGuire. Rick has contributed in many places, and is a pleasure to work with, and we look forward to his continued involvement as a committer. Please join us in congratulating Rick. The Apache Geronimo PMC
Re: SUMMARY OF: Change "configuration" to "module"
I think we can do it in a night. All we need is a sed script -- the syntax isn't changing other than literally replacing all occurances of "configId" with "moduleId" in *.xml files. Thanks, Aaron On 4/23/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > I'm for the change but as I ponder the ramifications to 1.1 I'm afraid the > scope of this > modification is too large. The TCK needs to be updated, lots of hard > references, etc. > > I vote that we change this in 1.2 and leave them as configId for now. If we > take this on I'm > confident that we'll miss Java One. > > -1 for 1.1 > +1 for 1.2 > > Thoughts? > > Matt > > Aaron Mulder wrote: > > So everyone seems to be in favor. > > > > I'm 100% in favor of making this change in our documentation and > > presentations and so on. > > > > I'm 95% in favor of changing "configId" to "moduleId" in our plans -- > > just need to find the time to do it and it'll be an extensive change > > to the current plans in Geronimo and the TCK. Even if we silently > > upgrade plans using "configId" during deployment I think we want the > > plans distributed with the server to use the recommended syntax > > wherever possible. Any volunteers? > > > > I'm not necessarily in favor of changing CAR to MAR. That's used so > > infrequently (and saying "just apply this MAR to your server" sounds > > so dubious) that I think we can just say "it's a just a CAR; it > > doesn't stand for anything". Or call them plugins instead. :) > > > > And while it might be nice to change the names of some of the server > > guts dealing with configurations (ConfigurationInfo, > > ConfigurationData, etc.) I don't feel the urge to do that myself -- if > > someone else wants to take a swing at it, be my guest. > > > > Thanks, > > Aaron > > > > On 4/23/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > > > >>+1 > >> > >>Aaron Mulder wrote: > >> > >>>All, > >>> > >>>How would you feel about referring to configurations (e.g. a group of > >>>GBeans with own ID and classloader) as a "module" instead? It seems > >>>like "configuration" can be confusing, as it more traditionally refers > >>>to a larger scope like an entire installation. For example, if you > >>>say you have two different WebLogic configurations or two different > >>>Apache (HTTP) configurations, you're saying either you have two > >>>installations, or you have two totally separate product configurations > >>>available for the same product installation. You're not saying you > >>>have an app and a database pool within one runtime, but that's what > >>>"two different configurations" presently would mean in relation to > >>>Geronimo. > >>> > >>>It seems like it would be clearer to say that a Geronimo installation > >>>loads many modules, and each module includes many components (GBeans). > >>> > >>>I'm not proposing that we go changing class names and stuff, but I'm > >>>proposing that we make a concerted effort in our documentation and > >>>presentations to present the name of the "unit with an ID and > >>>classloader holding many components" as a "module". > >>> > >>>What do you think? > >>> > >>>Thanks, > >>>Aaron > >>> > >>> > >>> > >> > > > > > > >
Re: SUMMARY OF: Change "configuration" to "module"
I'm for the change but as I ponder the ramifications to 1.1 I'm afraid the scope of this modification is too large. The TCK needs to be updated, lots of hard references, etc. I vote that we change this in 1.2 and leave them as configId for now. If we take this on I'm confident that we'll miss Java One. -1 for 1.1 +1 for 1.2 Thoughts? Matt Aaron Mulder wrote: So everyone seems to be in favor. I'm 100% in favor of making this change in our documentation and presentations and so on. I'm 95% in favor of changing "configId" to "moduleId" in our plans -- just need to find the time to do it and it'll be an extensive change to the current plans in Geronimo and the TCK. Even if we silently upgrade plans using "configId" during deployment I think we want the plans distributed with the server to use the recommended syntax wherever possible. Any volunteers? I'm not necessarily in favor of changing CAR to MAR. That's used so infrequently (and saying "just apply this MAR to your server" sounds so dubious) that I think we can just say "it's a just a CAR; it doesn't stand for anything". Or call them plugins instead. :) And while it might be nice to change the names of some of the server guts dealing with configurations (ConfigurationInfo, ConfigurationData, etc.) I don't feel the urge to do that myself -- if someone else wants to take a swing at it, be my guest. Thanks, Aaron On 4/23/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: +1 Aaron Mulder wrote: All, How would you feel about referring to configurations (e.g. a group of GBeans with own ID and classloader) as a "module" instead? It seems like "configuration" can be confusing, as it more traditionally refers to a larger scope like an entire installation. For example, if you say you have two different WebLogic configurations or two different Apache (HTTP) configurations, you're saying either you have two installations, or you have two totally separate product configurations available for the same product installation. You're not saying you have an app and a database pool within one runtime, but that's what "two different configurations" presently would mean in relation to Geronimo. It seems like it would be clearer to say that a Geronimo installation loads many modules, and each module includes many components (GBeans). I'm not proposing that we go changing class names and stuff, but I'm proposing that we make a concerted effort in our documentation and presentations to present the name of the "unit with an ID and classloader holding many components" as a "module". What do you think? Thanks, Aaron
Re: SUMMARY OF: Change "configuration" to "module"
Comments inline.. --- Aaron Mulder <[EMAIL PROTECTED]> wrote: > So everyone seems to be in favor. > > I'm 100% in favor of making this change in our documentation and > presentations and so on. > > I'm 95% in favor of changing "configId" to "moduleId" in our plans -- > just need to find the time to do it and it'll be an extensive change > to the current plans in Geronimo and the TCK. Even if we silently > upgrade plans using "configId" during deployment I think we want the > plans distributed with the server to use the recommended syntax > wherever possible. Any volunteers? Count me in. I can do Geronimo. If you have a list of what all is affected (other than configs/**/plan.xml), I can start from there. > > I'm not necessarily in favor of changing CAR to MAR. That's used so > infrequently (and saying "just apply this MAR to your server" sounds > so dubious) I did not like the sound of 'MAR' either, just mentioned it to start the conversation ;-) Thanks Anita that I think we can just say "it's a just a CAR; it > doesn't stand for anything". Or call them plugins instead. :) > > And while it might be nice to change the names of some of the server > guts dealing with configurations (ConfigurationInfo, > ConfigurationData, etc.) I don't feel the urge to do that myself -- > if > someone else wants to take a swing at it, be my guest. > > Thanks, > Aaron > > On 4/23/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > > +1 > > > > Aaron Mulder wrote: > > > All, > > > > > > How would you feel about referring to configurations (e.g. a > group of > > > GBeans with own ID and classloader) as a "module" instead? It > seems > > > like "configuration" can be confusing, as it more traditionally > refers > > > to a larger scope like an entire installation. For example, if > you > > > say you have two different WebLogic configurations or two > different > > > Apache (HTTP) configurations, you're saying either you have two > > > installations, or you have two totally separate product > configurations > > > available for the same product installation. You're not saying > you > > > have an app and a database pool within one runtime, but that's > what > > > "two different configurations" presently would mean in relation > to > > > Geronimo. > > > > > > It seems like it would be clearer to say that a Geronimo > installation > > > loads many modules, and each module includes many components > (GBeans). > > > > > > I'm not proposing that we go changing class names and stuff, but > I'm > > > proposing that we make a concerted effort in our documentation > and > > > presentations to present the name of the "unit with an ID and > > > classloader holding many components" as a "module". > > > > > > What do you think? > > > > > > Thanks, > > > Aaron > > > > > > > > > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: build failure
It means Maven was unable to download one of the dependency JARs. You can try manually downloading that one and placing it into your local Maven repository, or just run the build (or that one module's build) again and hope the download works the second time. Thanks, Aaron On 4/23/06, argyn <[EMAIL PROTECTED]> wrote: > i built with "maven new" and got this: > = > ... > > Attempting to download axis-1.4-SNAPSHOT.jar. > Error retrieving artifact from > [http://cvs.apache.org/repository/axis/jars/axis-1.4-SNAPSHOT.jar]: j > ava.net.ConnectException: Connection timed out: connect > Artifact /axis/jars/axis-1.4-SNAPSHOT.jar doesn't exists in remote > repository, but it exists locally > > BUILD FAILED > File.. L:\work\geronimo\geronimo\maven.xml > Element... maven:reactor > Line.. 222 > Column 148 > The build cannot continue because of the following unsatisfied dependency: > > geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar > > Total time: 43 minutes 5 seconds > Finished at: Sun Apr 23 17:22:54 EDT 2006 > = > > what does it mean? > > argyn > >
[jira] Resolved: (GERONIMO-1895) Issues with geronimo specs
[ http://issues.apache.org/jira/browse/GERONIMO-1895?page=all ] Rick McGuire resolved GERONIMO-1895: Regression: [Regression] Resolution: Fixed Committed revision 396321. > Issues with geronimo specs > -- > > Key: GERONIMO-1895 > URL: http://issues.apache.org/jira/browse/GERONIMO-1895 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: specs > Versions: 1.1 > Reporter: Kevan Miller > Assignee: Rick McGuire > Priority: Blocker > Fix For: 1.1 > > The following public/protected "extensions" have been added to the > javax.mail.internet.* spec. You can't do that. They must be removed prior to > 1.1 ship. > javax.mail.internet.MimeBodyPart.MIME_DECODEFILENAME > javax.mail.internet.MimeBodyPart.MIME_SETDEFAULTTEXTCHARSET > javax.mail.internet.MimeUtility.getDefaultMIMECharset() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
build failure
i built with "maven new" and got this: = ... Attempting to download axis-1.4-SNAPSHOT.jar. Error retrieving artifact from [http://cvs.apache.org/repository/axis/jars/axis-1.4-SNAPSHOT.jar]: j ava.net.ConnectException: Connection timed out: connect Artifact /axis/jars/axis-1.4-SNAPSHOT.jar doesn't exists in remote repository, but it exists locally BUILD FAILED File.. L:\work\geronimo\geronimo\maven.xml Element... maven:reactor Line.. 222 Column 148 The build cannot continue because of the following unsatisfied dependency: geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar Total time: 43 minutes 5 seconds Finished at: Sun Apr 23 17:22:54 EDT 2006 = what does it mean? argyn
[jira] Assigned: (GERONIMO-1895) Issues with geronimo specs
[ http://issues.apache.org/jira/browse/GERONIMO-1895?page=all ] Rick McGuire reassigned GERONIMO-1895: -- Assign To: Rick McGuire > Issues with geronimo specs > -- > > Key: GERONIMO-1895 > URL: http://issues.apache.org/jira/browse/GERONIMO-1895 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: specs > Versions: 1.1 > Reporter: Kevan Miller > Assignee: Rick McGuire > Priority: Blocker > Fix For: 1.1 > > The following public/protected "extensions" have been added to the > javax.mail.internet.* spec. You can't do that. They must be removed prior to > 1.1 ship. > javax.mail.internet.MimeBodyPart.MIME_DECODEFILENAME > javax.mail.internet.MimeBodyPart.MIME_SETDEFAULTTEXTCHARSET > javax.mail.internet.MimeUtility.getDefaultMIMECharset() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1900) Sample app links on welcome app are broken by default
[ http://issues.apache.org/jira/browse/GERONIMO-1900?page=all ] Aaron Mulder updated GERONIMO-1900: --- Priority: Blocker (was: Major) > Sample app links on welcome app are broken by default > - > > Key: GERONIMO-1900 > URL: http://issues.apache.org/jira/browse/GERONIMO-1900 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: usability, sample apps > Versions: 1.1 > Reporter: Aaron Mulder > Priority: Blocker > Fix For: 1.1 > > It would be nice to take users to a page that would prompt them to install > the sample if they click a link to it and it's not present. However, > automating this would require us to be able to construct a link into a > portlet, which does not seem easy. > For now, the welcome app can include pages at the locations where the sample > apps will be bound, with text to the effect of: > This sample has not yet been installed. To install it, visit the > (URL)console(/URL) and select the Plugins page, click the Search for Plugins > button, and select the (NAME HERE) sample to install. Then visit this same > URL again to view the (NAME HERE) example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1900) Sample app links on welcome app are broken by default
Sample app links on welcome app are broken by default - Key: GERONIMO-1900 URL: http://issues.apache.org/jira/browse/GERONIMO-1900 Project: Geronimo Type: Bug Security: public (Regular issues) Components: usability, sample apps Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1 It would be nice to take users to a page that would prompt them to install the sample if they click a link to it and it's not present. However, automating this would require us to be able to construct a link into a portlet, which does not seem easy. For now, the welcome app can include pages at the locations where the sample apps will be bound, with text to the effect of: This sample has not yet been installed. To install it, visit the (URL)console(/URL) and select the Plugins page, click the Search for Plugins button, and select the (NAME HERE) sample to install. Then visit this same URL again to view the (NAME HERE) example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1884) Samples not installed properly in G1.1 - several issues
[ http://issues.apache.org/jira/browse/GERONIMO-1884?page=all ] Aaron Mulder resolved GERONIMO-1884: Fix Version: 1.1 Resolution: Fixed Plugins on the plugin site have been updated; please try again. Creating new issue for the welcome app links. > Samples not installed properly in G1.1 - several issues > --- > > Key: GERONIMO-1884 > URL: http://issues.apache.org/jira/browse/GERONIMO-1884 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: sample apps > Versions: 1.1 > Reporter: Dave Colasurdo > Assignee: Aaron Mulder > Priority: Critical > Fix For: 1.1 > > IT appears that the Geronimo samples have recently been removed from the > default distributions and replaced with the ability to download them through > the admin console. There are several issues that need to be addressed: > 1) The Sample links on the Geronimo welcome page are dead.. This needs to be > updated with instructions on how to download, start and access the samples.. > 2) Assuming that the admin console "plugins" is the correct spot to download > the samples.. > 2a) The initial panel presented to the user is a bit confusing and is > missing the ldap-demo.. > 2b) After downloading the jsp or servlet examples.. The user is presented > with a "start examples" box.. Selecting this does not work and results in an > exception (attached below) > 2c) "start examples" box does not return any status > 2d) Manually starting the example via the command line also does not work. > and results in an exception... > Exception for 2b > Geronimo Application Server started > > # Installed configuration > # id = geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car > # location = > /home/davecola/geronimo-1.1-041906/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/repository/geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/jsp-examples-tomcat-1.1-SNAPSHOT.car > > 14:12:04,651 ERROR [GBeanInstanceState] Error while starting; GBean is now in > the FAILED state: > abstractName="geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car?configurationName=geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car" > java.lang.ClassCastException > at > org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:380) > at > org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322) > at > org.apache.geronimo.kernel.config.Configuration.(Configuration.java:267) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:274) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:932) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:525) > at > org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:376) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:143) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:267) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:235) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:210) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) > at > org.apache
[jira] Resolved: (GERONIMO-1882) Deploy from web console fails with NoSuchOperationException
[ http://issues.apache.org/jira/browse/GERONIMO-1882?page=all ] Aaron Mulder resolved GERONIMO-1882: Resolution: Fixed > Deploy from web console fails with NoSuchOperationException > --- > > Key: GERONIMO-1882 > URL: http://issues.apache.org/jira/browse/GERONIMO-1882 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Environment: windows xp > Reporter: Joe Bohn > Assignee: Aaron Mulder > Priority: Blocker > Fix For: 1.1 > > Following exception is thrown when attempting to deploy from the web console > portlet: > 09:01:07,467 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error > while dispatching portlet. > javax.portlet.PortletException > at > org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:139) > 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:615) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > 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(JettyServletHolder.java:97) > 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(WebApplicationHandler.java:471) > 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(PortletInvokerImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) > at > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(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:615) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) > at > org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97) > 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(WebApplicationHandler.java:471) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) > at org.mortbay.http.HttpServer.service(HttpServer.java:909) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) > Caused by: org.apache.geronimo.kernel.NoSuchOperationException: Unknown > operation deploy(java.io.File, java.io.File) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:836) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:244) > at > org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:112) > ... 38 more > Nested Exception is > org.apache.geronimo.kernel.NoSuchOperationException: Unknown operation > deploy(java.io.File, java.io.File) >
[jira] Resolved: (GERONIMO-1741) Console should provide option to "redeploy" applications
[ http://issues.apache.org/jira/browse/GERONIMO-1741?page=all ] Aaron Mulder resolved GERONIMO-1741: Fix Version: 1.1 (was: 1.2) Resolution: Fixed Assign To: Aaron Mulder Now there's a checkbox for redeploy > Console should provide option to "redeploy" applications > > > Key: GERONIMO-1741 > URL: http://issues.apache.org/jira/browse/GERONIMO-1741 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: console > Versions: 1.0, 1.1, 1.2 > Reporter: Vamsavardhana Reddy > Assignee: Aaron Mulder > Priority: Minor > Fix For: 1.1 > > Applications can be "deployed" through Admin Console. Admin Console does not > provide option to "redeploy" applications. Upon attempting to deploy an > application, if there is a module with the same name, a message "Module ... > already exists in the server. Try to undeploy it first or use the redeploy > command." is displayed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
SUMMARY OF: Change "configuration" to "module"
So everyone seems to be in favor. I'm 100% in favor of making this change in our documentation and presentations and so on. I'm 95% in favor of changing "configId" to "moduleId" in our plans -- just need to find the time to do it and it'll be an extensive change to the current plans in Geronimo and the TCK. Even if we silently upgrade plans using "configId" during deployment I think we want the plans distributed with the server to use the recommended syntax wherever possible. Any volunteers? I'm not necessarily in favor of changing CAR to MAR. That's used so infrequently (and saying "just apply this MAR to your server" sounds so dubious) that I think we can just say "it's a just a CAR; it doesn't stand for anything". Or call them plugins instead. :) And while it might be nice to change the names of some of the server guts dealing with configurations (ConfigurationInfo, ConfigurationData, etc.) I don't feel the urge to do that myself -- if someone else wants to take a swing at it, be my guest. Thanks, Aaron On 4/23/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > +1 > > Aaron Mulder wrote: > > All, > > > > How would you feel about referring to configurations (e.g. a group of > > GBeans with own ID and classloader) as a "module" instead? It seems > > like "configuration" can be confusing, as it more traditionally refers > > to a larger scope like an entire installation. For example, if you > > say you have two different WebLogic configurations or two different > > Apache (HTTP) configurations, you're saying either you have two > > installations, or you have two totally separate product configurations > > available for the same product installation. You're not saying you > > have an app and a database pool within one runtime, but that's what > > "two different configurations" presently would mean in relation to > > Geronimo. > > > > It seems like it would be clearer to say that a Geronimo installation > > loads many modules, and each module includes many components (GBeans). > > > > I'm not proposing that we go changing class names and stuff, but I'm > > proposing that we make a concerted effort in our documentation and > > presentations to present the name of the "unit with an ID and > > classloader holding many components" as a "module". > > > > What do you think? > > > > Thanks, > > Aaron > > > > > > >
[jira] Created: (GERONIMO-1899) Build includes J2EE 1.1-SNAPSHOT spec
Build includes J2EE 1.1-SNAPSHOT spec - Key: GERONIMO-1899 URL: http://issues.apache.org/jira/browse/GERONIMO-1899 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem, console, core Versions: 1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1 The current 1.1 build includes several individual J2EE specs at the 1.0 release level, then the spec uberJAR at the 1.1-SNAPSHOT release level. I don't think we want to be using the spec uberJAR at all, but if we do, we shouldn't be using a SNAPSHOT of it for the final 1.1 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: building.txt steps
I guess that's a bit out of date. You should run "maven new" (or "maven -o new" if you have all the dependencies downloaded already). Thanks, Aaron On 4/23/06, argyn <[EMAIL PROTECTED]> wrote: > in the building.txt doc, it says that "maven" command would build > everything. then there's a list of 4 steps. > > if simply build with "maven", do i really need to follow the additional > 4 steps? > > the reason i'm asking is that the codument says that to run the server > i've to > = > $> cd assemblies/j2ee-tomcat-server/target/geronimo-1.2-SNAPSHOT > > and finally execute the following command: > > $> java -jar bin/server.jar > = > > but i dont have the "target" directory after executing "maven" command. > i'm a bit confused, sorry > > argyn > >
building.txt steps
in the building.txt doc, it says that "maven" command would build everything. then there's a list of 4 steps. if simply build with "maven", do i really need to follow the additional 4 steps? the reason i'm asking is that the codument says that to run the server i've to = $> cd assemblies/j2ee-tomcat-server/target/geronimo-1.2-SNAPSHOT and finally execute the following command: $> java -jar bin/server.jar = but i dont have the "target" directory after executing "maven" command. i'm a bit confused, sorry argyn
Re: how to get the latest stable build?
Jeff Genender wrote: All depends on the ibiblio speed when doing an online build. If you have all of the jars already downloaded and have done a recent online build, you can convert to an offline build. My offline build on my Powerbook G4 1.67Ghz 2G mem takes about 15-20 minutes. You do an offline with the "-o" parameter... maven -o new argyn wrote: Jeff Genender wrote: m2 is not ready yet. Do a: maven m:co then a maven new how much time it takes to build clean on your machines? i was able to build yesterday. today it's been more than 2 hours and still in progress. thanks, argyn thank you for help. i'll probably wait until it builds with "maven" command, then try "-o" option in future. thanks, argyn
Re: how to get the latest stable build?
All depends on the ibiblio speed when doing an online build. If you have all of the jars already downloaded and have done a recent online build, you can convert to an offline build. My offline build on my Powerbook G4 1.67Ghz 2G mem takes about 15-20 minutes. You do an offline with the "-o" parameter... maven -o new argyn wrote: Jeff Genender wrote: m2 is not ready yet. Do a: maven m:co then a maven new how much time it takes to build clean on your machines? i was able to build yesterday. today it's been more than 2 hours and still in progress. thanks, argyn
Re: how to get the latest stable build?
Jeff Genender wrote: m2 is not ready yet. Do a: maven m:co then a maven new how much time it takes to build clean on your machines? i was able to build yesterday. today it's been more than 2 hours and still in progress. thanks, argyn
Re: Precompiled JSPs
Here's a patch that will precompile jsps for all apps by default. This patch also removes the jasper jars (compiler and runtime) from being bundled with the console. These jars exist in the repo anyways. Paul verified that the console runs successfully without these. Moreover these 2 jars were being bundled in 2 war modules, console-standard and console-framework. We should be able to get rid of close to 2MB of redundant jars. Cheers Prasad On 4/21/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > Sounds good to me. > > -dain > > On Apr 21, 2006, at 8:48 AM, Prasad Kashyap wrote: > > > Dain, > > > > In that case, should we consider moving the up to > > the /etc level ? This can then be generically used by any application > > wanting to precompile. Initially I left them in console-framework and > > console-standard thinking they'd be the only ones. But now I see that > > there is a scope for us to reuse this for others too in the future. > > > > Cheers > > Prasad > > > > On 4/21/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > >> Thanks to Prasad we now have percompiled jsps in the console, and the > >> console is much snappier on initial load. > >> > >> The difference is so drastic on my g4 mac, I'd like to see us > >> preprocess the welcome application also since it is the very first > >> impression of our users. > >> > >> Thanks for working on this one, > >> > >> -dain > >> > >> > >> > >> > > jsp-precompile_for_all.patch Description: Binary data
[jira] Created: (GERONIMO-1898) Console JVM statistics break b/c can't cast JVM to StatisticsProvider
Console JVM statistics break b/c can't cast JVM to StatisticsProvider - Key: GERONIMO-1898 URL: http://issues.apache.org/jira/browse/GERONIMO-1898 Project: Geronimo Type: Bug Security: public (Regular issues) Components: core, console Versions: 1.1 Reporter: Aaron Mulder Assigned to: Dain Sundstrom Priority: Blocker Fix For: 1.1 Right now the results of navigation methods backed by reference lookups only implement the interface required by the reference. We need them to implement their auxilliary interfaces too (e.g. reference type JVM but must also implement StatisticsProvider). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1871) Unable to deploy Tapestry app due to classloading issue
[ http://issues.apache.org/jira/browse/GERONIMO-1871?page=all ] Jeff Genender closed GERONIMO-1871: --- Fix Version: 1.1 Resolution: Fixed Looks like it in v1.1 now. > Unable to deploy Tapestry app due to classloading issue > --- > > Key: GERONIMO-1871 > URL: http://issues.apache.org/jira/browse/GERONIMO-1871 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: kernel > Versions: 1.2 > Environment: Windows XP > Reporter: Bryan Noll > Assignee: Gianny Damour > Priority: Critical > Fix For: 1.1 > > Here is the stacktrace encountered when attempting to deploy a Tapestry > application. Please scroll down to see more info after the stack trace. > org.apache.hivemind.ApplicationRuntimeException: Error: Module hivemind is > duplicated! Definition in > jar:file:/C:/tools/geronimo-1.2-SNAPSHOT/config-store/42/war/WEB-INF/lib/hivemind-1.1.jar!/META-INF/hivemodule.xml > has been ignored in favor of existing definition from > jar:file:/C:/tools/geronimo-1.2-SNAPSHOT/config-store/42/war/WEB-INF/lib/hivemind-1.1.jar!/META-INF/hivemodule.xml. > org.apache.hivemind.impl.StrictErrorHandler.error(StrictErrorHandler.java:39) > org.apache.hivemind.impl.RegistryInfrastructureConstructor.addModuleDescriptor(RegistryInfrastructureConstructor.java:202) > org.apache.hivemind.impl.RegistryBuilder.processModuleDescriptorProvider(RegistryBuilder.java:168) > org.apache.hivemind.impl.RegistryBuilder.constructRegistry(RegistryBuilder.java:143) > org.apache.tapestry.ApplicationServlet.constructRegistry(ApplicationServlet.java:253) > org.apache.tapestry.ApplicationServlet.init(ApplicationServlet.java:194) > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105) > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3915) > org.apache.catalina.core.StandardContext.start(StandardContext.java:4176) > org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:66) > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:270) > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) > org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:185) > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) > org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287) > org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke() > net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$7af7fb0d.addContext() > org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:416) > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) > org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) > org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke() > net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173) > org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:229) > org.apache.geronimo.kernel.
[jira] Resolved: (GERONIMO-1897) Configurations get version-ful reference to geronimo/j2ee-server/1.1-SNAPSHOT/car
[ http://issues.apache.org/jira/browse/GERONIMO-1897?page=all ] Aaron Mulder resolved GERONIMO-1897: Resolution: Fixed Assign To: Aaron Mulder > Configurations get version-ful reference to > geronimo/j2ee-server/1.1-SNAPSHOT/car > - > > Key: GERONIMO-1897 > URL: http://issues.apache.org/jira/browse/GERONIMO-1897 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Reporter: Aaron Mulder > Assignee: Aaron Mulder > Priority: Blocker > Fix For: 1.1 > > I deployed the web console and then listed the dependencies from its > ConfigurationData. There was an entry there for > geronimo/j2ee-server/1.1-SNAPSHOT/car (which should not be the case; it > should be geronimo/j2ee-server//car). > Then I listed dependencies for child configurations (it has two web modules) > and got two more geronimo/j2ee-server/1.1-SNAPSHOT/car, so it looks like each > of the parent and two children ended up with a dependency on > geronimo/j2ee-server/1.1-SNAPSHOT/car. I wonder if this is coming from the > default environment set by the deployer? > Needless to say this would prevent the deployed console running if the > j2ee-server was upgraded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
