[jira] Created: (GERONIMO-453) DerbySystemGBean doesn't call System.gc() in doStop() and soFail() as recommended in the Derby doco
DerbySystemGBean doesn't call System.gc() in doStop() and soFail() as recommended in the Derby doco --- Key: GERONIMO-453 URL: http://nagoya.apache.org/jira/browse/GERONIMO-453 Project: Apache Geronimo Type: Bug Reporter: John Sisson The Derby doco in the section Shutting Down the System at http://incubator.apache.org/derby/manuals/develop/develop12.html says the following: Typically, an application using an embedded Derby engine shuts down Derby just before shutting itself down. However, an application can shut down Derby and later restart it in the same JVM session. To restart Derby successfully, the JVM needs to unload org.apache.derby.jdbc.EmbeddedDriver, so that it can reload it when it restarts Derby. (Loading the local driver starts Derby.) You cannot explicitly request that the JVM unload a class, but you can ensure that the EmbeddedDriver class is unloaded by using a System.gc() to force it to garbage collect classes that are no longer needed. Running with -nogc or -noclassgc definitely prevents the class from being unloaded and makes you unable to restart Derby in the same JVM. Anyone have any objections to the recommendation of calling System.gc()? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
External Deployment Plans, Web Services, and EARs
So it looks like our EAR deployment plan can hold nested deployment plans for all the modules within it, using the any area of the module element in the geronimo-application.xml. I'm concerned that we may eventually want more than one nested deployment plan per module. For example, a module that uses web services would have a separate web services DD. Will we combine both the web services and standard settings into one Geronimo plan, or would we have, for example, a Geronimo EJB and Geronimo Web Services plan for the same EJB JAR? In JSR-88, the API allows you to access each J2EE deployment descriptor separately, and provide server-specific DConfigBeans for it. Each DConfigBean is tied to a specific DDBean (J2EE DD element), so it wouldn't really be possible for us to properly reflect the Geronimo-specific DD elements for both web services and standard J2EE modules without having separate DConfigBean trees for each. Still, we could take the two sets of DConfigBeans and merge them somehow and write out a single deployment plan... So we're not necessarily tied to having separate files. Anyway, if we do think we'll want multiple deployment plans for each module, we should probably change the EAR plan structure to take a group of file name/any pairs instead of just a single any. Aaron
Re: External Deployment Plans, Web Services, and EARs
A good concern but I don't think we'll need to do this. Each module in the EAR can be deployed standalone where we only get the single plan allowed by JSR-88; therefore we need to be able to nest plans for other things such as webservices or portlets inside that single plan. The ANY element in the EAR contains the same single plan as would be used for that module standalone. I don't think we've figured out how the stuff from DConfigBeans would get mapped down to that. When we do, it needs to come down to a single XML document that can be written as a deployment plan and hence which can be nested in a single ANY element. -- Jeremy Aaron Mulder wrote: So it looks like our EAR deployment plan can hold nested deployment plans for all the modules within it, using the any area of the module element in the geronimo-application.xml. I'm concerned that we may eventually want more than one nested deployment plan per module. For example, a module that uses web services would have a separate web services DD. Will we combine both the web services and standard settings into one Geronimo plan, or would we have, for example, a Geronimo EJB and Geronimo Web Services plan for the same EJB JAR? In JSR-88, the API allows you to access each J2EE deployment descriptor separately, and provide server-specific DConfigBeans for it. Each DConfigBean is tied to a specific DDBean (J2EE DD element), so it wouldn't really be possible for us to properly reflect the Geronimo-specific DD elements for both web services and standard J2EE modules without having separate DConfigBean trees for each. Still, we could take the two sets of DConfigBeans and merge them somehow and write out a single deployment plan... So we're not necessarily tied to having separate files. Anyway, if we do think we'll want multiple deployment plans for each module, we should probably change the EAR plan structure to take a group of file name/any pairs instead of just a single any. Aaron
[jira] Created: (GERONIMO-454) Support Group Name = Role Name Role Mapping
Support Group Name = Role Name Role Mapping --- Key: GERONIMO-454 URL: http://nagoya.apache.org/jira/browse/GERONIMO-454 Project: Apache Geronimo Type: Improvement Components: deployment, security Versions: 1.0-M2 Reporter: Aaron Mulder Currently, you must manually map principals to roles in the security component of a deployment descriptor. In the common case where group names match role names, this seems like unnecessary overhead. Alan and I talked and our plan is to make the role-mapping parts of the security elements look something like this: security ... automatic-role-mapping? principal-classfoo.GroupPrincipal/principal-class* /automatic-role-mapping role-mapping? ... /role-mapping /security The automatic-role-mapping is the new bit. If you specify that element empty, it would map every principal type the security realm considers to be a group to roles. For example, if you configure the seucrity realm to consider the principal class foo.GroupPrincipal as a role, and use an empty automatic-role-mapping element, that's what you'd get. You can also manually specify one or more principal classes that should be automatically mapped to roles. In any of these cases, the automatic mapping is done based on the role name and group name matching. If you specify automatic mapping *and* individual role mapping, then the user just needs to qualify for the role based on either one or the other (not both). So you could use a manual role mapping to add eligible users on top of the automatic role mapping, but not to subtract users from the automatic role mapping. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: Forthcoming Security Changes
On Sun, 7 Nov 2004, Aaron Mulder wrote: We will attempt to do this without breaking backward compatibility with the security realm API for now, though the security realm configuration in the deployment plans will need to change a bit, and we're going to mark the getXXXPrincipal() methods of the security realms as deprecated (to be removed after M3, perhaps for M4). Okay, I spoke in haste. I don't think we're actually going to make the realm interface fully backward compatible, but we're going to try to smooth the transition by not changing the interface *very much*. For example, it will now return an array of login modules configurations instead of just one, so it supports multiple login modules, and some things such as the local-ness will be configured instead of hardcoded in the default implementation... Aaron
[jira] Assigned: (GERONIMO-424) ConfigurationEntry support for multiple LoginModules
[ http://nagoya.apache.org/jira/browse/GERONIMO-424?page=history ] Alan Cabrera reassigned GERONIMO-424: - Assign To: Aaron Mulder (was: Alan Cabrera) ConfigurationEntry support for multiple LoginModules Key: GERONIMO-424 URL: http://nagoya.apache.org/jira/browse/GERONIMO-424 Project: Apache Geronimo Type: Improvement Components: security Versions: 1.0-M2 Reporter: Aaron Mulder Assignee: Aaron Mulder The abstract class ConfigurationEntry has support for returning multiple LoginModules (or more accurately, an array of AppConfigurationEntry's). However, none of the concrete implementations allow this. It's a required feature in order for the CallerIdentityUserPasswordRealmBridge to work, because that needs the password to be put in the private credential set. Currently we have one set of login modules that actually authenticate you, and a different LoginModule that populates the private credential set. In order to be both behaviors, you need to load both LoginModules, but currently the available ConfigurationEntries can't be configured for that. A problem is that the ConfigurationEntry gets its data from a SecurityRealm, and the SecurityRealm can only return a single AppConfigurationEntry (or LoginModule). It doesn't make sense to me to make the new multiple configuration entry take multiple security realms as its input. In concept, you want one security realm with two login modules. So I think the change has to start by allowing a SecurityRealm to return multiple AppConfgurationEntry values. Then we need the configuration syntax for the standard security realm GBeans to change so that they can take multiple login modules, including the options and control flags for each. Like, you might want to use a vanilla SQLSecurityRealm, but have it add a GeroinmoPasswordCredentialLoginModule (or a hypothetical AuditTrailLoginModule) in addition to its standard LoginModule. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-421) Better handling for null/empty users in default LoginModules
[ http://nagoya.apache.org/jira/browse/GERONIMO-421?page=history ] Alan Cabrera reassigned GERONIMO-421: - Assign To: Aaron Mulder (was: Alan Cabrera) Better handling for null/empty users in default LoginModules Key: GERONIMO-421 URL: http://nagoya.apache.org/jira/browse/GERONIMO-421 Project: Apache Geronimo Type: Bug Components: security Versions: 1.0-M2 Reporter: Aaron Mulder Assignee: Aaron Mulder The PropertiesFileLoginModule throws an assertion error if no username is provided. I think this should just return false (or worst case, throw a regular LoginException) instead. I expect it to be unusual that the username would be null, but if so, it's just a plain failed login, right? The SQLLoginModule doesn't seem to check at all, and would throw a NullPointerException if the user was null. Whatever we decide on the other one, we should do it here too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Renewed call for no checkin without full build
This checkin: geronimo/trunk/modules/j2ee-builder/src/java/org/apache/geronimo/j2ee/deployment/EARConfigBuilder.java Revision 56855 - (view) (download) - [select for diffs] Modified Sun Nov 7 17:26:43 2004 UTC (7 hours, 50 minutes ago) by djencks File length: 26550 byte(s) Diff to previous 56771 (colored) implement GERONIMO-435. Every builder can specify the default parentId. For services, a module can specify the empty string parentId= to get no parent. Seems to have broken the Axis module: [javac] symbol : constructor EARConfigBuilder(javax.management.ObjectName,javax.management.ObjectName,javax.management.ObjectName,javax.management.ObjectName,javax.management.ObjectName,nulltype,org.openejb.deployment.OpenEJBModuleBuilder,org.openejb.deployment.OpenEJBModuleBuilder,nulltype,nulltype,org.apache.geronimo.j2ee.deployment.ResourceReferenceBuilder,nulltype,nulltype) [javac] location: class org.apache.geronimo.j2ee.deployment.EARConfigBuilder [javac] EARConfigBuilder earConfigBuilder = new EARConfigBuilder(j2eeServer, [javac] ^ By changing the constructor that Axis depends upon. The Axis module catches a lot of heat, but the WSConfigBuilder was last changed 5 days ago. I can only assume that someone didn't do a full[*] build before checking in, because this is a clear compile failure, not even a test problem. There's a similar problem with the OpenEJBModuleBuilder, with the same cause. I believe dims had a preliminary fix, but didn't check it in tonight, so unfortunately things are still broken. I think he needs to change the Axis code to access existing GBeans instead of constructing new ones, but still, this was highly preventable. Thanks, Aaron [*] full build without anything like the axis module commented out locally
Re: Vote: Remove old deployer, rename new deployer
On Sun, 7 Nov 2004, Dain Sundstrom wrote: God I hope not. I spend a long long long time making sure our code would work with unpacked archives. People don't want to jar up a deployment during development. Having the tool jar it up, is a bit better than no support at all, but the extra coping is unbearable when dealing with a large web app (100 MB). I actually hope we soon will have support unpacked in place deployment, which involves no coping to the config store. Hmm... Well, maybe I should rethink this. I need to look at the API again. If it just takes a File, there's no reason that couldn't be a directory... Maybe I just need to adjust my assumptions. Aaron
Re: Renewed call for no checkin without full build
Actually as far as I can tell Dims' patch fixed the problem. If you get a different result reply soon... I won't be up much longer. Thanks, Dims. david jencks On Nov 7, 2004, at 11:34 PM, Aaron Mulder wrote: If there's anything I can do to help, I'm still up, and my Axis build works other than the new problem. Aaron On Sun, 7 Nov 2004, David Jencks wrote: sorry everyone, I never got my axis build cleaned up before starting on this parentid adventure. Working to fix it now... I hope I can fix my axis build. thanks david jencks On Nov 7, 2004, at 9:12 PM, Aaron Mulder wrote: This checkin: geronimo/trunk/modules/j2ee-builder/src/java/org/apache/geronimo/ j2ee/ deployment/EARConfigBuilder.java Revision 56855 - (view) (download) - [select for diffs] Modified Sun Nov 7 17:26:43 2004 UTC (7 hours, 50 minutes ago) by djencks File length: 26550 byte(s) Diff to previous 56771 (colored) implement GERONIMO-435. Every builder can specify the default parentId. For services, a module can specify the empty string parentId= to get no parent. Seems to have broken the Axis module: [javac] symbol : constructor EARConfigBuilder(javax.management.ObjectName,javax.management.ObjectN am e,javax.management.ObjectName,javax.management.ObjectName,javax.manag em ent.ObjectName,nulltype,org.openejb.deployment.OpenEJBModuleBuilder ,o rg.openejb.deployment.OpenEJBModuleBuilder,nulltype,nulltype,org. ap ache.geronimo.j2ee.deployment.ResourceReferenceBuilder,nulltype,nu ll type) [javac] location: class org.apache.geronimo.j2ee.deployment.EARConfigBuilder [javac] EARConfigBuilder earConfigBuilder = new EARConfigBuilder(j2eeServer, [javac] ^ By changing the constructor that Axis depends upon. The Axis module catches a lot of heat, but the WSConfigBuilder was last changed 5 days ago. I can only assume that someone didn't do a full[*] build before checking in, because this is a clear compile failure, not even a test problem. There's a similar problem with the OpenEJBModuleBuilder, with the same cause. I believe dims had a preliminary fix, but didn't check it in tonight, so unfortunately things are still broken. I think he needs to change the Axis code to access existing GBeans instead of constructing new ones, but still, this was highly preventable. Thanks, Aaron [*] full build without anything like the axis module commented out locally
Re: Renewed call for no checkin without full build
Yeah, you're right. Sorry I didn't give him credit! :) Aaron On Sun, 7 Nov 2004, David Jencks wrote: Actually as far as I can tell Dims' patch fixed the problem. If you get a different result reply soon... I won't be up much longer. Thanks, Dims. david jencks On Nov 7, 2004, at 11:34 PM, Aaron Mulder wrote: If there's anything I can do to help, I'm still up, and my Axis build works other than the new problem. Aaron On Sun, 7 Nov 2004, David Jencks wrote: sorry everyone, I never got my axis build cleaned up before starting on this parentid adventure. Working to fix it now... I hope I can fix my axis build. thanks david jencks On Nov 7, 2004, at 9:12 PM, Aaron Mulder wrote: This checkin: geronimo/trunk/modules/j2ee-builder/src/java/org/apache/geronimo/ j2ee/ deployment/EARConfigBuilder.java Revision 56855 - (view) (download) - [select for diffs] Modified Sun Nov 7 17:26:43 2004 UTC (7 hours, 50 minutes ago) by djencks File length: 26550 byte(s) Diff to previous 56771 (colored) implement GERONIMO-435. Every builder can specify the default parentId. For services, a module can specify the empty string parentId= to get no parent. Seems to have broken the Axis module: [javac] symbol : constructor EARConfigBuilder(javax.management.ObjectName,javax.management.ObjectN am e,javax.management.ObjectName,javax.management.ObjectName,javax.manag em ent.ObjectName,nulltype,org.openejb.deployment.OpenEJBModuleBuilder ,o rg.openejb.deployment.OpenEJBModuleBuilder,nulltype,nulltype,org. ap ache.geronimo.j2ee.deployment.ResourceReferenceBuilder,nulltype,nu ll type) [javac] location: class org.apache.geronimo.j2ee.deployment.EARConfigBuilder [javac] EARConfigBuilder earConfigBuilder = new EARConfigBuilder(j2eeServer, [javac] ^ By changing the constructor that Axis depends upon. The Axis module catches a lot of heat, but the WSConfigBuilder was last changed 5 days ago. I can only assume that someone didn't do a full[*] build before checking in, because this is a clear compile failure, not even a test problem. There's a similar problem with the OpenEJBModuleBuilder, with the same cause. I believe dims had a preliminary fix, but didn't check it in tonight, so unfortunately things are still broken. I think he needs to change the Axis code to access existing GBeans instead of constructing new ones, but still, this was highly preventable. Thanks, Aaron [*] full build without anything like the axis module commented out locally
[jira] Updated: (GERONIMO-430) Generalize security realms, consolidate logic into Login Modules
[ http://nagoya.apache.org/jira/browse/GERONIMO-430?page=history ] Aaron Mulder updated GERONIMO-430: -- Assign To: Aaron Mulder Generalize security realms, consolidate logic into Login Modules Key: GERONIMO-430 URL: http://nagoya.apache.org/jira/browse/GERONIMO-430 Project: Apache Geronimo Type: Improvement Components: security Versions: 1.0-M2 Reporter: Aaron Mulder Assignee: Aaron Mulder I'd like to generalize the security realm implementation, and make it take a more arbitrary/configurable list of login modules. That would let you implement features like auditing and lockout as login modules, and hopefully entirely encapsulate Kerberos, SQL, and File access as login modules. Then you pick login modules from here and there and pop them into a general security realm, and off you go. It makes it all much more modular, and lets us reuse the same features across realm types without needing to separately update multiple security realm implementations to handle them. To implement this, I'd suggest creating an interface such as DeployerSupport, to hold the methods getUserPrincipals and getGroupPrincipals (or their equivalents; see issue 410). Then the LoginModules could implement that, moving that logic from security realm to login module (though the realm could still provide a thin wrapper for it). For example, look at the SQL realm. Both SQLSecurityRealm and SQLLoginModule have database logic, and they don't share connections or reuse code or anything. If we make SQLLoginModule implement DeployerSupport, then all the DB/SQL logic could go in the SQLLoginModule. The SQLSecurityRealm would suddenly have no SQL-realm-specific code, and could be replaced by a generic realm. The same could be done with the PropertiesFile realm and Kerberos realm, so long as we provide a way to pass required options to the individual LoginModules. If we consolidate all 3 of our realms on one SecurityRealm implementation class, then it woudl be easier to make that one class support multiple login modules (issue 424). This would also let us solve the issue of passing options to login modules once, since it would need to be handled in order to configure multiple login modules as well. We could also consolidate down to one way to pass options to login modules (issue 422). If our combined realm took a ServerInfo parameter, that could provide the hook required for issue 426. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Feature list on wiki - please help update status
To help new users understand what is currently supported by Geronimo and what is still under development, I've started the following wiki page: http://wiki.apache.org/geronimo/RoadMap It breaks down functionality from the user's point of view and has a graphical status indicator next to each feature to show whether it's supported, partially supported or not yet implemented. Of course, right now this information is not very accurate, since I'm not sure of the current state of many of the listed features. It would be very helpful if active developers could look it over, fix anything that's wrong, and add anything that's missing. The level of detail is somewhat arbitrary, so feel free to add more features to the list where appropriate. Cheers, Erin
[jira] Assigned: (GERONIMO-386) openejb cmp attempt to modify identity columns
[ http://nagoya.apache.org/jira/browse/GERONIMO-386?page=history ] Gianny DAMOUR reassigned GERONIMO-386: -- Assign To: Gianny DAMOUR openejb cmp attempt to modify identity columns -- Key: GERONIMO-386 URL: http://nagoya.apache.org/jira/browse/GERONIMO-386 Project: Apache Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M2 Reporter: David Jencks Assignee: Gianny DAMOUR Attachments: run-with-derby.diff Some databases such as Derby have non-modifiable identity columns instead of sequences. Currently openejb cmp attempts to set such columns on insert. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-455) Too many ControlFlag arrays
[ http://nagoya.apache.org/jira/browse/GERONIMO-455?page=history ] Alan Cabrera reassigned GERONIMO-455: - Assign To: Alan Cabrera Too many ControlFlag arrays --- Key: GERONIMO-455 URL: http://nagoya.apache.org/jira/browse/GERONIMO-455 Project: Apache Geronimo Type: Improvement Components: security Versions: 1.0-M2 Reporter: Aaron Mulder Assignee: Alan Cabrera JAAS includes ConfigurationEntry.LoginModuleControlFlag with an array of values. We include LoginModuleControlFlag and SerializableACE.LoginModuleControlFlag. Three arrays for the same set of values is silly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: What hidden agenda?
Within the ASF, the use of the development mailing list is *the* method of development discussion. That's the reason for it. Wikis are good for after the fact documentation. IRC is good when a small subset of developers need to get together quickly to talk about some aspects of development, but it should quickly and completely migrate to email after the pressing matters have been dealt with. Same with thinks like meetings over beer and stuff like that. The reason, of course, should be obvious: it excludes by its very nature other developers. And you can't have collaborative development when that happens. Also, in-the-open development via Email makes it easy to prevent such claims as back door activity. How can it be back door when it's openly discussed in the primary development scheme? In general, however, such things as we discussed this on IRC and we decided to do this and we'll post a summary on Email when we can is never a good idea, and can result in kindly words that development is always done on the mailing list to fiery words that people are trying to have their cake and eat it too by riding on the ASF name without adhering to its standard practices. This is an issue that every ASF project has had to deal with in one way or another.
[jira] Closed: (GERONIMO-455) Too many ControlFlag arrays
[ http://nagoya.apache.org/jira/browse/GERONIMO-455?page=history ] Alan Cabrera closed GERONIMO-455: - Resolution: Fixed Too many ControlFlag arrays --- Key: GERONIMO-455 URL: http://nagoya.apache.org/jira/browse/GERONIMO-455 Project: Apache Geronimo Type: Improvement Components: security Versions: 1.0-M2 Reporter: Aaron Mulder Assignee: Alan Cabrera JAAS includes ConfigurationEntry.LoginModuleControlFlag with an array of values. We include LoginModuleControlFlag and SerializableACE.LoginModuleControlFlag. Three arrays for the same set of values is silly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: [VOTE] M3 pre ApacheCon
On 8/11/2004 8:19 AM, David Jencks wrote:
I'm not exactly ready to vote -1, but I think we should resolve these
issues before M3:
1. http://issues.apache.org/jira/browse/GERONIMO-386 Make cmp work
with derby. Prove it with the itests
I had a look to this one. I have committed a partial implementation and
switched itests to Derby.
As far as I know, these CMP EJBs are not portable as they are using an
auto-generated primary key by the DB. In other words, additional vendor
specific configurations are to be provided to map them to such a table.
The identity of these EJBs have been declared as auto-generated by the
GBean AutoIncrementTablePrimaryKeyGeneratorWrapper. This latter uses
JDBC3.0 to return auto-generated table primary keys.
More accurately, it inserts a dummy record into the entity table via
INSERT INTO entity (first_name) VALUES ('MOCK') and retrieves the
auto-generated primary key. This works; yet I will revisit the
implementation to get ride of this query to be manually specified.
Thanks,
Gianny
[jira] Commented: (GERONIMO-386) openejb cmp attempt to modify identity columns
[ http://nagoya.apache.org/jira/browse/GERONIMO-386?page=comments#action_55189 ] Gianny DAMOUR commented on GERONIMO-386: I have committed a new primary key generator, which uses table auto-generated primary key to generate the primary keys of a CMP EJB. I update in the following days the way this generator works. openejb cmp attempt to modify identity columns -- Key: GERONIMO-386 URL: http://nagoya.apache.org/jira/browse/GERONIMO-386 Project: Apache Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M2 Reporter: David Jencks Assignee: Gianny DAMOUR Attachments: run-with-derby.diff Some databases such as Derby have non-modifiable identity columns instead of sequences. Currently openejb cmp attempts to set such columns on insert. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: What hidden agenda?
Jim Jagielski wrote: Within the ASF, the use of the development mailing list is *the* method of development discussion. That's the reason for it. Wikis are good for after the fact documentation. IRC is good when a small subset of developers need to get together quickly to talk about some aspects of development, but it should quickly and completely migrate to email after the pressing matters have been dealt with. Same with thinks like meetings over beer and stuff like that. The reason, of course, should be obvious: it excludes by its very nature other developers. And you can't have collaborative development when that happens. Also, in-the-open development via Email makes it easy to prevent such claims as back door activity. How can it be back door when it's openly discussed in the primary development scheme? In general, however, such things as we discussed this on IRC and we decided to do this and we'll post a summary on Email when we can is never a good idea, and can result in kindly words that development is always done on the mailing list to fiery words that people are trying to have their cake and eat it too by riding on the ASF name without adhering to its standard practices. This is an issue that every ASF project has had to deal with in one way or another. I think you are missing the true issue here. The off-list discussion between Aaron and myself came about because it was pretty darn clear that we were not effectively communicating our thoughts in email and that the thread was disintegrating into dispute. Rather than indulge in a flame fest we took action to help reach consensus in the community. The intent and outcome of the off-list discussion was a plan on how to get back to a reasonable discussion *on the list* - no technical decisions were made. The bitter and personal attack that came as a response to this achieves the exact opposite of what you desire as it encourages people to keep quiet about such discussions; for, like it or not, such discussions will happen (ApacheCon anyone?). But it is more than that. Speculative allegations seed FUD about the project and are, in my opinion, deleterious to the project and community. We should not encourage or condone such behaviour. You had two individuals here trying to resolve a technical difference by discussing between themselves how to coherently present the issue to the community so all could be involved. This is a good thing. You had two individuals flame them for doing so with accusations of a hidden agenda. This is a bad thing. Talk of cake and coat-tails simply promulgates that meme. -- Jeremy
RE: Feature list on wiki - please help update status
This is pretty cool! -Original Message- From: Erin Mulder [mailto:[EMAIL PROTECTED] Sent: Monday, November 08, 2004 4:22 AM To: [EMAIL PROTECTED] Subject: Feature list on wiki - please help update status To help new users understand what is currently supported by Geronimo and what is still under development, I've started the following wiki page: http://wiki.apache.org/geronimo/RoadMap It breaks down functionality from the user's point of view and has a graphical status indicator next to each feature to show whether it's supported, partially supported or not yet implemented. Of course, right now this information is not very accurate, since I'm not sure of the current state of many of the listed features. It would be very helpful if active developers could look it over, fix anything that's wrong, and add anything that's missing. The level of detail is somewhat arbitrary, so feel free to add more features to the list where appropriate. Cheers, Erin
Re: What hidden agenda?
For the record, when the words hidden agenda came up, my exact response was, Can we turn this back into a technical discussion? Talking offline is fine. Throw in beer and it's even better. Can't wait to see everyone at ApacheCon next week. My beef was in the very first sentence of Aaron's email which came after a community vote. I talked to Jeremy. Our plan for now is that I will check in a deployer tool that includes the following features: I read this to mean that the features we voted on where not going to be committed and a new vision discussed offline was going to be committed. I should have asked Aaron to clarify his statement as taking action against a vote without public discussion is against The Apache Way. Aaron did clarify his statement, which I greatly appreciate: I guess some people thought that this was an instance of #1 [making critical decisions without input from others, offline], where Jeremy talked me out of the other half of the solution, thereby circumventing the community consensus and making a critical decision offline. In fact, I was just frustrated with keeping my pending changes in sync on several different computers, and I wanted to try to get some online features in before M3/ApacheCon. This clears it up for me. Mystery solved. Water under the bridge. My apologies to Jeremy as I had assumed the decision to commit a new deployer was part of a their discussion. I personally think Aaron's behavior was pretty good on this subject despite a poorly phrased sentence. With all the scm activity that takes place without any vote at all, I don't want to see someone punished for bothering to propose a vote. A good mix of both is healthy. -David On Nov 7, 2004, at 11:07 AM, Jeremy Boynes wrote: Last Thursday, Aaron Mulder and I had a heated but healthy technical discussion on this list about the implementation of certain features in the new deployer. It became clear to both of us that continuing to use email was getting unproductive and Aaron pinged me on IM to see if we could discuss them directly. We had a very productive hour-long discussion, clarified areas where we agreed and where we both saw issues, and came to consensus on how to proceed. Aaron summarized this to the list here: http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=9712 which basically says he was going to commit his new stuff for online deployment and offline packaging. He also inquired here: http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=9713 about how to create a experimental branch which he planned to use to check in the code for the areas that had issues that still needed to be resolved so that the entire community could see them and discuss. At the same time I promised to email the list a detailed description of the issues as I saw them. I told Aaron that this would take a couple of days and that things were really busy at work (for the record my company was in crunch mode getting a release done). http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=9721 The response to this by two members of the community was bitter and personal, almost indicative of paranoid delusion. In a stream of vitriolic email mostly with other community members I have been accused that my behaviour is not in the Apache Way, of trying to create a back channel, of not directing opinion to the list, of not fulfilling my obligation to vote, and had my motivations treated with suspicion. http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=9714 http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=9717 http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=9718 http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=9727 http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=9743 This is neither healthy nor technical. This behaviour is harmful to the reputation and perception of this community and this project. It will not be condoned. My promised description of the issues I saw has been sent to the list and is available at http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=9851 Let us civily seek consensus and get this behind us. -- Jeremy
M3 on Wednesday?
The vote to do a M3 release before ApacheCon was positive. Now the question is when. I know many of us are travelling on Friday. I suggest we prepare the release on Wednesday, so we have a bit of time to look it over before anyone hops on a plane. I'm not really looking for another vote, just speak up if you have a problem with Wednesday being the day. Hopefully there won't be any trouble getting a stable build for the M3 release, but if there is, we may need to revert some changes and ask them to be re-applied after the M3. So my plan is to continue to work on the release notes and, umm, last-minute features until Wednesday and then get a stable build and capture a modules/assembly/target/geronimo-1.0-SNAPSHOT.jar as the official M3 and then change it into a tarball and zip instead of a JAR and sign it and post the release notes and download archives... David B, if you're bored and want to take charge of this, you're more than welcome to. :) Thanks, Aaron
Re: What hidden agenda?
I think that this is an important issue, but not the important one for this thread, and we're getting caught in a rathole. The conversation in question started on the dev list, had a phone call between two individuals that really respect each other and wanted to figure out where the crossed wire was, and came back to the email list. From my POV, the phone call was a non-event. The issue contained in the message that triggered this thread was that a member of the community has a problem with the spirit in which we're interacting as a community, not the mechanism through which we are. I think it's important that we all think about and discuss this specific issue. geir On Nov 8, 2004, at 8:24 AM, Jim Jagielski wrote: Within the ASF, the use of the development mailing list is *the* method of development discussion. That's the reason for it. Wikis are good for after the fact documentation. IRC is good when a small subset of developers need to get together quickly to talk about some aspects of development, but it should quickly and completely migrate to email after the pressing matters have been dealt with. Same with thinks like meetings over beer and stuff like that. The reason, of course, should be obvious: it excludes by its very nature other developers. And you can't have collaborative development when that happens. Also, in-the-open development via Email makes it easy to prevent such claims as back door activity. How can it be back door when it's openly discussed in the primary development scheme? In general, however, such things as we discussed this on IRC and we decided to do this and we'll post a summary on Email when we can is never a good idea, and can result in kindly words that development is always done on the mailing list to fiery words that people are trying to have their cake and eat it too by riding on the ASF name without adhering to its standard practices. This is an issue that every ASF project has had to deal with in one way or another. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: What hidden agenda?
On Nov 8, 2004, at 12:24 PM, Jeremy Boynes wrote: Jim Jagielski wrote: Within the ASF, the use of the development mailing list is *the* method of development discussion. That's the reason for it. Wikis are good for after the fact documentation. IRC is good when a small subset of developers need to get together quickly to talk about some aspects of development, but it should quickly and completely migrate to email after the pressing matters have been dealt with. Same with thinks like meetings over beer and stuff like that. The reason, of course, should be obvious: it excludes by its very nature other developers. And you can't have collaborative development when that happens. Also, in-the-open development via Email makes it easy to prevent such claims as back door activity. How can it be back door when it's openly discussed in the primary development scheme? In general, however, such things as we discussed this on IRC and we decided to do this and we'll post a summary on Email when we can is never a good idea, and can result in kindly words that development is always done on the mailing list to fiery words that people are trying to have their cake and eat it too by riding on the ASF name without adhering to its standard practices. This is an issue that every ASF project has had to deal with in one way or another. I think you are missing the true issue here. The off-list discussion between Aaron and myself came about because it was pretty darn clear that we were not effectively communicating our thoughts in email and that the thread was disintegrating into dispute. Rather than indulge in a flame fest we took action to help reach consensus in the community. The intent and outcome of the off-list discussion was a plan on how to get back to a reasonable discussion *on the list* - no technical decisions were made. The bitter and personal attack that came as a response to this achieves the exact opposite of what you desire as it encourages people to keep quiet about such discussions; for, like it or not, such discussions will happen (ApacheCon anyone?). But it is more than that. Speculative allegations seed FUD about the project and are, in my opinion, deleterious to the project and community. We should not encourage or condone such behaviour. You had two individuals here trying to resolve a technical difference by discussing between themselves how to coherently present the issue to the community so all could be involved. This is a good thing. You had two individuals flame them for doing so with accusations of a hidden agenda. This is a bad thing. Talk of cake and coat-tails simply promulgates that meme. Don't throw me into that category. My exact words were, Motivations, diffusing, back channels Can we turn this back into a technical discussion? -David
Re: What hidden agenda?
On Nov 8, 2004, at 1:44 PM, Jeremy Boynes wrote: David Blevins wrote: My apologies to Jeremy as I had assumed the decision to commit a new deployer was part of a their discussion. Appreciated, thank you. To be clear, it _was_ part of the discussion; we were discussing the best way to proceed and concluded that that was for Aaron to commit the work he had done so far, in line which what had been proposed and what the community expected, and to work to present the issues clearly which would take time. This has been a huge storm in a small tea-cup, unfortunately conducted in public, and which I feel reflects poorly on the community. We must learn from this and move on. After all, we still need to discuss the technical stuff :-) Ok, this makes more sense. In the future can you vote with the rest of us? You disagreed, but never voted. -David
Re: What hidden agenda?
I never considered this issue as anything serious at all. Quite the opposite; as I mentioned just about every ASF project has had this pop up. I was simply stating the general rule, without any sort of interpretation of the events that lead to it. :)
Re: M3 on Wednesday?
+1 Wednesday I think the most important thing is we all agree to whined down development as Wednesday approaches. I know that normally there is a flood extra activity as a release approaches, which would make this release impossible, but I'm concerned that even at our current rate of change we will be unable to cut a release. I'd also like to try a dry run on Tuesday -dain On Nov 8, 2004, at 2:29 PM, Aaron Mulder wrote: The vote to do a M3 release before ApacheCon was positive. Now the question is when. I know many of us are travelling on Friday. I suggest we prepare the release on Wednesday, so we have a bit of time to look it over before anyone hops on a plane. I'm not really looking for another vote, just speak up if you have a problem with Wednesday being the day. Hopefully there won't be any trouble getting a stable build for the M3 release, but if there is, we may need to revert some changes and ask them to be re-applied after the M3. So my plan is to continue to work on the release notes and, umm, last-minute features until Wednesday and then get a stable build and capture a modules/assembly/target/geronimo-1.0-SNAPSHOT.jar as the official M3 and then change it into a tarball and zip instead of a JAR and sign it and post the release notes and download archives... David B, if you're bored and want to take charge of this, you're more than welcome to. :) Thanks, Aaron
Re: M3 on Wednesday?
Wednesday is good for me. More below On Nov 8, 2004, at 2:29 PM, Aaron Mulder wrote: The vote to do a M3 release before ApacheCon was positive. Now the question is when. I know many of us are travelling on Friday. I suggest we prepare the release on Wednesday, so we have a bit of time to look it over before anyone hops on a plane. I'm not really looking for another vote, just speak up if you have a problem with Wednesday being the day. Hopefully there won't be any trouble getting a stable build for the M3 release, but if there is, we may need to revert some changes and ask them to be re-applied after the M3. So my plan is to continue to work on the release notes and, umm, last-minute features until Wednesday and then get a stable build and capture a modules/assembly/target/geronimo-1.0-SNAPSHOT.jar as the official M3 and then change it into a tarball and zip instead of a JAR and sign it and post the release notes and download archives... David B, if you're bored and want to take charge of this, you're more than welcome to. :) Here is the filter settings you should use to create the Unfinished section of the changelog: Project: Apache Geronimo Status: Open, In Progress, Reopened Fix Version/s: No versions Affects Version/s: 1.0-M1,1.0-M2 Sorted by: Key descending Don't sweat the binary work. I've got a few hacked up scripts to tar,zip, md5, sha, pgp, and scp the source and binary distros. Though after all this is over, I would *love* get your help in converting them to jelly/maven so it would be easy for any of us to cut a release. I'd also like to automate the creation of the changelog. I have part of a stylesheet for it, but nothing working. -David
Re: M3 on Wednesday?
Aaron Mulder wrote: The vote to do a M3 release before ApacheCon was positive. Now the question is when. I know many of us are travelling on Friday. I suggest we prepare the release on Wednesday, so we have a bit of time to look it over before anyone hops on a plane. I'm not really looking for another vote, just speak up if you have a problem with Wednesday being the day. Hopefully there won't be any trouble getting a stable build for the M3 release, but if there is, we may need to revert some changes and ask them to be re-applied after the M3. So my plan is to continue to work on the release notes and, umm, last-minute features until Wednesday and then get a stable build and capture a modules/assembly/target/geronimo-1.0-SNAPSHOT.jar as the official M3 and then change it into a tarball and zip instead of a JAR and sign it and post the release notes and download archives... David B, if you're bored and want to take charge of this, you're more than welcome to. :) +1 Bruce -- perl -e 'print unpack(u30,0G)[EMAIL PROTECTED]5R\F9EG)E=\$\!FFEI+F-O;0\`\`);' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: M3 on Wednesday?
On Mon, 8 Nov 2004, David Blevins wrote: Here is the filter settings you should use to create the Unfinished section of the changelog: Project: Apache Geronimo Status: Open, In Progress, Reopened Fix Version/s: No versions Affects Version/s: 1.0-M1,1.0-M2 Sorted by: Key descending I think I mentioned this before, but I was hoping to cover this with text instead of specific issue ID's. There are too many of them, and many are internal-use-only (not real meaningful to an end user). But that is a good query to get this list that I need to summarize as text. Don't sweat the binary work. I've got a few hacked up scripts to tar,zip, md5, sha, pgp, and scp the source and binary distros. Cool. Though after all this is over, I would *love* get your help in converting them to jelly/maven so it would be easy for any of us to cut a release. I'd also like to automate the creation of the changelog. I have part of a stylesheet for it, but nothing working. Well, you're really asking the wrong guy for help with Jelly/Maven. I spend 10N hours confused, frustrated, and griping for every N hours of productivity when working with them. The change log automation would be cool. Does JIRA have any kind of API or would we really need to screen scrape? Aaron
Re: M3 on Wednesday?
David Blevins wrote: Wednesday is good for me. More below On Nov 8, 2004, at 2:29 PM, Aaron Mulder wrote: The vote to do a M3 release before ApacheCon was positive. Now the question is when. I know many of us are travelling on Friday. I suggest we prepare the release on Wednesday, so we have a bit of time to look it over before anyone hops on a plane. I'm not really looking for another vote, just speak up if you have a problem with Wednesday being the day. Hopefully there won't be any trouble getting a stable build for the M3 release, but if there is, we may need to revert some changes and ask them to be re-applied after the M3. So my plan is to continue to work on the release notes and, umm, last-minute features until Wednesday and then get a stable build and capture a modules/assembly/target/geronimo-1.0-SNAPSHOT.jar as the official M3 and then change it into a tarball and zip instead of a JAR and sign it and post the release notes and download archives... David B, if you're bored and want to take charge of this, you're more than welcome to. :) Here is the filter settings you should use to create the Unfinished section of the changelog: Project: Apache Geronimo Status: Open, In Progress, Reopened Fix Version/s: No versions Affects Version/s: 1.0-M1,1.0-M2 Sorted by: Key descending Don't sweat the binary work. I've got a few hacked up scripts to tar,zip, md5, sha, pgp, and scp the source and binary distros. Though after all this is over, I would *love* get your help in converting them to jelly/maven so it would be easy for any of us to cut a release. I'd also like to automate the creation of the changelog. I have part of a stylesheet for it, but nothing working. This is exactly why I asked earlier if this stuff was in the Maven scripts. I guess this is the answer I was seeking. I'd be willing to help with this effort. Bruce -- perl -e 'print unpack(u30,0G)[EMAIL PROTECTED]5R\F9EG)E=\$\!FFEI+F-O;0\`\`);' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: Logging problems
Either my email got lost in the flood or people are not too opinionated on logging. Anyway, does anyone have an opinion on point 2 Commons Log? -dain On Nov 5, 2004, at 1:29 PM, Dain Sundstrom wrote: After working with geronimo for a while, I am convinced our current logging solution was a bad idea (on my part :). There are several problems, so I'll try to categorize them. Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. Commons LogFactory Currently all of our code uses commons logging. The problem is how we obtain org.apache.commons.logging.Log implementation. This is most common code in to obtain a Log: private static Log log = LogFactory.getLog(MyGBean.class); The problem is the static LogFactory. As with log4j above anyone can come along an kick out our log factory. Also, the code we use to setup the LogFactory on geronimo boot is very very ugly and error prone. I propose we make Log log a GBean magic attributes, which means that is automatically available to all gbeans (just like class loader and kernel). If a gbean declares that it wants a log we will create and initialize a log. This will also let the kernel add additional information to log events such as gbean object name. Commons Log If we make the above changes, we will only be using the org.apache.commons.logging.Log class from commons logging. The problem is to get this class we include a commons-logging jar into geronimo and this jar will carry a specific version number. This means that all applications are restricted to use the version of commons logging that we ship. I can think of two solutions this problem: ship only the org.apache.commons.logging.Log class with geronimo or repackage Log into a geronimo package (say org.apache.geronimo.logging.Log or org.apache.geronimo.logging.GLog). I don't have much of a preference for either of these solutions, but I feel we must address this problem. I'm going to start working on the first proposal above, Log4j, as I think it is the least controversial. If you have any concerns about that one, please respond sooner rather then later. Thanks, -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
Re: Logging problems
Yes that is the one. -dain On Nov 8, 2004, at 4:03 PM, Aaron Mulder wrote: If you mean the bit about distribute 1 class or repackage, I vote repackage. Aaron On Mon, 8 Nov 2004, Dain Sundstrom wrote: Either my email got lost in the flood or people are not too opinionated on logging. Anyway, does anyone have an opinion on point 2 Commons Log? -dain On Nov 5, 2004, at 1:29 PM, Dain Sundstrom wrote: After working with geronimo for a while, I am convinced our current logging solution was a bad idea (on my part :). There are several problems, so I'll try to categorize them. Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. Commons LogFactory Currently all of our code uses commons logging. The problem is how we obtain org.apache.commons.logging.Log implementation. This is most common code in to obtain a Log: private static Log log = LogFactory.getLog(MyGBean.class); The problem is the static LogFactory. As with log4j above anyone can come along an kick out our log factory. Also, the code we use to setup the LogFactory on geronimo boot is very very ugly and error prone. I propose we make Log log a GBean magic attributes, which means that is automatically available to all gbeans (just like class loader and kernel). If a gbean declares that it wants a log we will create and initialize a log. This will also let the kernel add additional information to log events such as gbean object name. Commons Log If we make the above changes, we will only be using the org.apache.commons.logging.Log class from commons logging. The problem is to get this class we include a commons-logging jar into geronimo and this jar will carry a specific version number. This means that all applications are restricted to use the version of commons logging that we ship. I can think of two solutions this problem: ship only the org.apache.commons.logging.Log class with geronimo or repackage Log into a geronimo package (say org.apache.geronimo.logging.Log or org.apache.geronimo.logging.GLog). I don't have much of a preference for either of these solutions, but I feel we must address this problem. I'm going to start working on the first proposal above, Log4j, as I think it is the least controversial. If you have any concerns about that one, please respond sooner rather then later. Thanks, -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
Re: M3 on Wednesday?
On Nov 8, 2004, at 3:51 PM, Aaron Mulder wrote: On Mon, 8 Nov 2004, David Blevins wrote: Here is the filter settings you should use to create the Unfinished section of the changelog: Project: Apache Geronimo Status: Open, In Progress, Reopened Fix Version/s: No versions Affects Version/s: 1.0-M1,1.0-M2 Sorted by: Key descending I think I mentioned this before, but I was hoping to cover this with text instead of specific issue ID's. There are too many of them, and many are internal-use-only (not real meaningful to an end user). But that is a good query to get this list that I need to summarize as text. If we have time I really love the release notes Mozilla puts out http://www.mozilla.org/products/firefox/releases/ I also think we should have the detailed change log, but a summary like mozilla does would be spectacular. -dain
[jira] Resolved: (GERONIMO-457) Missing dependency in modules/axis
[ http://nagoya.apache.org/jira/browse/GERONIMO-457?page=history ]
Davanum Srinivas resolved GERONIMO-457:
---
Resolution: Fixed
already fixed. try latest SVN.
-- dims
Missing dependency in modules/axis
--
Key: GERONIMO-457
URL: http://nagoya.apache.org/jira/browse/GERONIMO-457
Project: Apache Geronimo
Type: Bug
Components: buildsystem
Versions: 1.0-M3
Reporter: Brian Topping
Priority: Minor
Index: geronimo/modules/axis/project.xml
===
--- geronimo/modules/axis/project.xml (revision 56800)
+++ geronimo/modules/axis/project.xml (working copy)
@@ -170,6 +170,11 @@
versiongeronimo-spec-ejb-version;/version
/dependency
dependency
+groupIdgeronimo/groupId
+artifactIdgeronimo-j2ee-builder/artifactId
+version${pom.currentVersion}/version
+/dependency
+dependency
groupIdjetty/groupId
artifactIdorg.mortbay.jetty/artifactId
versionjetty-version;/version
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
