Re: [ANNOUNCE] Jason Warner as Geronimo's most recent committer
Jason, congrats!! Best wishes, Paul On Apr 2, 2008, at 2:22 PM, Joe Bohn wrote: All, It is my privilege to announce that Jason has recently accepted an invitation to join the Apache Geronimo project. Jason has been working on Geronimo for a while now in multiple areas including J2G, javamail, G-shell commands, samples, and many more things. He is always eager to help users and goes the extra mile to ensure issues are addressed. We're grateful to have him on the project. Please give it up for Jason. Joe
Re: Entropy, or the heat death of the geronimo code base
On Feb 28, 2008, at 6:07 PM, David Jencks wrote: A few years ago I read about an information based perpetual motion machine someone came up with. IIRC many people studied it for quite a while before realizing that the flaw was an assumption that erasing information was free. It turned out to require the same energy as apparently extracted from the machine. By applying this green svn energy saving principle we have an unparalleled opportunity to assure that future visitors to our svn repo will have no way of finding the live code. OR... we could clean up the leftovers from completed refactoring efforts and releases. Here's the stuff I have located in a quick scan that I think has more recent versions elsewhere or is completely obsolete and can be removed, organized by last committer: pmcmahan: plugins/activemq plugins/console plugins/debugviews plugins/jee-management plugins/plancreator plugins/pluto plugins/system-database These plugins were created at that location as a result of our discussions about organizing the various source trees. http://tinyurl.com/2yakx6 But then later we copied those plugins into server/trunk in order to make releasing 2.1 easier: http://tinyurl.com/yw75fb The only value I can think of in keeping those plugins around would be if we want to use their svn maven structuring to implement the ideas we had discussed in the first thread. I won't be up to that task in the foreseeable future, so I'm fine with removing them unless someone else wants to start that effort back up again. Best wishes, Paul
Re: TCK Dog
Yeah, thanks Joe for all the hard work you have done on TCK! Paul On Feb 20, 2008, at 4:58 PM, Kevan Miller wrote: On Feb 20, 2008, at 1:15 PM, Jay D. McHugh wrote: I've been referred to as a puppy before :) But I'd be happy to graduate to TCK Dog. And, I already have my NDA registered. I am still trying to get my local TCK build environment set up though. But as long as I was able to transition into the role with some help, I'll volunteer. Cool. Thanks a lot Jay! I think we all owe Joe a big thanks. He's done a great job keeping our TCK status in the green... --kevan
[jira] Commented: (GERONIMO-3868) Plugin Installer Portlet Over Cluttered
[ https://issues.apache.org/jira/browse/GERONIMO-3868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12571085#action_12571085 ] Paul McMahan commented on GERONIMO-3868: I think this is a great idea. FYI here are some storyboards for a new plugin UI. Parts of it were implemented last year. http://people.apache.org/~pmcmahan/new_plugin_portlets.ppt Plugin Installer Portlet Over Cluttered --- Key: GERONIMO-3868 URL: https://issues.apache.org/jira/browse/GERONIMO-3868 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor The plugin-portlet piece is over cluttered by having too many function and it would be beneficial to split up the respective pieces (plugin installer, export a plugin, and assemble a server) into it's own pieces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
I share Jarek's concern about the impact of this problem but agree with Joe that there's an adequate (albeit not pretty) workaround. Knowing the full scope of this problem now my +1 still stands. But I wish we had more information about the underlying problem because it might be simple to fix, and worth holding up the release for since I would expect that most users will want to use HTTPS for administration activities. But if the fix involved getting a patch committed into pluto's svn then I think we should postpone that type of activity until Geronimo 2.1.1. Best wishes, Paul On Feb 15, 2008, at 12:39 PM, Joe Bohn wrote: Jarek Gawor wrote: On Fri, Feb 15, 2008 at 10:44 AM, Kevan Miller [EMAIL PROTECTED] wrote: On Feb 15, 2008, at 10:12 AM, Jarek Gawor wrote: Looks like I sent this to the wrong thread: This is about: https://issues.apache.org/jira/browse/GERONIMO-3855 Hmm this seems bad. I was able to reproduce the problem on port 8443 only but _all_ portlets failed in this way. So the console is pretty much unusable on port 8443. Can somebody else verify these findings? Yep. Looks like a bug. Don't see this as a security exposure. So, not sure why you want to discuss here. https://issues.apache.org/jira/browse/GERONIMO-3855 would seem like the appropriate location to work on getting this fixed. Do you disagree? But, IMHO, this is not just a bug it is a major bug where one of the important pieces of Geronimo functionality is simply not working on port 8443. Personally, I would have voted -1 on the release if I realized the full scope of this bug sooner. But maybe that's just me.. so I would like to know what other people think about this problem. If it's just me, that's fine. If not, maybe we should consider withdrawing the release. Although the admin console is working fine on port 8080 and maybe that's good enough. Jarek I agree that this is a significant bug but given the current state of the release and the fact that there is a work-around (although I admit that it's hardly perfect) I think it makes sense to fix this in a 2.1.1 release. IMO, this issue makes it all the more important to get 2.1.1 out without delay. Joe
Re: [VOTE] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
+1 Looks good except for the Plugins portlet which is not working for me. Several actions in that portlet lead to: javax.portlet.PortletSecurityException: No Supported org.apache.pluto.driver.services.container.PortletURLProviderImpl.setSec ure(PortletURLProviderImpl.java:67) org.apache.pluto.core.PortletContainerImpl.doAction (PortletContainerImpl.java:261) org.apache.pluto.driver.PortalDriverServlet.doGet (PortalDriverServlet.java:112) org.apache.pluto.driver.PortalDriverServlet.doPost (PortalDriverServlet.java:158) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) But I don't think that defect should hold up the release since the cli is still available and appears to be working ok. Best wishes, Paul On Feb 10, 2008, at 10:46 PM, Kevan Miller wrote: All, I've prepared a 2.1 release candidate for your review and vote. I've also prepared a 2.1.1 TxManager release candidate for review and vote. For simplicity, I'm holding a single vote for both releases. The Geronimo server release is dependent upon the TxManager 2.1.1 release. The source for the Geronimo 2.1 release currently resides here: https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.0 When the release vote is approved, I will svn mv the code to https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.0 An archive of this source code can be found here: http://people.apache.org/~kevan/release-votes/G-2.1/geronimo-2.1- dist/geronimo-2.1-src.tar.gz http://people.apache.org/~kevan/release-votes/G-2.1/geronimo-2.1- dist/ contains the 8 Java EE and Minimal server binary distributions to be released (tomcat/jetty, Java EE/Minimal, tar/ zip) as well as the RELEASE_NOTES and source code archives for the release. For your convenience, here are pointers to the urls for the distributions in zip format: http://people.apache.org/~kevan/release-votes/G-2.1/geronimo-2.1- dist/geronimo-jetty6-javaee5-2.1-bin.zip http://people.apache.org/~kevan/release-votes/G-2.1/geronimo-2.1- dist/geronimo-jetty6-minimal-2.1-bin.zip http://people.apache.org/~kevan/release-votes/G-2.1/geronimo-2.1- dist/geronimo-tomcat6-javaee5-2.1-bin.zip http://people.apache.org/~kevan/release-votes/G-2.1/geronimo-2.1- dist/geronimo-tomcat6-minimal-2.1-bin.zip The maven artifacts for the release can be found here: http://people.apache.org/~kevan/release-votes/G-2.1/geronimo-2.1/ or in the following archive (warning, this file is 458 megs): http://people.apache.org/~kevan/release-votes/G-2.1/geronimo-2.1- dist.tar.gz When the release vote is approved, these maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. Due to the discovery of a bug in the Connector component of Geronimo TxManager, a new release of TxManager was needed. TxManager 2.1.1 is also part of this vote. The source code for the TxManager 2.1.1 release can be found here: https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/ geronimo-txmanager-parent-2.1.1 The maven artifacts for TxManager 2.1.1 can be found here: http://people.apache.org/~kevan/release-votes/G-2.1/geronimo- txmanager-2.1.1/ When the release vote is approved, these maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. Please review these releases and register your vote. [ ] +1 Release Geronimo 2.1 and TxManager 2.1.1 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.1 and TxManager 2.1.1 (please provide rationale) I'll plan on calling this vote on Wednesday evening (11 PM EST). --kevan
Re: [VOTE] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Good question :-) I opened: https://issues.apache.org/jira/browse/GERONIMO-3855 Best wishes, Paul On Feb 14, 2008, at 1:32 PM, Jacek Laskowski wrote: On Thu, Feb 14, 2008 at 6:00 AM, Paul McMahan [EMAIL PROTECTED] wrote: Looks good except for the Plugins portlet which is not working for me. Several actions in that portlet lead to: javax.portlet.PortletSecurityException: No Supported Hi Paul, Have you reported it in JIRA? I could find any emails from jira about it. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Created: (GERONIMO-3855) PortletSecurityException in Plugins portlet
PortletSecurityException in Plugins portlet --- Key: GERONIMO-3855 URL: https://issues.apache.org/jira/browse/GERONIMO-3855 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1 Reporter: Paul McMahan Cannot take any actions in the Plugins portlet. Recreate: Go to the Plugins portlet in the admin console Click any action-- Update Repository List or Add Repository or Export a Plugin or Assemble a Server Note the exception: javax.servlet.ServletException: javax.portlet.PortletSecurityException: No Supported org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:116) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) root cause javax.portlet.PortletSecurityException: No Supported org.apache.pluto.driver.services.container.PortletURLProviderImpl.setSecure(PortletURLProviderImpl.java:67) org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:261) org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:112) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Adding a page to a plugin
There is some documentation on the extensible admin console here which describes the architecture and has samples: http://cwiki.apache.org/GMOxDEV/extensible-administration-console.html If you are writing a plugin for the admin console then I would encourage you to look over that documentation and improve/correct it as you see fit. Best wishes, Paul On Feb 8, 2008, at 1:49 AM, Manu George wrote: Hi, On a related note , since the pluggable console was introduced is there any doc on how to include new portlets or on the architecture of the pluggable console. A doc will really go a long way in helping others develop new portlets. A list of files to look at will in itself be a great help. Thanks Manu On Feb 8, 2008 3:20 AM, Joseph Leong [EMAIL PROTECTED] wrote: Hi everyone, I'm trying to add a page to a plugin. After tracing the code, it is running through the handler ie.. hitting the actionBeforeView and going into the renderView. However nothing of my jsp page is showing up. The steps i've taken are: 1) Create the handler page 2) create the jsp page 3) Add the addhelper in the ImportExportPortlet.java Is there anything blatantly obvious that I'm missing? Or i will continue to work with these 3 pieces. Thanks! -Joseph Leong
Re: Adding a page to a plugin
Right, the doc in the wiki about the extensible admin console was really only helpful for Manu's followup to your question. The mutipage portlet code you referred to is internal to the admin console and afaik is not documented anywhere nor is it intended to be exposed as an externally supported api. Creating an admin console extension does not require you to implement your portlet this way. Paul On Feb 8, 2008, at 10:37 AM, Joseph Leong wrote: Thank you for all the responses! The piece i'm working on is the plugin installer in the console, but it seems to be built with some sort of multipage model framework. So this part of it is working a little differently than the documentation, but It just so happens that your wiki references on the extensible administration console will really help on the debug viewer plugin piece i'm working on. I'll post updates on what the missing piece was once i figure it out, feel it'll save someone down the road a good bit of time should they go down this route and find any other pieces of the console working on this multipage model framework. Wishing you all the best, Joseph Leong On Feb 7, 2008 4:50 PM, Joseph Leong [EMAIL PROTECTED] wrote: Hi everyone, I'm trying to add a page to a plugin. After tracing the code, it is running through the handler ie.. hitting the actionBeforeView and going into the renderView. However nothing of my jsp page is showing up. The steps i've taken are: 1) Create the handler page 2) create the jsp page 3) Add the addhelper in the ImportExportPortlet.java Is there anything blatantly obvious that I'm missing? Or i will continue to work with these 3 pieces. Thanks! -Joseph Leong
Re: Changes needed to the website upon PRC communication
agreed, Epiq did a fantastic job and they deserve credit. Paul On Feb 5, 2008, at 10:29 PM, Matt Hogstrom wrote: double ditto :) On Feb 5, 2008, at 9:08 PM, Kevan Miller wrote: I think the Geronimo G graphics merit the continued gratitude of the Geronimo project. I'd like to see our little thank you restored. Would you be ok with that? How do others feel? --kevan
Re: New portlet for ActiveMQ
This sounds great. I agree with Vamsi that it would be good to expand the current JMS resources portlet if possible. As I recall, it was left in a somewhat transitional state and contains a lot of unused code that could still be refactored. Best wishes, Paul On Feb 6, 2008, at 7:56 AM, Vamsavardhana Reddy wrote: Hi Anish, I have added you as a Geronimo contributor. I suggest you create a JIRA so that we can track progress on this task. See if you can expand the JMS Resources portlet to provide these functions instead of creating a new portelt. ++Vamsi On Feb 6, 2008 4:41 PM, anish pathadan [EMAIL PROTECTED] wrote: Hi All, I would like to add an ActiveMQ portlet in admin console.The portlet will have informations like 1). Queues 2) Topics 3)Count of messages send to each queue/topic ,pending messages 4)Option to send messages to messages to queues/topics 5)Purge messages on queues/topics 6)Browse and send messages to queues/topics Please give me your suggestions on this. Also can somebody give me a contributer access for this. -- Best Regards, Anish Pathadan
Re: [ANNOUNCE] Viet Nguyen as Geronimo's most recent committer
Welcome Viet. Paul On Jan 30, 2008, at 10:47 PM, Kevan Miller wrote: All, I'd like to welcome Viet Nguyen as a new committer on the Geronimo project. Viet has made a number of contributions to Geronimo, including our new monitoring capabilities, the J2G conversion tool, as well as a number of bug fixes, and other helpful contributions. Let's lay some props on Viet! --kevan
Re: Remove old JVM Memory graph from console?
As I recall the graph doesn't display correctly in IE, see GERONIMO-1939. So now that the monitoring plugin provides this function I would advocate either replacing the old graph or removing it. Best wishes, Paul On Jan 26, 2008, at 6:08 AM, Erik B. Craig wrote: All, Currently in the admin console there is an 'Information' page under the 'Server' group that contains among other things a DWR driven graph that updates every second showing the current JVM memory usage. Now that we have the monitoring plugin rolled in with everything, I suggest this be removed as it is now antiquated and no longer necessary, perhaps leaving the 'Information' page to just show a snapshot of information on page load instead of automatically updating every second. If nobody objects to this, I will go ahead and make this change Thanks, Erik B. Craig [EMAIL PROTECTED]
Re: Do Plugins need Prerequisites?
Thanks Aaron for the thorough explanation. I agree that the prereq relationship provides useful information and functionality beyond what the dependency relationship provides. The plugins portlet in the admin console will currently inspect the prerequisites for the plugins listed in a remote catalog and will designate any plugins that have missing prerequisites as being not compatible with the server. (Incompatible server or JVM versions are handled the same way.) I think that designation is useful as it prompts the user to inspect the plugin's properties to get further details on what steps they might need to take to prepare or reconfigure their server -- e.g. manually create a db pool, replace a conflicting component, etc. I also think the prereq relationship is especially useful because webapp plugins are not compatible between tomcat and jetty assemblies, and like you say we don't want the plugin installer to automatically install a second web container into an assembly if the user picks the wrong plugin. Best wishes, Paul On Dec 13, 2007, at 1:21 PM, Aaron Mulder wrote: On Dec 12, 2007 8:27 PM, David Jencks [EMAIL PROTECTED] wrote: I must be missing something... how does the prerequisite system work better than dependencies here? I'm not 100% sure of what currently happens when you try to install a plugin that has an unavailable dependency, but it certainly won't start even if its downloaded. Originally I think, the plugin would refuse to download and install. The idea was that if something was a dependency it was more or less guaranteed to be available, whereas a prerequisite pretty much always required manual intervention (except for Jetty/Tomcat, which I mention below). Dependencies and prerequisites could be combined, but my concern would be how to clearly convey the directions for what the user needs to do to get get plugin to work. Like, if a plugin has 20 dependencies, and one of them is something that the user has to manually deal with, how do you emphasize to the user that in order to install the plugin, they need to take that action? If it's just in the dependency description, it seems like it would be lost among the 20 dependencies... Unless we have some logic to detect which dependencies can't be installed and emphasize those somehow. I really want to avoid the case where you identify the perfect plugin, install it, and then confusingly, it's not running afterward. You go to start it, and it won't start, perhaps with a confusing error (Dependency foo wasn't installed? Why not? I thought this was supposed to be automatic? Crappy product!) Again, so long as the user experience is good, the plumbing doesn't matter so much. I guess the other usage was to ensure you didn't install both Jetty and Tomcat in the same environment. As in, you have the Tomcat stack, and you accidentally click a web app built against Jetty, we don't want it to automatically download and install Jetty (because, among other things, if the default ports conflict the server won't start, and web app deployments suddenly get a lot more confusing if the wrong engine handles it). Also, it would be really unexpected that you click a web app plugin link, and suddenly it's installing a new Web server. So I'm not sure we want Jetty or Tomcat to appear as normal dependencies of a web app. Strike that, I'm pretty sure we don't want it, unless web app deployments change to be web-container-neutral so it would only install a Web container if one wasn't already there. Thanks, Aaron On Dec 12, 2007 6:33 PM, David Jencks [EMAIL PROTECTED] wrote: Aaron included a prerequisite feature for plugin metadata which is supposed to prevent you from installing a plugin if some prerequisite plugin is missing. After some thought I can't think of a reason this would possibly be useful or more useful than a dependency, where the needed plugin is simply installed for you. I disabled this functionality but forgot to discuss this point, but now that Jarek has re-enabled it I think it's time for a discussion. I do think there is some use for some feature that e.g. prevents installing jetty if tomcat is present, but I don't think prerequisites implement that in any useful way. comments? thanks david jencks
Re: [VOTE] Release Genesis 1.3
+1 On 11/12/2007, at 8:58 PM, Jason Dillon wrote: Folks, a small change to Genesis was made to support a custom legal resource bundle for the GShell release. I'd like to get this out so we can get GShell out too. +1 -Release it +0 -Eh, whatever -1 -Um, no no no no no... --jason
Re: [DISCUSS] Monitoring Client may need a new graphing engine
I have to agree with John that browser and platform support is the most important factor. Furthermore, I think the ajax library in library in Geronimo should continue to be shared across its webapps. On both of these accounts I would lean heavily towards upgrading the monitoring client (and the admin console) to Dojo 1.0.1 since it has IE Safari support and IMO is quickly becoming the open source ajax library of choice. I am excited about running the admin console on my ipod touch :-) Best wishes, Paul On Dec 7, 2007, at 6:46 AM, John Sisson wrote: Erik B. Craig wrote: All, Currently the monitoring client is using Dojo 0.4.3 charting, which does not necessarily behave as expected on Firefox/Safari on a mac, or on IE6 on Windows. I consider this to be a shortcoming, and given the new version of Dojo available (1.0.1), began investigating migrating the monitoring client over to the new version of Dojo, only to find that the new version of dojo appears to be a significant rewrite of the old code base, leaving out some features that I consider to be very visually pleasing and important for statistics viewing. While rummaging through the Dojo forums, I stumbled upon another Javascript graphing framework called Timeplot, which is part of the SIMILE project at MIT, and while this has it's own set of limitations... I'm trying to figure out the lesser of three evils before it comes a time that this monitoring plugin will be released, so that I have enough time (read: 3-5 days) to migrate the javascript generation over to something new if necessary. I have created a small demonstration page that shows all three options graphed with the same data series, as well as weighing some of the advantages/disadvantages I could come up with, Please have a look, and let me know your thoughts. http://people.apache.org/~ecraig/graphdemo/ Personally, I think it would be really cool if we could use the Timeplot graphing libraries, as it is all BSD licensed and therefore friendly I believe (right, Kevan?)... and also EXTREMELY cool for showing multiple data series in one chart. IMHO, as much as I dislike saying this.. IE support should be mandatory considering the number of users who use it. The disadvantages of Dojo 1.0.1 sound pretty minor compared the other options not supporting browsers. Regards, John
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007, at 12:45 PM, Kevan Miller wrote: 1. Are we ready to move monitoring plugin out of sandbox? +1 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. I would vote for server/trunk/plugins, if for no other reason than to synchronize the monitoring plugin release with the server release. When the plugin gets to be more mature and can support multiple versions of geronimo then maybe we would consider moving it to a separate subproject. Also, moving it to trunk ensures that it will be included in the plugin catalog (~/.m2/repo/geronimo- plugins.xml) when you build trunk and will make it very easy to add monitoring to an assembly by just editing that assembly's pom. 3. What bug fixes/new features need to be added to the monitoring plugin before it's ready to be released? I agree with Anita that it will need some testing feedback before releasing to the wild. IMO the best way to facilitate that type of exposure is to move it into trunk. I think that this new monitoring feature is important enough to justify holding up a 2.1 release if it actually comes down to that. Best wishes, Paul
Re: Geronimo 2.1 dependencies on SNAPSHOTs
On Nov 26, 2007, at 2:36 PM, Kevan Miller wrote: On Nov 26, 2007, at 11:29 AM, Joe Bohn wrote: Pluto 1.2.0-SNAPSHOT Has anybody pinged their list? Joe and I have pinged their list, no response yet. myfaces1.2.1-SNAPSHOT Has anybody pinged their list? Matthias indicated that he would be willing to push a MyFaces release when JSF TCK is 100% passing. But I would recommend that we postpone making that request until all JEE tests are passing in Geronimo since JSF is very susceptible to lower level changes in the servlet engine, deployment code, application classloader, etc. Best wishes, Paul
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Congrats Mr. Craig! Best wishes, Paul On Nov 20, 2007, at 11:45 AM, Matt Hogstrom wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt
[jira] Closed: (GERONIMO-1828) JSR-88 treats AbstractName like an ObjectName
[ https://issues.apache.org/jira/browse/GERONIMO-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-1828. -- JSR-88 treats AbstractName like an ObjectName - Key: GERONIMO-1828 URL: https://issues.apache.org/jira/browse/GERONIMO-1828 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Paul McMahan Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Attachments: dbplan.xml I get this stacktrace when trying to deploy a database plan: Deployer operation failed: Invalid value: 'geronimo.config:name=console/dbpool-test/1.0/rar' javax.management.MalformedObjectNameException: Invalid value: 'geronimo.config:name=console/dbpool-test/1.0/rar' at javax.management.ObjectName.parsePropertyValue(ObjectName.java:571) at javax.management.ObjectName.convertStringToProperties(ObjectName.java:462) at javax.management.ObjectName.parse(ObjectName.java:399) at javax.management.ObjectName.init(ObjectName.java:76) at org.apache.geronimo.deployment.plugin.local.CommandSupport.loadChildren(CommandSupport.java:326) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:70) at java.lang.Thread.run(Thread.java:534) I'll attach the db plan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1666) Console issues resulting from configID changes
[ https://issues.apache.org/jira/browse/GERONIMO-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-1666. -- Console issues resulting from configID changes -- Key: GERONIMO-1666 URL: https://issues.apache.org/jira/browse/GERONIMO-1666 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Paul McMahan Fix For: 1.1 This JIRA tracks what areas of the console need attention as a result of the configID changes. At Revision 382401: - Classloader for classes loaded from geronimo-console-core-1.1-SNAPSHOT.jar can't load classes from geronimo-jetty-1.1-SNAPSHOT.jar. This prevents BasicProxyManager from being able to create proxies needed by the Server Logs and Web Server portlets. - J2EEServerImpl.getRepositories() returns an empty String[]. This prevents the the Common Libraries portlet and the DB Pool Wizard from listing out the available jars in the repository. Also prevents the JMS Resource portlet from being able to create new JMS Resource groups for ActiveMQ. - Trying to delete a new activeio listener I created results in the following ST. BTW, it failed to start too but I see that problem in Geronimo-1.0 16:19:56,029 WARN [Util] No parents found for geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,J2EEServer=geronimo,broker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.9123-asdf 16:19:56,030 ERROR [ActiveMQManagerGBean] Unable to remove GBean java.lang.NullPointerException at org.apache.geronimo.kernel.basic.BasicKernel.createGBeanName(BasicKernel.java:427) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:177) at org.activemq.gbean.management.ActiveMQManagerGBean.removeConnector(ActiveMQManagerGBean.java:247) at org.activemq.gbean.management.ActiveMQManagerGBean$$FastClassByCGLIB$$a78b116e.invoke(generated) - ConfigurationManager.listStores() returns an empty list for the storeName: geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.1-SNAPSHOT/car,J2EEServer=geronimo,j2eeType=ConfigurationStore,name=Local This prevents the user from being able to start/stop/undeploy/etc their components from the EAR, WAR, EJB, Connector, App Client, and System Modules portlets - Deploying a simple WAR fails with an external plan fails with the error message: org.apache.geronimo.kernel.config.InvalidConfigException: Source is not readable /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/repository/test/test/1.1/test-1.1.war Source is not readable /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/repository/test/test/1.1/test-1.1.war I checked and the .../repository/test/test/1.1 directory is present but it is empty - Creating and then deploying a new security realm fails with the following ST: 17:20:06,704 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.kernel.repository.Version.parseVersion(Version.java:115) at org.apache.geronimo.kernel.repository.Version.init(Version.java:40) at org.apache.geronimo.kernel.repository.Artifact.init(Artifact.java:38) at org.apache.geronimo.deployment.service.EnvironmentBuilder.toArtifact(EnvironmentBuilder.java:229) at org.apache.geronimo.deployment.service.EnvironmentBuilder.buildEnvironment(EnvironmentBuilder.java:56) at org.apache.geronimo.deployment.service.EnvironmentBuilder.buildEnvironment(EnvironmentBuilder.java:125) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.getConfigurationID(ServiceConfigBuilder.java:147) The relevant part of the plan (which was generated by the wizard) looks like: environment configId groupIdUnspecified/groupId artifactIdtest/artifactId /configId /environment -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2465) Relocate plugin repository list to a source controlled location
[ https://issues.apache.org/jira/browse/GERONIMO-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-2465. -- Relocate plugin repository list to a source controlled location --- Key: GERONIMO-2465 URL: https://issues.apache.org/jira/browse/GERONIMO-2465 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.1, 1.1.1 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 1.2 The default list of plugin repositories that gets loaded into the admin console currently comes from a user directory at people.apache.org. The list should be relocated to SVN so that it can be version controlled and updated by project committers. See discussion at: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200609.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2804) implement jsf 1.2 support
[ https://issues.apache.org/jira/browse/GERONIMO-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-2804. -- implement jsf 1.2 support - Key: GERONIMO-2804 URL: https://issues.apache.org/jira/browse/GERONIMO-2804 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: web Affects Versions: 2.0-M3 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.0-M3 myfaces has not published the 1.2-SNAPSHOT binaries to a maven repo yet so Geronimo includes them in the jee5 assemblies by putting them in a local repo at modules/geronimo-web-2.5-builder/repository. Those binaries need to be updated to the latest snapshot. Also, the myfaces classes need to be added to all webapp's classloaders -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2805) add tribes clustering support for tomcat
[ https://issues.apache.org/jira/browse/GERONIMO-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-2805. -- add tribes clustering support for tomcat Key: GERONIMO-2805 URL: https://issues.apache.org/jira/browse/GERONIMO-2805 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0-M3 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.0-M3 Attachments: config.xml Tomcat6 has been redesigned to use tribes for clustering, so the o.a.g.tomcat.cluster package was temporarily disabled when tomcat6 was introduced into geronimo 2.0. Geronimo's tomcat cluster gbeans need to be updated to support tribes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2955) MyFaces Tag Library Descriptors are not found by the Jasper Compiler
[
https://issues.apache.org/jira/browse/GERONIMO-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul McMahan closed GERONIMO-2955.
--
MyFaces Tag Library Descriptors are not found by the Jasper Compiler
Key: GERONIMO-2955
URL: https://issues.apache.org/jira/browse/GERONIMO-2955
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: web
Affects Versions: 2.0-M3
Reporter: Paul McMahan
Assignee: Paul McMahan
Priority: Critical
Fix For: 2.0-M4
Jasper's technique for finding Tag Library Descriptors (TLDs) does not work
well with Geronimo's MultiParentClassLoader. The Jasper compiler tries to
find TLDs in jar files by getting the list of jars from the webapp's
classloader and scanning them for META-INF/\*\*.tld. Then it repeats this
process up the classloader hierarchy (at least what it *thinks* is the
classloader hierarchy) by calling ClassLoader.getParent(). That works OK
when then TLDs are in the webapp's WEB-INF/lib or in the JRE's system or
application classloader. But this technique doesn't work in Geronimo because
there are sometimes jars in the classloader hierarchy that are only
accessible by using Geronimo's special MultiParentClassLoader.getParents()
method.
The Jasper code referred to above can be viewed in the scanJars() method of
this class:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_10/java/org/apache/jasper/compiler/TldLocationsCache.java
Because of this limitation the Jasper compiler does not find the TLDs in
myfaces-impl-2.0-SNAPSHOT.jar because it doesn't find the classloader
containing that jar when it looks up the direct lineage of classloaders.
This causes the following error message when a JSP refers to the JSF taglibs:
{quote}
javax.servlet.ServletException: The absolute uri:
http://java.sun.com/jsf/html cannot be resolved in either web.xml or the jar
files deployed with this application
{quote}
The MyFaces TLDs need to be made accessible to Jasper so that webapps can
reference the JSF taglibs in their JSPs without copying the TLDs into their
WARs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1887) Remove unneeded jars from console WEB-INF/lib directories
[ https://issues.apache.org/jira/browse/GERONIMO-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-1887. -- Remove unneeded jars from console WEB-INF/lib directories - Key: GERONIMO-1887 URL: https://issues.apache.org/jira/browse/GERONIMO-1887 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.x Reporter: Paul McMahan Assignee: Jason Dillon Priority: Minor Fix For: 1.2 Several of the jars in the console's WEB-INF/lib directories are unneeded - both copies of jasper-compiler-5.5.12.jar (400K each) - both copies of jasper-runtime-5.5.12.jar (80K each) - the copy of castor-0.9.5.3.jar in console-standard (1.7M) Removing these jars will decrease the server footprint and binary image download size. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2160) Can't install a J2EE connector plugin
[ https://issues.apache.org/jira/browse/GERONIMO-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-2160. -- Can't install a J2EE connector plugin - Key: GERONIMO-2160 URL: https://issues.apache.org/jira/browse/GERONIMO-2160 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.1 Environment: windows xp, Reporter: Paul McMahan Assignee: Aaron Mulder Priority: Minor Fix For: 1.1.1 Attachments: test-1.0.rar Steps to recreate: - create a database pool using the wizard in the console - export the connector associated with the pool just created as a plugin using the plugins portlet (attached a copy fo this jira) - copy the connector plugin into a plugin repository - install the connector plugin using the pluigns portlet - start the plugin, which results in the following stacktrace: 15:36:16,187 INFO [DWRServlet] retrieved system configuration file: [EMAIL PROTECTED] 15:36:22,421 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=console.dbpool/test/1.0/rar?J2EEApplication=null,JCAConnectionFactory=test,JCAResource=console.dbpool/test/1.0/rar,ResourceAdapter=console.dbpool/test/1.0/rar,ResourceAdapterModule=console.dbpool/test/1.0/rar,j2eeType=JCAManagedConnectionFactory,name=test java.lang.ClassNotFoundException: org.tranql.connector.jdbc.JDBCDriverMCF in classloader console.dbpool/test/1.0/rar at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:249) at java.lang.ClassLoader.loadClass(Unknown Source) at org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrapper.init(ManagedConnectionFactoryWrapper.java:138) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:512) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:493) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57
[jira] Closed: (GERONIMO-3159) J2G documentation
[ https://issues.apache.org/jira/browse/GERONIMO-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-3159. -- J2G documentation - Key: GERONIMO-3159 URL: https://issues.apache.org/jira/browse/GERONIMO-3159 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: J2G Reporter: Paul McMahan Assignee: Paul McMahan Priority: Minor Attachments: geronimo-3159-2.patch, geronimo-3159.patch The J2G donation (GERONIMO-2743) contained some documentation. But that documentation had IBM Confidential footer. Need to secure new documentation from the contributor that does not contain the footer or get permission to remove the footer. Once the documentation has been secured it should be added to the J2G package and maybe also added to the wiki. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1876) backport console progress bar from 1.2 to 1.1
[ https://issues.apache.org/jira/browse/GERONIMO-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-1876. -- backport console progress bar from 1.2 to 1.1 - Key: GERONIMO-1876 URL: https://issues.apache.org/jira/browse/GERONIMO-1876 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: Paul McMahan Assignee: Aaron Mulder Fix For: 1.1 Attachments: progressbar.patch progress bar is needed for lengthy driver and plugin downloads -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2773) cannot create a new jetty http connector from console
[ https://issues.apache.org/jira/browse/GERONIMO-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-2773. -- cannot create a new jetty http connector from console - Key: GERONIMO-2773 URL: https://issues.apache.org/jira/browse/GERONIMO-2773 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, Jetty Affects Versions: 2.0-M2 Environment: 2.0-SNAPSHOT jetty jee5 assembly, macosx Reporter: Paul McMahan Assignee: Anita Kulshreshtha Fix For: 2.0-M6 Attachments: geronimo-2773.patch, geronimo-2773.patch, geronimo-2773.patch trying to create a new jetty http connector from the admin console produces the following stack trace: 00:16:26,133 ERROR [JettyManagerImpl] Unable to add GBean org.apache.geronimo.kernel.config.InvalidConfigException: Cound not add GBean org.apache.geronimo.configs/jetty6/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/jetty6/2.0-SNAPSHOT/car,j2eeType=GBean,name=test to configuration org.apache.geronimo.configs/jetty6/2.0-SNAPSHOT/car at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager.addGBeanToConfiguration(EditableKernelConfigurationManager.java:122) at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager.addGBeanToConfiguration(EditableKernelConfigurationManager.java:61) at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager$$FastClassByCGLIB$$daeffab3.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$de47e049.addGBeanToConfiguration(generated) at org.apache.geronimo.jetty6.JettyManagerImpl.addConnector(JettyManagerImpl.java:98) at org.apache.geronimo.jetty6.JettyManagerImpl$$FastClassByCGLIB$$f2d5e245.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.management.geronimo.WebManager$$EnhancerByCGLIB$$fb3a5d8f.addConnector(generated) at org.apache.geronimo.console.util.PortletManager.createWebConnector(PortletManager.java:247) at org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction(ConnectorPortlet.java:107) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:62) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:133) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) at org.apache.geronimo.jetty6
[jira] Closed: (GERONIMO-2007) Avoid Classloader warnings generated by BasicProxyManager
[ https://issues.apache.org/jira/browse/GERONIMO-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-2007. -- Avoid Classloader warnings generated by BasicProxyManager - Key: GERONIMO-2007 URL: https://issues.apache.org/jira/browse/GERONIMO-2007 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: Paul McMahan Assignee: Joe Bohn Fix For: 1.1.1 Attachments: GERONIMO-2007.patch Several views in the console create proxies for objects that implement interfaces not available in the console's classloader. The warning messages look like: 08:56:26,315 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer This warning message can be avoided by getting the classloader for the proxied object from the kernel and then using it to create the proxy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3157) unit test cases for J2G
[ https://issues.apache.org/jira/browse/GERONIMO-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-3157. -- unit test cases for J2G --- Key: GERONIMO-3157 URL: https://issues.apache.org/jira/browse/GERONIMO-3157 Project: Geronimo Issue Type: Test Security Level: public(Regular issues) Components: J2G Reporter: Paul McMahan Assignee: Jason Warner Priority: Minor Attachments: Geronimo-3157-LicenseHeaders.patch, Geronimo-3157.patch Create unit test cases for J2G tool to verify that its working correctly at build time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2784) Samples cleanup
[ https://issues.apache.org/jira/browse/GERONIMO-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-2784. -- Samples cleanup --- Key: GERONIMO-2784 URL: https://issues.apache.org/jira/browse/GERONIMO-2784 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: sample apps Affects Versions: 2.0-M3 Reporter: Paul McMahan Assignee: Paul McMahan Priority: Minor Fix For: 2.1 As discussed on dev: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200701.mbox/[EMAIL PROTECTED] # Move the following modules from server/trunk/applications to samples/trunk ** demo (security demo) ** geronimo-examples ** geronimo-ldap-demo ** magicGball # Move anything worth keeping from server/trunk/applications/daytrader to daytrader/trunk # Remove the configs for these modules from server/trunk/configs # Enable samples/trunk to build CARs so that the samples can be installed as plugins # Publish the CARs built in samples/trunk to a maven repo # Update the plugin catalog at site/trunk/plugins/ to reference the samples in maven repo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2521) add snapshot support to plugin installer gbean
[ https://issues.apache.org/jira/browse/GERONIMO-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-2521. -- add snapshot support to plugin installer gbean -- Key: GERONIMO-2521 URL: https://issues.apache.org/jira/browse/GERONIMO-2521 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.x Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 1.2 Attachments: GERONIMO-2521.patch When a snapshot artifact is published in an m2 repo the SNAPSHOT suffix of the artifact's filename is replaced with a timestamp and build number that come from a file named maven-metadata.xml in the artifacts directory. For example, the artifact org.apache.geronimo.configs/servlet-examples-tomcat/1.2-SNAPSHOT/car is published at: http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/configs/servlet-examples-tomcat/1.2-SNAPSHOT/servlet-examples-tomcat-1.2-20061026.113134-2.car When the plugin installer gbean is installing a SNAPSHOT version of a plugin it should create the download URL using the timestamp and build number obtained from maven-metadata.xml instead of the version number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2442) update geronimo-plugin.xml files to use org.apache.geronimo group ids
[ https://issues.apache.org/jira/browse/GERONIMO-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-2442. -- update geronimo-plugin.xml files to use org.apache.geronimo group ids - Key: GERONIMO-2442 URL: https://issues.apache.org/jira/browse/GERONIMO-2442 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.2 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 1.2 During the m2 conversion effort many of the maven group ids for geronimo modules changed from geronimo to org.apache.geronimo.modules or org.apache.geronimo.configs. prerequisite and dependency elements in several geronimo-plugin.xml files need to be updated to use the new group ids. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1392) update additional samples redirect in geronimo website
[ https://issues.apache.org/jira/browse/GERONIMO-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-1392. -- Assignee: Paul McMahan update additional samples redirect in geronimo website Key: GERONIMO-1392 URL: https://issues.apache.org/jira/browse/GERONIMO-1392 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Affects Versions: 1.x Environment: all envs Reporter: Paul McMahan Assignee: Paul McMahan Priority: Minor Attachments: GERONIMO-1392.patch The location of the additional samples document in confluence changed from: http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Samples+for+Apache+Geronimo to: http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Sample+applications Need to update the corresponding redirect at the Geronimo website. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Can we deal generically with container specific jsr77 statistics?
While I think that technically Anita is correct this approach produces some practical challenges. If all the *StatsImpl classes for all components in the server are gathered in g-management then how can the *StatsImpl classes be upgraded, modified, or replaced without also replacing g- management? The g-management module would become a major source of contention as various components fix and improve their management interfaces (and we hope they do). And since g-management is part of the core framework I think replacing it would require recycling the server (not verified). Let's weigh this out against the overhead of maintaining separate configs for each of the various assembly configurations, which is certainly no trivial matter. Best wishes, Paul On Nov 8, 2007, at 10:10 AM, Anita Kulshreshtha wrote: --- Erik B. Craig [EMAIL PROTECTED] wrote: say, openEJB or somesuch would also reside here rather than within our openEJB package? If so, how would this all play into the pluggable server/framework design? Since these classes ONLY depend on management classes and not on openEJB or somesuch, it does not affect the pluggable server/framework design. I do not think we are planning to strip down classes from g-management to cater to pluggable framework and add classes as we upgrade to a higher assembly. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Can we deal generically with container specific jsr77 statistics?
I hadn't really thought about footprint issues, but that's a good point. Put another way, my concern is: Can a component's management interface be modified without also replacing g-mangement? Best wishes, Paul On Nov 8, 2007, at 11:56 AM, Anita Kulshreshtha wrote: --- Paul McMahan [EMAIL PROTECTED] wrote: While I think that technically Anita is correct this approach produces some practical challenges. If all the *StatsImpl classes for all components in the server are gathered in g-management then how can the *StatsImpl classes be upgraded, modified, or replaced without also replacing g- management? Paul, We are talking about few classes (e.g. 3 each for tomcat/Jetty) per component not few jars. I do not think it is worth having separate g-management for each assembly. Especially when we still ship all specs _jars_ in the smallest assembly. I hope this answers your concerns.. Thanks Anita The g-management module would become a major source of contention as various components fix and improve their management interfaces (and we hope they do). And since g-management is part of the core framework I think replacing it would require recycling the server (not verified). Let's weigh this out against the overhead of maintaining separate configs for each of the various assembly configurations, which is certainly no trivial matter. Best wishes, Paul On Nov 8, 2007, at 10:10 AM, Anita Kulshreshtha wrote: --- Erik B. Craig [EMAIL PROTECTED] wrote: say, openEJB or somesuch would also reside here rather than within our openEJB package? If so, how would this all play into the pluggable server/framework design? Since these classes ONLY depend on management classes and not on openEJB or somesuch, it does not affect the pluggable server/framework design. I do not think we are planning to strip down classes from g-management to cater to pluggable framework and add classes as we upgrade to a higher assembly. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Assigned: (GERONIMO-3562) customizable navigator icons for admin console extensions
[
https://issues.apache.org/jira/browse/GERONIMO-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul McMahan reassigned GERONIMO-3562:
--
Assignee: Paul McMahan
customizable navigator icons for admin console extensions
-
Key: GERONIMO-3562
URL: https://issues.apache.org/jira/browse/GERONIMO-3562
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 2.1
Reporter: Paul McMahan
Assignee: Paul McMahan
The extensible admin console console should support customizable icons for
the navigator items. One way to implement this would be to enhance the
gbean definition like:
{code:xml}
gbean name=MyConsoleExtension
class=org.apache.geronimo.pluto.AdminConsoleExtensionGBean
attribute name=pageTitleApplications/My Console
Extension/attribute
attribute name=portletContext/my-console-extension/attribute
attribute name=portletList[MyPortlet]/attribute
attribute name=iconimages/myicon.png/attribute!--- new
attribute for icon --
/gbean
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] 2.1 Release
On Nov 6, 2007, at 11:35 AM, David Jencks wrote: 1. get rid of gbean proxies in gbean references. IIRC Dain did some experiments long ago and this resulted in a noticeable speedup. The problem at that time was that it broke the admin console. I think the main breakage was that attribute changes weren't saved??? I was wondering if we could leave the machinery to create proxies in place but not use it for gbean references and have the admin console explicitly request the proxies. Does anyone remember or know enough about this to comment on or refute this? As I recall the main issue with getting rid of the automatic proxy creation was that the console currently takes advantage of the fact that they can be cast to GeronimoManagedBean, which allows the console to do things like start/stop the gbean or get the gbean state and uptime in a generic way without knowing the ObjectName in advance. GeronimoManagedBean.getObjectName() is also pretty handy for introspection purposes. So leaving the machinery in place to support explicitly creating proxies would probably be required at minimum. But I like the idea of eliminating the automatic creation of proxies - not only for the speedup but also because the automagically generated src can drive me crazy when debugging. I know proxies can be turned off via Dain's experimental system property but I'm usually debugging the console, which needs them turned on. Catch-22. If someone wants to create a patch for the kernel that implements this idea then I can help assess the subsequent changes needed for the console. Best wishes. Paul
[jira] Commented: (GERONIMO-3523) java.io.IOException: FULL head
[ https://issues.apache.org/jira/browse/GERONIMO-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540542 ] Paul McMahan commented on GERONIMO-3523: Using the HTTP session to store render parms didn't work out. Rev. 592536 sets the header buffer size to 8k for jetty web connectors in G. The default buffer size had been tuned to 4k in jetty as part of http://fisheye.codehaus.org/browse/jetty/jetty/tags/jetty-6.1.5/modules/jetty/src/main/java/org/mortbay/jetty/AbstractBuffers.java?r1=1649r2=1723 java.io.IOException: FULL head -- Key: GERONIMO-3523 URL: https://issues.apache.org/jira/browse/GERONIMO-3523 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.x Reporter: Jarek Gawor Assignee: Paul McMahan On Jetty the testsuite/console-testsuite/advanced tests usually fail with strange errors while the same works fine on Tomcat. On the server I see the following errors: 16:22:43,046 WARN [log] handle failed java.io.IOException: FULL head at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:276) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:201) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:331) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) The tests fail with different errors e.g. (it changes from run to run): testNewJMSResource(org.apache.geronimo.testsuite.console.JMSResourcesTest) Time elapsed: 7.86 sec FAILURE! com.thoughtworks.selenium.SeleniumException: ERROR: Element //[EMAIL PROTECTED]'Add Destination'] not found at com.thoughtworks.selenium.HttpCommandProcessor.doCommand(HttpCommandProcessor.java:73) at com.thoughtworks.selenium.DefaultSelenium.click(DefaultSelenium.java:82) at org.apache.geronimo.testsuite.console.JMSResourcesTest.testNewJMSResource(JMSResourcesTest.java:47) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3523) java.io.IOException: FULL head
[ https://issues.apache.org/jira/browse/GERONIMO-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved GERONIMO-3523. Resolution: Fixed Fix Version/s: 2.1 java.io.IOException: FULL head -- Key: GERONIMO-3523 URL: https://issues.apache.org/jira/browse/GERONIMO-3523 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.x Reporter: Jarek Gawor Assignee: Paul McMahan Fix For: 2.1 On Jetty the testsuite/console-testsuite/advanced tests usually fail with strange errors while the same works fine on Tomcat. On the server I see the following errors: 16:22:43,046 WARN [log] handle failed java.io.IOException: FULL head at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:276) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:201) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:331) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) The tests fail with different errors e.g. (it changes from run to run): testNewJMSResource(org.apache.geronimo.testsuite.console.JMSResourcesTest) Time elapsed: 7.86 sec FAILURE! com.thoughtworks.selenium.SeleniumException: ERROR: Element //[EMAIL PROTECTED]'Add Destination'] not found at com.thoughtworks.selenium.HttpCommandProcessor.doCommand(HttpCommandProcessor.java:73) at com.thoughtworks.selenium.DefaultSelenium.click(DefaultSelenium.java:82) at org.apache.geronimo.testsuite.console.JMSResourcesTest.testNewJMSResource(JMSResourcesTest.java:47) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tomcat GBean names for valves
+1, this will help users wishing to customize their valve chain. Best wishes, Paul On Nov 5, 2007, at 4:19 PM, Joe Bohn wrote: Would anybody have a strong objection if I renamed the GBeans for the Tomcat valves from FirstValve and SecondValve to reflect the function of the valves themselves? FirstValve -- AccessLogValve SecondValve -- SingleSignOnValve Joe
Re: [DISCUSS] Release Devtools maven-plugins-1.0
On Oct 30, 2007, at 10:47 AM, Donald Woods wrote: Discussion thread for the maven-plugins-1.0 release... -Donald Will the scm info in these two poms be updated when you create the tag? https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/ branches/1.0/maven-emf-plugin/pom.xml https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/ branches/1.0/maven-eclipsepde-plugin/pom.xml Best wishes, Paul
Re: [jira] Commented: (GERONIMO-3300) Upgrade Dojo to 0.9
BTW, dojox.charting was missing from 0.9 but 1.0 includes it, refactored from 0.4 and now using the powerful dojox.gfx library. Best wishes, Paul On Nov 2, 2007, at 11:21 AM, Erik B. Craig wrote: Paul, Awesome plan! I've been tracking the improvements that have been going on with dojo since I started work on the monitoring project, and would be very excited to get 1.0 in for later use. -Erik Paul McMahan (JIRA) wrote: [ https://issues.apache.org/jira/browse/GERONIMO-3300? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12539609 ] Paul McMahan commented on GERONIMO-3300: Let's hold off on this until Dojo 1.0 is released. http://dojotoolkit.org/2007/11/02/dojo-1-0-release-candidate-1 Time permitting it would be great to get this into Geronimo 2.1. Since the new version of Dojo is not backwards compatible, and since existing apps like the admin console and the monitoring plugin use the Dojo 0.4 plugin, we should leave the current Dojo version in place alongside the new version. This could be accomplished by using different contexts as I described above. Upgrade Dojo to 0.9 --- Key: GERONIMO-3300 URL: https://issues.apache.org/jira/browse/ GERONIMO-3300 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh The new Dojo 0.9 Beta was just released. It will reduce the footprint of the main dojo.js to under 50k - But will require that some of the console screens to be reworked because the widget system was completely redesigned and is incompatible.
[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 0.9
[ https://issues.apache.org/jira/browse/GERONIMO-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539609 ] Paul McMahan commented on GERONIMO-3300: Let's hold off on this until Dojo 1.0 is released. http://dojotoolkit.org/2007/11/02/dojo-1-0-release-candidate-1 Time permitting it would be great to get this into Geronimo 2.1. Since the new version of Dojo is not backwards compatible, and since existing apps like the admin console and the monitoring plugin use the Dojo 0.4 plugin, we should leave the current Dojo version in place alongside the new version. This could be accomplished by using different contexts as I described above. Upgrade Dojo to 0.9 --- Key: GERONIMO-3300 URL: https://issues.apache.org/jira/browse/GERONIMO-3300 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh The new Dojo 0.9 Beta was just released. It will reduce the footprint of the main dojo.js to under 50k - But will require that some of the console screens to be reworked because the widget system was completely redesigned and is incompatible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Devtools maven-plugins-1.0 RC1
+1 On Oct 30, 2007, at 10:47 AM, Donald Woods wrote: The maven-plugins are build tools used by the Eclipse Plugin and J2G tools and are not included in either tool. A 72 hour vote is being called for the following: https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/ branches/1.0 Revision 590072 Binaries can be downloaded from: http://people.apache.org/~dwoods/releases/ maven-plugins-1.0-RC1-bin.tar.gz - files to be published maven-plugins-repo-1.0-RC1.tar.gz - captured build repo The source code will be moved to the following location in svn after the release has been approved: https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/ tags/1.0 Please record your vote by 11AM EDT Friday, Nov. 2, 2007. Thanks, Donald
Re: How to switch web service providers?
Why not use the plugins portlet in the admin console? From the admin console in tomcat6-jee5 I was able to stop the axis components and then install the cxf and cxf-deployer plugins from the online Geronimo plugin repository all within about a minute. Best wishes, Paul On Nov 2, 2007, at 12:26 PM, David Jencks wrote: I made the plugin system support the condition expressions we've been using to select a web service container but I can't see how to make it work usefully so I wonder if we need a new approach. Previously the conditions for axis2 and cxf we different in the jetty and tomcat servers, so cxf was on by default for jetty and axis2 for tomcat. However now these conditions are specified in the axis2 and cxf deployer plugins, so when installed they are going to be the same for jetty and tomcat. I guess we could come up with yet more complicated expressions that took into account whether we are on jetty or tomcat but this seems like its getting ridiculous and we need another way. Here are a few ideas. 1. More assemblies. I don't think anyone really wants this. 2. gshell commands to set the web service container. I guess we could run this on say the tomcat assembly to switch it to axis2 before we pack it up. Well, actually we could use this so we only ship one server and use such commands to turn it into a jetty or tomcat server. 3. gshell commands to remove sets of unneeded plugins: this would more permanently convert a server to axis2 or cxf only. However I think this is fairly appropriate. Again this could be used to get all non-framework servers out of one big distro. 4. gshell commands to download and install specific servers starting from framework. I'd actually like the gshell commands for 2,3,4 anyway but I'm wondering if any of them will actually provide a good solution for this problem. thoughts? Anyone have a better idea? thanks david jencks
Re: How to switch web service providers?
On Nov 2, 2007, at 1:32 PM, David Jencks wrote: On Nov 2, 2007, at 10:14 AM, Paul McMahan wrote: Why not use the plugins portlet in the admin console? From the admin console in tomcat6-jee5 I was able to stop the axis components and then install the cxf and cxf-deployer plugins from the online Geronimo plugin repository all within about a minute. I think this is related to my (4). I'm fine with shipping with only one web service framework per server but asking people to use the admin console and go through more than one step is too hard IMO. I agree that a gshell equivalent for this type of activity would be required for some types of users. Best wishes, Paul
Re: [DISCUSS/FEEDBACK] Usability improvements to Geronimo
On Nov 2, 2007, at 1:13 PM, Prasad Kashyap wrote: Can you be more specific here? What operations and how does a message make things any more dynamic? Is this a web console only concern or is it also a command line concern? Yes. Let me give you an example. Recently I was deploying a configuration. For a while the wheels turned and then I received an operation successful message. However, the deployment had spewn a boatload of stack traces to the geronimo.log file. In another example, the Websphere App Server shows informational messages as an app is being deployed. That is quite reassuring to an administrator. For now, this is a console-only concern. The console already provides this type of feedback while installing a plugin. Downloading JDBC drivers using the db wizard provides it as well. It should be pretty straightforward to use that same ajax widget to show progress info in the deployment portlet if that's desirable. I can't really think of any other console actions that take a non-trivial amount of time to complete. Maybe start/stop components in some cases. Best wishes, Paul
Re: [DISCUSS/FEEDBACK] Usability improvements to Geronimo
On Nov 2, 2007, at 1:35 PM, David Jencks wrote: Yes. Let me give you an example. Recently I was deploying a configuration. For a while the wheels turned and then I received an operation successful message. However, the deployment had spewn a boatload of stack traces to the geronimo.log file. In another example, the Websphere App Server shows informational messages as an app is being deployed. That is quite reassuring to an administrator. For now, this is a console-only concern. The console already provides this type of feedback while installing a plugin. Downloading JDBC drivers using the db wizard provides it as well. It should be pretty straightforward to use that same ajax widget to show progress info in the deployment portlet if that's desirable. I can't really think of any other console actions that take a non-trivial amount of time to complete. Maybe start/stop components in some cases. I think more important than dynamic feedback is accurate feedback on whether the operation failed. Maybe things have gotten better lately but my expectation honed through years of frustration is that to really find out if a console operation succeeded I have to look in the cli console or logs for the pages of stack trace that were suppressed in the admin console. Oh, well, you're right. The console does a poor job of surfacing error messages and diagnostic feedback in many cases. I would actually consider the lack of good error handling as a separate issue from progress info. Sorry if I am splitting hairs. Anyway, let's make sure that better error handling and diagnostic feedback is represented in some form on the list. Best wishes, Paul
[jira] Commented: (GERONIMO-3523) java.io.IOException: FULL head
[ https://issues.apache.org/jira/browse/GERONIMO-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539689 ] Paul McMahan commented on GERONIMO-3523: The two slashes '//' in the URL were a red herring. The problem is that when the console portlets process an action they persist their state in render parameters. When the action has completed pluto creates a URL that contains all of the render parameters and redirects the browser to it using response.sendredirect. The subsequent request header from the browser can get pretty big and overflow jetty's buffer. java.io.IOException: FULL head -- Key: GERONIMO-3523 URL: https://issues.apache.org/jira/browse/GERONIMO-3523 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.x Reporter: Jarek Gawor Assignee: Paul McMahan On Jetty the testsuite/console-testsuite/advanced tests usually fail with strange errors while the same works fine on Tomcat. On the server I see the following errors: 16:22:43,046 WARN [log] handle failed java.io.IOException: FULL head at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:276) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:201) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:331) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) The tests fail with different errors e.g. (it changes from run to run): testNewJMSResource(org.apache.geronimo.testsuite.console.JMSResourcesTest) Time elapsed: 7.86 sec FAILURE! com.thoughtworks.selenium.SeleniumException: ERROR: Element //[EMAIL PROTECTED]'Add Destination'] not found at com.thoughtworks.selenium.HttpCommandProcessor.doCommand(HttpCommandProcessor.java:73) at com.thoughtworks.selenium.DefaultSelenium.click(DefaultSelenium.java:82) at org.apache.geronimo.testsuite.console.JMSResourcesTest.testNewJMSResource(JMSResourcesTest.java:47) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
new Tomcat trunk
FYI -- the Tomcat team is planning to create a new trunk next week copied from the 6.0.15 tag. That tag includes the security fix for the Webdav servlet. IIUC they should also be agreeable to applying the annotation support patch developed by David Jencks and Remy to this new trunk, though we haven't discussed the exact timing of that yet. http://www.nabble.com/Time-to-organise-svn---Take-3-p13077171.html Best wishes, Paul
Re: [DISCUSS] 2.1 Release
On Nov 1, 2007, at 1:00 PM, Kevan Miller wrote: I think it's time to start discussing the particulars of a 2.1 release. There's been a lot of advancements made in our plugin infrastructure. There's also been the pluggable console enhancements. It would be good to get a release out, with these capabilities. They provide a more solid platform for future enhancements, I think. There are a lot of improvements to the plugin infrastructure in trunk. We have been using these new features internally for a while now which much success, so I agree it would be a great idea to get a new release into the hands of the user community for further testing and feedback. There's also GShell and new monitoring capabilities. I'm probably missing a few other new functions. I hope that monitoring can make it into 2.1. That stuff is really cool! Finally, IIUC, 2.1 would be able to support a Terracotta plugin. I'd also be very interested to hear what WADI capabilities that could be exposed. I'm willing to bang the release manager drum. I see that Joe has already started tugging on the TCK chain What do others think? How close are we to a 2.1 release? What additional capabilities and bug fixes are needed? Can we wrap up development activities in the next week or two? I think you summed things up pretty well. I'm still working on a few bug fixes but I think those can be wrapped up soon. Also I posted to the TCK list earlier today about a JSF issue that will need to be resolved. Best wishes, Paul
Re: Icons in web console disappeared
The JIRA for reenabling the icons in the admin console (GERONIMO-3562) can be completed if/when the Pluto team applies the patch attached to https://issues.apache.org/jira/browse/PLUTO-437 Best wishes, Paul On Oct 29, 2007, at 3:19 PM, Paul McMahan wrote: Icon support in the new admin console is not implemented yet. The early thoughts on this were to bundle the icons for the base console and the various extensions in their respective WAR files and pass the location of the icons to the portal driver thru the AdminConsoleExtensionGBean. I created https://issues.apache.org/jira/browse/GERONIMO-3562 Best wishes, Paul On Oct 27, 2007, at 1:38 PM, Jacek Laskowski wrote: Hi, What happened to the nice-looking icons next to administration menus in webconsole of 2.1-SNAPSHOT? They're in 2.0.2. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
On Oct 31, 2007, at 11:52 AM, Prasad Kashyap wrote: On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote: On Oct 27, 2007, at 11:32 AM, David Jencks wrote: The admin console needs to be lightweight and portable so it is based on Pluto. The Jetspeed MBE (as currently designed) would interfere with the deployment of admin console extensions. Adding something to the Geronimo plan to activate the Jetspeed MBE instead of just looking for a WEB-INF/portlet.xml sounds like a reasonable solution. Let's pursue that approach. +1 as I see many situations where the Pluto Admin Console will still be used even when Jetspeed or Liferay are installed. I haven't looked into exactly how the admin console plugins get added to the admin console but if they are geronimo plugins they have already gone through the deployment process and there is no chance for the jetspeed MBE to see them as the deployment machinery is not activated at all when a plugin is installed. I see your point. Limiting portal apps to installation via plugin would offer an advantage that developers can pick the appropriate MBEs at build time, giving them us (the MBE provider) fine grained control over every step in the deployment process. Isn't that a serious limitation ? We are forcing all portlet app developers to use maven and c-m-p. Most 3rd party developers would just want to build and deploy a portlet war and an associated geronimo plan. If the geronimo plan conveyed which portal and MBE to use, we don't have to have this limitation. Yes, I also think it is a serious limitation and I agree with your position that portlet apps should also be deployable as WARs. Technically speaking, though, requiring portlet apps to be predeployed via car-maven-plugin is an option that has some merit (such as the careful selection of MBEs as described by David) and IIUC the approach that was being advocated. While using MBEs has proven to be a very successful approach for deploying services and enterprise apps in Geronimo I am concerned that the lack of any standardization or a specification for deploying portal apps could make this difficult and fragile in the case of portlets. My observation has been that deployment into most portals (Liferay, Pluto, uPortal, and even Jetspeed itself) is based on the concept that the developer creates a standard WAR and uses the Portal's runtime or build-time utility for preprocessing it. Then the portal deploys the preprocessed WAR using the app server's standard deployment mechanism, or relies on the end user to do this. Can/should deployment of portlet into Geronimo be an extension of that process? I have been inclined to follow that approach so far but there may be disadvantages I haven't thought of. If the portal's runtime or built-time utility is preprocessing the WAR and deploying it to an appserver, then isn't the onus on them to deploy it accordingly for the appropriate appserver they support ? The portal can continue to have their own deployment mechanism while we can have ours, say in the form of plugins. This two-pronged approach should fill all gaps and cover all types of users. Yes, again I think that we are in agreement. IMHO the portal vendor should continue to be responsible for providing the end user interface for preprocessing the WAR (if necessary), and then handling deployment of the WAR into the app server or prompting the user to do it. This approach allows the portal's existing build-time and runtime deployment utilities to continue working as usual when the portal is running in Geronimo. But this is a major decision that will have long term effects wrt portal integration in Geronimo, so let's continue to look for feedback and direction on this matter. Best wishes, Paul
[jira] Resolved: (GERONIMO-2784) Samples cleanup
[ https://issues.apache.org/jira/browse/GERONIMO-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved GERONIMO-2784. Resolution: Fixed Fix Version/s: 2.1 deployed jsp-examples, servlet-examples, and ldap-sample to the snapshot repo updated the 2.1 plugin catalog Samples cleanup --- Key: GERONIMO-2784 URL: https://issues.apache.org/jira/browse/GERONIMO-2784 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: sample apps Affects Versions: 2.0-M3 Reporter: Paul McMahan Assignee: Paul McMahan Priority: Minor Fix For: 2.1 As discussed on dev: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200701.mbox/[EMAIL PROTECTED] # Move the following modules from server/trunk/applications to samples/trunk ** demo (security demo) ** geronimo-examples ** geronimo-ldap-demo ** magicGball # Move anything worth keeping from server/trunk/applications/daytrader to daytrader/trunk # Remove the configs for these modules from server/trunk/configs # Enable samples/trunk to build CARs so that the samples can be installed as plugins # Publish the CARs built in samples/trunk to a maven repo # Update the plugin catalog at site/trunk/plugins/ to reference the samples in maven repo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: J2G future positioning
I'm not in favor of generalizing the J2G Eclipse plugin into a super migrator that grows in complexity as we incorporate new types of source formats. I think that instead we should look into factoring out the parts of J2G that could be used for other types migrators into a separate Eclipse plugin. Then J2G could remain as J2G but could prereq this new Eclipse plugin, as would any other new migrators we create. Best wishes, Paul On Oct 29, 2007, at 11:32 AM, Tim McConnell wrote: Hi, Does anyone have any thoughts as to how we'll position the J2G plugin in the future ?? I understand now that in its initial iteration that it is narrowly scoped to work for JBoss specific migrations only (thus the JBoss in the name). However, it seems if we want to eventually enhance it as a more generic tool for migrating multiple applications to Geronimo (which I would hope we would), it might be a good time now to reconsider a more generic and/or appropriate name. Any thoughts ?? -- Thanks, Tim McConnell
Re: Restructuring build for flexible server
On Oct 29, 2007, at 3:47 PM, Prasad Kashyap wrote: With the latest commit to sandbox, I have all the artifacts building successfully. We have good assemblies too. Tthe groupId and artifactId of all the artifacts have essentially remained the same. I noticed that the groupIds in the poms don't always match their placement in the svn directory structure. Is the intention to keep things this way? For example: https://svn.apache.org/repos/asf/geronimo/sandbox/restructure/ plugins/cxf/cxf/pom.xml Also I'm curious what qualifies a subproject as belonging under plugins, applications, components, configs, or modules . Currently it's arranged as: applications: # ca-helper/ # geronimo-uddi-db/ # mejb/ # remote-deploy/ # sharedlib/ # uddi-server/ # welcome/ components: # spring/ # transformer-agent/ # upgrade/ framework/configs: # client-system/ # geronimo-gbean-deployer/ # geronimo-gbean-deployer-bootstrap/ # j2ee-security/ # j2ee-system/ # jee-specs/ # jsr88-cli/ # jsr88-deploymentfactory/ # offline-deployer/ # online-deployer/ # rmi-naming/ # server-security-config/ # shutdown/ # upgrade-cli/ # xmlbeans/ framework/modules: # geronimo-cli/ # geronimo-commands/ # geronimo-common/ # geronimo-core/ # geronimo-deploy-config/ # geronimo-deploy-jsr88/ # geronimo-deploy-jsr88-bootstrapper/ # geronimo-deploy-tool/ # geronimo-deployment/ # geronimo-interceptor/ # geronimo-j2ee/ # geronimo-jdbc/ # geronimo-jmx-remoting/ # geronimo-kernel/ # geronimo-management/ # geronimo-naming/ # geronimo-security/ # geronimo-service-builder/ # geronimo-system/ # geronimo-transformer/ # geronimo-upgrade/ # geronimo-util/ plugins: # activemq/ # axis/ # axis2/ # client/ # clustering/ # connector/ # console/ # corba/ # cxf/ # debugviews/ # dojo/ # hotdeploy/ # j2ee/ # jasper/ # javamail/ # jaxws/ # jetty/ # myfaces/ # openejb/ # openjpa/ # plancreator/ # pluto/ # system-database/ # tomcat/ # webservices/ Best wishes, Paul
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
On Oct 28, 2007, at 3:22 PM, Donald Woods wrote: Any thoughts on setting up automated builds of Samples at least once a week? That would be helpful. Now that we have catalog support in car-maven- plugin we could also automatically update the online plugins catalog as well. This would require some coordination around building server/ trunk and samples/trunk.Basically: 1.) build server/trunk 2.) build samples/trunk 3.) run a script on ~/.m2/repository/geronimo-plugins.xml to remove references to the local repo 4.) svn commit site/trunk/docs/plugins/geronimo-x.x/geronimo- plugins.xml I can help with a perl script for #3 if someone more savvy with build automation wants to look further into this. One other question -- should we try to have parity between what's in samples/trunk and what's in the samples section of the wiki? Are there barriers, technical or otherwise, that make this difficult? http://cwiki.apache.org/GMOxSAMPLES/index.html http://svn.apache.org/repos/asf/geronimo/samples/trunk/ Best wishes, Paul
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
On Oct 27, 2007, at 11:32 AM, David Jencks wrote: The admin console needs to be lightweight and portable so it is based on Pluto. The Jetspeed MBE (as currently designed) would interfere with the deployment of admin console extensions. Adding something to the Geronimo plan to activate the Jetspeed MBE instead of just looking for a WEB-INF/portlet.xml sounds like a reasonable solution. Let's pursue that approach. +1 as I see many situations where the Pluto Admin Console will still be used even when Jetspeed or Liferay are installed. I haven't looked into exactly how the admin console plugins get added to the admin console but if they are geronimo plugins they have already gone through the deployment process and there is no chance for the jetspeed MBE to see them as the deployment machinery is not activated at all when a plugin is installed. I see your point. Limiting portal apps to installation via plugin would offer an advantage that developers can pick the appropriate MBEs at build time, giving them us (the MBE provider) fine grained control over every step in the deployment process. While using MBEs has proven to be a very successful approach for deploying services and enterprise apps in Geronimo I am concerned that the lack of any standardization or a specification for deploying portal apps could make this difficult and fragile in the case of portlets. My observation has been that deployment into most portals (Liferay, Pluto, uPortal, and even Jetspeed itself) is based on the concept that the developer creates a standard WAR and uses the Portal's runtime or build-time utility for preprocessing it. Then the portal deploys the preprocessed WAR using the app server's standard deployment mechanism, or relies on the end user to do this. Can/should deployment of portlet into Geronimo be an extension of that process? I have been inclined to follow that approach so far but there may be disadvantages I haven't thought of. BTW, I have started using the term console extension instead of console plugin because adding portlets to the admin console doesn't currently require them to be packaged as plugins.A console extension can be installed as a plugin or it could be deployed like any other ordinary WAR. I hope most developers will offer their console extensions as plugins because they are easier for end users to browse and install. But I think the latter option (deploying console extensions as a WAR) will be important to developers that don't want to create plugins for reasons such as the reliance on maven to build them, the sensitivity of plugins to Geronimo server versions, etc. Best wishes, Paul
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
When I mentioned parity between svn and the wiki I really meant to stress the same stuff showing both locations, which I think Jarek's suggestion would help achieve.Another idea would be to build and deploy the samples using maven. Then we could point the wiki page at the maven repo for both the compiled binary and for the source.zip (which is automatically created by maven). Best wishes, Paul On Oct 29, 2007, at 2:12 PM, Jarek Gawor wrote: Binary files in wiki and source in svn? That works for me. Jarek On 10/29/07, Erik B. Craig [EMAIL PROTECTED] wrote: Prasad, I have put some thought into this myself and agree with you. It would be too much of a hassle for users, I think, if they have to download subversion and maven along with the sample app, and THEN compile it before attempting to deploy it. Probably the best thing would be to have 'releases' or snapshots of the sample apps up on the wiki, along with the source being in the subversion repo. -Erik Prasad Kashyap wrote: While a part of me seems to agree with you that we should remove the zip file from the samples' wiki pages, a greater part of me feels that we may be forcing some our users to now get SVN. A user who just downloads and installs from a binary server will have no need for svn. But just to get to the samples, he now has to get SVN. Then he has to get maven to play with the samples. So we are making him jump thro' many hoops just to see our prized samples. Hmm.. Cheers Prasad On 10/29/07, Jarek Gawor [EMAIL PROTECTED] wrote: On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote: One other question -- should we try to have parity between what's in samples/trunk and what's in the samples section of the wiki? Are there barriers, technical or otherwise, that make this difficult? http://cwiki.apache.org/GMOxSAMPLES/index.html http://svn.apache.org/repos/asf/geronimo/samples/trunk/ Yes, definitely. That was the goal for 2.0 samples at least. The wiki documentation should be up to date (expect the artifact version) and all the code in wiki should be in the samples svn. If anything, I would like to remove the attached sample .zip files from the wiki and instead direct the users to checkout the sample code from svn. Also, I think we should release samples at the same time (or close to) when we release Geronimo. Jarek
Re: Icons in web console disappeared
Icon support in the new admin console is not implemented yet. The early thoughts on this were to bundle the icons for the base console and the various extensions in their respective WAR files and pass the location of the icons to the portal driver thru the AdminConsoleExtensionGBean. I created https://issues.apache.org/jira/browse/GERONIMO-3562 Best wishes, Paul On Oct 27, 2007, at 1:38 PM, Jacek Laskowski wrote: Hi, What happened to the nice-looking icons next to administration menus in webconsole of 2.1-SNAPSHOT? They're in 2.0.2. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Created: (GERONIMO-3562) customizable navigator icons for admin console extensions
customizable navigator icons for admin console extensions
-
Key: GERONIMO-3562
URL: https://issues.apache.org/jira/browse/GERONIMO-3562
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: console
Affects Versions: 2.1
Reporter: Paul McMahan
The extensible admin console console should support customizable icons for the
navigator items. One way to implement this would be to enhance the gbean
definition like:
{code:xml}
gbean name=MyConsoleExtension
class=org.apache.geronimo.pluto.AdminConsoleExtensionGBean
attribute name=pageTitleApplications/My Console
Extension/attribute
attribute name=portletContext/my-console-extension/attribute
attribute name=portletList[MyPortlet]/attribute
attribute name=iconimages/myicon.png/attribute!--- new
attribute for icon --
/gbean
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
This jetspeed integration is coming along nicely! Very promising work. Instead of introducing a MBE that automatically configures the webapp for jetspeed based on the presence of WEB-INF/portlet.xml can we look into allowing jetspeed to handle its own deployment via placement in its hot deploy directory? When a war is placed in that directory jetspeed processes the portlets internally and then handles deploying the war to the app server. i.e. the portal recognizes the WAR as a special kind of app and handles the extra deployment steps, not the application server. I have a hunch that trying reverse that paradigm or somehow wrapper the deployment responsibilities of jetspeed from within an MBE could prove to be confusing to jetspeed users, difficult to implement correctly, and very sensitive to the jetspeed version. And like Donald pointed out it would interfere with other portal apps that might be deployed in Geronimo like Liferay, uPortal, Pluto (the admin console), etc. Best wishes, Paul On Oct 26, 2007, at 7:37 AM, Donald Woods wrote: Can this plugin coexist with the Pluto Admin portal in 2.1? Now that the Jetspeed plugin has a JetspeedModuleBuilderExtension.java which handles any webmodule with WEB-INF/portlet.xml as its own, how can we deploy Admin portlets to Pluto vs. user portlets to Jetspeed? Or is this meant only as a complete replacement of Pluto for users who want a full featured Portal? -Donald
Re: time to remove old plan files?
+1, they have already caused some confusion in at least one situation. Best wishes, Paul On Oct 26, 2007, at 2:07 PM, Jarek Gawor wrote: Is it time to remove the old/unused plan files from trunk? I mean the plan files in configs/module/src/plan/plan.xml. They have been replaced by plans in configs/module/src/main/plan/plan.xml. Jarek
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
On Oct 26, 2007, at 12:55 PM, David Jencks wrote: On Oct 26, 2007, at 9:34 AM, Paul McMahan wrote: This jetspeed integration is coming along nicely! Very promising work. Instead of introducing a MBE that automatically configures the webapp for jetspeed based on the presence of WEB-INF/portlet.xml can we look into allowing jetspeed to handle its own deployment via placement in its hot deploy directory? When a war is placed in that directory jetspeed processes the portlets internally and then handles deploying the war to the app server. i.e. the portal recognizes the WAR as a special kind of app and handles the extra deployment steps, not the application server. I think that what Prasad is doing is a better way :-) (which is why I suggested it). How would a portlet app plugin work with hot deploy? imho magic hot deploy directories are really out of line with the whole geronimo modularity philosophy and I would support removing the hot deploy functionality we have (well, I know that wont happen, but I'd still support it). I really didn't mean to focus on the issue of hot vs. cold deployment. I'm mainly wondering whether or not, in general, Geronimo should try to encapsulate or otherwise replace Jetspeed's deployment functionality. In addition to hot deploy, Jetspeed also provides a pretty complete maven plugin for managing the portal and deploying portlet applications. I bet it also provides some type of admin UI for deploying portlet applications. As a Jetspeed user I would expect the existing deployment mechanisms to all continue working in Geronimo. As a Geronimo developer I would like to take advantage of Jetspeed's deployment functionality as much as possible and avoid sensitivities to changes in their architecture going forward. Utilizing Jetspeed's hot deploy directory is only one idea for how to accomplish these goals, maybe not the best one. OTOH, using a MBE to subvert Jetspeed's normal deployment processes seems contrary to those goals. But maybe I am misunderstanding how you suggested to implement this. I was hoping that the pluto portlet app deployment would work in the same way with an MBE. While the portlet spec is pretty complete for application design there currently is no specification for deployment within a portal. In the absence of a spec Pluto implemented deployment in a pretty clever way that is heavily based on standard webapp deployment and therefore very portable across servlet containers without extra configuration. So an MBE for Pluto isn't necessarily required, but I can see where a MBE for translating portlet.xml entries into web.xml might be helpful (GERONIMO-3252). Meanwhile there is a Maven plugin for that. I have a hunch that trying reverse that paradigm or somehow wrapper the deployment responsibilities of jetspeed from within an MBE could prove to be confusing to jetspeed users, difficult to implement correctly, and very sensitive to the jetspeed version. And like Donald pointed out it would interfere with other portal apps that might be deployed in Geronimo like Liferay, uPortal, Pluto (the admin console), etc. I think we should look into selecting the portal to deploy to based on something in the geronimo plan if we really need to support multiple portals running at once. If we don't, building a portlet app into a plugin for a specific portal could be handled by specifying the desired portal MBE car in the plugin's pom. The admin console needs to be lightweight and portable so it is based on Pluto. The Jetspeed MBE (as currently designed) would interfere with the deployment of admin console extensions. Adding something to the Geronimo plan to activate the Jetspeed MBE instead of just looking for a WEB-INF/portlet.xml sounds like a reasonable solution. Let's pursue that approach. Maybe it's unavoidable, but if possible I hope we can avoid creating plugins that are sensitive to the Portal vendor. e.g. for one portal app I hope we don't require four plugins: myapp-jetty-jetspeed myapp-jetty-pluto myapp-tomcat-jetspeed myapp-tomcat-pluto Best wishes, Paul
[jira] Assigned: (GERONIMO-2784) Samples cleanup
[ https://issues.apache.org/jira/browse/GERONIMO-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan reassigned GERONIMO-2784: -- Assignee: Paul McMahan (was: Jarek Gawor) Thanks Jarek I will help with steps 5 and 6. Step 5 (publishing snapshots of new artifacts) requires PMC approval via lazy consensus. I will start that thread on dev. Samples cleanup --- Key: GERONIMO-2784 URL: https://issues.apache.org/jira/browse/GERONIMO-2784 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: sample apps Affects Versions: 2.0-M3 Reporter: Paul McMahan Assignee: Paul McMahan Priority: Minor As discussed on dev: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200701.mbox/[EMAIL PROTECTED] # Move the following modules from server/trunk/applications to samples/trunk ** demo (security demo) ** geronimo-examples ** geronimo-ldap-demo ** magicGball # Move anything worth keeping from server/trunk/applications/daytrader to daytrader/trunk # Remove the configs for these modules from server/trunk/configs # Enable samples/trunk to build CARs so that the samples can be installed as plugins # Publish the CARs built in samples/trunk to a maven repo # Update the plugin catalog at site/trunk/plugins/ to reference the samples in maven repo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Promoting GShell to a real subproject
Makes sense to me. +1 for gshell as a subproject. Best wishes, Paul On Oct 26, 2007, at 1:58 PM, Kevan Miller wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan
deploying snapshots of the samples to a new location in m2-snapshot-repo
Jarek helped on GERONIMO-2784 by moving the samples from server/trunk to samples/trunk. Now I would like to deploy those samples to the ASF snapshot repo so they can still be downloaded/installed from Geronimo's plugin catalog.This notification starts a 3 day lazy consensus timer for the PMC before I will deploy the snapshots to their new location in the ASF snapshot repo.Up until now the samples have been voted on and deployed concurrently with the server.See the JIRA for details. https://issues.apache.org/jira/browse/GERONIMO-2784 Best wishes, Paul
Re: GShell as main starting component for 2.1
GShell is awesome, let's make it the default. Best wishes, Paul On Oct 25, 2007, at 2:56 PM, Jeff Genender wrote: Title says it all...I'd really like to see gshell as the default execution for Geronimo 2.1. Any objectsions? Jason, is this something you can get going? Jeff
[jira] Resolved: (GERONIMO-3351) Plugin installer downloads a different version of dependecy than the one specified
[ https://issues.apache.org/jira/browse/GERONIMO-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved GERONIMO-3351. Resolution: Fixed Fix Version/s: (was: 2.0.x) Plugin installer downloads a different version of dependecy than the one specified -- Key: GERONIMO-3351 URL: https://issues.apache.org/jira/browse/GERONIMO-3351 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0, 2.0.x, 2.1 Environment: G 2.0 Tomcat (should be applicable to G 2.0 Jetty as well) Reporter: Vamsavardhana Reddy Assignee: Paul McMahan Fix For: 2.1 Plugin installer downloads a different version of dependecy than the one specified. A scenario below: I am trying to install a plugin which has a dependency on commonj/sdo-api-r2.1/1.0-incubating-SNAPSHOT/jar. During the stage at which the depedency jar are downloaded, I see the following: Searching for commonj/sdo- api-r2.1/1.0-incubating-SNAPSHOT/jar at http://people.apache.org/repo/m2-incubating-repository Downloading commonj/sdo-api-r2.1/1.0-incubating-beta1/jar... Notice that the version it is supposed to download (this is the same version specified in geronimo-plugin.xml) and the one it is actually downloading are different. The plugin is failing to start and is throwing an exception with reason: Unable to resolve dependency commonj/sdo- api-r2.1/1.0-incubating-SNAPSHOT/jar. A discussion thread on dev-list is at http://www.mail-archive.com/dev@geronimo.apache.org/msg48842.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3523) java.io.IOException: FULL head
[ https://issues.apache.org/jira/browse/GERONIMO-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan reassigned GERONIMO-3523: -- Assignee: Paul McMahan I think this is caused by the pluto actionurl tag creating a URL that contains two slashes '//'. When the browser posts to a URL like that the servlet engine 302's the request to a normalized URL, but it's a GET request the second time around with all the form inputs appended to the URL. i.e. the URL can get huge and exceed the servlet engine's internal buffers java.io.IOException: FULL head -- Key: GERONIMO-3523 URL: https://issues.apache.org/jira/browse/GERONIMO-3523 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.x Reporter: Jarek Gawor Assignee: Paul McMahan On Jetty the testsuite/console-testsuite/advanced tests usually fail with strange errors while the same works fine on Tomcat. On the server I see the following errors: 16:22:43,046 WARN [log] handle failed java.io.IOException: FULL head at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:276) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:201) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:331) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) The tests fail with different errors e.g. (it changes from run to run): testNewJMSResource(org.apache.geronimo.testsuite.console.JMSResourcesTest) Time elapsed: 7.86 sec FAILURE! com.thoughtworks.selenium.SeleniumException: ERROR: Element //[EMAIL PROTECTED]'Add Destination'] not found at com.thoughtworks.selenium.HttpCommandProcessor.doCommand(HttpCommandProcessor.java:73) at com.thoughtworks.selenium.DefaultSelenium.click(DefaultSelenium.java:82) at org.apache.geronimo.testsuite.console.JMSResourcesTest.testNewJMSResource(JMSResourcesTest.java:47) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
[
https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536355
]
pmcmahan edited comment on GERONIMO-3451 at 10/22/07 8:18 AM:
--
It's not clear to me that this error message is actually harmless. Tomcat uses
RestrictedServlet.properties and RestrictedFilters.properties files as a sort
of internalized/proprietary security mechanism to limit access to certain types
of servlets and filters. The instance manager patch that is applied to
Geronimo's build of tomcat (see GERONIMO-3010 and GERONIMO-3206) introduced a
new type of security check in DefaultInstanceManager for restricted Listeners :
{code:title=DefaultInstanceManager.java|borderStyle=solid}
private void checkAccess(Class clazz)
{
if(privileged)
return;
if(clazz.isAssignableFrom(javax/servlet/Filter))
checkAccess(clazz, restrictedFilters);
else
if(clazz.isAssignableFrom(javax/servlet/Servlet))
checkAccess(clazz, restrictedServlets);
else
checkAccess(clazz, restrictedListeners);
}
{code}
However, that class also has a bug in the place where the
RestrictedListeners.properties is read in, adding its contents to the
restrictedFilters list instead of the restrictedListeners list :
{code:title=DefaultInstanceManager.java|borderStyle=solid}
java.io.InputStream is =
getClass().getClassLoader().getResourceAsStream(org/apache/catalina/core/RestrictedListeners.properties);
if(is != null)
*restrictedFilters.load(is);* // should be
restrictedListeners.load(is)
else
catalinaContext.getLogger().error(sm.getString(defaultInstanceManager.restrictedListenersResources));
{code}
So addressing this issue will involve :
# determine if the DefaultInstanceManager really needs to check for restricted
listeners
# if so, determine which listeners should be restricted (what to put in the
RestrictedListeners.properties)
# add RestrictedListeners.properties to Geronimo's catalina.jar
# fix the bug in DefaultInstanceManager mentioned above
was (Author: pmcmahan):
It's not clear to me that this error message is actually harmless. Tomcat
uses RestrictedServlet.properties and RestrictedFilters.properties files as a
sort of internalized/proprietary security mechanism to limit access to certain
types of servlets and filters. The instance manager patch that is applied to
Geronimo's build of tomcat (see GERONIMO-3010 and GERONIMO-3206) introduced a
new type of security check in DefaultInstanceManager for restricted Listeners :
{{
private void checkAccess(Class clazz)
{
if(privileged)
return;
if(clazz.isAssignableFrom(javax/servlet/Filter))
checkAccess(clazz, restrictedFilters);
else
if(clazz.isAssignableFrom(javax/servlet/Servlet))
checkAccess(clazz, restrictedServlets);
else
checkAccess(clazz, restrictedListeners);
}
}}
However, that class also has a bug in the place where the
RestrictedListeners.properties is read in, adding its contents to the
restrictedFilters list instead of the restrictedListeners list.
{{
java.io.InputStream is =
getClass().getClassLoader().getResourceAsStream(org/apache/catalina/core/RestrictedListeners.properties);
if(is != null)
*restrictedFilters.load(is);*
else
catalinaContext.getLogger().error(sm.getString(defaultInstanceManager.restrictedListenersResources));
}}
So addressing this issue will involve :
# determine if the DefaultInstanceManager really needs to check for restricted
listeners
# if so, determine which listeners should be restricted (what to put in the
RestrictedListeners.properties)
# add RestrictedListeners.properties to Geronimo's catalina.jar
# fix the bug in DefaultInstanceManager mentioned above
Restricted listeners property file not found error logged during Tomcat
server startup
Key: GERONIMO-3451
URL: https://issues.apache.org/jira/browse/GERONIMO-3451
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Affects Versions: 2.0, 2.0.x
Reporter: Kevan Miller
Fix For: 2.0.x
During Tomcat server startup, the following log error is displayed on the
console:
12:57:32,559 ERROR [[/]] Restricted listeners property file not found
Althgough the log message can be ignored, users assume that something is
broken...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
[
https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536355
]
Paul McMahan commented on GERONIMO-3451:
It's not clear to me that this error message is actually harmless. Tomcat uses
RestrictedServlet.properties and RestrictedFilters.properties files as a sort
of internalized/proprietary security mechanism to limit access to certain types
of servlets and filters. The instance manager patch that is applied to
Geronimo's build of tomcat (see GERONIMO-3010 and GERONIMO-3206) introduced a
new type of security check in DefaultInstanceManager for restricted Listeners :
{{
private void checkAccess(Class clazz)
{
if(privileged)
return;
if(clazz.isAssignableFrom(javax/servlet/Filter))
checkAccess(clazz, restrictedFilters);
else
if(clazz.isAssignableFrom(javax/servlet/Servlet))
checkAccess(clazz, restrictedServlets);
else
checkAccess(clazz, restrictedListeners);
}
}}
However, that class also has a bug in the place where the
RestrictedListeners.properties is read in, adding its contents to the
restrictedFilters list instead of the restrictedListeners list.
{{
java.io.InputStream is =
getClass().getClassLoader().getResourceAsStream(org/apache/catalina/core/RestrictedListeners.properties);
if(is != null)
*restrictedFilters.load(is);*
else
catalinaContext.getLogger().error(sm.getString(defaultInstanceManager.restrictedListenersResources));
}}
So addressing this issue will involve :
# determine if the DefaultInstanceManager really needs to check for restricted
listeners
# if so, determine which listeners should be restricted (what to put in the
RestrictedListeners.properties)
# add RestrictedListeners.properties to Geronimo's catalina.jar
# fix the bug in DefaultInstanceManager mentioned above
Restricted listeners property file not found error logged during Tomcat
server startup
Key: GERONIMO-3451
URL: https://issues.apache.org/jira/browse/GERONIMO-3451
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Affects Versions: 2.0, 2.0.x
Reporter: Kevan Miller
Fix For: 2.0.x
During Tomcat server startup, the following log error is displayed on the
console:
12:57:32,559 ERROR [[/]] Restricted listeners property file not found
Althgough the log message can be ignored, users assume that something is
broken...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3393) scrub the attribute lists for tomcat connector gbeans
[ https://issues.apache.org/jira/browse/GERONIMO-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-3393. -- Resolution: Fixed scrub the attribute lists for tomcat connector gbeans - Key: GERONIMO-3393 URL: https://issues.apache.org/jira/browse/GERONIMO-3393 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0.x Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.1 The list of attributes for tomcat connectors defined in TomcatManagerImpl should match Tomcat's online documentation as much as possible. The default values and descriptions are a little out of synch. HTTP : http://tomcat.apache.org/tomcat-6.0-doc/config/http.html AJP : http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html APR: http://tomcat.apache.org/tomcat-6.0-doc/apr.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3393) scrub the attribute lists for tomcat connector gbeans
[ https://issues.apache.org/jira/browse/GERONIMO-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated GERONIMO-3393: --- Description: The list of attributes for tomcat connectors defined in TomcatManagerImpl should match Tomcat's online documentation as much as possible. The default values and descriptions are a little out of synch. HTTP : http://tomcat.apache.org/tomcat-6.0-doc/config/http.html AJP : http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html APR: http://tomcat.apache.org/tomcat-6.0-doc/apr.html was: The list of attributes for tomcat connectors defined in TomcatManagerImpl should match Tomcat's online documentation as much as possible. The default values and descriptions are a little out of synch. HTTP : http://tomcat.apache.org/tomcat-6.0-doc/config/http.html AJP : http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html Fix Version/s: 2.1 scrub the attribute lists for tomcat connector gbeans - Key: GERONIMO-3393 URL: https://issues.apache.org/jira/browse/GERONIMO-3393 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0.x Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.1 The list of attributes for tomcat connectors defined in TomcatManagerImpl should match Tomcat's online documentation as much as possible. The default values and descriptions are a little out of synch. HTTP : http://tomcat.apache.org/tomcat-6.0-doc/config/http.html AJP : http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html APR: http://tomcat.apache.org/tomcat-6.0-doc/apr.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3393) scrub the attribute lists for tomcat connector gbeans
[ https://issues.apache.org/jira/browse/GERONIMO-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan reassigned GERONIMO-3393: -- Assignee: Paul McMahan scrub the attribute lists for tomcat connector gbeans - Key: GERONIMO-3393 URL: https://issues.apache.org/jira/browse/GERONIMO-3393 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0.x Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.1 The list of attributes for tomcat connectors defined in TomcatManagerImpl should match Tomcat's online documentation as much as possible. The default values and descriptions are a little out of synch. HTTP : http://tomcat.apache.org/tomcat-6.0-doc/config/http.html AJP : http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3516) Replace the administration console with the new extensible version
[ https://issues.apache.org/jira/browse/GERONIMO-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-3516. -- Resolution: Fixed Replace the administration console with the new extensible version -- Key: GERONIMO-3516 URL: https://issues.apache.org/jira/browse/GERONIMO-3516 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console, Plugins Affects Versions: 2.1 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.1 Delete the administration console in applications/console and use the new version from plugins/console -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3509) copy the extensible administration console plugin into the server project
[ https://issues.apache.org/jira/browse/GERONIMO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-3509. -- Resolution: Fixed copy the extensible administration console plugin into the server project - Key: GERONIMO-3509 URL: https://issues.apache.org/jira/browse/GERONIMO-3509 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: console, Plugins Affects Versions: 2.1 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.1 The extensible admin console and the various extensions for it are in separate maven projects and in separate areas of SVN from the server. The process for building server assemblies currently requires all the plugins to be within the same parent maven project. Based on that limitation the console and extensions need to be copied into the server project. If/when the build and assemble process can be enhanced to span multiple top level maven projects they can be moved back out into separate projects. For background discussion see: http://www.nabble.com/Plugin-installer-in-trunk-broke--tf4533623s134.html#a13042533 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Geronimo 2.0.2 (rc1)
+1 On Oct 12, 2007, at 9:57 PM, Kevan Miller wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/ jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/ ~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/ geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https:// svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https:// svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan
Re: [VOTE] Release geronimo-txmanager 2.0.2
+1 On Oct 10, 2007, at 1:42 AM, Kevan Miller wrote: As discussed in the Geronimo 2.0.2 release discussion thread, we need to release geronimo-txmanager 2.0.2 to pick up fixes for the Geronimo 2.0.2 release. geronimo-txmanager contains the geronimo- transaction and geronimo-connector components. The proposed binary release artifacts can be found here -- http:// people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2.zip Your can browse these artifacts here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2/ The source for the release is currently here -- https:// svn.apache.org/repos/asf/geronimo/components/txmanager/branches/2.0.2 Once released, I'll tag this source as -- https://svn.apache.org/ repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager- parent-2.0.2 For your convenience, a zip file containing this source is here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2-src.zip A RAT report for this source is here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2-rat.txt Please vote on this release. [ ] +1 Release geronimo-txmanager 2.0.2 [ ] 0 No opinion [ ] -1 Do not release geronimo-txmanager 2.0.2 Barring any problems or ongoing discussions, I'll plan on calling the vote at 8 AM (EDT) on Saturday October 13. --kevan
Re: Make useMavenDependencies default true ?
On Oct 10, 2007, at 2:26 AM, David Jencks wrote: 0. As at present, any dependency in the c-m-p config must already be in the pom dependencies. 1. All the (compile, runtime) scoped maven dependencies in the pom turn into plan dependencies and geronimo-plugin.xml dependencies 2. Unless overridden the import type is all 3. For other import types or other customization a dependency can be mentioned in the c-m-p config in the pom. #1-3 look right on. I'm wondering if #0 is really necessary and desirable. For example, if I create plugin1 that needs a service type dependency against plugin2 then the pom could look like: project artifactIdplugin1/artifactId dependencies // a reference to plugin2 is not desirable here, don't // want maven processing it as a build time dep or // including its classes in the environment inherited // by car-maven-plugin /dependencies build plugin artifactIdcar-maven-plugin/artifactId configuration dependency artifactIdplugin2/artifactId importservice/import /dependency /configuration /plugin /build /project Best wishes, Paul
Re: Make useMavenDependencies default true ?
On Oct 10, 2007, at 11:50 AM, David Jencks wrote: project artifactIdplugin1/artifactId dependencies // a reference to plugin2 is not desirable here, don't // want maven processing it as a build time dep or // including its classes in the environment inherited // by car-maven-plugin /dependencies build plugin artifactIdcar-maven-plugin/artifactId configuration dependency artifactIdplugin2/artifactId importservice/import /dependency /configuration /plugin /build /project #0 is necessary to help maven build the modules in a correct order. I believe we have successfully written the c-m-p so the maven dependencies have no effect on the c-m-p environment, only on the configuration that the c-m-p is compiling . Basically the c- m-p fires up a small geronimo instance, and the root classloader of that geronimo instance is the root maven classloader, without any of the maven dependencies in it. Then we load dependencies of the module we are constructing into this geronimo instance just like a standalone geronimo server does. So, the only effect these maven dependencies have is to assure build order and to contribute to the geronimo module classloader according to the rules above. make sense? Yes, makes sense. I didn't realize that the c-m-p was intended to behave that way because of a problem I was having using importservices/import in the c-m-p configuration section. When I included a reference to plugin2 in the main dependency section the gbean deployer invoked by the c-m-p was still trying to include plugin2's dependencies even though I overrode that dependency with importservices/import in the c-m-p's configuration section (like shown above). That might actually be a problem with the kernel's handling of service type deps though and it just surfaced to me through the c-m-p. Best wishes, Paul
Re: Make useMavenDependencies default true ?
On Oct 10, 2007, at 3:32 PM, David Jencks wrote: Indeed it might. AFAIK no one has found an actual use for importservice/import dependencies before could I inquire what use you found for it and how you avoided class cast exceptions? I looked into to using it to enforce module startup order.The console should startup before any console extensions because the console listens for extensions being added to its navigator. But those extensions should not (necessarily) inherit the console's classloader, especially since the console uses spring for configuring the pluto internals. The services dependency type didn't work as I had expected while using the c-m-p so I never actually used it in a server to see any class cast exceptions. Best wishes, Paul
[jira] Created: (GERONIMO-3521) plugin catalog for 2.0.2
plugin catalog for 2.0.2 Key: GERONIMO-3521 URL: https://issues.apache.org/jira/browse/GERONIMO-3521 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: Plugins Affects Versions: 2.0.2 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.0.2 Attachments: GERONIMO-3521.patch create a plugin catalog for geronimo 2.0.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3521) plugin catalog for 2.0.2
[ https://issues.apache.org/jira/browse/GERONIMO-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated GERONIMO-3521: --- Attachment: GERONIMO-3521.patch plugin catalog for 2.0.2 Key: GERONIMO-3521 URL: https://issues.apache.org/jira/browse/GERONIMO-3521 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0.2 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.0.2 Attachments: GERONIMO-3521.patch create a plugin catalog for geronimo 2.0.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3521) plugin catalog for 2.0.2
[ https://issues.apache.org/jira/browse/GERONIMO-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-3521. -- Resolution: Fixed plugin catalog for 2.0.2 Key: GERONIMO-3521 URL: https://issues.apache.org/jira/browse/GERONIMO-3521 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0.2 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.0.2 Attachments: GERONIMO-3521.patch create a plugin catalog for geronimo 2.0.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3413) factor the console portlets into separate plugins
[ https://issues.apache.org/jira/browse/GERONIMO-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-3413. -- Resolution: Fixed console plugins available in SVN at /repos/asf/geronimo/plugins factor the console portlets into separate plugins - Key: GERONIMO-3413 URL: https://issues.apache.org/jira/browse/GERONIMO-3413 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.1 Attachments: geronimo-3413.patch The administration console contains portlets for configuring the components in a JEE5 server, and a few more things like debugging, creating deployment plans, etc. Right now the collection of portlets is hard coded in the console's pluto configuration. This makes it difficult for users to choose which portlets they want in their console. For example some users may not want the various classloader/dependency/JMX/LDAP/etc viewers because they require the dojo library, which adds a non-trivial server footprint. But more importantly this makes it difficult to deploy the administration console into a customized geronimo assembly (like the minimal ones) because those assemblies typically don't have all the JEE5 components installed that would be necessary to satisfy the console's dependencies. There is some work going on to make the console customizable using pluto 1.2's portal driver framework. The portal driver allows the console to dynamically add/remove portlets. Using this new capability from pluto provides the capability to create an administration console for the minimal assembly that contains only the base portlets, such as those necessary for deployment and web server configuration. The other portlets need to be factored out of the admin console as separately deployable WAR files and provided as plugins. This allows the user to selectively install portlets from the plugin catalog. And when the user deploys a component into the minimal assembly such as ActiveMQ they should be able to install the JMS administration portlet at that point in time, if desired. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3516) Replace the administration console with the new extensible version
Replace the administration console with the new extensible version -- Key: GERONIMO-3516 URL: https://issues.apache.org/jira/browse/GERONIMO-3516 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: console, Plugins Affects Versions: 2.1 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.1 Delete the administration console in applications/console and use the new version from plugins/console -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [BUILD] 2.1: Failed for Revision: 582939
This looks like the OOM PermGen problem we were seeing a while ago: http://www.nabble.com/FATAL-ERROR-build-tf3227422s134.html#a8965424 The solution in that case was to bump the memory args. Best wishes, Paul On Oct 8, 2007, at 3:41 PM, [EMAIL PROTECTED] wrote: [INFO] Packaging module configuration: /home/prasad/geronimo/trunk/ plugins/console/console-jetty/target/resources/META-INF/plan.xml [INFO] -- -- [ERROR] FATAL ERROR [INFO] -- -- --- constituent[0]: file:/usr/local/maven/lib/maven-core-2.0.7-uber.jar constituent[1]: file:/home/prasad/.m2/repository/org/apache/ geronimo/genesis/config/checkstyle-config/1.2/checkstyle- config-1.2.jar constituent[2]: file:/home/prasad/.m2/repository/org/apache/maven/ wagon/wagon-ssh-common/1.0-beta-2/wagon-ssh-common-1.0-beta-2.jar
Re: Make useMavenDependencies default true ?
On Oct 8, 2007, at 4:49 PM, Prasad Kashyap wrote: Can we make the c-m-p use the maven dependencies by default ? 58 of the 95 configs already use the maven deps. There are approx 15-20 configs that need to be converted to plugins. Odds are we'll end up with 75% of our configs using maven deps. Thus we should consider using the maven deps as default. +1, can this setting can be inherited from the parent project like the other settings such as source-repository currently are? see configs/pom.xml and plugins/pom.xml Also, by default, it should merge the maven deps with the explicit deps, IF ANY are specified in the c-m-p configuration. I don't see a use case for this now, but if there ever is a need to use both maven deps and an explicit list, this will let us achieve it. +1, one use case would be when you want to use the importservices/ import environmental setting for a plugin dependency. I was trying to do that earlier today but it didn't seem to work right. Lastly, the exisiting useMavenDependencies parameter can be used to specifically exclude the maven deps. This will include only the explicit deps in the c-m-p configuration. settings inherited from the parent projects can be overridden. Best wishes, Paul
[jira] Created: (GERONIMO-3509) copy the extensible administration console plugin into the server project
copy the extensible administration console plugin into the server project - Key: GERONIMO-3509 URL: https://issues.apache.org/jira/browse/GERONIMO-3509 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: console, Plugins Affects Versions: 2.1 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 2.1 The extensible admin console and the various extensions for it are in separate maven projects and in separate areas of SVN from the server. The process for building server assemblies currently requires all the plugins to be within the same parent maven project. Based on that limitation the console and extensions need to be copied into the server project. If/when the build and assemble process can be enhanced to span multiple top level maven projects they can be moved back out into separate projects. For background discussion see: http://www.nabble.com/Plugin-installer-in-trunk-broke--tf4533623s134.html#a13042533 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How to assemble servers: was: Re: Plugin installer in trunk broke?
On Sep 28, 2007, at 2:50 PM, David Jencks wrote: I think that we should approach the assemble server from plugins idea in stages: 1. build all the plugins inside the current server/trunk build framework and assemble the server from these. This is almost working locally maybe this weekend. 2. distribute the sets of related plugins into a different svn layout with unconnected release cycles and figure out how to end up with a usable server with so many moving parts. :-) So in line with (1) I'd like to see the new console move ASAP, perhaps temporarily, into maybe server/trunk/plugins where we can immediately start including it in servers without having to solve (2). Now that #1 above (assemblies created using plugins) is available in trunk I can go ahead and move the new console under server/trunk/ plugins like David suggested as a transitional step towards #2 (plugins maintained and released separately from the server).I will go ahead and move the new console to that location for the transitional phase unless there is strong support around going straight for #2. i.e. if someone wants to figure out how to build assemblies from multiple moving parts in the 2.1 time frame then please chime in before I hard wire the console and its various plugins into server/ trunk. Best wishes, Paul
Re: Adding j2g to site
Thanks Tim. I updated the wiki page to point at : http://people.apache.org/dist/geronimo/j2g/nightly/ Assuming that is where your J2G build script uploads the file(?) Best wishes, Paul On Oct 2, 2007, at 7:29 PM, Tim McConnell wrote: Thanks Paul, now I don't have to worry about blowing away the one on the unstable site ;-) Paul McMahan wrote: On Oct 2, 2007, at 7:15 PM, Tim McConnell wrote: Hi Erik, thanks very for reviewing. Sorry I didn't know that J2G has its own unstable site. So, I'll change the wiki to point to the j2g/unstable site instead of the eclipse/unstable site and change my build script to FTP the latest trunk version to the j2g/ unstable site every Sunday morning. That all work for you ?? There's also a more recent build at http://people.apache.org/dist/geronimo/j2g/nightly/ Best wishes, Paul -- Thanks, Tim McConnell
pluggable admin console and jetty
There is a bug with Pluto's session code that only surfaces in Jetty. When you view an admin console extension this bug can cause a IllegalStateException and require you to log back in to the console again. It's not difficult to work around, but if it becomes an annoyance then you can build pluto/trunk/pluto-container locally with this patch applied : https://issues.apache.org/jira/browse/PLUTO-436 Best wishes, Paul
Re: Adding j2g to site
On Oct 2, 2007, at 7:15 PM, Tim McConnell wrote: Hi Erik, thanks very for reviewing. Sorry I didn't know that J2G has its own unstable site. So, I'll change the wiki to point to the j2g/unstable site instead of the eclipse/unstable site and change my build script to FTP the latest trunk version to the j2g/unstable site every Sunday morning. That all work for you ?? There's also a more recent build at http://people.apache.org/dist/geronimo/j2g/nightly/ Best wishes, Paul
Re: Plugin installer in trunk broke?
The old admin console in trunk still has a few loose ends after the schema changes in GERONIMO-3330. Right now we're fixing/improving the plugin management portlet in the new admin console based on the ppt I sent out the other day and it should work OK for you. It's pretty easy to install into a minimal assembly using: % bin/deploy.sh search-plugins http://geronimo.apache.org/plugins/ geronimo-2.1/ Administration Console :: Tomcat plugin 63: (1.0-SNAPSHOT) Administration Console :: Jetty plugin 64: (1.0-SNAPSHOT) You can install it into a jee5 assembly if you uninstall the old admin console first (they both want to use /console context root). As indicated above, the new pluggable admin console is itself a plugin and is not kept in server/trunk. So when we start building the full-sized assemblies from framework+plugins we can replace the old admin console. I left the old one in place to minimize disruption while we figure out how we want to build servers using the more modular approach. Best wishes, Paul On Sep 28, 2007, at 6:23 AM, Jeff Genender wrote: Is the plugin installer broke? Duno if a java 1.4 dependency got in or not, but I am unable to install plugins from the console: java.lang.IllegalArgumentException: Cannot convert [1.5] of type class java.util.ArrayList to class [Ljava.lang.String; at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java: 374) at org.apache.el.parser.AstFunction.getValue (AstFunction.java:86) at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java: 186) at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate (PageContextImpl.java:923) at jsp.WEB_002dINF.view.car.viewForDownload_jsp._jspx_meth_c_005fotherwis e_005f2(viewForDownload_jsp.java:488) at jsp.WEB_002dINF.view.car.viewForDownload_jsp._jspx_meth_c_005fchoose_0 05f2(viewForDownload_jsp.java:435) at jsp.WEB_002dINF.view.car.viewForDownload_jsp._jspService (viewForDownload_jsp.java:136) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java: 806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke (ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.doInclude (ApplicationDispatcher.java:557) at org.apache.catalina.core.ApplicationDispatcher.include (ApplicationDispatcher.java:481) at org.apache.pluto.core.impl.PortletRequestDispatcherImpl.include (PortletRequestDispatcherImpl.java:65) at org.apache.geronimo.console.MultiPagePortlet.doView (MultiPagePortlet.java:153) at javax.portlet.GenericPortlet.doDispatch (GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java: 175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java: 693) at javax.servlet.http.HttpServlet.service(HttpServlet.java: 806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke (ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.doInclude (ApplicationDispatcher.java:557) at org.apache.catalina.core.ApplicationDispatcher.include (ApplicationDispatcher.java:481) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke (PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.render (PortletInvokerImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet (PortletContainerImpl.java:119) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPor tlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service (PortletFragment.java:168) at jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService (ColumnFragment_jsp.java:70)
Re: How to assemble servers: was: Re: Plugin installer in trunk broke?
Sounds great to me. I'm assuming that on top of what you have working locally we could copy geronimo/plugins/console/trunk into geronimo/server/trunk/plugins/console (or wherever you had in mind) and tweak the poms accordingly for an interim solution. That will provide our pre-assembled servers with a base console that contains a plugin installer for installing the other server plugins and console extensions like the dojo viewers, system DB and activemq portlets, etc. Those plugins would still need to be built, released, and installed separately unless we wanted to move them under server/trunk as well as part of this interim solution. Depends on how far we want to go with reflecting the modularity of the server in how we structure SVN and handle release management. Best wishes, Paul On Sep 28, 2007, at 2:50 PM, David Jencks wrote: I think that we should approach the assemble server from plugins idea in stages: 1. build all the plugins inside the current server/trunk build framework and assemble the server from these. This is almost working locally maybe this weekend. 2. distribute the sets of related plugins into a different svn layout with unconnected release cycles and figure out how to end up with a usable server with so many moving parts. :-) So in line with (1) I'd like to see the new console move ASAP, perhaps temporarily, into maybe server/trunk/plugins where we can immediately start including it in servers without having to solve (2). thanks david jencks On Sep 28, 2007, at 9:44 AM, David Jencks wrote: On Sep 28, 2007, at 9:35 AM, Paul McMahan wrote: The old admin console in trunk still has a few loose ends after the schema changes in GERONIMO-3330. Right now we're fixing/ improving the plugin management portlet in the new admin console based on the ppt I sent out the other day and it should work OK for you. It's pretty easy to install into a minimal assembly using: % bin/deploy.sh search-plugins http://geronimo.apache.org/ plugins/geronimo-2.1/ Administration Console :: Tomcat plugin 63: (1.0-SNAPSHOT) Administration Console :: Jetty plugin 64: (1.0-SNAPSHOT) You can install it into a jee5 assembly if you uninstall the old admin console first (they both want to use /console context root). As indicated above, the new pluggable admin console is itself a plugin and is not kept in server/trunk. So when we start building the full-sized assemblies from framework+plugins we can replace the old admin console. I left the old one in place to minimize disruption while we figure out how we want to build servers using the more modular approach. BTW I've made a lot of progress on this locally I have a jetty server that's assembled from plugins that starts and shows the (old) admin console that's assembled from plugins. I'm hoping to get the other servers assembled this way this weekend and then commit. david jencks Best wishes, Paul On Sep 28, 2007, at 6:23 AM, Jeff Genender wrote: Is the plugin installer broke? Duno if a java 1.4 dependency got in or not, but I am unable to install plugins from the console: java.lang.IllegalArgumentException: Cannot convert [1.5] of type class java.util.ArrayList to class [Ljava.lang.String; at org.apache.el.lang.ELSupport.coerceToType (ELSupport.java:374) at org.apache.el.parser.AstFunction.getValue (AstFunction.java:86) at org.apache.el.ValueExpressionImpl.getValue (ValueExpressionImpl.java:186) at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate (PageContextImpl.java:923) at jsp.WEB_002dINF.view.car.viewForDownload_jsp._jspx_meth_c_005fother wise_005f2(viewForDownload_jsp.java:488) at jsp.WEB_002dINF.view.car.viewForDownload_jsp._jspx_meth_c_005fchoos e_005f2(viewForDownload_jsp.java:435) at jsp.WEB_002dINF.view.car.viewForDownload_jsp._jspService (viewForDownload_jsp.java:136) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service (HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke (ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.doInclude (ApplicationDispatcher.java:557) at org.apache.catalina.core.ApplicationDispatcher.include (ApplicationDispatcher.java:481) at org.apache.pluto.core.impl.PortletRequestDispatcherImpl.include (PortletRequestDispatcherImpl.java:65) at org.apache.geronimo.console.MultiPagePortlet.doView (MultiPagePortlet.java:153) at javax.portlet.GenericPortlet.doDispatch (GenericPortlet.java:247
