[jira] Created: (GERONIMO-816) Spaces missing in help for deploy and distribute commands
Spaces missing in help for deploy and distribute commands - Key: GERONIMO-816 URL: http://issues.apache.org/jira/browse/GERONIMO-816 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M4, 1.0-M5 Reporter: John Sisson Assigned to: John Sisson Priority: Trivial Fix For: 1.0-M4 Some words were run together due to spaces missing at end of strings when they were concatenated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-816) Spaces missing in help for deploy and distribute commands
[ http://issues.apache.org/jira/browse/GERONIMO-816?page=comments#action_12316722 ] John Sisson commented on GERONIMO-816: -- Fixed in M4: Modified: OpenSourceJava\geronimo_m4qa\geronimo\modules\deploy-tool\src\java\org\apache\geronimo\deployment\cli\CommandDeploy.java Modified: OpenSourceJava\geronimo_m4qa\geronimo\modules\deploy-tool\src\java\org\apache\geronimo\deployment\cli\CommandDistribute.java Sending Content: C:\OpenSourceJava\geronimo_m4qa\geronimo\modules\deploy-tool\src\java\org\apache\geronimo\deployment\cli\CommandDeploy.java Sending Content: C:\OpenSourceJava\geronimo_m4qa\geronimo\modules\deploy-tool\src\java\org\apache\geronimo\deployment\cli\CommandDistribute.java Completed: At revision: 225245 Fixed in HEAD. Modified: OpenSourceJava\geronimo_head\geronimo\modules\deploy-tool\src\java\org\apache\geronimo\deployment\cli\CommandDeploy.java Modified: OpenSourceJava\geronimo_head\geronimo\modules\deploy-tool\src\java\org\apache\geronimo\deployment\cli\CommandDistribute.java Sending Content: C:\OpenSourceJava\geronimo_head\geronimo\modules\deploy-tool\src\java\org\apache\geronimo\deployment\cli\CommandDeploy.java Sending Content: C:\OpenSourceJava\geronimo_head\geronimo\modules\deploy-tool\src\java\org\apache\geronimo\deployment\cli\CommandDistribute.java Completed: At revision: 225246 > Spaces missing in help for deploy and distribute commands > - > > Key: GERONIMO-816 > URL: http://issues.apache.org/jira/browse/GERONIMO-816 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4, 1.0-M5 > Reporter: John Sisson > Assignee: John Sisson > Priority: Trivial > Fix For: 1.0-M4 > > Some words were run together due to spaces missing at end of strings when > they were concatenated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-816) Spaces missing in help for deploy and distribute commands
[ http://issues.apache.org/jira/browse/GERONIMO-816?page=all ] John Sisson closed GERONIMO-816: > Spaces missing in help for deploy and distribute commands > - > > Key: GERONIMO-816 > URL: http://issues.apache.org/jira/browse/GERONIMO-816 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4, 1.0-M5 > Reporter: John Sisson > Assignee: John Sisson > Priority: Trivial > Fix For: 1.0-M4 > > Some words were run together due to spaces missing at end of strings when > they were concatenated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-816) Spaces missing in help for deploy and distribute commands
[ http://issues.apache.org/jira/browse/GERONIMO-816?page=all ] John Sisson resolved GERONIMO-816: -- Resolution: Fixed > Spaces missing in help for deploy and distribute commands > - > > Key: GERONIMO-816 > URL: http://issues.apache.org/jira/browse/GERONIMO-816 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4, 1.0-M5 > Reporter: John Sisson > Assignee: John Sisson > Priority: Trivial > Fix For: 1.0-M4 > > Some words were run together due to spaces missing at end of strings when > they were concatenated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-817) deploy-jsr88 module has dependency on openejb
[ http://issues.apache.org/jira/browse/GERONIMO-817?page=all ] David Jencks updated GERONIMO-817: -- Attachment: nobuilderdependencies simple patch removing architecturally unacceptable dependencies from deployment managers. > deploy-jsr88 module has dependency on openejb > - > > Key: GERONIMO-817 > URL: http://issues.apache.org/jira/browse/GERONIMO-817 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4, 1.0-M5 > Reporter: David Jencks > Assignee: Aaron Mulder > Priority: Blocker > Fix For: 1.0-M4, 1.0-M5 > Attachments: nobuilderdependencies > > Apparently in an attempt to support dconfig beans, the deploy-jsr88 module > grew dependencies on several builder modules including openejb builder. This > is a totally non-extensible archtecture and prevents building geronimo and > openejb in any semblance of a reasonable order. I think that some kind of > registration scheme might be plausible but the current hard-coded > dependencies to specific builder implementations are not acceptable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-817) deploy-jsr88 module has dependency on openejb
deploy-jsr88 module has dependency on openejb - Key: GERONIMO-817 URL: http://issues.apache.org/jira/browse/GERONIMO-817 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Assigned to: Aaron Mulder Priority: Blocker Fix For: 1.0-M4, 1.0-M5 Attachments: nobuilderdependencies Apparently in an attempt to support dconfig beans, the deploy-jsr88 module grew dependencies on several builder modules including openejb builder. This is a totally non-extensible archtecture and prevents building geronimo and openejb in any semblance of a reasonable order. I think that some kind of registration scheme might be plausible but the current hard-coded dependencies to specific builder implementations are not acceptable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Attacking M4
Thanks a ton. -- dims On 7/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Davanum Srinivas <[EMAIL PROTECTED]> wrote on 26/07/2005 11:47:05 AM: > > > sisson, > > > > On 7/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Davanum Srinivas <[EMAIL PROTECTED]> wrote on 26/07/2005 09:22:34 AM: > > > > > > > Javamail & Axis... > > > > > > > > - Am done with changes to JavaMail. tests are working as well. > > > > > > Dims, are you going to build a new release candidate of the javamail > spec > > > jar - GERONIMO-802 and update the M4 branch to point to it? > > > > Could someone who has done it before do it please? I have no clue > > about the steps involved. > > Ok, I'll do it tonight (Sydney time). > > > > > > Currently both M4 and HEAD are using > > > geronimo_spec_javamail_version=1.3.1-rc4 which was built before some > of > > > you JavaMail spec changes. > > > > > > > - We most probably can't squeeze in a new release of Axis this week. > > > > What do we do? (dated snapshot?) > > > > > > Dated build sounds good to me. I don't think it should have SNAPSHOT > as > > > part of its version or name, as that would cause maven unnecessarily > check > > > for updates for it. > > > > Sounds good. Let me review the Axis bugs list and come up a dated > > build in the next few days. > > > > > Thanks, > > > > > > John > > > > > > > > thanks, > > > > -- dims > > > > > > > > On 7/25/05, David Blevins <[EMAIL PROTECTED]> wrote: > > > > > Alright, here is the deal on M4. We have OSCON coming up and from > my > > > > > experience, if we don't get M4 out the door this week, then we > won't > > > > > see it till the week after OSCON. I actually tried to cut M3 at > > > > > OSCON last year and we all know how that went. > > > > > > > > > > If we don't get M4 out the door this week, our hopes of having M5 > by > > > > > the 15th are lost. Assuming we don't want this to happen, here is > my > > > > > attack plan: > > > > > > > > > > =ATTACK PLAN== > > > > > > > > > > LAST ISSUES > > > > > > > > > >- Undeployment issue (GERONIMO-812, David Jencks) > > > > >- Snapshots (Javamail & Axis=>Dims, jUDDI & Scout=>Geir, > > > > > ServiceMix=>Hiram, tmpOrb=>Dain) > > > > >- Web Services startup issue (GERONIMO-785, David Blevins) > > > > >- Corba interop problem (GERONIMO-813, Dain Sundstrom) > > > > >- Izpack/Tomcat issue (GERONIMO-811, Unassigned) > > > > >- Unknown CTS issues (need to clear up GERONIMO-812 to run it > > > > > completely) > > > > > > > > > > No sitting on tasks, if you are not going to do it, mark it > > > unassigned. > > > > > > > > > > Issue GERONIMO-811 is unassigned. Can someone either remove the > > > > > Tomcat option from the IzPack installer or add a the link to the > wiki? > > > > > > > > > > It seems GERONIMO-809 is actually completed, is that right? > > > > > > > > > > THE FINAL STUFF > > > > > > > > > > We have to run the TCK on the final binary, which means we need to > > > > > allow for a couple days of just testing the actual geronimo-1.0- > > > > > M4.zip that people will download. To even get that far, we need > to: > > > > > > > > > >1. [notes] Create release notes for M4 and check them into the > QA > > > > > branch > > > > >2. [svn] Close the QA branch and copy it to tags/v1_0_M4 > > > > >3. [dist] Cut and sign the binary and source distributions > > > > > > > > > > We are going to need to be done with the remaining JIRA items > above > > > > > by like Wednesday (best) or Thursday morning in order to do the > above > > > > > tasks. > > > > > > > > > > I am willing to take care of the svn and dist work. Side-note: I > have > > > > > to go to a wedding on Friday, so I personally would like to shoot > for > > > > > Wednesday as Thursday night is too late for me. > > > > > > > > > > Aaron, you willing to do the nice release notes like you did for > M3? > > > > > > > > > > > > > > > > > > > > Sound good to everyone? Going to assume a lazy consensus > otherwise. > > > > > > > > > > -David > > > > > > > > > > > > > > > > > > > > > > -- > > > > Davanum Srinivas -http://blogs.cocoondev.org/dims/ > > > > > > > > > > > > -- > > Davanum Srinivas -http://blogs.cocoondev.org/dims/ > > -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
[jira] Commented: (GERONIMO-433) Tolerate non-Sun JREs
[
http://issues.apache.org/jira/browse/GERONIMO-433?page=comments#action_12316737
]
Vamsavardhana Reddy commented on GERONIMO-433:
--
I tried building the Geronimo M4 source thru Eclipse using Sun's SDK 1.4.2 and
IBM's SDK 1.4.2 . Here are my findings:
With IBM's SDK, only one file, namely,
modules\security\src\test\org\apache\geronimo\security\network\protocol\SubjectCarryingProtocolTest.java
fails to compile with error, "import com.sun.security.auth.login.ConfigFile
can not be resolved". All other references to com.sun.* classes are made
indirectly by coding the class name as a String parameter.
-- Did not find any references to com.sun.security.jgss.GSSUtil in the workspace
-- com.sun.jndi.rmi.registry.RegistryContextFactory is available in IBM's SDK
under server.jar
-- com.sun.security.auth.login.ConfigFile is not in IBM's SDK, but,
com.ibm.security.auth.login.ConfigFile is available in security.jar
-- com.sun.security.auth.module.Krb5LoginModule is not in IBM's SDK, but,
com.ibm.security.auth.module.Krb5LoginModule is in ibmjgssprovider.jar
The classes available in IBM's SDK implement the same interface/extend the same
class as their counterparts in Sun's SDK. To tolerate other JRE's, the
references to these classes need to be moved into a configuration file instead
of hardcoding them in the java files.
OpenEJB seems to have a dependency on Sun's SDK. As of now, I don't know how
this can be made to tolerate non-Sun JREs
> Tolerate non-Sun JREs
> -
>
> Key: GERONIMO-433
> URL: http://issues.apache.org/jira/browse/GERONIMO-433
> Project: Geronimo
> Type: Improvement
> Components: general
> Reporter: Glyn Normington
> Assignee: Alan Cabrera
> Priority: Critical
>
> Geronimo fails to build against a non-Sun JRE (e.g. IBM's) because of the use
> of non-standard Sun internal classes (in com.sun.* packages) such as
> com.sun.security.jgss.GSSUtil. The build stops with:
> A compilation error occurred in the network module:
> C:\apache\geronimo\modules\network\src\java\org\apache\geronimo\network\protocol\GSSAPIServerProtocol.java:29:
> package com.sun.security.jgss does not exist import
> com.sun.security.jgss.GSSUtil;
> grep also found the following other references to com.sun in Java files, some
> of which will need to be modified to tolerate non-Sun JREs.
> modules/client/src/java/org/apache/geronimo/client/StaticJndiContextPlugin.java:
> System.setProperty("java.naming.factory.initial",
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/connector/src/test/org/apache/geronimo/connector/outbound/ManagedConnectionFactoryWrapperTest.java:
> env.put("java.naming.factory.initial",
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/naming/src/test/org/apache/geronimo/naming/geronimo/GeronimoRootContextTest.java:
> System.setProperty("java.naming.factory.initial",
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/naming/src/test/org/apache/geronimo/naming/java/AbstractContextTest.java:
> System.setProperty("java.naming.factory.initial",
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/naming/src/test/org/apache/geronimo/naming/java/ThreadContextTest.java:
> System.setProperty("java.naming.factory.initial",
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/security/src/java/org/apache/geronimo/security/realm/providers/KerberosSecurityRealm.java:
> AppConfigurationEntry entry = new
> AppConfigurationEntry("com.sun.security.auth.module.Krb5LoginModule",
> modules/security/src/test/org/apache/geronimo/security/jaas/LoginKerberosNonGeronimoTest.java:
> gbean.setAttribute("loginModuleName",
> "com.sun.security.auth.module.Krb5LoginModule");
> modules/security/src/test/org/apache/geronimo/security/network/protocol/SubjectCarryingProtocolTest.java:import
> com.sun.security.auth.login.ConfigFile;
> modules/system/src/test/org/apache/geronimo/system/properties/NamingPropertiesTest.java:
> private static final String NAMING_FACTORY_INITIAL =
> "com.sun.jndi.rmi.registry.RegistryContextFactory";
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Does J2EE 1.5/5.0 include JBI?
no JBI is not part of Java EE 5 Davanum Srinivas wrote: Does anyone know if the J2EE 1.5 (now called 5.0) include JBI? Quote from http://radio.weblogs.com/0112098/2005/07/25.html#a532: "Am looking forward to it passing the JBI TCK through the Geronimo project." -- dims
[jira] Resolved: (GERONIMO-802) Publish geronimo_spec_javamail jar version 1.3.1-rc5
[ http://issues.apache.org/jira/browse/GERONIMO-802?page=all ] John Sisson resolved GERONIMO-802: -- Resolution: Fixed > Publish geronimo_spec_javamail jar version 1.3.1-rc5 > > > Key: GERONIMO-802 > URL: http://issues.apache.org/jira/browse/GERONIMO-802 > Project: Geronimo > Type: Task > Components: dependencies, specs > Versions: 1.0-M4 > Reporter: John Sisson > Assignee: John Sisson > Fix For: 1.0-M4 > > Done. geronimo-spec-javamail-1.3.1-rc5.jar has been deployed from HEAD. > The last javamail change that was included in this rc5 version was Revision: > 219524 Author: dims Date: 2:06:41 AM, Tuesday, 19 July 2005 Message: set > parsed default to true. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-802) Publish geronimo_spec_javamail jar version 1.3.1-rc5
[ http://issues.apache.org/jira/browse/GERONIMO-802?page=all ] John Sisson closed GERONIMO-802: > Publish geronimo_spec_javamail jar version 1.3.1-rc5 > > > Key: GERONIMO-802 > URL: http://issues.apache.org/jira/browse/GERONIMO-802 > Project: Geronimo > Type: Task > Components: dependencies, specs > Versions: 1.0-M4 > Reporter: John Sisson > Assignee: John Sisson > Fix For: 1.0-M4 > > Done. geronimo-spec-javamail-1.3.1-rc5.jar has been deployed from HEAD. > The last javamail change that was included in this rc5 version was Revision: > 219524 Author: dims Date: 2:06:41 AM, Tuesday, 19 July 2005 Message: set > parsed default to true. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-802) Publish geronimo_spec_javamail jar version 1.3.1-rc5
[ http://issues.apache.org/jira/browse/GERONIMO-802?page=all ] John Sisson updated GERONIMO-802: - Summary: Publish geronimo_spec_javamail jar version 1.3.1-rc5 (was: Publish new geronimo_spec_javamail jar since changes have been made since 1.3.1-rc4 was published) Description: Done. geronimo-spec-javamail-1.3.1-rc5.jar has been deployed from HEAD. The last javamail change that was included in this rc5 version was Revision: 219524 Author: dims Date: 2:06:41 AM, Tuesday, 19 July 2005 Message: set parsed default to true. was: Dims, can you comment on the changes you have made to geronimo_spec_javamail. What is needing these changes? Are you finished work in this area? Are we ready to publish a new version? Should this be done before M4 goes out and etc/properties updated in M4 & HEAD to point to this new version? Updated v1_0_M4-QA branch to use geronimo-spec-javamail-1.3.1-rc5.jar : Modified: OpenSourceJava\geronimo_m4qa\geronimo\etc\project.properties Sending Content: C:\OpenSourceJava\geronimo_m4qa\geronimo\etc\project.properties Completed: At revision: 225275 Updated HEAD to use geronimo-spec-javamail-1.3.1-rc5.jar: Modified: OpenSourceJava\geronimo_head\geronimo\etc\project.properties Sending Content: C:\OpenSourceJava\geronimo_head\geronimo\etc\project.properties Completed: At revision: 225273 > Publish geronimo_spec_javamail jar version 1.3.1-rc5 > > > Key: GERONIMO-802 > URL: http://issues.apache.org/jira/browse/GERONIMO-802 > Project: Geronimo > Type: Task > Components: dependencies, specs > Versions: 1.0-M4 > Reporter: John Sisson > Assignee: John Sisson > Fix For: 1.0-M4 > > Done. geronimo-spec-javamail-1.3.1-rc5.jar has been deployed from HEAD. > The last javamail change that was included in this rc5 version was Revision: > 219524 Author: dims Date: 2:06:41 AM, Tuesday, 19 July 2005 Message: set > parsed default to true. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-433) Tolerate non-Sun JREs
Vamsavardhana Reddy (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-433?page=comments#action_12316737 ] Vamsavardhana Reddy commented on GERONIMO-433: -- I tried building the Geronimo M4 source thru Eclipse using Sun's SDK 1.4.2 and IBM's SDK 1.4.2 . Here are my findings: OpenEJB seems to have a dependency on Sun's SDK. As of now, I don't know how this can be made to tolerate non-Sun JREs I've spent a bit of time looking at you to remove OpenEJB's Sun SDK dependencies, and have arrived at the conclusion that replacing the Sun ORB with a truely portable ORB is the only solution. The Sun ORB class references cause problems with both IBM's SDK 1.4.2 and Suns 5.0 SDK, so this is not an easy problem to attack. Unfortunately, there appear to be no portable solutions available for the places where it was necessary to directly reference the Sun ORB classes directly. Right now, it looks like the Trifork ORB contribution may be the best means of achieving SDK portability. Rick
[jira] Updated: (GERONIMO-811) Remove Tomcat option from izpack installer for M4 release
[ http://issues.apache.org/jira/browse/GERONIMO-811?page=all ] John Sisson updated GERONIMO-811: - Summary: Remove Tomcat option from izpack installer for M4 release (was: Lack of information for those using izpack installer on how to enable Tomcat in M4) Description: It has been agreed that the Tomcat support will be made available in the M5 release as the procedures required to get Tomcat running in M4 is too complex and prone to error. (was: When you select Tomcat in the M4 installer, it does not mention that there are further steps involved in getting Tomcat to be used as the web container. Does the user have to edit the plan files in C:\Program Files\GeronimoM4QA\installer-temp as discussed in http://wiki.apache.org/geronimo/Tomcat ? If so we need some documentation with the installation. For example, the output below is from starting Geronimo from an installation where Tomcat was selected. C:\Program Files\GeronimoM4QA>java -jar bin\server.jar Booting Geronimo Kernel (in Java 1.4.2_06)... 21:05:50,864 WARN [ToolsJarHack] Could not find java compiler: lib\tools.jar file not found in C:\Program Files\Java\j2re1.4.2_06 o r C:\Program Files\Java Starting Geronimo Application Server [***] 100% 7s Startup complete Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 127.0.0.1 Derby Connector 4201 127.0.0.1 OpenEJB Connector EJB 8080 0.0.0.0 Jetty Connector HTTP 8443 0.0.0.0 Jetty Connector HTTPS 61616 0.0.0.0 ActiveMQ Message Broker Connector Geronimo Application Server started (version 1.0-M4-SNAPSHOT) Firstly, you can see that Tomcat isn't started. We need to point out that that will be the case and what they need to do (editing plans etc) before they can start it. C:\Program Files\GeronimoM4QA>java -jar bin\deployer.jar --user system --password manager list-modules --stopped Found 10 modules org/apache/geronimo/DeployerSystem org/apache/geronimo/DebugConsole org/apache/geronimo/ClientSystem org/apache/geronimo/J2EEDeployer org/apache/geronimo/Client org/apache/geronimo/Secure org/apache/geronimo/Tomcat org/apache/geronimo/Demo org/apache/geronimo/SpringRuntime org/apache/geronimo/SpringDeployer) > Remove Tomcat option from izpack installer for M4 release > - > > Key: GERONIMO-811 > URL: http://issues.apache.org/jira/browse/GERONIMO-811 > Project: Geronimo > Type: Task > Components: installer > Versions: 1.0-M4 > Reporter: John Sisson > Assignee: John Sisson > Fix For: 1.0-M4 > > It has been agreed that the Tomcat support will be made available in the M5 > release as the procedures required to get Tomcat running in M4 is too complex > and prone to error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
xsd schemas for deployment plans?
Hi Are there any xsd schema's for each of the deployment plan files?
Re: xsd schemas for deployment plans?
Yes: you can find them in the folder schema of a geronimo server installation. Thanks, Gianny On 26/07/2005 10:10 PM, Sachin Patel wrote: Hi Are there any xsd schema's for each of the deployment plan files?
Re: Does J2EE 1.5/5.0 include JBI?
On Jul 25, 2005, at 10:58 PM, Davanum Srinivas wrote: Does anyone know if the J2EE 1.5 (now called 5.0) include JBI? No, it doesn't. Quote from http://radio.weblogs.com/0112098/2005/07/25.html#a532: "Am looking forward to it passing the JBI TCK through the Geronimo project." The plan was to test Apache Geronimo with a JBI module backed by ServiceMix and certify *that*. Geronimo would be certified, not ServiceMix. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Closed: (GERONIMO-811) Remove Tomcat option from izpack installer for M4 release
[ http://issues.apache.org/jira/browse/GERONIMO-811?page=all ] John Sisson closed GERONIMO-811: > Remove Tomcat option from izpack installer for M4 release > - > > Key: GERONIMO-811 > URL: http://issues.apache.org/jira/browse/GERONIMO-811 > Project: Geronimo > Type: Task > Components: installer > Versions: 1.0-M4 > Reporter: John Sisson > Assignee: John Sisson > Fix For: 1.0-M4 > > It has been agreed that the Tomcat support will be made available in the M5 > release as the procedures required to get Tomcat running in M4 is too complex > and prone to error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-811) Remove Tomcat option from izpack installer for M4 release
[ http://issues.apache.org/jira/browse/GERONIMO-811?page=all ] John Sisson resolved GERONIMO-811: -- Resolution: Fixed Done. Tested installer. Revision: 225291 Author: jsisson Date: 10:37:56 PM, Tuesday, 26 July 2005 Message: GERONIMO-811 Remove Tomcat option from izpack installer for M4 release Modified : /geronimo/branches/v1_0_M4-QA/modules/assembly/src/izpack/geronimo-izpack.xml Modified : /geronimo/branches/v1_0_M4-QA/modules/assembly/src/izpack/izpack-process.xml Modified : /geronimo/branches/v1_0_M4-QA/modules/assembly/src/izpack/izpack-user-input.xml > Remove Tomcat option from izpack installer for M4 release > - > > Key: GERONIMO-811 > URL: http://issues.apache.org/jira/browse/GERONIMO-811 > Project: Geronimo > Type: Task > Components: installer > Versions: 1.0-M4 > Reporter: John Sisson > Assignee: John Sisson > Fix For: 1.0-M4 > > It has been agreed that the Tomcat support will be made available in the M5 > release as the procedures required to get Tomcat running in M4 is too complex > and prone to error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-453) DerbySystemGBean doesn't call System.gc() in doStop() and soFail() as recommended in the Derby doco
[ http://issues.apache.org/jira/browse/GERONIMO-453?page=all ] John Sisson reassigned GERONIMO-453: Assign To: John Sisson > DerbySystemGBean doesn't call System.gc() in doStop() and soFail() as > recommended in the Derby doco > --- > > Key: GERONIMO-453 > URL: http://issues.apache.org/jira/browse/GERONIMO-453 > Project: Geronimo > Type: Bug > Reporter: John Sisson > Assignee: 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://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-818) Change system-database-plan.xml to specify userid and password on the SystemDatasource and enhance installer to configure it
Change system-database-plan.xml to specify userid and password on the SystemDatasource and enhance installer to configure it Key: GERONIMO-818 URL: http://issues.apache.org/jira/browse/GERONIMO-818 Project: Geronimo Type: Improvement Components: core Versions: 1.0-M4, 1.0-M5 Reporter: John Sisson Assigned to: John Sisson Fix For: 1.0-M5 If a user creates a derby.properties file in geronimo/var/derby that enables Authentication, e.g. # #Security settings # derby.connection.requireAuthentication=true derby.authentication.provider=BUILTIN # # User and password list for Derby BUILTIN authentication provider # derby.user.geronimo=manager derby.user.myapp=myapppswd Then this causes problems with the system-database-plan processing.. e.g. 12:42:07,277 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName="geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/SystemDatabase ,J2EEServer=geronimo,j2eeType=GBean,name=JDBCNonTransactionalThreadPooledTimer" SQL Exception: Connection refused : Invalid authentication. Currently the tables created by Geronimo and ActiveMQ are created by default under the APP schema. If we change the system-database-plan to use the userid 'geronimo', then the tables will be created under a schema of the same name. I would prefer that we don't user a userid of system, as it may be confused with Derby's SYS schema. We need to allow users to configure authentication in Derby without breaking Geronimo. Need to investigate further. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Web Console Status
Was a consensus ever reached on this issue? We need to get this resolved if we are to move the console from the sandbox into the Head in time for M5. I personally liked David Colasurdo's original proposal: Is the required fix as simple as: 1) Rename pluto-portal-1.0.1-rc2.jar to geronimo-pluto-portal.jar 2) Publish the new jar to the Apache maven repository 3) Change the console dependency references to use the new name And Gier's proposal to include this in geronimo/jars ... but that's just me. Alan D. Cabrera wrote: Aaron Mulder wrote, On 7/22/2005 7:19 AM: On Thu, 21 Jul 2005, Geir Magnusson Jr wrote: geronimo/jars (our output) geronimo/wars (our demo apps) geronimo-spec/jars (our spec output) geronimo-dependencies/jars/(put pluto thing here) I think that this is confusing, because things like openejb, mx4j, tomcat... are dependencies too. can we just put the things we create in geronimo/jars? It just seems weird to me to put both "our code" and "other people's code that we packaged" in the same directory. Agreed. Regards, Alan -- Joe Bohn [EMAIL PROTECTED] "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
[jira] Commented: (GERONIMO-817) deploy-jsr88 module has dependency on openejb
[ http://issues.apache.org/jira/browse/GERONIMO-817?page=comments#action_12316759 ] David Jencks commented on GERONIMO-817: --- Upon further thought just using reflection seems like a good short-term solution until a registration scheme can be written. > deploy-jsr88 module has dependency on openejb > - > > Key: GERONIMO-817 > URL: http://issues.apache.org/jira/browse/GERONIMO-817 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4, 1.0-M5 > Reporter: David Jencks > Assignee: Aaron Mulder > Priority: Blocker > Fix For: 1.0-M4, 1.0-M5 > Attachments: nobuilderdependencies > > Apparently in an attempt to support dconfig beans, the deploy-jsr88 module > grew dependencies on several builder modules including openejb builder. This > is a totally non-extensible archtecture and prevents building geronimo and > openejb in any semblance of a reasonable order. I think that some kind of > registration scheme might be plausible but the current hard-coded > dependencies to specific builder implementations are not acceptable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-817) deploy-jsr88 module has dependency on openejb
[ http://issues.apache.org/jira/browse/GERONIMO-817?page=comments#action_12316767 ] Aaron Mulder commented on GERONIMO-817: --- The patch (to disable DConfigBean support) is not acceptable. Reflection is fine for now. Simple registration is not workable becuase a client/tool uses this API when the server is not available (the DisconnectedDeploymentManager). That would argue for a configuration-based format where the config file lists the implementations to use. It's possible that we could have a GBean or Servlet that generates the necessary client JAR, including identifying DConfigBean sources according to what's available in the server at the moment based on a registration scheme, but that seems like it's going kind of a long way, considering we only support OpenEJB anyway. A more straightforward solution might be pull the EJB configuration format into Geronimo like we did for web, so this only depends on Geronimo code in any case. > deploy-jsr88 module has dependency on openejb > - > > Key: GERONIMO-817 > URL: http://issues.apache.org/jira/browse/GERONIMO-817 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4, 1.0-M5 > Reporter: David Jencks > Assignee: Aaron Mulder > Priority: Blocker > Fix For: 1.0-M4, 1.0-M5 > Attachments: nobuilderdependencies > > Apparently in an attempt to support dconfig beans, the deploy-jsr88 module > grew dependencies on several builder modules including openejb builder. This > is a totally non-extensible archtecture and prevents building geronimo and > openejb in any semblance of a reasonable order. I think that some kind of > registration scheme might be plausible but the current hard-coded > dependencies to specific builder implementations are not acceptable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-433) Tolerate non-Sun JREs
[
http://issues.apache.org/jira/browse/GERONIMO-433?page=comments#action_12316768
]
Alan Cabrera commented on GERONIMO-433:
---
Rick McGuire:
I've spent a bit of time looking at you to remove OpenEJB's Sun SDK
dependencies, and have arrived at the conclusion that replacing the Sun ORB
with a truely portable ORB is the only solution. The Sun ORB class references
cause problems with both IBM's SDK 1.4.2 and Suns 5.0 SDK, so this is not an
easy problem to attack. Unfortunately, there appear to be no portable
solutions available for the places where it was necessary to directly reference
the Sun ORB classes directly.
Right now, it looks like the Trifork ORB contribution may be the best means of
achieving SDK portability.
> Tolerate non-Sun JREs
> -
>
> Key: GERONIMO-433
> URL: http://issues.apache.org/jira/browse/GERONIMO-433
> Project: Geronimo
> Type: Improvement
> Components: general
> Reporter: Glyn Normington
> Assignee: Alan Cabrera
> Priority: Critical
>
> Geronimo fails to build against a non-Sun JRE (e.g. IBM's) because of the use
> of non-standard Sun internal classes (in com.sun.* packages) such as
> com.sun.security.jgss.GSSUtil. The build stops with:
> A compilation error occurred in the network module:
> C:\apache\geronimo\modules\network\src\java\org\apache\geronimo\network\protocol\GSSAPIServerProtocol.java:29:
> package com.sun.security.jgss does not exist import
> com.sun.security.jgss.GSSUtil;
> grep also found the following other references to com.sun in Java files, some
> of which will need to be modified to tolerate non-Sun JREs.
> modules/client/src/java/org/apache/geronimo/client/StaticJndiContextPlugin.java:
> System.setProperty("java.naming.factory.initial",
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/connector/src/test/org/apache/geronimo/connector/outbound/ManagedConnectionFactoryWrapperTest.java:
> env.put("java.naming.factory.initial",
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/naming/src/test/org/apache/geronimo/naming/geronimo/GeronimoRootContextTest.java:
> System.setProperty("java.naming.factory.initial",
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/naming/src/test/org/apache/geronimo/naming/java/AbstractContextTest.java:
> System.setProperty("java.naming.factory.initial",
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/naming/src/test/org/apache/geronimo/naming/java/ThreadContextTest.java:
> System.setProperty("java.naming.factory.initial",
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/security/src/java/org/apache/geronimo/security/realm/providers/KerberosSecurityRealm.java:
> AppConfigurationEntry entry = new
> AppConfigurationEntry("com.sun.security.auth.module.Krb5LoginModule",
> modules/security/src/test/org/apache/geronimo/security/jaas/LoginKerberosNonGeronimoTest.java:
> gbean.setAttribute("loginModuleName",
> "com.sun.security.auth.module.Krb5LoginModule");
> modules/security/src/test/org/apache/geronimo/security/network/protocol/SubjectCarryingProtocolTest.java:import
> com.sun.security.auth.login.ConfigFile;
> modules/system/src/test/org/apache/geronimo/system/properties/NamingPropertiesTest.java:
> private static final String NAMING_FACTORY_INITIAL =
> "com.sun.jndi.rmi.registry.RegistryContextFactory";
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: GBeans: Saving Changes
I really like this model and explanation and wonder just how soon we can make it a reality. Last fall I thought we needed the ability to add gbeans to running configurations so you could add datasources, queues, etc to the server while you were getting ready to deploy an app, using an admin console (in fact an earlier version of the one just donated by IBM). However, I think there's a better way to do this, namely, instead of adding bits to the app server to make the environment ready for the app, add bits of app server to the application so it brings what it needs along with itself. Right now we can do this with plain gbeans in all components (such as for security, corba, and web connectors), and resource adapters in app clients. I'm planning the ability to add at least entire resource adapter configurations into other module types, and considering adding the ability to deploy additional complete j2ee modules just using the vendor plan. I can imagine a bit of a ui that analyzes the configurations present in a server (i.e. a bunch of deployed configurations) and your application and shows you what is unresolved in the application, and guides you through either adding more prebuild configs to your server or adding additional stuff into your application so everything is pre-resolved before you try to deploy for the first time. I think with this point of view and possibly with such tools most of the need to add gbeans to running configurations goes away. As for the question of changing and saving gbean attributes in a running configuration, I'm not sure what to think. It seems like an interpreted vs compiled language debate. Right now our "compiler" is decidedly inconvenient for a rapid change cycle: I'm not sure how much faster it would need to get before it seemed like a more reasonable alternative to live changes. thanks david jencks On Jul 25, 2005, at 7:09 PM, Jeremy Boynes wrote: I'd ask you to set aside traditional thinking and try this out for a bit. When you write code, you edit a couple of source files, compile it, fix the typos, build a jar, test it, decide its good enough and commit the change. After doing this a few times you decide its good enough and do a release, taking the jar file you built and saving for posterity. You then do it all over again. If you're doing this with Maven, it spells out the difference between the jar you are working with (a SNAPSHOT) and the jar you release (something with a version number). Sound familiar? In a large production environment you do the same kind of thing with system configurations. You set up a system the way you want, check that it works, beat the snot out of it (aka stress testing or benchmarking), see how/when it falls over, tweak the config and repeat until it you're happy, then document it, have someone else try the change in your staging environment, check it still works, then beg the change control board to let you move it to production at 3AM on a Sunday morning. You then cross your fingers and hope it really works. A bit different from changing things on a desktop machine or the box that runs the family website, but not unrealistic and the problem the architecture was trying to simplify. [[ to avoid a disgression, is Geronimo ready for this? Who knows; in the end the people doing such things factor in the risks associated with any software no matter how mature and they will make up their own minds ]] The idea behind the configuration bundles is that they are pre-wired sets of closely coupled components that co-ordinate to perform a specific task. A single bundle is *not* meant to represent the entire system assembly - the current o/a/g/Server is an abberation caused by problems in the classloader model (described elsewhere) not example of "best practice." The purpose of a bundle is to allow a knowledgable person to, for example, pre-wire a web container in a way that allows other people to use it just by defining a few characteristics. So, for example, someone can go to a repository and find, for example, a pre-wired version of a Jetty bundle pre-configured for 100 concurrent users at 95% static content with a typical dynamic reponse time of 500ms when running on an Acme-4000 Linux machine. So why does this need to be immutable? Because if you are pulling these things from a catalog then you need to know that you're going to get what you expect and not some version that someone happened to tweak but just forgot to change the name. It would be like having several jar files out there called log4j-1.2.8.jar that were actually different - a recipe for chaos. BTW one reason bundles are JAR files is because it's dead easy to sign them so that you can tell if they have been tweaked. Now, just as in the code development example I gave at the top, these kind of pre-packaged bundles are also going to go through a development process. One reason we didn't
Re: GBeans: Saving Changes
I don't understand why Jeremy's vision is incompatible with altering configurations on the fly. That is to say, you change and change and change, and when it's right, you (sign and) export "myconfig-1.3.1.jar". Perhaps that includes a single configuration (web container). Perhaps it contains several (J2EE server in a box, ready to apply to nodes in a cluster). If anyone else posts "myconfig-1.3.1.jar" to your download catalog, then either 1) they're an idiot (just like if I posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not signed with your certificate and can be recognized as a forgery. If we package configurations in JARs (and we haven't defined the "interchange format" to move configurations between servers / config stores but a JAR certainly seems reasonable), then they can be signed using the same tools that are normally avialable. Having immutable configurations does not affect these issues. I can name and version my configuration the same as you do even if they were both totally unchanged at runtime. Without some sense and/or signatures, there's nothing to prevent anything from conflicting. Just like we could post an updated set of M4 QA JARs today with the same name but different content. I'll grant you I could download your configuration and then change it and then blame you if it doesn't work. But I already said I don't mind adding a flag of some sort. And really, what are the odds that a configuration is going to be 100% perfect? What if the web configuration is totally groovy but aimed at a bigger box so you want to tone down the accept thread pool? What if you want to change ports? What if you prefer Jikes? If you must take it entirely without alteration or not at all, I don't think that will be worth so much. As far as the volume of "stuff" in a configuration, we can think of some way to disentangle class loaders from configurations. But we have (in my poor estimation) probably hundreds of GBeans in a server today, and I don't think it makes sense to have tens or hundreds of configurations. That just means that if you want to disable some feature, you have to run loads of commands instead of one. And if you want to download from a catalog, you have a lot more individual stuff to download. It might be useful to separate EJB out from Web and J2EE foundation, but it doesn't bother me all that much -- we already have JMS and JDBC separate, which is a fine start. Not a big deal to me either way. I totally agree with David that it would be great to be able to deploy more bits as parts of an application. I think it's pretty desirable to be able to deploy connectors as part of an application, so you can bundle your DB pool or JMS destinations with your app. However, I don't at all think it makes sense to claim that replaces the ability to adjust server configuration at runtime, and I don't believe that it makes sense to actually bundle web connectors as part of an application. If nothing else, what happens if you have two applications that are both going to run via an AJP connection on port 8009? Which gets the connector? What if one app deploys HTTP on 8080 and another deploys HTTPS on 8080? What if you have developers who prepare applications, and administrators who do server administration? Does it make sense to require that admins have the skills and tools to alter the application plans (potentially damaging the plans that just passed QA)? In any case, to address the compiled vs interpreted bit, if your vision of management is that you must always edit a config file and then run a tool on the config file to replace the old state of the server with the new state, and the web console will always be read-only, I have to respectfully disagree (no matter how fast the tool runs). Thanks, Aaron P.S. I think we should ultimately separate some goals from implementation and agree on things like "would be nice to have portable format for exchanging configurations, with ability to bundle one or more in a JAR and sign it" and "would be nice to be able to deploy connectors with apps". It seems to be the implications we disagree on more than the fundamental goals. On Tue, 26 Jul 2005, David Jencks wrote: > I really like this model and explanation and wonder just how soon we > can make it a reality. > > Last fall I thought we needed the ability to add gbeans to running > configurations so you could add datasources, queues, etc to the server > while you were getting ready to deploy an app, using an admin console > (in fact an earlier version of the one just donated by IBM). > > However, I think there's a better way to do this, namely, instead of > adding bits to the app server to make the environment ready for the > app, add bits of app server to the application so it brings what it > needs along with itself. Right now we can do this with plain gbeans > in all components (such
[jira] Updated: (GERONIMO-817) deploy-jsr88 module has dependency on openejb
[ http://issues.apache.org/jira/browse/GERONIMO-817?page=all ] Aaron Mulder updated GERONIMO-817: -- Fix Version: (was: 1.0-M4) > deploy-jsr88 module has dependency on openejb > - > > Key: GERONIMO-817 > URL: http://issues.apache.org/jira/browse/GERONIMO-817 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4, 1.0-M5 > Reporter: David Jencks > Assignee: Aaron Mulder > Priority: Blocker > Fix For: 1.0-M5 > Attachments: nobuilderdependencies > > Apparently in an attempt to support dconfig beans, the deploy-jsr88 module > grew dependencies on several builder modules including openejb builder. This > is a totally non-extensible archtecture and prevents building geronimo and > openejb in any semblance of a reasonable order. I think that some kind of > registration scheme might be plausible but the current hard-coded > dependencies to specific builder implementations are not acceptable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (GERONIMO-320) Geronimo Realm provider for existing Tomcat Realm implementations
[ http://issues.apache.org/jira/browse/GERONIMO-320?page=all ] Aaron Mulder reopened GERONIMO-320: --- This issue is actually the reverse -- using existing Tomcat realms as Geronimo realm providers (not using Geronimo realms for Tomcat) > Geronimo Realm provider for existing Tomcat Realm implementations > - > > Key: GERONIMO-320 > URL: http://issues.apache.org/jira/browse/GERONIMO-320 > Project: Geronimo > Type: Task > Components: Tomcat, security > Versions: 1.0-M3, 1.0-M4 > Reporter: David Blevins > Assignee: Alan Cabrera > Fix For: 1.0 > > Create an adapter to leverage Tomcat Realm implementations as RealmProviders > in the Geronimo security framework. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-320) Geronimo Realm provider for existing Tomcat Realm implementations
[ http://issues.apache.org/jira/browse/GERONIMO-320?page=all ] Aaron Mulder updated GERONIMO-320: -- Fix Version: 1.0 (was: 1.0-M4) Version: 1.0-M3 1.0-M4 Environment: Priority: Minor (was: Major) > Geronimo Realm provider for existing Tomcat Realm implementations > - > > Key: GERONIMO-320 > URL: http://issues.apache.org/jira/browse/GERONIMO-320 > Project: Geronimo > Type: Task > Components: Tomcat, security > Versions: 1.0-M3, 1.0-M4 > Reporter: David Blevins > Assignee: Alan Cabrera > Priority: Minor > Fix For: 1.0 > > Create an adapter to leverage Tomcat Realm implementations as RealmProviders > in the Geronimo security framework. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: GBeans: Saving Changes
Aaron Mulder wrote: I don't understand why Jeremy's vision is incompatible with altering configurations on the fly. That is to say, you change and change and change, and when it's right, you (sign and) export "myconfig-1.3.1.jar". Perhaps that includes a single configuration (web container). Perhaps it contains several (J2EE server in a box, ready to apply to nodes in a cluster). If anyone else posts "myconfig-1.3.1.jar" to your download catalog, then either 1) they're an idiot (just like if I posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not signed with your certificate and can be recognized as a forgery. If we package configurations in JARs (and we haven't defined the "interchange format" to move configurations between servers / config stores but a JAR certainly seems reasonable), then they can be signed using the same tools that are normally avialable. Having immutable configurations does not affect these issues. I can name and version my configuration the same as you do even if they were both totally unchanged at runtime. Without some sense and/or signatures, there's nothing to prevent anything from conflicting. Just like we could post an updated set of M4 QA JARs today with the same name but different content. You alude to the problem yourself without realizing it. We have an example of the problem right now with our build system and its use of SNAPSHOT jars. SNAPSHOTs are mutable. Their content varies over time based on whatever happened to be in the source tree when they were built. If you have a SNAPSHOT artifactId you won't know from one build to another that you are using the same code. To the person developing that artifact, that it is a SNAPSHOT doesn't matter - it's output work product to them, what they are using is the source tree. However, to the person using the library it does matter. If they rely on a SNAPSHOT published to a repo they can't rely on getting the same code each time. If they need stability they need to use an explicit version. If the publisher publishes two different codebases under the same version number then, to use your phrasing, "they're an idiot" and as a user you start looking for alternatives. In other words, you want released artifacts to be immutable and versioned. To have a consistent release we can't use mutable SNAPSHOTS and we (primarily John) are going through and replacing them with immutable versions. Putting this in the configuration context, when you start modifying a configuration you are "developing" it - you're tweaking it to do what you want. This is not a problem for you. However, it is a problem for things that "use" that configuration and have certain expectations on its behaviour as it is now doing what you want and not what it advertised that it could do. There are things in the system that "use" your configuration - the config builders and the applications that they build are two examples. If you mutate the Server configuration from using Jetty to using Tomcat, an application that was built against that configuration with the assumption that it was Jetty will no longer work. The HTTP connector example we are so fond of is a bad one as nothing "uses" that bundle - it is a user of other bundles, dispatching requests to them but nothing actually references it. You can mutate it to your heart's content and nothing will notice. As an alternative, consider an example where an application contains a message-link that uses a queue. The application builder can look at the server configuration, see that there is no queue there and decide that it should define one in the application bundle. That bundle can be moved to any instance running that server configuration and will run quite happily as it is taking its queue along with it. However, if the server configuration is mutated on some instances so that it has a queue you now have a conflict: two queues, one from the mutated server, one from the application. Or if the configuration is mutated to use a different message provider then it may not work at all. The challenge we face is finding a balance between the things that can mutate that no-one will notice and things that should be immutable so that they can reliably be used by others. -- Jeremy
Re: GBeans: Saving Changes
FYI, I'm considering this a discussion on our long-term policy. In the immediate future, I'm planning to go ahead with mutable configurations to support the desired functionality in the web console. I'm definitely open to revising that when the time comes and we have a more comprehensive strategy around this. Aaron On Tue, 26 Jul 2005, Jeremy Boynes wrote: > Aaron Mulder wrote: > > I don't understand why Jeremy's vision is incompatible with > > altering configurations on the fly. That is to say, you change and change > > and change, and when it's right, you (sign and) export > > "myconfig-1.3.1.jar". Perhaps that includes a single configuration (web > > container). Perhaps it contains several (J2EE server in a box, ready to > > apply to nodes in a cluster). If anyone else posts "myconfig-1.3.1.jar" > > to your download catalog, then either 1) they're an idiot (just like if I > > posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not > > signed with your certificate and can be recognized as a forgery. If we > > package configurations in JARs (and we haven't defined the "interchange > > format" to move configurations between servers / config stores but a JAR > > certainly seems reasonable), then they can be signed using the same tools > > that are normally avialable. > > > > Having immutable configurations does not affect these issues. I > > can name and version my configuration the same as you do even if they were > > both totally unchanged at runtime. Without some sense and/or signatures, > > there's nothing to prevent anything from conflicting. Just like we could > > post an updated set of M4 QA JARs today with the same name but different > > content. > > > > You alude to the problem yourself without realizing it. We have an > example of the problem right now with our build system and its use of > SNAPSHOT jars. > > SNAPSHOTs are mutable. Their content varies over time based on whatever > happened to be in the source tree when they were built. If you have a > SNAPSHOT artifactId you won't know from one build to another that you > are using the same code. > > To the person developing that artifact, that it is a SNAPSHOT doesn't > matter - it's output work product to them, what they are using is the > source tree. > > However, to the person using the library it does matter. If they rely on > a SNAPSHOT published to a repo they can't rely on getting the same code > each time. If they need stability they need to use an explicit version. > If the publisher publishes two different codebases under the same > version number then, to use your phrasing, "they're an idiot" and as a > user you start looking for alternatives. In other words, you want > released artifacts to be immutable and versioned. > > To have a consistent release we can't use mutable SNAPSHOTS and we > (primarily John) are going through and replacing them with immutable > versions. > > Putting this in the configuration context, when you start modifying a > configuration you are "developing" it - you're tweaking it to do what > you want. This is not a problem for you. However, it is a problem for > things that "use" that configuration and have certain expectations on > its behaviour as it is now doing what you want and not what it > advertised that it could do. > > There are things in the system that "use" your configuration - the > config builders and the applications that they build are two examples. > If you mutate the Server configuration from using Jetty to using Tomcat, > an application that was built against that configuration with the > assumption that it was Jetty will no longer work. > > The HTTP connector example we are so fond of is a bad one as nothing > "uses" that bundle - it is a user of other bundles, dispatching requests > to them but nothing actually references it. You can mutate it to your > heart's content and nothing will notice. > > As an alternative, consider an example where an application contains a > message-link that uses a queue. The application builder can look at the > server configuration, see that there is no queue there and decide that > it should define one in the application bundle. That bundle can be moved > to any instance running that server configuration and will run quite > happily as it is taking its queue along with it. However, if the server > configuration is mutated on some instances so that it has a queue you > now have a conflict: two queues, one from the mutated server, one from > the application. Or if the configuration is mutated to use a different > message provider then it may not work at all. > > The challenge we face is finding a balance between the things that can > mutate that no-one will notice and things that should be immutable so > that they can reliably be used by others. > > -- > Jeremy >
Re: GBeans: Saving Changes
there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this without more thought and a clear upgrade path to whatever we decide we want to do long-term. Still, this seems more reasonable to me than (1). thanks david jencks On Jul 26, 2005, at 2:18 PM, Aaron Mulder wrote: FYI, I'm considering this a discussion on our long-term policy. In the immediate future, I'm planning to go ahead with mutable configurations to support the desired functionality in the web console. I'm definitely open to revising that when the time comes and we have a more comprehensive strategy around this. Aaron On Tue, 26 Jul 2005, Jeremy Boynes wrote: Aaron Mulder wrote: I don't understand why Jeremy's vision is incompatible with altering configurations on the fly. That is to say, you change and change and change, and when it's right, you (sign and) export "myconfig-1.3.1.jar". Perhaps that includes a single configuration (web container). Perhaps it contains several (J2EE server in a box, ready to apply to nodes in a cluster). If anyone else posts "myconfig-1.3.1.jar" to your download catalog, then either 1) they're an idiot (just like if I posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not signed with your certificate and can be recognized as a forgery. If we package configurations in JARs (and we haven't defined the "interchange format" to move configurations between servers / config stores but a JAR certainly seems reasonable), then they can be signed using the same tools that are normally avialable. Having immutable configurations does not affect these issues. I can name and version my configuration the same as you do even if they were both totally unchanged at runtime. Without some sense and/or signatures, there's nothing to prevent anything from conflicting. Just like we could post an updated set of M4 QA JARs today with the same name but different content. You alude to the problem yourself without realizing it. We have an example of the problem right now with our build system and its use of SNAPSHOT jars. SNAPSHOTs are mutable. Their content varies over time based on whatever happened to be in the source tree when they were built. If you have a SNAPSHOT artifactId you won't know from one build to another that you are using the same code. To the person developing that artifact, that it is a SNAPSHOT doesn't matter - it's output work product to them, what they are using is the source tree. However, to the person using the library it does matter. If they rely on a SNAPSHOT published to a repo they can't rely on getting the same code each time. If they need stability they need to use an explicit version. If the publisher publishes two different codebases under the same version number then, to use your phrasing, "they're an idiot" and as a user you start looking for alternatives. In other words, you want released artifacts to be immutable and versioned. To have a consistent release we can't use mutable SNAPSHOTS and we (primarily John) are going through and replacing them with immutable versions. Putting this in the configuration context, when you start modifying a configuration you are "developing" it - you're tweaking it to do what you want. This is not a problem for you. However, it is a problem for things that "use" that configuration and have certain expectations on its behaviour as it is now doing what you want and not what it advertised that it could do. There are things in the system that "use" your configuration - the config builders and the applications that they build are two examples. If you mutate the Server configuration from using Jetty to using Tomcat, an application that was built against that configuration with the assumption that it was Jetty will no longer work. The HTTP connector example we are so fond of is a bad one as nothing "uses" that bundle - it is a user of other bundles, dispatching requests to them but nothing actually references it. You can mutate it to your heart's content and nothing will notice. As an alternative, consider an example where an application contains a message-link that uses a queue. The application builder can look at the server configuration, see that there is no queue there and decide that it should define one in the application bundle. That bundle can be
Re: GBeans: Saving Changes
On Tue, 26 Jul 2005, David Jencks wrote: > there are at least 2 aspects to mutable configurations. > > 1. adding/ removing gbeans. I don't think there is a valid use case > for this and don't think we should support it, ever. I don't think we > should allow changing reference patterns either for essentially the > same reasons. Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Under the covers, a connector GBean has been added to the o/a/g/Server Configuration. > 2. changing attribute values on pre-existing gbeans. To me this is > less clear. I'm not thrilled with the idea of changing the content of > a configuration jar: I'd prefer to see local modifications saved in a > local database outside the supplied configurations. I can see how you > would want to play with a running server till you like it, then save > and seal a configuration, but I'm reluctant to allow this without more > thought and a clear upgrade path to whatever we decide we want to do > long-term. Still, this seems more reasonable to me than (1). Use case: server ships with HTTPS pointing to a self-signed cert. You want to point it to a real cert, which requires the server to use a password different than "secret". You go to the console, fill out a form, and the GBean property is changed to use the correct password. As for your implementation thoughts, I thought this is essentially what was implemented -- that saved state was saved to a different place than original state. I do not think we need the scope creep of creating another database just for this. Aaron
Re: GBeans: Saving Changes
IMO both of these are much better done as part of the offline deployment process well before the configuration gets anywhere near a running server. Both of these are reasonable things to do, but again IMO not on a running server. I'm not really sure how the current configuration saving works. thanks david jencks On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote: On Tue, 26 Jul 2005, David Jencks wrote: there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Under the covers, a connector GBean has been added to the o/a/g/Server Configuration. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this without more thought and a clear upgrade path to whatever we decide we want to do long-term. Still, this seems more reasonable to me than (1). Use case: server ships with HTTPS pointing to a self-signed cert. You want to point it to a real cert, which requires the server to use a password different than "secret". You go to the console, fill out a form, and the GBean property is changed to use the correct password. As for your implementation thoughts, I thought this is essentially what was implemented -- that saved state was saved to a different place than original state. I do not think we need the scope creep of creating another database just for this. Aaron
Re: GBeans: Saving Changes
Aaron Mulder wrote: Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Implementation: you set the magic "enabled" attribute causing the disabled bean to be started. New value of the property is saved in the database[1]. This is already possible. No modification to the o/a/g/Server configuration is required. Use case: You want to add a second HTTP connector. On the console you fill in a form describing the usage pattern of the new interface Implementation: using knowledge of the container in use and data from the form the console selects a suitable connector configuration from its catalog and adds it into the list of running configurations. No modification to the o/a/g/Server configuration is required. This is already possible with the degree of sophistication varying based on how the console locates the template configuration; a rudimentary implementation could just be code in the console (which IIRC is how JMS queues get added) Use case: server ships with HTTPS pointing to a self-signed cert. You want to point it to a real cert, which requires the server to use a password different than "secret". You go to the console, fill out a form, and the GBean property is changed to use the correct password. Implementation: property value is saved in the database No modification to the o/a/g/Server configuration is required. As for your implementation thoughts, I thought this is essentially what was implemented -- that saved state was saved to a different place than original state. I do not think we need the scope creep of creating another database just for this. [1] Database in this case is the dump of persistent attribute values that is currently held inside the config store. This implementation has problems (like no way to merge in modified values when a new version of a configuration is installed) but those are a separate discussion. -- Jeremy
Re: GBeans: Saving Changes
+1 for adding support for adding services to and removing services from a configuration On Jul 26, 2005, at 2:40 PM, David Jencks wrote: IMO both of these are much better done as part of the offline deployment process well before the configuration gets anywhere near a running server. Both of these are reasonable things to do, but again IMO not on a running server. I don't think there is any way to avoid it in the current design. I'm not really sure how the current configuration saving works. Simple. In doStop of the configuration we package up the current configuration state and then tell the configuration store, the one from which the configuration was originally loaded, to update the configuration. The local cofinguration store simply, creates a new serilized file in the configuration "save.ser". There is only one save version, so you could conceivably rollback to the original saved state, but not to a previous revision. Of course we have no "rollback" logic anywhere in the current code base. -dain
Re: GBeans: Saving Changes
David, I believe we need to be able to make this kind of change to a running server. The commercial products we're (at least in theory) competing with all support making this kind of change through their management console, though for certain types of changes a server restart is required. Changing the port you're using to connect to the console at runtime would be a little weird, but I'm strongly opposed to requiring someone to locate, modify, and redeploy the o/a/g/Server plan in order to make any change at all. Jeremy, I agree that changing an attribute value does not need to alter "the configuration" based on what is implemented today. IIUC, when you alter a GBean, a new set of config info is written to a separate file, and next time the configuration is loaded that file is read and the new value kicks in instead of the original value. So you have both the unaltered original configuration and the modified "current state", and it just happens that future server starts will use that "current state" (though I suppose we could provide some sort of command to revert a configuration to its original state). That would actually be a kind of cool option in the console -- "revert to factory default settings". Maybe I've been casting this entire discussion in the wrong way. Both changes to GBean properties and adds/removes of GBeans can be accomplished by adjusting the "current state" saved *in addition to* the original state -- so at the end of the day, we're not really altering "the configuration", we're preserving the original configuration and altering our "current state for the configuration". Perhaps we're in violent agreement. :) Aaron On Tue, 26 Jul 2005, David Jencks wrote: > IMO both of these are much better done as part of the offline > deployment process well before the configuration gets anywhere near a > running server. Both of these are reasonable things to do, but again > IMO not on a running server. > > I'm not really sure how the current configuration saving works. > > thanks > david jencks > On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote: > > > On Tue, 26 Jul 2005, David Jencks wrote: > >> there are at least 2 aspects to mutable configurations. > >> > >> 1. adding/ removing gbeans. I don't think there is a valid use case > >> for this and don't think we should support it, ever. I don't think we > >> should allow changing reference patterns either for essentially the > >> same reasons. > > > > Use case: Server ships with HTTPS or AJP disabled. You want to enable > > it. > > You go to the console, fill in a form, click a button, it is now > > running. > > Under the covers, a connector GBean has been added to the o/a/g/Server > > Configuration. > > > >> 2. changing attribute values on pre-existing gbeans. To me this is > >> less clear. I'm not thrilled with the idea of changing the content of > >> a configuration jar: I'd prefer to see local modifications saved in a > >> local database outside the supplied configurations. I can see how you > >> would want to play with a running server till you like it, then save > >> and seal a configuration, but I'm reluctant to allow this without more > >> thought and a clear upgrade path to whatever we decide we want to do > >> long-term. Still, this seems more reasonable to me than (1). > > > > Use case: server ships with HTTPS pointing to a self-signed cert. You > > want to point it to a real cert, which requires the server to use a > > password different than "secret". You go to the console, fill out a > > form, > > and the GBean property is changed to use the correct password. > > > > As for your implementation thoughts, I thought this is essentially what > > was implemented -- that saved state was saved to a different place than > > original state. I do not think we need the scope creep of creating > > another database just for this. > > > > Aaron > > > >
Re: GBeans: Saving Changes
BTW this is already has a JIRA entry GERONIMO-400. I added this almost a year ago. -dain On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote: David, I believe we need to be able to make this kind of change to a running server. The commercial products we're (at least in theory) competing with all support making this kind of change through their management console, though for certain types of changes a server restart is required. Changing the port you're using to connect to the console at runtime would be a little weird, but I'm strongly opposed to requiring someone to locate, modify, and redeploy the o/a/g/Server plan in order to make any change at all. Jeremy, I agree that changing an attribute value does not need to alter "the configuration" based on what is implemented today. IIUC, when you alter a GBean, a new set of config info is written to a separate file, and next time the configuration is loaded that file is read and the new value kicks in instead of the original value. So you have both the unaltered original configuration and the modified "current state", and it just happens that future server starts will use that "current state" (though I suppose we could provide some sort of command to revert a configuration to its original state). That would actually be a kind of cool option in the console -- "revert to factory default settings". Maybe I've been casting this entire discussion in the wrong way. Both changes to GBean properties and adds/removes of GBeans can be accomplished by adjusting the "current state" saved *in addition to* the original state -- so at the end of the day, we're not really altering "the configuration", we're preserving the original configuration and altering our "current state for the configuration". Perhaps we're in violent agreement. :) Aaron On Tue, 26 Jul 2005, David Jencks wrote: IMO both of these are much better done as part of the offline deployment process well before the configuration gets anywhere near a running server. Both of these are reasonable things to do, but again IMO not on a running server. I'm not really sure how the current configuration saving works. thanks david jencks On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote: On Tue, 26 Jul 2005, David Jencks wrote: there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Under the covers, a connector GBean has been added to the o/a/g/ Server Configuration. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this without more thought and a clear upgrade path to whatever we decide we want to do long-term. Still, this seems more reasonable to me than (1). Use case: server ships with HTTPS pointing to a self-signed cert. You want to point it to a real cert, which requires the server to use a password different than "secret". You go to the console, fill out a form, and the GBean property is changed to use the correct password. As for your implementation thoughts, I thought this is essentially what was implemented -- that saved state was saved to a different place than original state. I do not think we need the scope creep of creating another database just for this. Aaron
[jira] Assigned: (GERONIMO-400) Add/remove gbeans to an exisiting configuration
[ http://issues.apache.org/jira/browse/GERONIMO-400?page=all ] Dain Sundstrom reassigned GERONIMO-400: --- Assign To: Aaron Mulder (was: Dain Sundstrom) > Add/remove gbeans to an exisiting configuration > --- > > Key: GERONIMO-400 > URL: http://issues.apache.org/jira/browse/GERONIMO-400 > Project: Geronimo > Type: New Feature > Components: kernel > Reporter: Dain Sundstrom > Assignee: Aaron Mulder > > It should be possible to add gbeans to and remove gbeans from an existing > configuration. Without this feature we end up with lots of little > configurations containing a single gbean such as javamail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-234) Build fails when maven/plugins is not writable
[ http://issues.apache.org/jira/browse/GERONIMO-234?page=all ] Dain Sundstrom closed GERONIMO-234: --- Resolution: Fixed This was resolved a long time ago. > Build fails when maven/plugins is not writable > -- > > Key: GERONIMO-234 > URL: http://issues.apache.org/jira/browse/GERONIMO-234 > Project: Geronimo > Type: Improvement > Components: buildsystem > Versions: 1.0-M1 > Environment: Linux [Debian | SuSE ], Maven RC1, Geronimo HEAD > Reporter: Bernd Fondermann > Assignee: Dain Sundstrom > Priority: Minor > > When building by invoking 'maven' the build fails with the following error > message when the maven plugin directory is not writable: > + > | Executing (default): Geronimo :: Deployment > | Memory: 34M/43M > + > Attempting to download geronimo-xmlbeans-plugin-1.0-SNAPSHOT.jar. > Attempting to download geronimo-kernel-1.0-SNAPSHOT.jar. > Attempting to download geronimo-common-1.0-SNAPSHOT.jar. > Attempting to download geronimo-system-1.0-SNAPSHOT.jar. > BUILD FAILED > File.. file:/home/username/apache/incubator-geronimo/ > Element... maven:reactor > Line.. 180 > Column 27 > /usr/local/maven-1.0-rc1/plugins/geronimo-xmlbeans-plugin-1.0-SNAPSHOT.jar > (Permission denied) > The immediate fix is to make plugins folder writable. > I don't like any project modifying their sibbling projects... couldn't this > also lead to unexpected results in a multi-user environment where maven is > shared among users? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-400) Add/remove gbeans to an exisiting configuration
[ http://issues.apache.org/jira/browse/GERONIMO-400?page=comments#action_12316807 ] David Jencks commented on GERONIMO-400: --- While I originally thought this was a good idea, I now have really strong reservations about it and would prefer more discussion before it is implemented. I think "disabled" gbeans in a configuration are a much better solution to the kind of problems I think this is intended to address. > Add/remove gbeans to an exisiting configuration > --- > > Key: GERONIMO-400 > URL: http://issues.apache.org/jira/browse/GERONIMO-400 > Project: Geronimo > Type: New Feature > Components: kernel > Reporter: Dain Sundstrom > Assignee: Aaron Mulder > > It should be possible to add gbeans to and remove gbeans from an existing > configuration. Without this feature we end up with lots of little > configurations containing a single gbean such as javamail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-254) ServerInfo is too darned useful
[ http://issues.apache.org/jira/browse/GERONIMO-254?page=all ] Dain Sundstrom closed GERONIMO-254: --- Resolution: Won't Fix Coupling lots of services to ServerInfo is a sign of a poor configuration system. We need to address the root case instead of masking it with an easier interface. > ServerInfo is too darned useful > --- > > Key: GERONIMO-254 > URL: http://issues.apache.org/jira/browse/GERONIMO-254 > Project: Geronimo > Type: Improvement > Components: general > Versions: 1.0-M2 > Reporter: Jeremy Boynes > Assignee: Dain Sundstrom > Priority: Minor > > This GBean provides information on the system including the location of the > install which is used to find data files. The location itself is transient > (so installs can be moved) but needs to be injected early. > It seems reasonable to have a reference to this available by magic, which > means moving it to the kernel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: GBeans: Saving Changes
On Jul 26, 2005, at 3:06 PM, Dain Sundstrom wrote: BTW this is already has a JIRA entry GERONIMO-400. I added this almost a year ago. No wonder I couldn't find it. I thought I added it :-) Now that how saving configuration works has been explained so even I can understand it, I don't have any problem in saving configuration locally. I can even imagine a tool to merge a local state with a configuration to produce a new configuration (with a different version number or name). Before we jump into adding gbeans to a running configuration, can we please think about whether the "disabled gbean" approach would work just as well, and, if not, if the "application centered deployment" idea would work better. IIRC the original motivation behind GERONIMO-400 was to put the admin objects you can add by the admin portal into the original jms configuration rather than making a separate configuration per queue/topic. If you have the opportunity to add the admin objects while you are deploying your app that will use them, I can't actually see any reason to support deploying "standalone" admin objects at all, whatever configuration they go into. thanks david jencks -dain On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote: David, I believe we need to be able to make this kind of change to a running server. The commercial products we're (at least in theory) competing with all support making this kind of change through their management console, though for certain types of changes a server restart is required. Changing the port you're using to connect to the console at runtime would be a little weird, but I'm strongly opposed to requiring someone to locate, modify, and redeploy the o/a/g/Server plan in order to make any change at all. Jeremy, I agree that changing an attribute value does not need to alter "the configuration" based on what is implemented today. IIUC, when you alter a GBean, a new set of config info is written to a separate file, and next time the configuration is loaded that file is read and the new value kicks in instead of the original value. So you have both the unaltered original configuration and the modified "current state", and it just happens that future server starts will use that "current state" (though I suppose we could provide some sort of command to revert a configuration to its original state). That would actually be a kind of cool option in the console -- "revert to factory default settings". Maybe I've been casting this entire discussion in the wrong way. Both changes to GBean properties and adds/removes of GBeans can be accomplished by adjusting the "current state" saved *in addition to* the original state -- so at the end of the day, we're not really altering "the configuration", we're preserving the original configuration and altering our "current state for the configuration". Perhaps we're in violent agreement. :) Aaron On Tue, 26 Jul 2005, David Jencks wrote: IMO both of these are much better done as part of the offline deployment process well before the configuration gets anywhere near a running server. Both of these are reasonable things to do, but again IMO not on a running server. I'm not really sure how the current configuration saving works. thanks david jencks On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote: On Tue, 26 Jul 2005, David Jencks wrote: there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Under the covers, a connector GBean has been added to the o/a/g/Server Configuration. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this without more thought and a clear upgrade path to whatever we decide we want to do long-term. Still, this seems more reasonable to me than (1). Use case: server ships with HTTPS pointing to a self-signed cert. You want to point it to a real cert, which requires the server to use a password different than "secret". You go to the console, fill out a form, and the GBean property is changed to use the correct password. As for your implementation thoughts, I thought this is essentially what was implemented -- that saved state was saved to a different place than original state. I do not think we need the scope creep of creating a
[jira] Commented: (GERONIMO-400) Add/remove gbeans to an exisiting configuration
[ http://issues.apache.org/jira/browse/GERONIMO-400?page=comments#action_12316812 ] Aaron Mulder commented on GERONIMO-400: --- I don't think that's a good solution. For one thing, in many cases you might want to create several items. For example, how many disabled LoginModules would you add to a security realm configuration to allow fo future additions? For another, why is it better to have a bunch of empty unused stuff that will be modified in the future, rather than just adding new stuff as it's needed? > Add/remove gbeans to an exisiting configuration > --- > > Key: GERONIMO-400 > URL: http://issues.apache.org/jira/browse/GERONIMO-400 > Project: Geronimo > Type: New Feature > Components: kernel > Reporter: Dain Sundstrom > Assignee: Aaron Mulder > > It should be possible to add gbeans to and remove gbeans from an existing > configuration. Without this feature we end up with lots of little > configurations containing a single gbean such as javamail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: GBeans: Saving Changes
On Tue, 26 Jul 2005, David Jencks wrote:
> Now that how saving configuration works has been explained so even I
> can understand it, I don't have any problem in saving configuration
> locally. I can even imagine a tool to merge a local state with a
> configuration to produce a new configuration (with a different version
> number or name).
Great.
> Before we jump into adding gbeans to a running
> configuration, can we please think about whether the "disabled gbean"
> approach would work just as well, and, if not, if the "application
> centered deployment" idea would work better. IIRC the original
> motivation behind GERONIMO-400 was to put the admin objects you can add
> by the admin portal into the original jms configuration rather than
> making a separate configuration per queue/topic. If you have the
> opportunity to add the admin objects while you are deploying your app
> that will use them, I can't actually see any reason to support
> deploying "standalone" admin objects at all, whatever configuration
> they go into.
RE "disabled GBeans" ("blanks"): The counter-example I gave in JIRA was
security realms, which may use any number of LoginModules. It doesn't
make sense to me to add "enough" blanks that you're sure no one would ever
want to add more than that, nor to require that someone writing a new plan
for their own purposes add "enough" blanks to accomodate future changes
via the web console. What number would you tell them? 10? 5?
RE "app-centric deployment": And again, I believe there are cases where
server administrators will be configuring the services in the server, and
will not have the skills or tools to alter embedded XML files in the
application configuration. This is more realistic for web listen ports,
security realms, databases (where devs may not have prod DB password) or
J2CA connections to back-end services than for admin objects (which I
admit could often be best packaged with an application). Even without the
administrator vs. developer issue, imagine staging your application from
dev to test to production, where each server has connections to different
databases and back-end services. It would be much nicer to put that
configuration in the app server, so the application itself can be totally
unchanged when it's migrated between environments. The application says
"I use a data source called 'DB2'", and the server provides the data
source pointing to a specific database, different in each of the 3
environments.
I do like the *ability* to deploy data sources with an app -- just not
making it the only options.
Aaron
Re: GBeans: Saving Changes
Aaron Mulder wrote: Maybe I've been casting this entire discussion in the wrong way. Both changes to GBean properties and adds/removes of GBeans can be accomplished by adjusting the "current state" saved *in addition to* the original state -- so at the end of the day, we're not really altering "the configuration", we're preserving the original configuration and altering our "current state for the configuration". Perhaps we're in violent agreement. :) Almost but not quite. The problem comes with which version of the state is used by things like the (runtime) deployer to build new configurations. If it uses the "original" then the new configuration may not run with the "current" one; if it uses the "current" then it may not run on a server using the "original" one. This may never become apparent if the configurations are never moved between servers. However, being able to do that was half the point - e.g. build the bundle on a master node in a cluster and then automatically push it to worker nodes. It is also a requirement for offline or in-Maven packaging where the deployer will be using the "original" version and not the "current" modified one. This is not a question of whether it is technically possible to make bundles mutable - the construction phase gets much easier if they are. It is whether they are usable by anything else after they have been mutated. I think we all agree that modifying attribute values and persisting the changes is a good idea. David has proposed saving this separately from the internal structure of the bundle and that seems like an idea worth exploring. I'd go further and suggest we separate bundle level properties from component level ones (at least for this kind of management) but that is something we really haven't discussed at all. Where we still seem to disagree is on whether structural changes to the bundle are a good idea. So far I haven't seen any solution that allows this and addresses the technical problems raised above and don't think we should go down this route until we have consensus. -- Jeremy
Re: GBeans: Saving Changes
How is enabling and subsequently configuring a service is substantially different then just adding a new one? Simmilary, why is disabling a service substantially different then removing it? -dain On Jul 26, 2005, at 3:23 PM, David Jencks wrote: On Jul 26, 2005, at 3:06 PM, Dain Sundstrom wrote: BTW this is already has a JIRA entry GERONIMO-400. I added this almost a year ago. No wonder I couldn't find it. I thought I added it :-) Now that how saving configuration works has been explained so even I can understand it, I don't have any problem in saving configuration locally. I can even imagine a tool to merge a local state with a configuration to produce a new configuration (with a different version number or name). Before we jump into adding gbeans to a running configuration, can we please think about whether the "disabled gbean" approach would work just as well, and, if not, if the "application centered deployment" idea would work better. IIRC the original motivation behind GERONIMO-400 was to put the admin objects you can add by the admin portal into the original jms configuration rather than making a separate configuration per queue/topic. If you have the opportunity to add the admin objects while you are deploying your app that will use them, I can't actually see any reason to support deploying "standalone" admin objects at all, whatever configuration they go into. thanks david jencks -dain On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote: David, I believe we need to be able to make this kind of change to a running server. The commercial products we're (at least in theory) competing with all support making this kind of change through their management console, though for certain types of changes a server restart is required. Changing the port you're using to connect to the console at runtime would be a little weird, but I'm strongly opposed to requiring someone to locate, modify, and redeploy the o/a/g/Server plan in order to make any change at all. Jeremy, I agree that changing an attribute value does not need to alter "the configuration" based on what is implemented today. IIUC, when you alter a GBean, a new set of config info is written to a separate file, and next time the configuration is loaded that file is read and the new value kicks in instead of the original value. So you have both the unaltered original configuration and the modified "current state", and it just happens that future server starts will use that "current state" (though I suppose we could provide some sort of command to revert a configuration to its original state). That would actually be a kind of cool option in the console -- "revert to factory default settings". Maybe I've been casting this entire discussion in the wrong way. Both changes to GBean properties and adds/removes of GBeans can be accomplished by adjusting the "current state" saved *in addition to* the original state -- so at the end of the day, we're not really altering "the configuration", we're preserving the original configuration and altering our "current state for the configuration". Perhaps we're in violent agreement. :) Aaron On Tue, 26 Jul 2005, David Jencks wrote: IMO both of these are much better done as part of the offline deployment process well before the configuration gets anywhere near a running server. Both of these are reasonable things to do, but again IMO not on a running server. I'm not really sure how the current configuration saving works. thanks david jencks On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote: On Tue, 26 Jul 2005, David Jencks wrote: there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Under the covers, a connector GBean has been added to the o/a/g/ Server Configuration. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this without more thought and a clear upgrade path to whatever we decide we want to do long-term. Still, this seems more reasonable to me than (1). Use case: server ships with HTTPS pointing to a self-signed cert. You want to point it to a real cert, which requires the server to use a password different than "secret". You
[jira] Reopened: (GERONIMO-254) ServerInfo is too darned useful
[ http://issues.apache.org/jira/browse/GERONIMO-254?page=all ] Jeremy Boynes reopened GERONIMO-254: Reopened as a placeholder until we know what the "root cause" is. Perhaps then we can close this and link to the issue that is fixing that problem. > ServerInfo is too darned useful > --- > > Key: GERONIMO-254 > URL: http://issues.apache.org/jira/browse/GERONIMO-254 > Project: Geronimo > Type: Improvement > Components: general > Versions: 1.0-M2 > Reporter: Jeremy Boynes > Assignee: Dain Sundstrom > Priority: Minor > > This GBean provides information on the system including the location of the > install which is used to find data files. The location itself is transient > (so installs can be moved) but needs to be injected early. > It seems reasonable to have a reference to this available by magic, which > means moving it to the kernel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: GBeans: Saving Changes
Dain Sundstrom wrote: How is enabling and subsequently configuring a service is substantially different then just adding a new one? Simmilary, why is disabling a service substantially different then removing it? I'm not a great fan of the "disabled" component option either - I just used it because Aaron's example referred to a "disabled" connector. Having said that, there is a big difference between a "disabled" service and an absent service - you know that is it there and hence can refer to it. It becomes a placeholder. -- Jeremy
Re: GBeans: Saving Changes
FYI, I don't think this is a technical issue, I think this is a scope issue. You're talking about how to support "build the bundle on a master node in a cluster and then automatically push it to worker nodes" and how to support features that no other app server has. I'm talking about how to provide a usable management environment for ONE server, which is something we most definitely need to be competitive. We have to get past reasonable 1-server support (plus of course add clustering support) before we need the features you're describing. I feel that we should proceed with a short-term option and plan to refactor when we are at a place where supporting the environment you're describing becomes feasible. It doesn't make sense to me to not proceed with any change until we can solve every problem we might ever have. That said, back to the issue: On Tue, 26 Jul 2005, Jeremy Boynes wrote: > The problem comes with which version of the state is used by things like > the (runtime) deployer to build new configurations. > > If it uses the "original" then the new configuration may not run with > the "current" one; if it uses the "current" then it may not run on a > server using the "original" one. This is true today; if we don't implement add/remove, we still have the problem. For example, you could deploy an EJB that depends on a data source, then go change the password used by the data source to be invalid so it doesn't start or function, thereby breaking your EJB. This is true of every app server that I've ever used. I don't consider it to be a critical flaw of the product. But of course it would be nice to have a way around it down the road. > This may never become apparent if the configurations are never moved > between servers. However, being able to do that was half the point - > e.g. build the bundle on a master node in a cluster and then > automatically push it to worker nodes. > > It is also a requirement for offline or in-Maven packaging where the > deployer will be using the "original" version and not the "current" > modified one. Why won't the deployer use the current state in offline mode? If it touches it at all, it should use the same "current" state that the server would use if it started. Otherwise, what's the point? This shouldn't be at all hard to fix if that's not the way it works today. > This is not a question of whether it is technically possible to make > bundles mutable - the construction phase gets much easier if they are. > It is whether they are usable by anything else after they have been mutated. > > I think we all agree that modifying attribute values and persisting the > changes is a good idea. David has proposed saving this separately from > the internal structure of the bundle and that seems like an idea worth > exploring. I'd go further and suggest we separate bundle level > properties from component level ones (at least for this kind of > management) but that is something we really haven't discussed at all. I think this is a fine candidate for later refactoring. Aaron > Where we still seem to disagree is on whether structural changes to the > bundle are a good idea. So far I haven't seen any solution that allows > this and addresses the technical problems raised above and don't think > we should go down this route until we have consensus.
Re: GBeans: Saving Changes
On Jul 26, 2005, at 3:36 PM, Jeremy Boynes wrote: If it uses the "original" then the new configuration may not run with the "current" one; if it uses the "current" then it may not run on a server using the "original" one. We have this problem regardless. Any mutation in the environment or configuration state can cause a service to not start. For example, if a users moves an important directory, or changes a service attribute to point to a new directory. The proposed change does not solve that problem but it doesn't cause that problem either. When someone comes up with a solution to this problem, we can change the console also. It is *soft*ware after all. It is also a requirement for offline or in-Maven packaging where the deployer will be using the "original" version and not the "current" modified one. The command line maven tool will load the current state from the server configuration store. If the maven plugin doesn't do that I would consider that a bug. -dain
Re: GBeans: Saving Changes
On Jul 26, 2005, at 3:43 PM, Aaron Mulder wrote:
On Tue, 26 Jul 2005, David Jencks wrote:
Now that how saving configuration works has been explained so even I
can understand it, I don't have any problem in saving configuration
locally. I can even imagine a tool to merge a local state with a
configuration to produce a new configuration (with a different version
number or name).
Great.
Before we jump into adding gbeans to a running
configuration, can we please think about whether the "disabled gbean"
approach would work just as well, and, if not, if the "application
centered deployment" idea would work better. IIRC the original
motivation behind GERONIMO-400 was to put the admin objects you can
add
by the admin portal into the original jms configuration rather than
making a separate configuration per queue/topic. If you have the
opportunity to add the admin objects while you are deploying your app
that will use them, I can't actually see any reason to support
deploying "standalone" admin objects at all, whatever configuration
they go into.
RE "disabled GBeans" ("blanks"): The counter-example I gave in JIRA was
security realms, which may use any number of LoginModules. It doesn't
make sense to me to add "enough" blanks that you're sure no one would
ever
want to add more than that, nor to require that someone writing a new
plan
for their own purposes add "enough" blanks to accomodate future changes
via the web console. What number would you tell them? 10? 5?
I think this is a prime example of where you should use app-centric
deployment, i.e. put the security gbeans in the application.
RE "app-centric deployment": And again, I believe there are cases where
server administrators will be configuring the services in the server,
and
will not have the skills or tools to alter embedded XML files in the
application configuration. This is more realistic for web listen
ports,
security realms, databases (where devs may not have prod DB password)
or
J2CA connections to back-end services than for admin objects (which I
admit could often be best packaged with an application). Even without
the
administrator vs. developer issue, imagine staging your application
from
dev to test to production, where each server has connections to
different
databases and back-end services. It would be much nicer to put that
configuration in the app server, so the application itself can be
totally
unchanged when it's migrated between environments. The application
says
"I use a data source called 'DB2'", and the server provides the data
source pointing to a specific database, different in each of the 3
environments.
I'd think you'd want to have a compatibility-layer configuration
including all the app specific stuff that needs to be different for
each server. Each environment would get its own compatibility layer,
exposing the same stuff to the application.
I do like the *ability* to deploy data sources with an app -- just not
making it the only options.
I think we might be missing the point to some extent. We all want
geronimo to be easy to use and configure, and scale well to really
large deployments. Obviously we need ways to deploy applications so
they run, and all their needs are met. The questions seem to me to be
"when" (deploy or runtime) and "where" (which configuration). Other
servers AFAIK tend to have monolithic server configurations and limited
application configuration, and a lot of server configuration may have
to be done at runtime. What if we take a step back from what we are
used to doing and think if there is a better way.
One point of view is that if you have to change something on your
running server, your deployment tools weren't good enough: they should
be good enough so when you deploy, everything is there, and it works.
This is sort of like type safety in compiled languages: by the time you
get to running, the system has already eliminated many classes of
errors.
thanks
david jencks
Aaron
Re: GBeans: Saving Changes
On Jul 26, 2005, at 3:36 PM, Dain Sundstrom wrote: How is enabling and subsequently configuring a service is substantially different then just adding a new one? Simmilary, why is disabling a service substantially different then removing it? My idea is that live changes should only affect attribute values, not reference patterns. So, a disabled gbean will still be (potentially) hooked up to the correct other gbeans, and will have some sort of attribute values that might possibly be useful. An entirely new gbean won't have these features. david jencks -dain On Jul 26, 2005, at 3:23 PM, David Jencks wrote: On Jul 26, 2005, at 3:06 PM, Dain Sundstrom wrote: BTW this is already has a JIRA entry GERONIMO-400. I added this almost a year ago. No wonder I couldn't find it. I thought I added it :-) Now that how saving configuration works has been explained so even I can understand it, I don't have any problem in saving configuration locally. I can even imagine a tool to merge a local state with a configuration to produce a new configuration (with a different version number or name). Before we jump into adding gbeans to a running configuration, can we please think about whether the "disabled gbean" approach would work just as well, and, if not, if the "application centered deployment" idea would work better. IIRC the original motivation behind GERONIMO-400 was to put the admin objects you can add by the admin portal into the original jms configuration rather than making a separate configuration per queue/topic. If you have the opportunity to add the admin objects while you are deploying your app that will use them, I can't actually see any reason to support deploying "standalone" admin objects at all, whatever configuration they go into. thanks david jencks -dain On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote: David, I believe we need to be able to make this kind of change to a running server. The commercial products we're (at least in theory) competing with all support making this kind of change through their management console, though for certain types of changes a server restart is required. Changing the port you're using to connect to the console at runtime would be a little weird, but I'm strongly opposed to requiring someone to locate, modify, and redeploy the o/a/g/Server plan in order to make any change at all. Jeremy, I agree that changing an attribute value does not need to alter "the configuration" based on what is implemented today. IIUC, when you alter a GBean, a new set of config info is written to a separate file, and next time the configuration is loaded that file is read and the new value kicks in instead of the original value. So you have both the unaltered original configuration and the modified "current state", and it just happens that future server starts will use that "current state" (though I suppose we could provide some sort of command to revert a configuration to its original state). That would actually be a kind of cool option in the console -- "revert to factory default settings". Maybe I've been casting this entire discussion in the wrong way. Both changes to GBean properties and adds/removes of GBeans can be accomplished by adjusting the "current state" saved *in addition to* the original state -- so at the end of the day, we're not really altering "the configuration", we're preserving the original configuration and altering our "current state for the configuration". Perhaps we're in violent agreement. :) Aaron On Tue, 26 Jul 2005, David Jencks wrote: IMO both of these are much better done as part of the offline deployment process well before the configuration gets anywhere near a running server. Both of these are reasonable things to do, but again IMO not on a running server. I'm not really sure how the current configuration saving works. thanks david jencks On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote: On Tue, 26 Jul 2005, David Jencks wrote: there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Under the covers, a connector GBean has been added to the o/a/g/Server Configuration. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this
[jira] Commented: (GERONIMO-728) Jetty gives misleading NPE on "port in use" condition
[ http://issues.apache.org/jira/browse/GERONIMO-728?page=comments#action_12316815 ] John Sisson commented on GERONIMO-728: -- Has been fixed in Jetty's CVS for the upcoming 5.1.5 release. https://sourceforge.net/tracker/?func=detail&atid=107322&aid=1240821&group_id=7322 > Jetty gives misleading NPE on "port in use" condition > - > > Key: GERONIMO-728 > URL: http://issues.apache.org/jira/browse/GERONIMO-728 > Project: Geronimo > Type: Improvement > Components: web, dependencies > Versions: 1.0-M3, 1.0-M5, 1.0-M4 > Reporter: Aaron Mulder > Assignee: John Sisson > Fix For: 1.0-M5 > > When Jetty starts up but the port it wants is in use, you get an error like > this: > 19 ERROR [GBeanInstance] Problem in doFail of > geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=GBean,name=JettyWebConnector > java.lang.NullPointerException > at org.mortbay.util.ThreadedServer.stop(ThreadedServer.java:544) > at org.mortbay.http.SocketListener.stop(SocketListener.java:211) > at > org.apache.geronimo.jetty.connector.JettyConnector.doFail(JettyConnector.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:869) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:328) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:111) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:486) > at > org.apache.geronimo.gbean.runtime.GBeanSingleReference.attemptFullStart(GBeanSingleReference.java:154) > at > org.apache.geronimo.gbean.runtime.GBeanSingleReference.targetAdded(GBeanSingleReference.java:127) > at > org.apache.geronimo.gbean.runtime.AbstractGBeanReference.addTarget(AbstractGBeanReference.java:242) > at > org.apache.geronimo.gbean.runtime.GBeanSingleReference$1.running(GBeanSingleReference.java:163) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:155) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:38) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:231) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:352) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:111) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:133) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:503) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:207) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:141) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:503) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:207) > at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:247) > at org.apache.geronimo.system.main.Daemon.(Daemon.java:81) > at org.apache.geronimo.system.main.Daemon.main(Daemon.java:320) > Only later does the BindException show up, whereas I believe the > BindException should be first (and in fact only -- what good does the NPE > do?). > So what I think should happen is that we should trap a BindException, and if > it comes up, don't try to stop the SocketListener (or at least don't generate > another exception if it doesn't work). Then print an ERROR message including > the port number (ERROR: Jetty unable to bind to port 8080). Then throw the > BindException if the full stack trace would be useful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Reopened: (GERONIMO-254) ServerInfo is too darned useful
Please don't reopen. I find these placeholder issues annoying and misleading. If you have specific improvement, then open a new issue. On this specific issue, Spring solved this by allowing an attribute value to be the result of invoking another bean. So we would have something like this: var/mydir BTW I just made up this xml, but you get the idea. Instead of storing a specific attribute value, you tell the container to invoke another bean and use the return value for the property value. -dain On Jul 26, 2005, at 3:43 PM, Jeremy Boynes (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-254?page=all ] Jeremy Boynes reopened GERONIMO-254: Reopened as a placeholder until we know what the "root cause" is. Perhaps then we can close this and link to the issue that is fixing that problem. ServerInfo is too darned useful --- Key: GERONIMO-254 URL: http://issues.apache.org/jira/browse/GERONIMO-254 Project: Geronimo Type: Improvement Components: general Versions: 1.0-M2 Reporter: Jeremy Boynes Assignee: Dain Sundstrom Priority: Minor This GBean provides information on the system including the location of the install which is used to find data files. The location itself is transient (so installs can be moved) but needs to be injected early. It seems reasonable to have a reference to this available by magic, which means moving it to the kernel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Reopened: (GERONIMO-254) ServerInfo is too darned useful
This strikes me as a cool idea. Can we please get out of the habit of replying to Jira notifications and, instead, add comments to the Jira issues themselves or start new threads? Regards, Alan On 7/26/2005 4:07 PM, Dain Sundstrom wrote: Please don't reopen. I find these placeholder issues annoying and misleading. If you have specific improvement, then open a new issue. On this specific issue, Spring solved this by allowing an attribute value to be the result of invoking another bean. So we would have something like this: var/mydir BTW I just made up this xml, but you get the idea. Instead of storing a specific attribute value, you tell the container to invoke another bean and use the return value for the property value. -dain On Jul 26, 2005, at 3:43 PM, Jeremy Boynes (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-254?page=all ] Jeremy Boynes reopened GERONIMO-254: Reopened as a placeholder until we know what the "root cause" is. Perhaps then we can close this and link to the issue that is fixing that problem. ServerInfo is too darned useful --- Key: GERONIMO-254 URL: http://issues.apache.org/jira/browse/GERONIMO-254 Project: Geronimo Type: Improvement Components: general Versions: 1.0-M2 Reporter: Jeremy Boynes Assignee: Dain Sundstrom Priority: Minor This GBean provides information on the system including the location of the install which is used to find data files. The location itself is transient (so installs can be moved) but needs to be injected early. It seems reasonable to have a reference to this available by magic, which means moving it to the kernel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-254) ServerInfo is too darned useful
[ http://issues.apache.org/jira/browse/GERONIMO-254?page=all ] Dain Sundstrom closed GERONIMO-254: --- Resolution: Won't Fix No need to keep this issue open. When someone has a specific request they can open a new issue. > ServerInfo is too darned useful > --- > > Key: GERONIMO-254 > URL: http://issues.apache.org/jira/browse/GERONIMO-254 > Project: Geronimo > Type: Improvement > Components: general > Versions: 1.0-M2 > Reporter: Jeremy Boynes > Assignee: Dain Sundstrom > Priority: Minor > > This GBean provides information on the system including the location of the > install which is used to find data files. The location itself is transient > (so installs can be moved) but needs to be injected early. > It seems reasonable to have a reference to this available by magic, which > means moving it to the kernel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Reopened: (GERONIMO-254) ServerInfo is too darned useful
what happens when ServerInfo (or the supplying gbean) stops? Personally, I'd rather see an annoying poorly worded issue than no issue. david jencks On Jul 26, 2005, at 4:07 PM, Dain Sundstrom wrote: Please don't reopen. I find these placeholder issues annoying and misleading. If you have specific improvement, then open a new issue. On this specific issue, Spring solved this by allowing an attribute value to be the result of invoking another bean. So we would have something like this: var/mydir BTW I just made up this xml, but you get the idea. Instead of storing a specific attribute value, you tell the container to invoke another bean and use the return value for the property value. -dain On Jul 26, 2005, at 3:43 PM, Jeremy Boynes (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-254?page=all ] Jeremy Boynes reopened GERONIMO-254: Reopened as a placeholder until we know what the "root cause" is. Perhaps then we can close this and link to the issue that is fixing that problem. ServerInfo is too darned useful --- Key: GERONIMO-254 URL: http://issues.apache.org/jira/browse/GERONIMO-254 Project: Geronimo Type: Improvement Components: general Versions: 1.0-M2 Reporter: Jeremy Boynes Assignee: Dain Sundstrom Priority: Minor This GBean provides information on the system including the location of the install which is used to find data files. The location itself is transient (so installs can be moved) but needs to be injected early. It seems reasonable to have a reference to this available by magic, which means moving it to the kernel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Reopened: (GERONIMO-254) ServerInfo is too darned useful
Dain Sundstrom wrote: Please don't reopen. I find these placeholder issues annoying and misleading. If you have specific improvement, then open a new issue. Please don't close issues without indicating why something is not relevant. Your message states that there is a different problem but you didn't identify what it is or link to an issue for it - that's how issues get missed. Out of common courtesy, you might have asked for clarification first. There is now a thread going on about it, so please reopen at least until we reach consensus. -- Jeremy
Re: GBeans: Saving Changes
Aaron Mulder wrote: FYI, I don't think this is a technical issue, I think this is a scope issue. You're talking about how to support "build the bundle on a master node in a cluster and then automatically push it to worker nodes" and how to support features that no other app server has. Yep, that was one of the design goals when we started on this, er, two years ago. And there are other servers that do this kind of thing, WebSphere-ND is one. I'm talking about how to provide a usable management environment for ONE server, which is something we most definitely need to be competitive. We have to get past reasonable 1-server support (plus of course add clustering support) before we need the features you're describing. None of these interfere with 1-server support. There's just no need to break N-server support that is already there whilst doing so, especially when people have already stated to talk about adding clustering support. I feel that we should proceed with a short-term option and plan to refactor when we are at a place where supporting the environment you're describing becomes feasible. It doesn't make sense to me to not proceed with any change until we can solve every problem we might ever have. No one is advocating not making any changes so please do not over dramatize the discussion. What doesn't make sense is breaking features we have now for a solution we have already identified has problems, planning on a refactoring say within 6 months to a mode that can't use the interim solution as there is no guarantee of consistency. Why not start the discussion on how to impove what we have e.g. by providing bundle level properties, by separating out management properties into an human-readable database rather than burying them in the config store, by separating manageable attributes from unmanageable ones used for wiring purposes, by adding bundle metadata? That said, back to the issue: On Tue, 26 Jul 2005, Jeremy Boynes wrote: The problem comes with which version of the state is used by things like the (runtime) deployer to build new configurations. If it uses the "original" then the new configuration may not run with the "current" one; if it uses the "current" then it may not run on a server using the "original" one. This is true today; if we don't implement add/remove, we still have the problem. For example, you could deploy an EJB that depends on a data source, then go change the password used by the data source to be invalid so it doesn't start or function, thereby breaking your EJB. This is true of every app server that I've ever used. I don't consider it to be a critical flaw of the product. But of course it would be nice to have a way around it down the road. That is a different problem - we didn't "break" your EJB, it failed because it could not connect to the database. The same problem would occur if the DBA changed the database password or took it down for maintenance. This is just a regular operational problem. This may never become apparent if the configurations are never moved between servers. However, being able to do that was half the point - e.g. build the bundle on a master node in a cluster and then automatically push it to worker nodes. It is also a requirement for offline or in-Maven packaging where the deployer will be using the "original" version and not the "current" modified one. Why won't the deployer use the current state in offline mode? If it touches it at all, it should use the same "current" state that the server would use if it started. Otherwise, what's the point? This shouldn't be at all hard to fix if that's not the way it works today. Because it may be on a different machine, for example. This is not a question of whether it is technically possible to make bundles mutable - the construction phase gets much easier if they are. It is whether they are usable by anything else after they have been mutated. I think we all agree that modifying attribute values and persisting the changes is a good idea. David has proposed saving this separately from the internal structure of the bundle and that seems like an idea worth exploring. I'd go further and suggest we separate bundle level properties from component level ones (at least for this kind of management) but that is something we really haven't discussed at all. I think this is a fine candidate for later refactoring. Perhaps we should look at it now - it may make things simpler. Well, after M4 of course :-) -- Jeremy
Re: GBeans: Saving Changes
Dain Sundstrom wrote: On Jul 26, 2005, at 3:36 PM, Jeremy Boynes wrote: If it uses the "original" then the new configuration may not run with the "current" one; if it uses the "current" then it may not run on a server using the "original" one. We have this problem regardless. Any mutation in the environment or configuration state can cause a service to not start. For example, if a users moves an important directory, or changes a service attribute to point to a new directory. The proposed change does not solve that problem but it doesn't cause that problem either. When someone comes up with a solution to this problem, we can change the console also. It is *soft*ware after all. There's a difference between not starting and not present. If something doesn't start because of environmental issues then you have an operational problem. If the server says it offers some services (e.g. a Jetty container) but has incompatibly mutated (e.g. into a Tomcat container) then you have a much bigger set of problems. The immutablity is there to solve that. It is also a requirement for offline or in-Maven packaging where the deployer will be using the "original" version and not the "current" modified one. The command line maven tool will load the current state from the server configuration store. If the maven plugin doesn't do that I would consider that a bug. No, we've been there already (ApacheCon last year). That is coupling offline deployment to an instance of the online system rather than allowing it to use the advertised target environment. The current command line tool in offline mode loads the state from its internal config store which just happens to point to the same directory. Ironically, this would be fine if configurations were immutable. The plugin loads bundles as artifacts from the local maven repo - which is fine as they are immutable - automatically giving us the ability to publish bundles online. -- Jeremy
Re: GBeans: Saving Changes
On Tue, 26 Jul 2005, David Jencks wrote: > I think this is a prime example of where you should use app-centric > deployment, i.e. put the security gbeans in the application. What if your developers are not trusted with the production database or LDAP accounts? Are you arguing that your application deployment information should need to be changed between final test and production? I think it's a pretty important feature to be able to have an unaltered EAR going from test to prod. > I'd think you'd want to have a compatibility-layer configuration > including all the app specific stuff that needs to be different for > each server. Each environment would get its own compatibility layer, > exposing the same stuff to the application. Okay, now you're arguing that app-centric deployment does not always work, which I would obviously agree with. So what if you want to change the compatibility layer? Wouldn't it be nice if you could do that in the web console instead of be writing deployment plans and redeploying them? This is what ease of use is all about to me. We can totally support changing things on the fly in the web console. Why not give people that option? > Other servers AFAIK tend to have monolithic server configurations and > limited application configuration, and a lot of server configuration may > have to be done at runtime. What if we take a step back from what we > are used to doing and think if there is a better way. Again, I support this 100% as an option. I just don't believe it is the *only* option. I think each approach has its advantages, and different situations would benefit from each. I believe we should support both. Aaron > One point of view is that if you have to change something on your > running server, your deployment tools weren't good enough: they should > be good enough so when you deploy, everything is there, and it works. > This is sort of like type safety in compiled languages: by the time you > get to running, the system has already eliminated many classes of > errors.
Re: GBeans: Saving Changes
Okay, I think we're getting to the root of this. You believe I am proposing breaking a current feature. I believe I am proposing only adding new features without breaking anything. If we add the ability to add/remove GBeans to a configuration at runtime, then based on the current HEAD, which feature will that break? Thanks, Aaron On Tue, 26 Jul 2005, Jeremy Boynes wrote: > Aaron Mulder wrote: > > FYI, I don't think this is a technical issue, I think this is a > > scope issue. You're talking about how to support "build the bundle on a > > master node in a cluster and then automatically push it to worker nodes" > > and how to support features that no other app server has. > > Yep, that was one of the design goals when we started on this, er, two > years ago. And there are other servers that do this kind of thing, > WebSphere-ND is one. > > > I'm talking > > about how to provide a usable management environment for ONE server, which > > is something we most definitely need to be competitive. We have to get > > past reasonable 1-server support (plus of course add clustering support) > > before we need the features you're describing. > > None of these interfere with 1-server support. There's just no need to > break N-server support that is already there whilst doing so, especially > when people have already stated to talk about adding clustering support. > > > I feel that we should > > proceed with a short-term option and plan to refactor when we are at a > > place where supporting the environment you're describing becomes feasible. > > It doesn't make sense to me to not proceed with any change until we can > > solve every problem we might ever have. > > > > No one is advocating not making any changes so please do not over > dramatize the discussion. > > What doesn't make sense is breaking features we have now for a solution > we have already identified has problems, planning on a refactoring say > within 6 months to a mode that can't use the interim solution as there > is no guarantee of consistency. > > Why not start the discussion on how to impove what we have e.g. by > providing bundle level properties, by separating out management > properties into an human-readable database rather than burying them in > the config store, by separating manageable attributes from unmanageable > ones used for wiring purposes, by adding bundle metadata? > > > That said, back to the issue: > > > > On Tue, 26 Jul 2005, Jeremy Boynes wrote: > > > >>The problem comes with which version of the state is used by things like > >>the (runtime) deployer to build new configurations. > >> > >>If it uses the "original" then the new configuration may not run with > >>the "current" one; if it uses the "current" then it may not run on a > >>server using the "original" one. > > > > > > This is true today; if we don't implement add/remove, we still > > have the problem. For example, you could deploy an EJB that depends on a > > data source, then go change the password used by the data source to be > > invalid so it doesn't start or function, thereby breaking your EJB. This > > is true of every app server that I've ever used. I don't consider it to > > be a critical flaw of the product. But of course it would be nice to have > > a way around it down the road. > > > > That is a different problem - we didn't "break" your EJB, it failed > because it could not connect to the database. The same problem would > occur if the DBA changed the database password or took it down for > maintenance. This is just a regular operational problem. > > > > >>This may never become apparent if the configurations are never moved > >>between servers. However, being able to do that was half the point - > >>e.g. build the bundle on a master node in a cluster and then > >>automatically push it to worker nodes. > >> > >>It is also a requirement for offline or in-Maven packaging where the > >>deployer will be using the "original" version and not the "current" > >>modified one. > > > > > > Why won't the deployer use the current state in offline mode? If it > > touches it at all, it should use the same "current" state that the server > > would use if it started. Otherwise, what's the point? This shouldn't be > > at all hard to fix if that's not the way it works today. > > > > Because it may be on a different machine, for example. > > > > >>This is not a question of whether it is technically possible to make > >>bundles mutable - the construction phase gets much easier if they are. > >>It is whether they are usable by anything else after they have been mutated. > >> > >>I think we all agree that modifying attribute values and persisting the > >>changes is a good idea. David has proposed saving this separately from > >>the internal structure of the bundle and that seems like an idea worth > >>exploring. I'd go further and suggest we separate bundle level > >>prop
Re: GBeans: Saving Changes
Aaron Mulder wrote: Okay, I think we're getting to the root of this. You believe I am proposing breaking a current feature. I believe I am proposing only adding new features without breaking anything. If we add the ability to add/remove GBeans to a configuration at runtime, then based on the current HEAD, which feature will that break? The ability to build a configuration on one machine and have it run reliably on another. The ability for the packaging plugin to use artifacts from the Maven repo (using Maven's dependency system) rather than having to contact an online server. The ability to reliably run a worker server without a runtime deployment system. -- Jeremy
Re: GBeans: Saving Changes
All of those are broken today if you change the properties of the GBeans using the setAttribute calls, right? Aaron On Tue, 26 Jul 2005, Jeremy Boynes wrote: > The ability to build a configuration on one machine and have it run > reliably on another. > > The ability for the packaging plugin to use artifacts from the Maven > repo (using Maven's dependency system) rather than having to contact an > online server. > > The ability to reliably run a worker server without a runtime deployment > system.
Re: GBeans: Saving Changes
well... If the runtime deployer works off of the original configurations, ignoring any local modifications, it won't break anything, but it also will be pretty much useless (I think). If the runtime deployer works off of the locally modified configuration, then the runtime deployer should not be used to build configurations you intend to distribute to any other server. If you do, it breaks the immutability guarantees. BTW, I don't see how the runtime deployer can avoid using the locally modified configuration state -- you would have to find a way to load 2 copies of the same configuration at once. If the only changes allowed are attribute values, this is unlikely to have a really serious effect on the deployed configuration. Allowing more gbeans in is definitely going to welcome in all sorts of compatibility problems I continue to think adding gbeans at runtime will be a big mistake and that we don't see all the bad consequences yet. david jencks On Jul 26, 2005, at 4:48 PM, Aaron Mulder wrote: Okay, I think we're getting to the root of this. You believe I am proposing breaking a current feature. I believe I am proposing only adding new features without breaking anything. If we add the ability to add/remove GBeans to a configuration at runtime, then based on the current HEAD, which feature will that break? Thanks, Aaron On Tue, 26 Jul 2005, Jeremy Boynes wrote: Aaron Mulder wrote: FYI, I don't think this is a technical issue, I think this is a scope issue. You're talking about how to support "build the bundle on a master node in a cluster and then automatically push it to worker nodes" and how to support features that no other app server has. Yep, that was one of the design goals when we started on this, er, two years ago. And there are other servers that do this kind of thing, WebSphere-ND is one. I'm talking about how to provide a usable management environment for ONE server, which is something we most definitely need to be competitive. We have to get past reasonable 1-server support (plus of course add clustering support) before we need the features you're describing. None of these interfere with 1-server support. There's just no need to break N-server support that is already there whilst doing so, especially when people have already stated to talk about adding clustering support. I feel that we should proceed with a short-term option and plan to refactor when we are at a place where supporting the environment you're describing becomes feasible. It doesn't make sense to me to not proceed with any change until we can solve every problem we might ever have. No one is advocating not making any changes so please do not over dramatize the discussion. What doesn't make sense is breaking features we have now for a solution we have already identified has problems, planning on a refactoring say within 6 months to a mode that can't use the interim solution as there is no guarantee of consistency. Why not start the discussion on how to impove what we have e.g. by providing bundle level properties, by separating out management properties into an human-readable database rather than burying them in the config store, by separating manageable attributes from unmanageable ones used for wiring purposes, by adding bundle metadata? That said, back to the issue: On Tue, 26 Jul 2005, Jeremy Boynes wrote: The problem comes with which version of the state is used by things like the (runtime) deployer to build new configurations. If it uses the "original" then the new configuration may not run with the "current" one; if it uses the "current" then it may not run on a server using the "original" one. This is true today; if we don't implement add/remove, we still have the problem. For example, you could deploy an EJB that depends on a data source, then go change the password used by the data source to be invalid so it doesn't start or function, thereby breaking your EJB. This is true of every app server that I've ever used. I don't consider it to be a critical flaw of the product. But of course it would be nice to have a way around it down the road. That is a different problem - we didn't "break" your EJB, it failed because it could not connect to the database. The same problem would occur if the DBA changed the database password or took it down for maintenance. This is just a regular operational problem. This may never become apparent if the configurations are never moved between servers. However, being able to do that was half the point - e.g. build the bundle on a master node in a cluster and then automatically push it to worker nodes. It is also a requirement for offline or in-Maven packaging where the deployer will be using the "original" version and not the "current" modified one. Why won't the deployer use the current state in offline mode? If it touches it at all, it should us
[jira] Updated: (GERONIMO-812) TargetModuleId sometimes has quotes and sometimes no quotes around moduleID
[ http://issues.apache.org/jira/browse/GERONIMO-812?page=all ] David Jencks updated GERONIMO-812: -- Summary: TargetModuleId sometimes has quotes and sometimes no quotes around moduleID (was: undeployment sometimes seems incomplete) Description: The TargetModuleID returned from a ProgressObject has quotes around the moduleID whereas the TargetModuleID returned by listing modules doesn't. This causes equality comparisons to break. This is causing TCK problems. (was: when deploying and undeploying a lot of related apps without restarting geronimo, sometimes the deploy of the 2nd app fails. The 2nd app deploys fine if geronimo is restarted in between. ) > TargetModuleId sometimes has quotes and sometimes no quotes around moduleID > --- > > Key: GERONIMO-812 > URL: http://issues.apache.org/jira/browse/GERONIMO-812 > Project: Geronimo > Type: Bug > Versions: 1.0-M4, 1.0-M5 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.0-M4, 1.0-M5 > > The TargetModuleID returned from a ProgressObject has quotes around the > moduleID whereas the TargetModuleID returned by listing modules doesn't. > This causes equality comparisons to break. This is causing TCK problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-522) Misleading GBean Startup Error Message
[ http://issues.apache.org/jira/browse/GERONIMO-522?page=all ] Dain Sundstrom closed GERONIMO-522: --- Resolution: Cannot Reproduce That error message is no longer present in the server. > Misleading GBean Startup Error Message > -- > > Key: GERONIMO-522 > URL: http://issues.apache.org/jira/browse/GERONIMO-522 > Project: Geronimo > Type: Bug > Components: kernel > Versions: 1.0-M3 > Reporter: Aaron Mulder > Assignee: Dain Sundstrom > > If a GBean fails to start, the error message generated is (for example): > org.apache.geronimo.kernel.config.InvalidConfigException: Invalid GBean > configuration for geronimo.config:name="org/apache/geronimo/Server" > at > org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:379) > at org.apache.geronimo.system.main.Daemon.main(Daemon.java:150) > Caused by: java.net.BindException: Address already in use > at java.net.PlainSocketImpl.socketBind(Native Method) > The problem is, it's not usually an invalid GBean configuration (which says > to me, a syntax error in a config file or the like). The GBean configuration > is fine, it's really a startup error. The message would be better if it said > "Unable to start GBean XYZ, see the 'Caused By:' message below" > This commonly happens for network services when the port is already in use as > above (arguably a configuration problem, but the user has typically done no > configuration at all when it happens, because they probably just started > Geronimo for the first time). > It commonly happens for applications when there's some sort of classloader > problem resulting in the wrong classes being loaded or a class not being > found. (For example, Struts/Spring/Hibernate type web apps have a lot of > Jakarta Common dependencies, and Tomcat supplies some of those that Geronimo > doesn't, so an app that worked in Tomcat may not work in Geronimo if all the > commons stuff isn't in the WAR). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: GBeans: Saving Changes
Let me try to propose some alternatives for us to consider. Assume you want to make a change to the server configuration, and for whatever reason, NOT bundle that with your application. This change involves adding or removing a GBean, which is naturally related to the content of the o/a/g/Server configuration. You want to make this change at runtime via the web console. Do we all agree that this is a use case we wish to support? If not, I think we should gather some input on that instead. But assuming we're in agreement there: Option 1: alter the o/a/g/Server plan in place. Apps that declare that configuration as a parent will work unchanged, unless the nature of the change breaks them (you swapped Jetty for Tomcat and the apps assume that a particular Tomcat Valve is deployed but it's not). If an app is deployed on this server, it might not work if sent to a different server (depending on how that server defines "o/a/g/Server"). Option 2: save a new configuration as o/a/g/Server-UUID, and disable the old o/a/g/Server configuration. All apps which declared Server as a parent will refuse to run until their deployment plan is updated. All apps must incude the correct UUID to function. The UUID must be globally unique, so a different server didn't have a different change applied and arrive at the same UUID. Option 3: disable the relevant GBeans in o/a/g/Server, and create a new configuration o/a/g/Genered-By-Console-UUID with any previous o/a/g/Generated-By-Console-[PreviousUUID] as the parent (or the original o/a/g/Server if this is the first change). All apps which declared Server as a parent may or may not work and may or may not need to be changed to refer to a different parent, depending on the nature of the change. If they do need to reflect the change, their dependency must include the correct UUID to function. Option 4: Require that "Server" include some number of disabled GBean "blanks" for every GBean you might want to add. If you want to add something, you instead activate a blank, If you want to remove something, you disable it. If an app is deployed on this server, it might not work if sent to a different server (depending on which GBeans are or are not enabled in the "Server" configuration on each, and whether the app relies on them). If you have any other alternatives to propose, please do so. Thanks, Aaron
[jira] Reopened: (GERONIMO-668) Unable to determine username from EJB method
[ http://issues.apache.org/jira/browse/GERONIMO-668?page=all ] Aaron Mulder reopened GERONIMO-668: --- I think we need to look at this issue in more detail. I believe the app servers I've used all managed to pick out the "user" principal to return from getCallerPrincipal, and every time I've used it it's been with the intention of identifying the login name of the current user. It seems that most login modules produce both a "user" and at least one "group" principal. We need to be able to figure out which principal class is "primary" and should be returned from getCallerPrincipal. It seems like this could be metadata we associate with the login module or realm. > Unable to determine username from EJB method > > > Key: GERONIMO-668 > URL: http://issues.apache.org/jira/browse/GERONIMO-668 > Project: Geronimo > Type: Bug > Versions: 1.0-M4 > Reporter: Ivan Dubrov > Assignee: David Jencks > Fix For: 1.0-M4, 1.0-M5 > > When calling EJB method from the Web module some important security context > information (username) is lost. It is impossible to determine caller user > name from the EJB method. EJBContext.getCallerPrincipal().getName() returns > something like this: > [org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal: manager] > Note that only group name can be determined from this string or from the > EJBMethod.getCallerPrincipal(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-812) TargetModuleId sometimes has quotes and sometimes no quotes around moduleID
[ http://issues.apache.org/jira/browse/GERONIMO-812?page=all ] David Jencks closed GERONIMO-812: - Resolution: Fixed Unquote configID when extracting from Configuration Name. M4: Sending modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/local/StartCommand.java Transmitting file data . Committed revision 225434. M5 Sending modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/local/StartCommand.java Transmitting file data . Committed revision 225435. > TargetModuleId sometimes has quotes and sometimes no quotes around moduleID > --- > > Key: GERONIMO-812 > URL: http://issues.apache.org/jira/browse/GERONIMO-812 > Project: Geronimo > Type: Bug > Versions: 1.0-M4, 1.0-M5 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.0-M4, 1.0-M5 > > The TargetModuleID returned from a ProgressObject has quotes around the > moduleID whereas the TargetModuleID returned by listing modules doesn't. > This causes equality comparisons to break. This is causing TCK problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-819) DeploymentContext doesn't actually keep track of childConfigurations
DeploymentContext doesn't actually keep track of childConfigurations
Key: GERONIMO-819
URL: http://issues.apache.org/jira/browse/GERONIMO-819
Project: Geronimo
Type: Bug
Components: deployment
Versions: 1.0-M4, 1.0-M5
Reporter: David Jencks
Assigned to: David Jencks
Fix For: 1.0-M4, 1.0-M5
stupid typo:
public void addChildConfiguration(ConfigurationData configurationData) {
-configurationData.addChildConfiguration(configurationData);
+this.configurationData.addChildConfiguration(configurationData);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-820) CommandSupport does not adequately synchronize access to "state"
CommandSupport does not adequately synchronize access to "state"
Key: GERONIMO-820
URL: http://issues.apache.org/jira/browse/GERONIMO-820
Project: Geronimo
Type: Bug
Components: deployment
Versions: 1.0-M4, 1.0-M5
Reporter: David Jencks
Assigned to: David Jencks
Fix For: 1.0-M4, 1.0-M5
Changing state is synchronized, reading it should be also.
-public DeploymentStatus getDeploymentStatus() {
+public synchronized DeploymentStatus getDeploymentStatus() {
return new Status(command, action, state, message);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-819) DeploymentContext doesn't actually keep track of childConfigurations
[ http://issues.apache.org/jira/browse/GERONIMO-819?page=all ]
David Jencks closed GERONIMO-819:
-
Resolution: Fixed
M4:
Sending
modules/deployment/src/java/org/apache/geronimo/deployment/DeploymentContext.java
Transmitting file data .
Committed revision 225436.
M5:
Sending
modules/deployment/src/java/org/apache/geronimo/deployment/DeploymentContext.java
Transmitting file data .
Committed revision 225437.
> DeploymentContext doesn't actually keep track of childConfigurations
>
>
> Key: GERONIMO-819
> URL: http://issues.apache.org/jira/browse/GERONIMO-819
> Project: Geronimo
> Type: Bug
> Components: deployment
> Versions: 1.0-M4, 1.0-M5
> Reporter: David Jencks
> Assignee: David Jencks
> Fix For: 1.0-M4, 1.0-M5
>
> stupid typo:
> public void addChildConfiguration(ConfigurationData configurationData) {
> -configurationData.addChildConfiguration(configurationData);
> +this.configurationData.addChildConfiguration(configurationData);
> }
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: GBeans: Saving Changes
Aaron Mulder wrote: Let me try to propose some alternatives for us to consider. Assume you want to make a change to the server configuration, and for whatever reason, NOT bundle that with your application. This change involves adding or removing a GBean, which is naturally related to the content of the o/a/g/Server configuration. You want to make this change at runtime via the web console. First caveat - o/a/g/Server is too monolithic which is contributing factor to these discussions. The reasons why this is a problem and how to start to fix it have been discussed elsewhere. This impacts this discussion because of the clause "which is naturally related to the content of the o/a/g/Server configuration." Let's assume o/a/g/Server is made more modular; the problem does not change, it just gets applies to the smaller bundles. Second caveat, change through the web console is one use case. It applies to small installations (desktop, single server) but is less applicable to larger installations, say with > 10 servers. It also does not apply to "headless" servers which may not be running a web container at all. Do we all agree that this is a use case we wish to support? I do, but as you can tell from the caveats there are other use cases I also wish to see supported. skipping straight to suggestions of other alternatives :-) If you have any other alternatives to propose, please do so. I have two I've given some thought to although they're not fully thought out - but hey, we're brainstorming right? Option 5: We have two different bundle types, mutable and immutable. Mutable ones have a special ID, e.g. containing the word SNAPSHOT so they can be clearly identified; immutable ones have a specific version number e.g. o/a/g/Server/1.0-M5. Any structural modification of the bundle, e.g. adding a GBean, changing a reference pattern etc. makes the bundle mutable. We enhance the configuration manager so that it can handle bundle version ranges so that bundle-to-bundle dependencies are squishier than they are now. So, when the deployer builds the application it could say "this application expects a Jetty bundle with version between 1.0.1 and 1.0.5 or a SNAPSHOT." Modifications through the web console that require strucutural change convert the config say o/a/g/Jetty-1.0.2 to o/a/g/Jetty-1.0.2-SNAPSHOT; bundles built with a tolerance for mutability will still run but ones that assume a release version won't. For desktop and small installations we do a default assembly using SNAPSHOT bundles; larger installations will probably build their own assemblies using released versions only. --- Option 6: We add a "local" bundle to the runtime that is used to hold "stuff associated with this instance." This would be mutable and contain GBeans associated with this instance e.g. edge components like network listeners. With this model, a second HTTP connector would be added to the "local" bundle rather than o/a/g/Server or o/a/g/Jetty. Deployment does not break for portable applications which only use components from named bundles. For this to work we will need to fix the classloader to provide the import/export mechanism add will need to be able to add imports to the "local" configuration at runtime. We need to be careful about adding multiple GBeans that require classes from conflicting imports. --- There may be the possibility of a combination of multiple options e.g. mixing "local" bundles with SNAPSHOTs or UUIDs. -- Jeremy
Re: GBeans: Saving Changes
Starting a new sub-thread... One of the examples we use all the time when talking about bundles is that of a web connector. However, this is bad example to take because it is too simple to highlight some of the issues. * it only contains one GBean * that bean has a couple of fairly simple properties * nothing references that GBean so it has little impact on other bundles I think the last issue there is systemic to this kind of component: it is an edge component that takes something from the outside world (i.e. an inbound socket connection) and hands it off to other services inside the server. So in Jetty, the HTTPConnector references the JettyContainer but not the other way around. The same can be said for other edge connectors such as the EJB Daemon, the ORB, the JMX Connector ... The first two issues also cloud things because they simplify the connector to a degenerate case. Things would be more interesting if we considered a HTTPS connector that split the functionality into three components: a socket listener, a thread pool and an SSL keystore. Then, when the user wanted to add an HTTPS port we would need to create three GBeans and wire them together properly. Bear in mind that depending on the runtime, the user may want the thread pool and SSL keystore to be bundled with the connector or may want to use ones from other bundles. Other things that may seem quite simple to the user may require several GBeans be constructed - this is what we do when we package an application, we create a new bundle with a bucket load of GBeans in it (e.g. servlet holders, ejb containers, admin objects, ...). Simplicity comes from not exposing all this detail to the user. -- Jeremy
[jira] Closed: (GERONIMO-525) Exception rethrowing in KernelDelegate is often wrong
[ http://issues.apache.org/jira/browse/GERONIMO-525?page=all ] Dain Sundstrom closed GERONIMO-525: --- Fix Version: 1.0-M5 Resolution: Fixed Cleaned up the exception handling. Open a new issue if something new is found. Sending modules/kernel/src/java/org/apache/geronimo/kernel/jmx/KernelDelegate.java Transmitting file data . Committed revision 225447. > Exception rethrowing in KernelDelegate is often wrong > - > > Key: GERONIMO-525 > URL: http://issues.apache.org/jira/browse/GERONIMO-525 > Project: Geronimo > Type: Bug > Components: kernel > Versions: 1.0-M4 > Reporter: David Jencks > Assignee: Dain Sundstrom > Fix For: 1.0-M5 > > The exception rethrowing in KernelDelegate needs careful review. For > example, stopConfiguration doesn't rethrow NoSuchConfigException, thus > breaking the jsr-88 deployment tool rather completely along with other items > that depend on it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-668) Unable to determine username from EJB method
[ http://issues.apache.org/jira/browse/GERONIMO-668?page=comments#action_12316845 ] Alan Cabrera commented on GERONIMO-668: --- What about having a special Geronimo class that is designated as by Geronimo as primary, then have a convention where a special login module would insert it into the subject? This way, people could have a variety of schemes to insert the primary principal by simply writing their own login module that followed the convention and we wouldn't have to have an "uber" metadata and code to handle all the different possibilities. > Unable to determine username from EJB method > > > Key: GERONIMO-668 > URL: http://issues.apache.org/jira/browse/GERONIMO-668 > Project: Geronimo > Type: Bug > Versions: 1.0-M4 > Reporter: Ivan Dubrov > Assignee: David Jencks > Fix For: 1.0-M4, 1.0-M5 > > When calling EJB method from the Web module some important security context > information (username) is lost. It is impossible to determine caller user > name from the EJB method. EJBContext.getCallerPrincipal().getName() returns > something like this: > [org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal: manager] > Note that only group name can be determined from this string or from the > EJBMethod.getCallerPrincipal(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: GBeans: Saving Changes
We're making progress! :) On Tue, 26 Jul 2005, Jeremy Boynes wrote: > First caveat - o/a/g/Server is too monolithic which is contributing > factor to these discussions. The reasons why this is a problem and how > to start to fix it have been discussed elsewhere. True, though there are certain advantages too (like the ability to start and stop all that stuff with one command). Anyway, that's another topic. > Second caveat, change through the web console is one use case. It > applies to small installations (desktop, single server) but is less > applicable to larger installations, say with > 10 servers. It also does > not apply to "headless" servers which may not be running a web container > at all. Agreed. > I have two I've given some thought to although they're not fully thought > out - but hey, we're brainstorming right? Yes. Of the two, I like option 5 more -- and more than all the UUID-based options. I'm not sure the mutability needs to be reflected in the configuration name, though -- couldn't we have non-name properties for the version and mutability? That way the start/stop command would be the same and so on. You would refer to a prerequisite by providing the name and version range separately, and perhaps even indicating explicitly whether you're willing to depend on a mutable version. If you provide nothing but the name, that implies "any version will do". I'd propose we add a tool that can export one or more configurations named on the command line (or all current configs) and optionally: - mark them immutable - assign them a specific version or UUID - update any references between exported modules to use the new version number or UUID - include an explicit list of all their repository references if that's at all possible (as even locking the configuration contents does not prevent them from failing due to missing repository contents). - sign the exported file(s) Then we likewise need an import tool that can do whatever name-based validation we want (perhaps prompt or automatically disable any other configs with the same name and different version), make sure the repository contains all the referenced libs, and load the configurations into the config store. Then the installer could offer a bit more flexibility, and let you literally install with nothing but o/a/g/System (for a "slave" node), so that you could then use the configuration import tool to get all the (immutable or otherwise) content into that server. We also need the kernel to be aware of Configurations to the level that it can ensure a configuration is marked mutable when a change is made to any GBean in the configuration. Finally, I don't have a satisfactory answer to "what if you just redeploy from a plan with different contents but the same name". It doesn't seem all that different than making changes through the console, except the kernel has no way to intercept that if the configuration was marked immutable. Aaron > Option 5: We have two different bundle types, mutable and immutable. > Mutable ones have a special ID, e.g. containing the word SNAPSHOT so > they can be clearly identified; immutable ones have a specific version > number e.g. o/a/g/Server/1.0-M5. Any structural modification of the > bundle, e.g. adding a GBean, changing a reference pattern etc. makes the > bundle mutable. We enhance the configuration manager so that it can > handle bundle version ranges so that bundle-to-bundle dependencies are > squishier than they are now. > > So, when the deployer builds the application it could say "this > application expects a Jetty bundle with version between 1.0.1 and 1.0.5 > or a SNAPSHOT." Modifications through the web console that require > strucutural change convert the config say o/a/g/Jetty-1.0.2 to > o/a/g/Jetty-1.0.2-SNAPSHOT; bundles built with a tolerance for > mutability will still run but ones that assume a release version won't. > > For desktop and small installations we do a default assembly using > SNAPSHOT bundles; larger installations will probably build their own > assemblies using released versions only. > > --- > > Option 6: We add a "local" bundle to the runtime that is used to hold > "stuff associated with this instance." This would be mutable and contain > GBeans associated with this instance e.g. edge components like network > listeners. > > With this model, a second HTTP connector would be added to the "local" > bundle rather than o/a/g/Server or o/a/g/Jetty. Deployment does not > break for portable applications which only use components from named > bundles. > > For this to work we will need to fix the classloader to provide the > import/export mechanism add will need to be able to add imports to the > "local" configuration at runtime. We need to be careful about adding > multiple GBeans that require classes from conflicting imports. > > ---
[jira] Commented: (GERONIMO-668) Unable to determine username from EJB method
[ http://issues.apache.org/jira/browse/GERONIMO-668?page=comments#action_12316849 ] Aaron Mulder commented on GERONIMO-668: --- That works for me too. We could even make it an interface that extends Principal, so a custom LoginModule could either have one of their principal classes implement it or add a separate Gernoimo LoginModule that just adds a trivial implementation based on the login username (thus keeping the Geronimo interface out of an otherwise portable custom login module). I think it should be pretty obvious how to apply it to our own login modules. And when the server needs to reply to getCallerPrincipal, it can scan the principals and return the first one that implements that interface, or if none do, just the first principal it comes across. > Unable to determine username from EJB method > > > Key: GERONIMO-668 > URL: http://issues.apache.org/jira/browse/GERONIMO-668 > Project: Geronimo > Type: Bug > Versions: 1.0-M4 > Reporter: Ivan Dubrov > Assignee: David Jencks > Fix For: 1.0-M4, 1.0-M5 > > When calling EJB method from the Web module some important security context > information (username) is lost. It is impossible to determine caller user > name from the EJB method. EJBContext.getCallerPrincipal().getName() returns > something like this: > [org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal: manager] > Note that only group name can be determined from this string or from the > EJBMethod.getCallerPrincipal(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-668) Unable to determine username from EJB method
[ http://issues.apache.org/jira/browse/GERONIMO-668?page=comments#action_12316851 ] David Jencks commented on GERONIMO-668: --- I like the interface idea. > Unable to determine username from EJB method > > > Key: GERONIMO-668 > URL: http://issues.apache.org/jira/browse/GERONIMO-668 > Project: Geronimo > Type: Bug > Versions: 1.0-M4 > Reporter: Ivan Dubrov > Assignee: David Jencks > Fix For: 1.0-M4, 1.0-M5 > > When calling EJB method from the Web module some important security context > information (username) is lost. It is impossible to determine caller user > name from the EJB method. EJBContext.getCallerPrincipal().getName() returns > something like this: > [org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal: manager] > Note that only group name can be determined from this string or from the > EJBMethod.getCallerPrincipal(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-791) Remove GBeanInstance support for J2EEManagedObject methods
[ http://issues.apache.org/jira/browse/GERONIMO-791?page=all ] Dain Sundstrom closed GERONIMO-791: --- Fix Version: 1.0-M5 Resolution: Fixed Deleting modules/kernel/src/java/org/apache/geronimo/gbean/GBeanLifecycleController.java Sending modules/kernel/src/java/org/apache/geronimo/gbean/runtime/GBeanInstance.java Sending modules/kernel/src/java/org/apache/geronimo/gbean/runtime/GBeanInstanceState.java Sendingmodules/kernel/src/test/org/apache/geronimo/kernel/GBeanTest.java Sending modules/kernel/src/test/org/apache/geronimo/kernel/MockEndpoint.java Sendingmodules/kernel/src/test/org/apache/geronimo/kernel/MockGBean.java Transmitting file data . Committed revision 225470. > Remove GBeanInstance support for J2EEManagedObject methods > -- > > Key: GERONIMO-791 > URL: http://issues.apache.org/jira/browse/GERONIMO-791 > Project: Geronimo > Type: Bug > Components: kernel > Versions: 1.0-M3 > Reporter: Aaron Mulder > Assignee: Dain Sundstrom > Fix For: 1.0-M5 > > The current "GBean Framework" provides support for the methods of > J2EEManagedObject, meaning they're effectively implemented for every GBean > regardless of whether the GBean itself implements them. This happens in > GBeanInstace.addManagedObjectAttributes, and the attributes in question are: > objectName (String, "special") > stateManageable (boolean, "framework") > statisticsProvider (boolean, "framework") > eventProvider (boolean, "framework") > These should be removed. If a GBean wants to implement J2EEManagedObject, it > should provide its own implementation of this stuff. (It can get its > ObjectName injected as a magic attribute.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
