[jira] Created: (GERONIMO-3577) Monitoring client needs basic graph creation/definition page
Monitoring client needs basic graph creation/definition page Key: GERONIMO-3577 URL: https://issues.apache.org/jira/browse/GERONIMO-3577 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Reporter: Erik B. Craig Code for this is laid down locally, waiting on GERONIMO-3576 to be committed to generate patch, as was written after this point locally. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3578) Delta Replication of HttpSessions - Jetty Clustered Web-Applications
Delta Replication of HttpSessions - Jetty Clustered Web-Applications Key: GERONIMO-3578 URL: https://issues.apache.org/jira/browse/GERONIMO-3578 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Fix For: 2.1 State stored in HttpSessions can now be replicated via a fine grained approach. More information is provided there: http://docs.codehaus.org/display/WADI/5.+Delta+Session+Replication -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3578) Delta Replication of HttpSessions - Jetty Clustered Web-Applications
[ https://issues.apache.org/jira/browse/GERONIMO-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3578. --- Resolution: Fixed Assignee: Gianny Damour Checked in. Delta Replication of HttpSessions - Jetty Clustered Web-Applications Key: GERONIMO-3578 URL: https://issues.apache.org/jira/browse/GERONIMO-3578 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1 State stored in HttpSessions can now be replicated via a fine grained approach. More information is provided there: http://docs.codehaus.org/display/WADI/5.+Delta+Session+Replication -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3573) monitoring plugin: collecting agent's EJB should not be spawning and monitoring a thread
[ https://issues.apache.org/jira/browse/GERONIMO-3573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3573: --- Component/s: monitoring Affects Version/s: 2.1 monitoring plugin: collecting agent's EJB should not be spawning and monitoring a thread Key: GERONIMO-3573 URL: https://issues.apache.org/jira/browse/GERONIMO-3573 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Attachments: geronimo-3573.patch The collecting agent is spawning and monitoring a thread. It does this in order to periodically capture snapshots of the server's status. However, Anita pointed out that it is a violation of the EJB spec. And I have confirmed this. An alternative is to use EJB's TimerService. -- 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: config.xml changes
Joe Bohn wrote: Thanks for the explanation David. I'll look into the geronimo-plugins.xml for Tomcat. I'll also try adding some comments in the geronimo-plugins.xml and see if it makes it into the config.xml. Well, I guess adding comments into geronimo-plugin.xml isn't going to work since those files themselves are generated too. I think this all goes back to the poms, right? Joe
Re: [VOTE] Release Devtools maven-plugins-1.0 RC1
+1, and a big Thanks for doing this !! 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 -- Thanks, Tim McConnell
Re: config.xml changes
On Nov 1, 2007, at 9:11 AM, Joe Bohn wrote: Joe Bohn wrote: Thanks for the explanation David. I'll look into the geronimo- plugins.xml for Tomcat. I'll also try adding some comments in the geronimo-plugins.xml and see if it makes it into the config.xml. Well, I guess adding comments into geronimo-plugin.xml isn't going to work since those files themselves are generated too. I think this all goes back to the poms, right? Yes, but I would think we could add comment elements there -- didn't someone recently add this less-volatile way of commenting? BTW I expect to be reworking the LocalAttributeManager to use jaxb shortly. thanks david jencks Joe
Re: basic security review
Yes, that's a good idea. Also, excellent work with reviewing the LoginModules and adding tests!!! I just added two new LoginModules to look at. I'm particularly concerned about CertificateChainLoginModule since it always returns true in its login() function. But I'm not exactly sure how this is being used. Jarek On 10/31/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I think we should create JIRAs for each review activity that results in code changes and update the wiki with the JIRA number. This way we will be able to track the progress on each activity in one central place. Also, add important points from this discussion thread to the wiki too. ++Vamsi On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote: I agree. Our strategy to make Geronimo secure should include an elaborate set of unit testcases, a rich set of tests in the security-testsuite in our testsuite framework, along with peer review of code in components that are potential security risks. We should aim to have imbricate or maybe even duplicate tests than have gaps. Towards this end, I created a security-testsuite in our testsuite framework. It contains one test now. I shall add some more soon. Please contribute to this testsuite with more and more tests that you can think of. Thanx Prasad On 10/29/07, Jarek Gawor [EMAIL PROTECTED] wrote: A few security problems were discovered in Geronimo in the last few months and weeks. Most of them were Geronimo-specific except one. Therefore, I think we should spend a little bit of our time to review our code and check for potential security problems. As the first step, I think we should identify components that make security decisions (e.g. LoginModules) or enable access to server management and control (e.g. MEJB) or any other components that might be important for sever security. Once we have a few components identified we can start the review. Besides finding and fixing the potential security problems during the review we must also ensure that we have decent tests for these components that cover a range of inputs. For each problem that we do discover, we must write a test case to make sure it never happens again. Basically, a problem is not fully addressed until we have a test for it. For now, I created the following page where we can keep track of the components and the review: http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review Feel free to update it in any way. Opinions? Ideas? Thoughts? Jarek
[DISCUSS] 2.1 Release
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's also GShell and new monitoring capabilities. I'm probably missing a few other new functions. 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? --kevan
Re: config.xml changes
David Jencks wrote: On Nov 1, 2007, at 9:11 AM, Joe Bohn wrote: Joe Bohn wrote: Thanks for the explanation David. I'll look into the geronimo-plugins.xml for Tomcat. I'll also try adding some comments in the geronimo-plugins.xml and see if it makes it into the config.xml. Well, I guess adding comments into geronimo-plugin.xml isn't going to work since those files themselves are generated too. I think this all goes back to the poms, right? Yes, but I would think we could add comment elements there -- didn't someone recently add this less-volatile way of commenting? BTW I expect to be reworking the LocalAttributeManager to use jaxb shortly. thanks david jencks Joe There has been a change added that allows comments to be maintained in the config.xml file through server start/stops and config changes. It requires the use of the attributes-1.2 schema (which seems to be the currently used version in the geronimo-plugins.xml files). So, it shouldn't be too painful to add support for comments in the geronimo-plugins.xml. Where are these files being generated from the poms? Jay
Re: config.xml changes
David Jencks wrote: On Nov 1, 2007, at 9:11 AM, Joe Bohn wrote: Joe Bohn wrote: Thanks for the explanation David. I'll look into the geronimo-plugins.xml for Tomcat. I'll also try adding some comments in the geronimo-plugins.xml and see if it makes it into the config.xml. Well, I guess adding comments into geronimo-plugin.xml isn't going to work since those files themselves are generated too. I think this all goes back to the poms, right? Yes, but I would think we could add comment elements there -- didn't someone recently add this less-volatile way of commenting? BTW I expect to be reworking the LocalAttributeManager to use jaxb shortly. I'll keep on experimenting. Comments added in the pom config-xml-content don't make it into the geronimo-plugin.xml or the config.xml. I'm not sure what the less-volatile way of commenting is but I'll keep looking. I did see some enhancements to preserve comments that were added by users to config.xml. BTW, the TomcatEngine gbean didn't appear in the config.xml because it was already commented out in the pom with info on how to remove access logging (which is why I started looking into this in the first place :-) ). Joe
[jira] Created: (GERONIMO-3579) PluginInstaller and assembly should be able to construct all the server config files, not just the main ones (e.g. config.xml)
PluginInstaller and assembly should be able to construct all the server config files, not just the main ones (e.g. config.xml) -- Key: GERONIMO-3579 URL: https://issues.apache.org/jira/browse/GERONIMO-3579 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: car-maven-plugin Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 The plugin system lets you specify stuff to add to an attribute manager and artifact resolver, which ends up meaning config.xml, config-substitutions.properties, and artifact_aliases.properties. But many assemblies actually let you start a lot of servers (such as client, offline deployer, etc) so we should let the geronimo-plugin.xml add stuff to the config files for any of these servers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3580) LocalAttributeManager should use jaxb
LocalAttributeManager should use jaxb - Key: GERONIMO-3580 URL: https://issues.apache.org/jira/browse/GERONIMO-3580 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: core Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 The LocalAttributeManager already depends on jaxb due to how it is called by the plugin installer. We should just use jaxb for everything. Among the other advantages is that we should get pretty-printed output. -- 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 1, 2007, at 10:00 AM, 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's also GShell and new monitoring capabilities. I'm probably missing a few other new functions. 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? Let's try to wrap things up :-) I have a few tweaks to the car-maven-plugin and plugin installer that I think are nearly done (GERONIMO-3579). After that I'm planning to clean up the plans and remove non-generated geronimo-plugin.xml files and then convert LocalAttributeManager to use jaxb (GERONIMO-3580). This should be pretty quick. I think we need to make sure we're all happy with the versioning and groupIds of the plugins following Prasad's build rearrangement. I'm not sure how long we should allow for this. I hope in another week we'll at least have a good idea if any more changes are needed. We need to make sure all the security review changes get into trunk. I don't really know the status of gshell. We might want to add a bit more command functionality such as easily running the server with remote debugging. I haven't had a chance to look into how to do stuff like this. thanks david jencks --kevan
Re: [DISCUSS] 2.1 Release
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's also GShell and new monitoring capabilities. I'm probably missing a few other new functions. 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 it would be good to get 2.1 out before the Holidays and I think that is reasonable. IMO we have enough function now to declare a release. Aside from getting tck passing and released version of current SNAPSHOT dependencies ... I think we ought to get config.xml updated. With the changes for the flexible server, config.xml is now being generated and isn't quite as user friendly as it once was. I don't know much about this area but I'll gladly help. There are also a few usability items that I'd like to see if I can get in ... but they are not critical. Joe
Re: [DISCUSS] 2.1 Release
I think the following two issues should be fixed for 2.1: 1) https://issues.apache.org/jira/browse/GERONIMO-3502 - this prevents a single assembly to have both cxf and axis2 installed (which we supported in 2.0.x) 2) https://issues.apache.org/jira/browse/GERONIMO-3523 - can't do certain actions through the console on jetty. Jarek On 11/1/07, Joe Bohn [EMAIL PROTECTED] wrote: 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's also GShell and new monitoring capabilities. I'm probably missing a few other new functions. 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 it would be good to get 2.1 out before the Holidays and I think that is reasonable. IMO we have enough function now to declare a release. Aside from getting tck passing and released version of current SNAPSHOT dependencies ... I think we ought to get config.xml updated. With the changes for the flexible server, config.xml is now being generated and isn't quite as user friendly as it once was. I don't know much about this area but I'll gladly help. There are also a few usability items that I'd like to see if I can get in ... but they are not critical. Joe
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
[jira] Assigned: (GERONIMO-3502) Module conditions when installed as a plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned GERONIMO-3502: -- Assignee: David Jencks Module conditions when installed as a plugin Key: GERONIMO-3502 URL: https://issues.apache.org/jira/browse/GERONIMO-3502 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1 Reporter: Jarek Gawor Assignee: David Jencks Currently, I don't think there is a way to specify module conditions in the geronimo-plugin.xml. That creates problem in certain situations where two modules can be installed at the same time but only one can be running at a time. For example, as in case of Axis2 and CXF. Before, the assembly's config.xml file specified the appropriate module conditions which prevented the two modules from running at the same time. Right now, the deployment of applications will fail if both both Axis2 and CXF modules are running at the same time. -- 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
Yep. It's time ! I really want to see how flexibly the user community will actually build their servers. I also wish we'd all spend some extra time and effort to check for security issues in the server in general and in our individual domain of expertise, in particular. Cheers Prasad On 11/1/07, Kevan Miller [EMAIL PROTECTED] 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's also GShell and new monitoring capabilities. I'm probably missing a few other new functions. 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? --kevan
Re: Promoting GShell to a real subproject
So shall we move the project out of the sandbox? Do we need an official vote for this? --jason On Oct 26, 2007, at 6:43 AM, Guillaume Nodet wrote: i think the subject is explicit. What do people think about that ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Closed: (GERONIMO-3579) PluginInstaller and assembly should be able to construct all the server config files, not just the main ones (e.g. config.xml)
[ https://issues.apache.org/jira/browse/GERONIMO-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3579. -- Resolution: Fixed Implemented in rev 591154 PluginInstaller and assembly should be able to construct all the server config files, not just the main ones (e.g. config.xml) -- Key: GERONIMO-3579 URL: https://issues.apache.org/jira/browse/GERONIMO-3579 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: car-maven-plugin Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 The plugin system lets you specify stuff to add to an attribute manager and artifact resolver, which ends up meaning config.xml, config-substitutions.properties, and artifact_aliases.properties. But many assemblies actually let you start a lot of servers (such as client, offline deployer, etc) so we should let the geronimo-plugin.xml add stuff to the config files for any of these servers. -- 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
No, not in my opinion. I haven't heard of any dissenters. There's been plenty of time for someone to raise an objection. I say -- have at it... --kevan On 11/1/07, Jason Dillon [EMAIL PROTECTED] wrote: So shall we move the project out of the sandbox? Do we need an official vote for this? --jason On Oct 26, 2007, at 6:43 AM, Guillaume Nodet wrote: i think the subject is explicit. What do people think about that ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Commented: (GERONIMO-3527) Monitoring client needs default viewmode when selecting servers from the list
[ https://issues.apache.org/jira/browse/GERONIMO-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539505 ] Anita Kulshreshtha commented on GERONIMO-3527: -- GERONIMO-3576 patch applied in rev. 591189. Monitoring client needs default viewmode when selecting servers from the list - Key: GERONIMO-3527 URL: https://issues.apache.org/jira/browse/GERONIMO-3527 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Reporter: Erik B. Craig Assignee: Erik B. Craig Currently selecting a server from the list in the monitoring client portlet links to #, must create a default view for this in the same styling of the default view for the 'views', with additional server-related functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3576) Monitoring client needs ability to add/edit/delete views in the dbase
[ https://issues.apache.org/jira/browse/GERONIMO-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig resolved GERONIMO-3576. - Resolution: Fixed Good after commit Thanks, Anita! Monitoring client needs ability to add/edit/delete views in the dbase - Key: GERONIMO-3576 URL: https://issues.apache.org/jira/browse/GERONIMO-3576 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Reporter: Erik B. Craig Assignee: Erik B. Craig Attachments: GERONIMO-3576.patch Monitoring client needs ability to add/edit/delete views in the dbase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3581) Default security relam name in ContextManager
Default security relam name in ContextManager - Key: GERONIMO-3581 URL: https://issues.apache.org/jira/browse/GERONIMO-3581 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Jarek Gawor ContextManager.login() should use a default security realm name if user did not pass a security realm. Null security realm will cause an exception in LoginContext. Right now becuase of this issue, a standalone ejb client must set a custom property (openejb.authentication.realmName) in order for authentication to succeed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
