Re: [VOTE] M4 release
+1 David Blevins wrote: The tests are still running on David J's machine and should finish sometime tomorrow. Since voting takes a day or so anyway, let's get started and do them in parallel. Vote: Let's Release these binaries when the tests successfully complete. (http://cvs.apache.org/dist/geronimo/unstable/1.0-M4) Here is my +1. -David -- Jeff Genender http://geronimo.apache.org
Re: [jira] Created: (GERONIMO-843) Move Packaging Plugin from cglib 2.1 to cglib 2.1_2 to be consistent with cglib in Geronimo builds
Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/08/2005 04:10:42 PM: > John Sisson (JIRA) wrote: > > Move Packaging Plugin from cglib 2.1 to cglib 2.1_2 to be > consistent with cglib in Geronimo builds > > > -- > > > > Key: GERONIMO-843 > > URL: http://issues.apache.org/jira/browse/GERONIMO-843 > > Project: Geronimo > > Type: Task > > Versions: 1.0-M4 > > Reporter: John Sisson > > Priority: Minor > > Fix For: 1.0-M5 > > > > > > Need to update geronimo/plugins/geronimo-packaging-plugin/project. > xml to use cglib version 2.1_2 (note the underscore). > > > > Do we have anything using the packaging plugin at the moment? > > > > No, go for it. Currently the version number for the packaging plugin is 0.1.1. This seems to be inconsistent with the versioning scheme used for the other plugins. Is this intended? I noticed the plugin isn't in http://cvs.apache.org/repository/geronimo/plugins/ . When are the geronimo plugins normally deployed to the repo? John > -- > Jeremy >
[jira] Commented: (GERONIMO-794) List only installed applications that are not part of Geronimo itself
[ http://issues.apache.org/jira/browse/GERONIMO-794?page=comments#action_12317579 ] Dondi Imperial commented on GERONIMO-794: - If I understand correctly you want a way for each portlet that lists configurations to be able to filter the configs they list (system/user/both). This is easy enough to add. The problem is, how do you know that a config is part of the System? Do you use a naive filter where all configs whose ids start with "org/apache/geronimo/" are system configs and everything else is a user config? > List only installed applications that are not part of Geronimo itself > - > > Key: GERONIMO-794 > URL: http://issues.apache.org/jira/browse/GERONIMO-794 > Project: Geronimo > Type: Improvement > Components: management > Versions: 1.0-M5 > Environment: all > Reporter: Joe Bohn > Attachments: console.diff > > A user should only see applications that they installed when accessing the > list of installed applications from the admin console. We can still show the > "system" applications but under an additional portet that by default is > minimized on the page. -- 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-851) Move Geronimo Build to M2 (Maven 2)
Move Geronimo Build to M2 (Maven 2) --- Key: GERONIMO-851 URL: http://issues.apache.org/jira/browse/GERONIMO-851 Project: Geronimo Type: Task Components: buildsystem Reporter: John Sisson Fix For: 1.0 Created this issue to keep track of the status of work to move the Geronimo build to Maven 2. Does anyone know the status of this effort? I believe some work was done in OpenEJB? When is the move to M2 planned for? 1.0 or 1.1 FYI.. In June I attempted to use Maven 1.1 beta 1 to build geronimo and got some parse exceptions in maven. As a result, some small changes were made to some project.xml files by David Jencks, which fixed the parse problem, but we then ran into another problem where we were getting a java.lang.NoSuchMethodError in maven. This should now be fixed using an updated artifact plugin, see http://jira.codehaus.org/browse/MAVEN-1625 (but I have not verified this). -- 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: [VOTE] M4 release
David Blevins <[EMAIL PROTECTED]> wrote on 04/08/2005 11:54:41 AM: > The tests are still running on David J's machine and should finish > sometime tomorrow. Since voting takes a day or so anyway, let's get > started and do them in parallel. > > Vote: > Let's Release these binaries when the tests successfully complete. > (http://cvs.apache.org/dist/geronimo/unstable/1.0-M4) > > Here is my +1. > > -David +1 This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally.
[jira] Updated: (GERONIMO-555) Write a thread-safe timer/interrupt based transaction timout implementation
[ http://issues.apache.org/jira/browse/GERONIMO-555?page=all ] Aaron Mulder updated GERONIMO-555: -- Fix Version: 1.0 Description: We should investigate whether it is practical to have a thread safe timer/interrupt based transaction timeout implementation. A non-thread safe implementation was present prior to revision 128441. Among the issues that need to be investigated are the extent to which IO is actually interruptable and what existing drivers do when they are interrupted. For this to work, managed connections that get interrupted during io must be reliably destroyed. We should also investigate to what extent this provides a solution for deadlock resolution. If we decide that this is impractical, we should change the internal time unit for timeouts from milliseconds to seconds as proposed in GERONIMO-550 was: We should investigate whether it is practical to have a thread safe timer/interrupt based transaction timeout implementation. A non-thread safe implementation was present prior to revision 128441. Among the issues that need to be investigated are the extent to which IO is actually interruptable and what existing drivers do when they are interrupted. For this to work, managed connections that get interrupted during io must be reliably destroyed. We should also investigate to what extent this provides a solution for deadlock resolution. If we decide that this is impractical, we should change the internal time unit for timeouts from milliseconds to seconds as proposed in GERONIMO-550 Environment: > Write a thread-safe timer/interrupt based transaction timout implementation > --- > > Key: GERONIMO-555 > URL: http://issues.apache.org/jira/browse/GERONIMO-555 > Project: Geronimo > Type: New Feature > Components: transaction manager > Reporter: David Jencks > Fix For: 1.0 > > We should investigate whether it is practical to have a thread safe > timer/interrupt based transaction timeout implementation. A non-thread safe > implementation was present prior to revision 128441. > Among the issues that need to be investigated are the extent to which IO is > actually interruptable and what existing drivers do when they are > interrupted. For this to work, managed connections that get interrupted > during io must be reliably destroyed. > We should also investigate to what extent this provides a solution for > deadlock resolution. > If we decide that this is impractical, we should change the internal time > unit for timeouts from milliseconds to seconds as proposed in GERONIMO-550 -- 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-557) smooth application upgrade/versioning
[ http://issues.apache.org/jira/browse/GERONIMO-557?page=all ] Aaron Mulder updated GERONIMO-557: -- Fix Version: 1.1 Description: There have been several requests for the ability to change fairly fundamental bits of application configuration at runtime, such as which resource a resource-ref points to. Currently the only way to do this is to redeploy the reconfigured application, and changing this would break a lot of our implementation and some of our philosophy. Perhaps a better way to approach this kind of problem is to version applications, and have a process for seamlessly switching between versions of an application. So, to change the target of a resource-ref, you'd configure a new "copy" of your app with the new target, deploy it, and undeploy the old version. was: There have been several requests for the ability to change fairly fundamental bits of application configuration at runtime, such as which resource a resource-ref points to. Currently the only way to do this is to redeploy the reconfigured application, and changing this would break a lot of our implementation and some of our philosophy. Perhaps a better way to approach this kind of problem is to version applications, and have a process for seamlessly switching between versions of an application. So, to change the target of a resource-ref, you'd configure a new "copy" of your app with the new target, deploy it, and undeploy the old version. Environment: > smooth application upgrade/versioning > - > > Key: GERONIMO-557 > URL: http://issues.apache.org/jira/browse/GERONIMO-557 > Project: Geronimo > Type: New Feature > Reporter: David Jencks > Fix For: 1.1 > > There have been several requests for the ability to change fairly fundamental > bits of application configuration at runtime, such as which resource a > resource-ref points to. Currently the only way to do this is to redeploy the > reconfigured application, and changing this would break a lot of our > implementation and some of our philosophy. > Perhaps a better way to approach this kind of problem is to version > applications, and have a process for seamlessly switching between versions of > an application. > So, to change the target of a resource-ref, you'd configure a new "copy" of > your app with the new target, deploy it, and undeploy the old version. -- 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-572) GBeanName instead of ObjectName
[ http://issues.apache.org/jira/browse/GERONIMO-572?page=all ] Aaron Mulder updated GERONIMO-572: -- Fix Version: 1.1 Description: We may want to completely avoid jmx in the kernel and provide alternative naming schemes. This would presumably involve a gbean name that has a map of key-value pairs. Currently jsr-77 has encroached into the kernel in the following ways: Configuration has two named key-value pairs, domain and server. These should be replaced by a map that can be used by any naming system, not just jsr-77. GBeanInfoFactory/GBeanInfo has a hardcoded type key-value. This should be reexamined for possible generalization/replacement/modification. This issue is intended primarily as a placeholder for proposals and discussion on this issue. was: We may want to completely avoid jmx in the kernel and provide alternative naming schemes. This would presumably involve a gbean name that has a map of key-value pairs. Currently jsr-77 has encroached into the kernel in the following ways: Configuration has two named key-value pairs, domain and server. These should be replaced by a map that can be used by any naming system, not just jsr-77. GBeanInfoFactory/GBeanInfo has a hardcoded type key-value. This should be reexamined for possible generalization/replacement/modification. This issue is intended primarily as a placeholder for proposals and discussion on this issue. Version: 1.0-M4 Environment: > GBeanName instead of ObjectName > --- > > Key: GERONIMO-572 > URL: http://issues.apache.org/jira/browse/GERONIMO-572 > Project: Geronimo > Type: New Feature > Components: kernel > Versions: 1.0-M4 > Reporter: David Jencks > Fix For: 1.1 > > We may want to completely avoid jmx in the kernel and provide alternative > naming schemes. This would presumably involve a gbean name that has a map of > key-value pairs. > Currently jsr-77 has encroached into the kernel in the following ways: > Configuration has two named key-value pairs, domain and server. These should > be replaced by a map that can be used by any naming system, not just jsr-77. > GBeanInfoFactory/GBeanInfo has a hardcoded type key-value. This should be > reexamined for possible generalization/replacement/modification. > This issue is intended primarily as a placeholder for proposals and > discussion on this issue. -- 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-571) Provide ability to start all non-started GBeans and see error messages as to why they did not start
[ http://issues.apache.org/jira/browse/GERONIMO-571?page=all ] Aaron Mulder updated GERONIMO-571: -- Fix Version: 1.0 Description: David Jencks suggested this as a small but useful project for me to do. Could either be implemented as : * an operation on a GBean that would return the info for the non-started gbeans. We'd have to find ways to call the operation. * an enhancement to the Debug console Comments welcome. was: David Jencks suggested this as a small but useful project for me to do. Could either be implemented as : * an operation on a GBean that would return the info for the non-started gbeans. We'd have to find ways to call the operation. * an enhancement to the Debug console Comments welcome. Version: 1.0-M4 Environment: > Provide ability to start all non-started GBeans and see error messages as to > why they did not start > --- > > Key: GERONIMO-571 > URL: http://issues.apache.org/jira/browse/GERONIMO-571 > Project: Geronimo > Type: Improvement > Versions: 1.0-M4 > Reporter: John Sisson > Fix For: 1.0 > > David Jencks suggested this as a small but useful project for me to do. > Could either be implemented as : > * an operation on a GBean that would return the info for the non-started > gbeans. We'd have to find ways to call the operation. > * an enhancement to the Debug console > Comments welcome. -- 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-575) updates to the web site
[ http://issues.apache.org/jira/browse/GERONIMO-575?page=all ] Aaron Mulder resolved GERONIMO-575: --- Resolution: Invalid Web site has been independently updated (and as I understand it is no longer generated by Maven). If you think the new one could be improved as well, please reopen this with an updated patch. > updates to the web site > --- > > Key: GERONIMO-575 > URL: http://issues.apache.org/jira/browse/GERONIMO-575 > Project: Geronimo > Type: Improvement > Components: web > Environment: subversion revision 153446. > Reporter: toby cabot > Attachments: website-patch.txt > > per the discussion on the user mailing list in early February (I'd link but > the archive appears to be broken at the moment) here's a patch to freshen the > maven-generated web site. highlights include: > o removing links to old source releases > o adding "Getting Involved" section on front page > o removing download section from front page (it's got its own page) > o adding a news item > there are a lot of smaller changes, too. you can see the results at > http://www.caboteria.org/~tobyc/g6o-docs/ . -- 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-589) Standalone war does not have a default context
[ http://issues.apache.org/jira/browse/GERONIMO-589?page=all ] Aaron Mulder updated GERONIMO-589: -- Fix Version: 1.0-M5 Description: If I have a standalone war with the following deployment plan: http://geronimo.apache.org/xml/ns/web/jetty"; configId="foo" parentId="org/apache/geronimo/Server"> false The module will deploy, but the following exception is thrown on startup: java.lang.IllegalArgumentException: Illegal context spec:null at org.mortbay.http.HttpContext.canonicalContextPathSpec(HttpContext.java:241) at org.mortbay.http.HttpContext.setContextPath(HttpContext.java:263) at org.mortbay.http.HttpContext$$FastClassByCGLIB$$c359e803.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanAttribute.setValue(GBeanAttribute.java:387) at org.apache.geronimo.gbean.runtime.GBeanAttribute.inject(GBeanAttribute.java:318) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:331) 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:494) at org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:348) This can be fixed by adding a context-root element to the deployment plan. Either the context-root element should be required, or preferably set the default context to the configuration id which is the default in the case where you have no deployment plan. Also the context-priority-classloader element should be optional. was: If I have a standalone war with the following deployment plan: http://geronimo.apache.org/xml/ns/web/jetty"; configId="foo" parentId="org/apache/geronimo/Server"> false The module will deploy, but the following exception is thrown on startup: java.lang.IllegalArgumentException: Illegal context spec:null at org.mortbay.http.HttpContext.canonicalContextPathSpec(HttpContext.java:241) at org.mortbay.http.HttpContext.setContextPath(HttpContext.java:263) at org.mortbay.http.HttpContext$$FastClassByCGLIB$$c359e803.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanAttribute.setValue(GBeanAttribute.java:387) at org.apache.geronimo.gbean.runtime.GBeanAttribute.inject(GBeanAttribute.java:318) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:331) 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:494) at org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:348) This can be fixed by adding a context-root element to the deployment plan. Either the context-root element should be required, or preferably set the default context to the configuration id which is the default in the case where you have no deployment plan. Also the context-priority-classloader element should be optional. Environment: > Standalone war does not have a default context > -- > > Key: GERONIMO-589 > URL: http://issues.apache.org/jira/browse/GERONIMO-589 > Project: Geronimo > Type: Bug > Components: web > Versions: 1.0-M3 > Reporter: Dain Sundstrom > Assignee: David Jencks > Fix For: 1.0-M5 > Attachments: patch.tar.gz > > If I have a standalone war with the following deployment plan: > > http://geronimo.apache.org/xml/ns/web/jetty"; > configId="foo" > parentId="org/apache/geronimo/Server"> > false > > The module will deploy, but the following exception is thrown on startup: > java.lang.IllegalArgumentException: Illegal context spec:null > at > org.mortbay.http.HttpContext.canonicalContextPathSpec(HttpContext.java:241) > at org.mortbay.http.HttpContext.setContextPath(HttpContext.java:263) > at > org.mortbay.http.HttpContext$$FastClassByCGLIB$$c359e803.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.ap
[jira] Updated: (GERONIMO-592) Startup failure in Turkish language settings
[ http://issues.apache.org/jira/browse/GERONIMO-592?page=all ] Aaron Mulder updated GERONIMO-592: -- Fix Version: 1.1 Assign To: Aaron Mulder I don't have a foreign-language machine to test this with for the current code. Please try the upcoming M4 release and let me know if this is still a problem. I will need to work with you to resolve this if it's still a problem. Thanks! > Startup failure in Turkish language settings > > > Key: GERONIMO-592 > URL: http://issues.apache.org/jira/browse/GERONIMO-592 > Project: Geronimo > Type: Bug > Components: kernel > Versions: 1.0-M3 > Environment: Windows XP with Turkish language settings > Reporter: Gorkem Ercan > Assignee: Aaron Mulder > Fix For: 1.1 > > If tried to start with java -jar server.jar in Turkish language setting. > startup fails with no log messages. Console prints some error messages but > these are due to failed services. -- 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-578) Repeated Deploy Attempts See Old Code
[ http://issues.apache.org/jira/browse/GERONIMO-578?page=all ] Aaron Mulder closed GERONIMO-578: - Fix Version: 1.0-M5 Resolution: Fixed Assign To: Aaron Mulder Does not seem to be a problem for the current HEAD. > Repeated Deploy Attempts See Old Code > - > > Key: GERONIMO-578 > URL: http://issues.apache.org/jira/browse/GERONIMO-578 > Project: Geronimo > Type: Bug > Components: OpenEJB, deployment > Versions: 1.0-M3 > Reporter: Aaron Mulder > Assignee: Aaron Mulder > Fix For: 1.0-M5 > > Attempted to deploy an EAR containing a RAR and an EJB JAR with an MDB in to > Geronimo M3. Got a stack trace including a message that my openejb-jar.xml > syntax was wrong (was still using pre-M3 openejb-jar.xml). Updated syntax, > rebuilt, and tried to deploy again. Got the same message again referencing > the old DD content. Double-checked that application was updated; it was. > Tried again, same message. Stopped and started server and tried the deploy > again, and it worked. It seems like repeated deploy attempts while the > server is running just attempt to deploy the original code again instead of > seeing the new code. > I have not tried this on HEAD. -- 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-585) No indication when DefaultWorkManager pool is exhausted
[ http://issues.apache.org/jira/browse/GERONIMO-585?page=all ] Aaron Mulder updated GERONIMO-585: -- Fix Version: 1.1 Description: I created a connector that executes 8 long-running Work objects at startup (DefaultWorkManager pool size = 10). If I deploy it twice, the second deploy operation hangs, causing the deploy tool to hang as well (and in fact the server hangs if you try to shut down and you have to kill -9 it). There's no evidence what the problem is. It would be nice if we at least printed a debug message or something when you submit work and there's no worker thread available. In truth, there are better ways to code the RA, but the hangs, and the fact that it hangs the deployer and server shutdown too... was: I created a connector that executes 8 long-running Work objects at startup (DefaultWorkManager pool size = 10). If I deploy it twice, the second deploy operation hangs, causing the deploy tool to hang as well (and in fact the server hangs if you try to shut down and you have to kill -9 it). There's no evidence what the problem is. It would be nice if we at least printed a debug message or something when you submit work and there's no worker thread available. In truth, there are better ways to code the RA, but the hangs, and the fact that it hangs the deployer and server shutdown too... Environment: > No indication when DefaultWorkManager pool is exhausted > --- > > Key: GERONIMO-585 > URL: http://issues.apache.org/jira/browse/GERONIMO-585 > Project: Geronimo > Type: Improvement > Components: connector > Versions: 1.0-M3 > Reporter: Aaron Mulder > Fix For: 1.1 > > I created a connector that executes 8 long-running Work objects at startup > (DefaultWorkManager pool size = 10). If I deploy it twice, the second deploy > operation hangs, causing the deploy tool to hang as well (and in fact the > server hangs if you try to shut down and you have to kill -9 it). There's no > evidence what the problem is. It would be nice if we at least printed a > debug message or something when you submit work and there's no worker thread > available. In truth, there are better ways to code the RA, but the hangs, > and the fact that it hangs the deployer and server shutdown too... -- 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-583) Missing J2EE Validations
[ http://issues.apache.org/jira/browse/GERONIMO-583?page=all ] Aaron Mulder updated GERONIMO-583: -- Fix Version: 1.1 Description: This is a list of validations that are not currently implemented, but perhaps should be. EJB - session bean impl class should have ejbCreate() - EJB 1.1 CMP entity should not use EJB QL Connector - classes should be in JAR in RAR, not directly in RAR (maybe just check whether all listed classes -- RA, ActivationSpect, etc. are available) was: This is a list of validations that are not currently implemented, but perhaps should be. EJB - session bean impl class should have ejbCreate() - EJB 1.1 CMP entity should not use EJB QL Connector - classes should be in JAR in RAR, not directly in RAR (maybe just check whether all listed classes -- RA, ActivationSpect, etc. are available) Environment: > Missing J2EE Validations > > > Key: GERONIMO-583 > URL: http://issues.apache.org/jira/browse/GERONIMO-583 > Project: Geronimo > Type: Improvement > Components: connector, application client, deployment, OpenEJB, web > Versions: 1.0-M3 > Reporter: Aaron Mulder > Fix For: 1.1 > > This is a list of validations that are not currently implemented, but perhaps > should be. > EJB > - session bean impl class should have ejbCreate() > - EJB 1.1 CMP entity should not use EJB QL > Connector > - classes should be in JAR in RAR, not directly in RAR (maybe just check > whether all listed classes -- RA, ActivationSpect, etc. are available) -- 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-848) Deployer ignores Geronimo URL host/port
[ http://issues.apache.org/jira/browse/GERONIMO-848?page=comments#action_12317569 ] Kevan Miller commented on GERONIMO-848: --- Aaron is right that the syntax for the uri was incorrect. I was looking into the problem also, but hadn't gotten to the root of the problem. I can't say that I fully comprehend how things are working at present, however. For instance, why does the URI work as long as you don't specify a port number? Oh, I kind of see... deployer:geronimo:jmx:rmi://foobar/jndi/rmi://:/JMXConnector works just as well... I would suggest at least one code change for this issue. org.apache.geronimo.deployment.cli.ServerConnection.java contains the following static variable used for generating the default uri in the absence of one specified on the command line: private final static String DEFAULT_URI = "deployer:geronimo:jmx:rmi://localhost/jndi/rmi:/JMXConnector"; I'd update to reflect a more educational syntax. I see the Wiki (http://wiki.apache.org/geronimo/Running) also references the same uri... Aaron, BTW, isn't this a dup of http://issues.apache.org/jira/browse/GERONIMO-462 ? > Deployer ignores Geronimo URL host/port > --- > > Key: GERONIMO-848 > URL: http://issues.apache.org/jira/browse/GERONIMO-848 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4 > Reporter: Aaron Mulder > Fix For: 1.0-M5 > > When the deployer connects to a server, it uses a URL of the form: > deployer:geronimo:jmx:rmi://host:port/jndi/rmi:/JMXConnector > Under the covers, this strips off the beginning and uses a connection of the > form: > jmx:rmi://host:port/jndi/rmi:/JMXConnector > However, no matter what you use as the host and port, it connects to the > standard port on localhost. It should actually attempt to connect to the > host and port specified and give an error if they are not valid. -- 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-609) geronimo.log can be closed whilst distributing an EAR if the application uses log4j
[ http://issues.apache.org/jira/browse/GERONIMO-609?page=all ] Aaron Mulder updated GERONIMO-609: -- Fix Version: 1.0 Description: The following stack trace shows the geronimo.log file being closed as a result of static code being executed in a session bean whilst the configuration is being stored. The EAR has a geronimo-application.xml file that contains a dependencies element that adds log4j as a dependency, to ensure the application (when it initialises its logging) does not interfere with geronimo's logging. Well, that was the plan, but I wasn't expecting to see the application's code being executed without using the dependencies it was configured with. Here is the stack trace: System Thread [RMI TCP Connection(7)-172.21.35.170] (Suspended (breakpoint at line 171 in org.apache.log4j.FileAppender)) org.apache.log4j.RollingFileAppender(org.apache.log4j.FileAppender).closeFile() line: 171 org.apache.log4j.RollingFileAppender(org.apache.log4j.FileAppender).reset() line: 302 org.apache.log4j.RollingFileAppender(org.apache.log4j.WriterAppender).close() line: 195 org.apache.log4j.helpers.AppenderAttachableImpl.removeAllAppenders() line: 132 org.apache.log4j.spi.RootCategory(org.apache.log4j.Category).removeAllAppenders() line: 879 org.apache.log4j.PropertyConfigurator.parseCategory(java.util.Properties, org.apache.log4j.Logger, java.lang.String, java.lang.String, java.lang.String) line: 594 org.apache.log4j.PropertyConfigurator.configureRootCategory(java.util.Properties, org.apache.log4j.spi.LoggerRepository) line: 500 org.apache.log4j.PropertyConfigurator.doConfigure(java.util.Properties, org.apache.log4j.spi.LoggerRepository) line: 406 org.apache.log4j.PropertyConfigurator.configure(java.util.Properties) line: 340 com.blah.server.ejb.ServerConfigPvtBean.() line: 93 java.io.ObjectStreamClass.hasStaticInitializer(java.lang.Class) line: not available [native method] java.io.ObjectStreamClass.computeDefaultSUID(java.lang.Class) line: 1557 java.io.ObjectStreamClass.access$100(java.lang.Class) line: 47 java.io.ObjectStreamClass$1.run() line: 173 java.security.AccessController.doPrivileged(java.security.PrivilegedAction) line: not available [native method] java.io.ObjectStreamClass.getSerialVersionUID() line: 170 java.io.ObjectStreamClass.writeNonProxy(java.io.ObjectOutputStream) line: 557 java.io.ObjectOutputStream.writeClassDescriptor(java.io.ObjectStreamClass) line: 591 java.io.ObjectOutputStream.writeNonProxyDesc(java.io.ObjectStreamClass, boolean) line: 1142 java.io.ObjectOutputStream.writeClassDesc(java.io.ObjectStreamClass, boolean) line: 1100 java.io.ObjectOutputStream.writeClass(java.lang.Class, boolean) line: 1082 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 996 java.io.ObjectOutputStream.defaultWriteFields(java.lang.Object, java.io.ObjectStreamClass) line: 1332 java.io.ObjectOutputStream.writeSerialData(java.lang.Object, java.io.ObjectStreamClass) line: 1304 java.io.ObjectOutputStream.writeOrdinaryObject(java.lang.Object, java.io.ObjectStreamClass, boolean) line: 1247 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 1052 java.io.ObjectOutputStream.writeArray(java.lang.Object, java.io.ObjectStreamClass, boolean) line: 1224 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 1050 java.io.ObjectOutputStream.defaultWriteFields(java.lang.Object, java.io.ObjectStreamClass) line: 1332 java.io.ObjectOutputStream.writeSerialData(java.lang.Object, java.io.ObjectStreamClass) line: 1304 java.io.ObjectOutputStream.writeOrdinaryObject(java.lang.Object, java.io.ObjectStreamClass, boolean) line: 1247 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 1052 java.io.ObjectOutputStream.writeObject(java.lang.Object) line: 278 org.apache.geronimo.gbean.GBeanData.writeExternal(java.io.ObjectOutput) line: 132 org.apache.geronimo.kernel.config.Configuration.storeGBeans(org.apache.geronimo.gbean.GBeanData[]) line: 422 org.apache.geronimo.j2ee.deployment.EARContext(org.apache.geronimo.deployment.DeploymentContext).saveConfiguration() line: 490 org.apache.geronimo.j2ee.deployment.EARContext(org.apache.geronimo.deployment.DeploymentContext).close() line: 452 org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(java.lang.Object, java.util.jar.JarFile, java.io.File) line: 359 org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(int, java.lang.Object, java.lang.Object[]) line: not available net.sf.cglib.reflect.FastMethod.invoke(java.lang.Object, java.lang.Obje
[jira] Updated: (GERONIMO-611) Changes required to Geronimo to work with Log4j 1.3 (alpha-6)
[ http://issues.apache.org/jira/browse/GERONIMO-611?page=all ] Aaron Mulder updated GERONIMO-611: -- Fix Version: 1.0 Description: Changes are required to Geronimo in the in the org.apache.geronimo.system.logging.log4j package to compile against the upcoming Log4j version 1.3. In particular, the method of implementing custom PatternLayouts has changed. See http://www.qos.ch/logging/PatternLayout.jsp I am investigating further. Also see related OpenEJB patch in http://jira.codehaus.org/browse/OPENEJB-20 was: Changes are required to Geronimo in the in the org.apache.geronimo.system.logging.log4j package to compile against the upcoming Log4j version 1.3. In particular, the method of implementing custom PatternLayouts has changed. See http://www.qos.ch/logging/PatternLayout.jsp I am investigating further. Also see related OpenEJB patch in http://jira.codehaus.org/browse/OPENEJB-20 Environment: Assign To: John Sisson > Changes required to Geronimo to work with Log4j 1.3 (alpha-6) > - > > Key: GERONIMO-611 > URL: http://issues.apache.org/jira/browse/GERONIMO-611 > Project: Geronimo > Type: Task > Reporter: John Sisson > Assignee: John Sisson > Fix For: 1.0 > > Changes are required to Geronimo in the in the > org.apache.geronimo.system.logging.log4j package to compile against the > upcoming Log4j version 1.3. In particular, the method of implementing custom > PatternLayouts has changed. See http://www.qos.ch/logging/PatternLayout.jsp > I am investigating further. > Also see related OpenEJB patch in http://jira.codehaus.org/browse/OPENEJB-20 -- 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-616) Wrong package statement for DoubleKeyedHashMap
[ http://issues.apache.org/jira/browse/GERONIMO-616?page=all ] Aaron Mulder closed GERONIMO-616: - Fix Version: 1.0-M5 Resolution: Fixed Appears to have been fixed some time in the past > Wrong package statement for DoubleKeyedHashMap > -- > > Key: GERONIMO-616 > URL: http://issues.apache.org/jira/browse/GERONIMO-616 > Project: Geronimo > Type: Bug > Components: transaction manager > Reporter: Kristian Koehler > Assignee: Jeremy Boynes > Fix For: 1.0-M5 > Attachments: doubleKey.patch > > the file DoubleKeyedHashMap.java contains a wrong package statement. > included statement: org.apache.geronimo.transaction > should be: org.apache.geronimo.transaction.context > patch attached -- 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-601) Reverse context identifier transformations when possible
[ http://issues.apache.org/jira/browse/GERONIMO-601?page=all ] Aaron Mulder updated GERONIMO-601: -- Fix Version: 1.0 Version: (was: 1.0-M3) Environment: Assign To: Gianny Damour > Reverse context identifier transformations when possible > > > Key: GERONIMO-601 > URL: http://issues.apache.org/jira/browse/GERONIMO-601 > Project: Geronimo > Type: Task > Components: OpenEJB > Reporter: Gianny Damour > Assignee: Gianny Damour > Fix For: 1.0 > > ContainerSecurityBuilder and EJBSecurityInterceptor replace ',' with a '_'. > This operation needs to be reversed "when possible". -- 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: [VOTE] M4 release
+1 On Aug 3, 2005, at 9:54 PM, David Blevins wrote: The tests are still running on David J's machine and should finish sometime tomorrow. Since voting takes a day or so anyway, let's get started and do them in parallel. Vote: Let's Release these binaries when the tests successfully complete. (http://cvs.apache.org/dist/geronimo/unstable/1.0-M4) Here is my +1. -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Updated: (GERONIMO-627) no link to Geronimo from the incubator web page
[ http://issues.apache.org/jira/browse/GERONIMO-627?page=all ] Aaron Mulder updated GERONIMO-627: -- Fix Version: 1.0-M5 Description: The old incubator web page for Geronimo has no reference or indication that Geronimo has moved on from the incubator stage. This leads to visitors thinking the project may have ended, especially given the last news item on display (which is from 2003...). http://incubator.apache.org/projects/geronimo.html Also the incubator page is the number one Google hit for queries on "apache j2ee" and "apache ejb", so many people will only find the outdated incubator page. http://www.google.com/search?q=apache+j2ee http://www.google.com/search?q=apache+ejb was: The old incubator web page for Geronimo has no reference or indication that Geronimo has moved on from the incubator stage. This leads to visitors thinking the project may have ended, especially given the last news item on display (which is from 2003...). http://incubator.apache.org/projects/geronimo.html Also the incubator page is the number one Google hit for queries on "apache j2ee" and "apache ejb", so many people will only find the outdated incubator page. http://www.google.com/search?q=apache+j2ee http://www.google.com/search?q=apache+ejb Version: 1.0-M4 Assign To: Davanum Srinivas As of 8/3/2005 this page still shows Incubator status (apparently the redirect didn't work) > no link to Geronimo from the incubator web page > --- > > Key: GERONIMO-627 > URL: http://issues.apache.org/jira/browse/GERONIMO-627 > Project: Geronimo > Type: Task > Components: web > Versions: 1.0-M4 > Environment: n/a > Reporter: Leonard Norrgard > Assignee: Davanum Srinivas > Fix For: 1.0-M5 > > The old incubator web page for Geronimo has no reference or indication that > Geronimo has moved on from the incubator stage. This leads to visitors > thinking the project may have ended, especially given the last news item on > display (which is from 2003...). > http://incubator.apache.org/projects/geronimo.html > Also the incubator page is the number one Google hit for queries on "apache > j2ee" and "apache ejb", so many people will only find the outdated incubator > page. > http://www.google.com/search?q=apache+j2ee > http://www.google.com/search?q=apache+ejb -- 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-433) Tolerate non-Sun JREs
[ http://issues.apache.org/jira/browse/GERONIMO-433?page=all ]
Aaron Mulder updated GERONIMO-433:
--
Fix Version: 1.1
Description:
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";
was:
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";
Version: 1.0-M4
Environment:
> Tolerate non-Sun JREs
> -
>
> Key: GERONI
[jira] Updated: (GERONIMO-640) Remove dependency on Sun internals code for URL decoding
[ http://issues.apache.org/jira/browse/GERONIMO-640?page=all ] Aaron Mulder updated GERONIMO-640: -- Fix Version: 1.0-M5 Description: [Looking at 1.0-M3 source code] The Geronimo types: org.apache.geronimo.system.url.file.Handler and org.apache.geronimo.system.url.file.FileURLConnection both import and use the Sun non-API type "sun.net.www.ParseUtil". It appears that the usage is quite trivial, and can easily be replaced by API calls on URLDecoder. This will remove a JRE-implementation dependency. The only caveat is that simple tests show that URLDecoder decodes 'more' than the ParseUtil, so while both methods will convert "a%20b" to "a b"; the URLDecoder will convert "a+b" to "a b" whereas ParseUtil leaves it as "a+b". Is this difference in decoding behavior expected by Geronimo? was: [Looking at 1.0-M3 source code] The Geronimo types: org.apache.geronimo.system.url.file.Handler and org.apache.geronimo.system.url.file.FileURLConnection both import and use the Sun non-API type "sun.net.www.ParseUtil". It appears that the usage is quite trivial, and can easily be replaced by API calls on URLDecoder. This will remove a JRE-implementation dependency. The only caveat is that simple tests show that URLDecoder decodes 'more' than the ParseUtil, so while both methods will convert "a%20b" to "a b"; the URLDecoder will convert "a+b" to "a b" whereas ParseUtil leaves it as "a+b". Is this difference in decoding behavior expected by Geronimo? Environment: Still a problem for M4 and HEAD as of today > Remove dependency on Sun internals code for URL decoding > > > Key: GERONIMO-640 > URL: http://issues.apache.org/jira/browse/GERONIMO-640 > Project: Geronimo > Type: Improvement > Versions: 1.0-M3 > Reporter: Tim Ellison > Fix For: 1.0-M5 > Attachments: decode-patch.txt > > [Looking at 1.0-M3 source code] > The Geronimo types: > org.apache.geronimo.system.url.file.Handler > and > org.apache.geronimo.system.url.file.FileURLConnection > both import and use the Sun non-API type "sun.net.www.ParseUtil". It appears > that the usage is quite trivial, and can easily be replaced by API calls on > URLDecoder. This will remove a JRE-implementation dependency. > The only caveat is that simple tests show that URLDecoder decodes 'more' than > the ParseUtil, so while both methods will convert "a%20b" to "a b"; the > URLDecoder will convert "a+b" to "a b" whereas ParseUtil leaves it as "a+b". > Is this difference in decoding behavior expected by Geronimo? -- 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: [VOTE] M4 release
+1 On 3 Aug 2005, at 19:38, Aaron Mulder wrote: +1 Aaron On Wed, 3 Aug 2005, David Blevins wrote: The tests are still running on David J's machine and should finish sometime tomorrow. Since voting takes a day or so anyway, let's get started and do them in parallel. Vote: Let's Release these binaries when the tests successfully complete. (http://cvs.apache.org/dist/geronimo/unstable/1.0-M4) Here is my +1. -David James --- http://radio.weblogs.com/0112098/
[jira] Updated: (GERONIMO-623) ejb timer sometimes doesn't get cancelled when ejb is undeployed.
[ http://issues.apache.org/jira/browse/GERONIMO-623?page=all ] Aaron Mulder updated GERONIMO-623: -- Fix Version: 1.0 Description: In some unknown circumstances an ejb timer can not get cancelled and continues firing even after the ejb has been undeployed. This results in a stack trace like this: 23:18:26,695 INFO [TransactionalExecutorTask] Exception occured while running user task java.lang.RuntimeException: Dead proxy for ejb geronimo.server:EJBModule=modulename.jar,J2EEApplication=appName,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=ejbName at org.openejb.timer.BasicTimerServiceImpl.getTimerById(BasicTimerServiceImpl.java:204) at org.openejb.timer.BasicTimerServiceImpl$EJBInvokeTask.run(BasicTimerServiceImpl.java:256) at org.apache.geronimo.timer.TransactionalExecutorTask.run(TransactionalExecutorTask.java:57) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:552) I'm going to put in some temporary hacks to BasicTimerServiceImpl so this message only gets printed once even though the timer keeps firing. was: In some unknown circumstances an ejb timer can not get cancelled and continues firing even after the ejb has been undeployed. This results in a stack trace like this: 23:18:26,695 INFO [TransactionalExecutorTask] Exception occured while running user task java.lang.RuntimeException: Dead proxy for ejb geronimo.server:EJBModule=modulename.jar,J2EEApplication=appName,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=ejbName at org.openejb.timer.BasicTimerServiceImpl.getTimerById(BasicTimerServiceImpl.java:204) at org.openejb.timer.BasicTimerServiceImpl$EJBInvokeTask.run(BasicTimerServiceImpl.java:256) at org.apache.geronimo.timer.TransactionalExecutorTask.run(TransactionalExecutorTask.java:57) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:552) I'm going to put in some temporary hacks to BasicTimerServiceImpl so this message only gets printed once even though the timer keeps firing. Environment: > ejb timer sometimes doesn't get cancelled when ejb is undeployed. > - > > Key: GERONIMO-623 > URL: http://issues.apache.org/jira/browse/GERONIMO-623 > Project: Geronimo > Type: Bug > Components: OpenEJB > Versions: 1.0-M3 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.0 > > In some unknown circumstances an ejb timer can not get cancelled and > continues firing even after the ejb has been undeployed. This results in a > stack trace like this: > 23:18:26,695 INFO [TransactionalExecutorTask] Exception occured while > running user task > java.lang.RuntimeException: Dead proxy for ejb > geronimo.server:EJBModule=modulename.jar,J2EEApplication=appName,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=ejbName > at > org.openejb.timer.BasicTimerServiceImpl.getTimerById(BasicTimerServiceImpl.java:204) > at > org.openejb.timer.BasicTimerServiceImpl$EJBInvokeTask.run(BasicTimerServiceImpl.java:256) > at > org.apache.geronimo.timer.TransactionalExecutorTask.run(TransactionalExecutorTask.java:57) > at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:552) > I'm going to put in some temporary hacks to BasicTimerServiceImpl so this > message only gets printed once even though the timer keeps firing. -- 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-849) Be able to add configuration dependencies
[ http://issues.apache.org/jira/browse/GERONIMO-849?page=all ]
Aaron Mulder resolved GERONIMO-849:
---
Resolution: Invalid
> Be able to add configuration dependencies
> -
>
> Key: GERONIMO-849
> URL: http://issues.apache.org/jira/browse/GERONIMO-849
> Project: Geronimo
> Type: Improvement
> Components: kernel
> Versions: 1.0-M4
> Reporter: Aaron Mulder
> Fix For: 1.0
>
> It would be nice if the code of a GBean could register new dependencies for
> iteself. This could be used for:
> - Tomcat, so you could give it a list of valves and it could make itself
> depend on them
> - A security realm, so you could give it a list of login modules and it
> could make itself depend on them
> - J2EE modules, so when you declare a resource-ref or EJB-ref to a
> resource/EJB in a separate app or module then it could make itself depend on
> that app or module
> Note all of these are cases where the current GBean knows precisely which
> target GBeans it depends upon -- this does not deal with queries for which an
> unknown number of GBeans might match.
> The first two cases are currently handled by a, erm, unfortunate workaround
> whereby the first GBean depends on the second that depends on a third so each
> "target" GBean needs a "next" reference that it doesn't actually need but
> arranges the dependencies. It would be nice to not have to do that.
> The third case can't be done right now AFAIK.
> I'm imagining some kind of kernel call like addDependency(me,
> thingIDependUpon) -- where the method won't return until a dependency has
> been registered for "my configuration" on "my target's configuration" and
> that configuration has been loaded and the target GBean has been loaded. The
> main problem seems to be figuring out what configuration the target GBean is
> in. Seems like this could be determined by parsing the ObjectName of the
> target.
> Perhaps instead of working like standard dependencies, this could be arranged
> to work via a helper class where the master GBean just says "helper.load(new
> String[]{a,b,c})" when the master is loaded, and "helper.start(new
> String[]{a,b,c})" when the master is started.
--
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-512) non-reference gbean dependencies
[ http://issues.apache.org/jira/browse/GERONIMO-512?page=all ] Aaron Mulder updated GERONIMO-512: -- Fix Version: 1.0 Description: Currently there is no way to make gbeans start in a particular order unless they have a reference to each other. This is unsatisfactory as for instance one might open a server socket the other wants to connect to. Also, jndi refs are not reflected in the gbean dependency graph. So far the best idea seems to be to add a list of dependencies (object names or their successors) to GBeanData, and add these to the dependency manager on startup (and presumably remove them on shutdown). was: Currently there is no way to make gbeans start in a particular order unless they have a reference to each other. This is unsatisfactory as for instance one might open a server socket the other wants to connect to. Also, jndi refs are not reflected in the gbean dependency graph. So far the best idea seems to be to add a list of dependencies (object names or their successors) to GBeanData, and add these to the dependency manager on startup (and presumably remove them on shutdown). Environment: > non-reference gbean dependencies > > > Key: GERONIMO-512 > URL: http://issues.apache.org/jira/browse/GERONIMO-512 > Project: Geronimo > Type: New Feature > Components: kernel > Versions: 1.0-M3 > Reporter: David Jencks > Fix For: 1.0 > > Currently there is no way to make gbeans start in a particular order unless > they have a reference to each other. This is unsatisfactory as for instance > one might open a server socket the other wants to connect to. Also, jndi > refs are not reflected in the gbean dependency graph. > So far the best idea seems to be to add a list of dependencies (object names > or their successors) to GBeanData, and add these to the dependency manager on > startup (and presumably remove them on shutdown). -- 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-462) JMX Connector ignores port number
[ http://issues.apache.org/jira/browse/GERONIMO-462?page=all ] Aaron Mulder closed GERONIMO-462: - Fix Version: 1.0-M5 Resolution: Duplicate Fixed by GERONIMO-848 > JMX Connector ignores port number > - > > Key: GERONIMO-462 > URL: http://issues.apache.org/jira/browse/GERONIMO-462 > Project: Geronimo > Type: Bug > Components: general > Versions: 1.0-M2 > Reporter: Aaron Mulder > Priority: Critical > Fix For: 1.0-M5 > > The JMX connector processes a port number in a URI like this: > jmx:rmi://localhost:1234561234/jndi/rmi:/JMXConnector > For example, if you put in a port number that's too large, you get: > Bad port number: "123456123434526": java.lang.NumberFormatException: For > input string: "123456123434526" > However, the connector will connect no matter what port number you specify in > the URI. I suspect that means that if the server side is listening on a > different port, it will *not* connect, no matter what port you use. But as I > don't know how to change the port that the server listens on, it's difficult > to test. :) Perhaps it's going for the rmiregistry on 1099? > In any case, to test this, try to run: > java -jar bin/deployer.jar --uri > deployer:geronimo:jmx:rmi://localhost:1234561234/jndi/rmi:/JMXConnector > list-targets > and just fool with the port numbers in the URI -- 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-512) non-reference gbean dependencies
[ http://issues.apache.org/jira/browse/GERONIMO-512?page=comments#action_12317563 ] Aaron Mulder commented on GERONIMO-512: --- My understanding of this issue is: Allow a single GBean reference to be created such that it does not originate from a specific GBean constructor argument or property, but is just an anonymous reference from one GBean to another GBean. > non-reference gbean dependencies > > > Key: GERONIMO-512 > URL: http://issues.apache.org/jira/browse/GERONIMO-512 > Project: Geronimo > Type: New Feature > Components: kernel > Versions: 1.0-M3 > Reporter: David Jencks > > Currently there is no way to make gbeans start in a particular order unless > they have a reference to each other. This is unsatisfactory as for instance > one might open a server socket the other wants to connect to. Also, jndi > refs are not reflected in the gbean dependency graph. > So far the best idea seems to be to add a list of dependencies (object names > or their successors) to GBeanData, and add these to the dependency manager on > startup (and presumably remove them on shutdown). -- 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: [VOTE] M4 release
+1 Aaron On Wed, 3 Aug 2005, David Blevins wrote: > The tests are still running on David J's machine and should finish > sometime tomorrow. Since voting takes a day or so anyway, let's get > started and do them in parallel. > > Vote: >Let's Release these binaries when the tests successfully complete. >(http://cvs.apache.org/dist/geronimo/unstable/1.0-M4) > > Here is my +1. > > -David >
Re: [VOTE] M4 release
David Blevins wrote, On 8/3/2005 6:54 PM: The tests are still running on David J's machine and should finish sometime tomorrow. Since voting takes a day or so anyway, let's get started and do them in parallel. Vote: Let's Release these binaries when the tests successfully complete. (http://cvs.apache.org/dist/geronimo/unstable/1.0-M4) +1 Regards, Alan
Re: [VOTE] M4 release
On Aug 3, 2005, at 6:54 PM, David Blevins wrote: The tests are still running on David J's machine and should finish sometime tomorrow. Since voting takes a day or so anyway, let's get started and do them in parallel. Vote: Let's Release these binaries when the tests successfully complete. (http://cvs.apache.org/dist/geronimo/unstable/1.0-M4) +1 /Hiram Here is my +1. -David
Re: [VOTE] M4 release
+1 from me. -- dims On 8/3/05, David Blevins <[EMAIL PROTECTED]> wrote: > The tests are still running on David J's machine and should finish > sometime tomorrow. Since voting takes a day or so anyway, let's get > started and do them in parallel. > > Vote: >Let's Release these binaries when the tests successfully complete. >(http://cvs.apache.org/dist/geronimo/unstable/1.0-M4) > > Here is my +1. > > -David > -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
[VOTE] M4 release
The tests are still running on David J's machine and should finish sometime tomorrow. Since voting takes a day or so anyway, let's get started and do them in parallel. Vote: Let's Release these binaries when the tests successfully complete. (http://cvs.apache.org/dist/geronimo/unstable/1.0-M4) Here is my +1. -David
[jira] Resolved: (GERONIMO-836) jmx port should be explicit in the plans and set from the installer
[ http://issues.apache.org/jira/browse/GERONIMO-836?page=all ] Aaron Mulder resolved GERONIMO-836: --- Resolution: Invalid The deployer connects via the RMI Naming port (1099). If there's another port involved, please let me know. > jmx port should be explicit in the plans and set from the installer > --- > > Key: GERONIMO-836 > URL: http://issues.apache.org/jira/browse/GERONIMO-836 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0-M5 > Reporter: David Jencks > Assignee: Aaron Mulder > Fix For: 1.0-M5 > > I think the only port that is not configured by the installer is the jmx port > used by the deployer (and similar tools). If this port was configurable by > the installer you could use the installer to set up multiple geronimos on one > machine. Dain says the jmx port can actually be included in the url so this > should be an easy change. -- 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-848) Deployer ignores Geronimo URL host/port
[ http://issues.apache.org/jira/browse/GERONIMO-848?page=all ] Aaron Mulder resolved GERONIMO-848: --- Resolution: Invalid Correct URL is deployer:geronimo:jmx:rmi:///jndi/rmi://host:port/JMXConnector > Deployer ignores Geronimo URL host/port > --- > > Key: GERONIMO-848 > URL: http://issues.apache.org/jira/browse/GERONIMO-848 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4 > Reporter: Aaron Mulder > Fix For: 1.0-M5 > > When the deployer connects to a server, it uses a URL of the form: > deployer:geronimo:jmx:rmi://host:port/jndi/rmi:/JMXConnector > Under the covers, this strips off the beginning and uses a connection of the > form: > jmx:rmi://host:port/jndi/rmi:/JMXConnector > However, no matter what you use as the host and port, it connects to the > standard port on localhost. It should actually attempt to connect to the > host and port specified and give an error if they are not valid. -- 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: Portal framework in Geronimo w/ or w/o the Web Console
OK, we can assume that for now. That certainly the quickest approach to get the console included (and I really do want the console included as quickly as possible). I just think the question will come up from users sooner rather than later. The only reason that I was even brining it up again was because I'm already being asked by folks if they can use the portlet container included in Geronimo for their own purposes once the Web Console brings it in. >From a pure architectural perspective it makes more sense to pull in the dependencies of a component as you want them before you pull in the higher level components. We can rework the architecture to pull it out later but if we could consider it now it would make the design much, much cleaner. -Joe Aaron Mulder wrote: I think the short-term plan is to use the Pluto "integration" that we have in the web console. It's horrible as portal servers go because it's totally static (from layout to portlet selection), but since it's totally statically customized for the web console, it works. If someone wanted to use it for their application, they can, but it would be extremely painful. I guess the long-term plan should be some reasonable Pluto integration in the form of a proper "portal server" where you can dynamically select portlets and alter layout and so on. But that's a pretty big effort. Aaron On Wed, 3 Aug 2005, Joe Bohn wrote: A few weeks back we had a discussion about how we should deal with the Portal framework (and the portlet container) that is included in the web console contribution. At the time, here were some of the comments: Aaron Mulder wrote: So I took a look at the web console. There are two main changes I'd like to make before we "go live" with it. 1) Combine the "framework" and "standard" web apps into one. Currently the "framework" holds the Pluto engine and page framing and so on, while the "standard" holds all the actual portlets. Some of the issues are that I don't really fancy taking two contexts for this, there's no security on the portlet (standard) context, it can be accessed directly with a variety of unpleasant side effects, it makes the whole thing require multiple build modules and an EAR, etc. I responded with: On Tue, 19 Jul 2005, Joe Bohn wrote: Regarding #1 below ... I think there are probably some good reasons to keep this split into 2 or maybe even more web applications. As you mention, the "framework" appears to hold the necessary components for the console framework itself. Since this may be replaced at some point in the future by an open source Portal Server (not just the container) it probably makes sense to keep this split apart. The "standard" application includes the portlets necessary for console administration. One of the benefits of the portlet model (and I suspect the reason it was chosen for the console) is that it is extensible. Multiple applications can be installed as necessary. This seems like it would be a desirable feature for a modular server like Geronimo. If there is no need for the EJB container it need not be included in the resultant image and therefore the portlets that administer the EJB container would not be deployed into the solution. I wasn't one of the authors of this console structure but I can see how it makes sense in the big picture even it is seems like overkill for now. to which Aaron added: Aaron Mulder wrote: Maybe the real answer to #1 is to actually integrate Pluto into Geronimo -- you know, so if you deploy a web app with portlet deployment descriptors then a PortletDeployer GBean "magically" wires it up and makes it available to Pluto, and then some other admin web site lets you arrange your portlets on the page... Gosh, this is sounding like a bigger effort already. I guess it would be a portal server module for Geronimo, as opposed to the current "static" Pluto configuration. Now that I've caught you all up on the discussion I was wondering if we can figure out what we are doing with the portlet container and portal framework for the console contribution. Since the container will most like be included as an optional element with Geronimo (even without the console) I think that raises the question of what should we do about a Portal framework around that container. What does this mean to the user? If the portlet container is integrated directly into Geronimo it will be visible to the user (actually, the user will know it's there when he sees the console anyway). Can a user deploy portlets into this container? If so, how are the portlets accessed (one at a time via URL?) and/or should we provide some type of generic Portal framework capabilities that include aggregation, navigation, persistence, etc? I know these are muddy waters, but I think the questions will come from the users as soon as we include
Re: How I can get involved in the admin web console?
I try to build the project with "maven", and obtain this: +| Executing default Geronimo :: Servlet Specification| Memory: 11M/12M+DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml BUILD FAILEDFile.. C:\Documents and Settings\alejandro_gavia\.maven\cache\maven-multiproject-plugin-1.4.1\plugin.jellyElement... maven:reactorLine.. 218Column -1Unable to obtain goal [default] -- C:\Documents and Settings\alejandro_gavia\geronimo\trunk\etc\maven.xml:43:-1: No goal [java:jar-resources]Total time : 7 secondsFinished at : Wednesday, August 3, 2005 5:54:44 PM CST -- daniel rangel Aaron Mulder <[EMAIL PROTECTED]> escribió: Well, you have two problems:1) M4 is in the process of being released right now, and M3 is really old and should not be used.2) That doesn't really matter because you can't use a milestone to work on the web console anyway. You need to check out the source code from Subversion (see http://geronimo.apache.org/svn.html) and then build it from there. (First, the console source is not included in M3 or M4 because it's more recent than that, and second, you'll need to be able to run "svn diff" in order to contribute your changes.)AaronOn Tue, 2 Aug 2005, Daniel Alejandro Rangel Gavia wrote:> I have this: geronimo-1.0-M3-src, is this the last one? > > there are the folder: geronimo-1.0-M3/modules/console-web... > I need build this with maven, or what? > > daniel rangel> & gt; > Aaron Mulder <[EMAIL PROTECTED]>escribió:> Start by checking out the code for Geronimo, building the server, > building the web console, and getting the console running in the server. > If you need help with this, let us know.> > Next, think about which portlets you want to work on, and speak up > on the list. Some of them are implemented but need updating; many of them > are not implemented yet. There's plenty of work to go around. :)> > Aaron> > On Tue, 2 Aug 2005, Daniel Alejandro Rangel Gavia wrote:> > Hello, I'm interested in collaborating with the web console, how I can> > help?> > > -> Do You Yahoo!? La mejor conexión a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx __Correo Yahoo!Espacio par a todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.com.mx/
Re: Portal framework in Geronimo w/ or w/o the Web Console
I'm agree with Aaron, first step is to use the Pluto "integration", and in a long-term a big plan to "portal server" implementation, because this option has more implicit work. daniel rangelAaron Mulder <[EMAIL PROTECTED]> escribió: I think the short-term plan is to use the Pluto "integration" thatwe have in the web console. It's horrible as portal servers go becauseit's totally static (from layout to portlet selection), but since it'stotally statically customized for the web console, it works. If someonewanted to use it for their application, they can, but it would beextremely painful.I guess the long-term plan should be some reasonable Pluto integration in the form of a proper "portal server" where you can dynamically select portlets and alter layout and so on. But that's a pretty big effort.AaronOn Wed, 3 Aug 2005, Joe Bohn wrote:> A few weeks back we had a discussion about how we should deal with the > Portal framework (and the portlet container) that is included in the web > console contribution.> > At the time, here were some of the comments:> > Aaron Mulder wrote:> > >So I took a look at the web console. There are two main changes I'd like> >to make before we "go live" with it.> >> >1) Combine the "framework" and "standard" web apps into one. Currently> > the "framework" holds the Pluto engine and page framing and so on,> > while the "standard" holds all the actual portlets. Some of the issues> > are that I don't really fancy taking two contexts for this, there's no> > security on the portlet (standard) context, it can be accessed directly> > with a variety of unpleasant side effects, it makes the whole thing> > require multiple build modules and an EAR, etc.> >> > > I responded with:> > On Tue, 19 Jul 2005, Joe Bohn wrote:> > >Regarding #1 below ... I think there are probably some good reasons to > >keep this split into 2 or maybe even more web applications.> >As you mention, the "framework" appears to hold the necessary components > >for the console framework itself. Since this may be replaced> >at some point in the future by an open source Portal Server (not just > >the container) it probably makes sense to keep this split apart.> >The "standard" application includes the portlets necessary for console > >administration. One of the benefits of the portlet model (and I> >suspect the reason it was chosen for the console) is that it is > >extensible. Multiple applications can be installed as necessary. This > >seems> >like it would be a desirable feature for a modular server like > >Geronimo. If there is no need for the EJB container it need not be> >included in the resultant image and therefore the portlets that > >administer the EJB container would not be deployed into the solution.> >I wasn't one of the authors of this console structure but I can see how > >it makes sense in the big picture even it is seems like overkill for now.> >> > > to which Aaron added:> Aaron Mulder wrote:> > Maybe the real answer to #1 is to actually integrate Pluto into > Geronimo -- you know, so if you deploy a web app with portlet deployment > descriptors then a PortletDeployer GBean "magically" wires it up and makes > it available to Pluto, and then some other admin web site lets you arrange > your portlets on the page... Gosh, this is sounding like a bigger effort > already. I guess it would be a portal server module for Geronimo, as > opposed to the current "static" Pluto configuration.> > Now that I've caught you all up on the discussion I was wondering > if we can figure out w hat we are doing with the portlet container and > portal framework for the console contribution. Since the container will > most like be included as an optional element with Geronimo (even without > the console) I think that raises the question of what should we do about > a Portal framework around that container. What does this mean to the > user? If the portlet container is integrated directly into Geronimo it > will be visible to the user (actually, the user will know it's there > when he sees the console anyway). Can a user deploy portlets into this > container? If so, how are the portlets accessed (one at a time via > URL?) and/or should we provide some type of generic Portal framework > capabilities that include aggregation, navigation, persistence, etc? > > I know these are muddy waters, but I think the questions will come from > the users as soon as we include the portlet containe r for the web console. > > We're not trying to compete/clash with JetSpeed but at the same time it > appears that what they are creating is a bit too heavy weight for the > web console needs alone. However, it might be just fine if the user > wants to directly exploit the portal capabilities. With this in mind > should we be looking to update the Web Console so that it can run either > with the static Portal included as part of the console contribution or > full JetSpeed depending upon the GBean configuration (assuming we > include Je
[jira] Closed: (GERONIMO-850) Be able to add configuration dependencies
[ http://issues.apache.org/jira/browse/GERONIMO-850?page=all ]
Aaron Mulder closed GERONIMO-850:
-
Fix Version: (was: 1.0)
Resolution: Duplicate
Didn't really need to be submitted twice
> Be able to add configuration dependencies
> -
>
> Key: GERONIMO-850
> URL: http://issues.apache.org/jira/browse/GERONIMO-850
> Project: Geronimo
> Type: Improvement
> Components: kernel
> Versions: 1.0-M4
> Reporter: Aaron Mulder
>
> It would be nice if the code of a GBean could register new dependencies for
> iteself. This could be used for:
> - Tomcat, so you could give it a list of valves and it could make itself
> depend on them
> - A security realm, so you could give it a list of login modules and it
> could make itself depend on them
> - J2EE modules, so when you declare a resource-ref or EJB-ref to a
> resource/EJB in a separate app or module then it could make itself depend on
> that app or module
> Note all of these are cases where the current GBean knows precisely which
> target GBeans it depends upon -- this does not deal with queries for which an
> unknown number of GBeans might match.
> The first two cases are currently handled by a, erm, unfortunate workaround
> whereby the first GBean depends on the second that depends on a third so each
> "target" GBean needs a "next" reference that it doesn't actually need but
> arranges the dependencies. It would be nice to not have to do that.
> The third case can't be done right now AFAIK.
> I'm imagining some kind of kernel call like addDependency(me,
> thingIDependUpon) -- where the method won't return until a dependency has
> been registered for "my configuration" on "my target's configuration" and
> that configuration has been loaded and the target GBean has been loaded. The
> main problem seems to be figuring out what configuration the target GBean is
> in. Seems like this could be determined by parsing the ObjectName of the
> target.
> Perhaps instead of working like standard dependencies, this could be arranged
> to work via a helper class where the master GBean just says "helper.load(new
> String[]{a,b,c})" when the master is loaded, and "helper.start(new
> String[]{a,b,c})" when the master is started.
--
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: Portal framework in Geronimo w/ or w/o the Web Console
I think the short-term plan is to use the Pluto "integration" that we have in the web console. It's horrible as portal servers go because it's totally static (from layout to portlet selection), but since it's totally statically customized for the web console, it works. If someone wanted to use it for their application, they can, but it would be extremely painful. I guess the long-term plan should be some reasonable Pluto integration in the form of a proper "portal server" where you can dynamically select portlets and alter layout and so on. But that's a pretty big effort. Aaron On Wed, 3 Aug 2005, Joe Bohn wrote: > A few weeks back we had a discussion about how we should deal with the > Portal framework (and the portlet container) that is included in the web > console contribution. > > At the time, here were some of the comments: > > Aaron Mulder wrote: > > >So I took a look at the web console. There are two main changes I'd like > >to make before we "go live" with it. > > > >1) Combine the "framework" and "standard" web apps into one. Currently > > the "framework" holds the Pluto engine and page framing and so on, > > while the "standard" holds all the actual portlets. Some of the issues > > are that I don't really fancy taking two contexts for this, there's no > > security on the portlet (standard) context, it can be accessed directly > > with a variety of unpleasant side effects, it makes the whole thing > > require multiple build modules and an EAR, etc. > > > > > I responded with: > > On Tue, 19 Jul 2005, Joe Bohn wrote: > > >Regarding #1 below ... I think there are probably some good reasons to > >keep this split into 2 or maybe even more web applications. > >As you mention, the "framework" appears to hold the necessary components > >for the console framework itself. Since this may be replaced > >at some point in the future by an open source Portal Server (not just > >the container) it probably makes sense to keep this split apart. > >The "standard" application includes the portlets necessary for console > >administration. One of the benefits of the portlet model (and I > >suspect the reason it was chosen for the console) is that it is > >extensible. Multiple applications can be installed as necessary. This > >seems > >like it would be a desirable feature for a modular server like > >Geronimo. If there is no need for the EJB container it need not be > >included in the resultant image and therefore the portlets that > >administer the EJB container would not be deployed into the solution. > >I wasn't one of the authors of this console structure but I can see how > >it makes sense in the big picture even it is seems like overkill for now. > > > > > to which Aaron added: > Aaron Mulder wrote: > > Maybe the real answer to #1 is to actually integrate Pluto into > Geronimo -- you know, so if you deploy a web app with portlet deployment > descriptors then a PortletDeployer GBean "magically" wires it up and makes > it available to Pluto, and then some other admin web site lets you arrange > your portlets on the page... Gosh, this is sounding like a bigger effort > already. I guess it would be a portal server module for Geronimo, as > opposed to the current "static" Pluto configuration. > > Now that I've caught you all up on the discussion I was wondering > if we can figure out what we are doing with the portlet container and > portal framework for the console contribution. Since the container will > most like be included as an optional element with Geronimo (even without > the console) I think that raises the question of what should we do about > a Portal framework around that container. What does this mean to the > user? If the portlet container is integrated directly into Geronimo it > will be visible to the user (actually, the user will know it's there > when he sees the console anyway). Can a user deploy portlets into this > container? If so, how are the portlets accessed (one at a time via > URL?) and/or should we provide some type of generic Portal framework > capabilities that include aggregation, navigation, persistence, etc? > > I know these are muddy waters, but I think the questions will come from > the users as soon as we include the portlet container for the web console. > > We're not trying to compete/clash with JetSpeed but at the same time it > appears that what they are creating is a bit too heavy weight for the > web console needs alone. However, it might be just fine if the user > wants to directly exploit the portal capabilities. With this in mind > should we be looking to update the Web Console so that it can run either > with the static Portal included as part of the console contribution or > full JetSpeed depending upon the GBean configuration (assuming we > include JetSpeed as an option)? Maybe I'm moving too fast here I > guess the first question is are we
[jira] Created: (GERONIMO-850) Be able to add configuration dependencies
Be able to add configuration dependencies
-
Key: GERONIMO-850
URL: http://issues.apache.org/jira/browse/GERONIMO-850
Project: Geronimo
Type: Improvement
Components: kernel
Versions: 1.0-M4
Reporter: Aaron Mulder
Fix For: 1.0
It would be nice if the code of a GBean could register new dependencies for
iteself. This could be used for:
- Tomcat, so you could give it a list of valves and it could make itself
depend on them
- A security realm, so you could give it a list of login modules and it could
make itself depend on them
- J2EE modules, so when you declare a resource-ref or EJB-ref to a
resource/EJB in a separate app or module then it could make itself depend on
that app or module
Note all of these are cases where the current GBean knows precisely which
target GBeans it depends upon -- this does not deal with queries for which an
unknown number of GBeans might match.
The first two cases are currently handled by a, erm, unfortunate workaround
whereby the first GBean depends on the second that depends on a third so each
"target" GBean needs a "next" reference that it doesn't actually need but
arranges the dependencies. It would be nice to not have to do that.
The third case can't be done right now AFAIK.
I'm imagining some kind of kernel call like addDependency(me, thingIDependUpon)
-- where the method won't return until a dependency has been registered for "my
configuration" on "my target's configuration" and that configuration has been
loaded and the target GBean has been loaded. The main problem seems to be
figuring out what configuration the target GBean is in. Seems like this could
be determined by parsing the ObjectName of the target.
Perhaps instead of working like standard dependencies, this could be arranged
to work via a helper class where the master GBean just says "helper.load(new
String[]{a,b,c})" when the master is loaded, and "helper.start(new
String[]{a,b,c})" when the master is started.
--
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: milestone branching and taging (was Re: svn commit: r226882 - in /geronimo: branches/v1_0_M4-QA/ tags/v1_0_M4/)
Geir Magnusson Jr. wrote, On 8/3/2005 1:57 PM: On Aug 3, 2005, at 4:14 PM, David Blevins wrote: On Wed, Aug 03, 2005 at 09:04:22AM -0400, Geir Magnusson Jr. wrote: There is never going to be another release from the M4-QA branch. It's a dead branch and shouldn't be updated after we vote to release the M4 binaries. Why wouldn't we set a process that's standard and stick with it? Further, it's entirely reasonable to keep our option open for a subsequent release of M4. Remember M3? And what if we find a major problem? We don't want to ram forward a M5 - we'd want to fix M4 and get that out there, retracting the problematic release, say a M4r1. This makes sense to me. Regards, Alan
[jira] Created: (GERONIMO-849) Be able to add configuration dependencies
Be able to add configuration dependencies
-
Key: GERONIMO-849
URL: http://issues.apache.org/jira/browse/GERONIMO-849
Project: Geronimo
Type: Improvement
Components: kernel
Versions: 1.0-M4
Reporter: Aaron Mulder
Fix For: 1.0
It would be nice if the code of a GBean could register new dependencies for
iteself. This could be used for:
- Tomcat, so you could give it a list of valves and it could make itself
depend on them
- A security realm, so you could give it a list of login modules and it could
make itself depend on them
- J2EE modules, so when you declare a resource-ref or EJB-ref to a
resource/EJB in a separate app or module then it could make itself depend on
that app or module
Note all of these are cases where the current GBean knows precisely which
target GBeans it depends upon -- this does not deal with queries for which an
unknown number of GBeans might match.
The first two cases are currently handled by a, erm, unfortunate workaround
whereby the first GBean depends on the second that depends on a third so each
"target" GBean needs a "next" reference that it doesn't actually need but
arranges the dependencies. It would be nice to not have to do that.
The third case can't be done right now AFAIK.
I'm imagining some kind of kernel call like addDependency(me, thingIDependUpon)
-- where the method won't return until a dependency has been registered for "my
configuration" on "my target's configuration" and that configuration has been
loaded and the target GBean has been loaded. The main problem seems to be
figuring out what configuration the target GBean is in. Seems like this could
be determined by parsing the ObjectName of the target.
Perhaps instead of working like standard dependencies, this could be arranged
to work via a helper class where the master GBean just says "helper.load(new
String[]{a,b,c})" when the master is loaded, and "helper.start(new
String[]{a,b,c})" when the master is started.
--
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
Portal framework in Geronimo w/ or w/o the Web Console
A few weeks back we had a discussion about how we should deal with the Portal framework (and the portlet container) that is included in the web console contribution. At the time, here were some of the comments: Aaron Mulder wrote: So I took a look at the web console. There are two main changes I'd like to make before we "go live" with it. 1) Combine the "framework" and "standard" web apps into one. Currently the "framework" holds the Pluto engine and page framing and so on, while the "standard" holds all the actual portlets. Some of the issues are that I don't really fancy taking two contexts for this, there's no security on the portlet (standard) context, it can be accessed directly with a variety of unpleasant side effects, it makes the whole thing require multiple build modules and an EAR, etc. I responded with: On Tue, 19 Jul 2005, Joe Bohn wrote: Regarding #1 below ... I think there are probably some good reasons to keep this split into 2 or maybe even more web applications. As you mention, the "framework" appears to hold the necessary components for the console framework itself. Since this may be replaced at some point in the future by an open source Portal Server (not just the container) it probably makes sense to keep this split apart. The "standard" application includes the portlets necessary for console administration. One of the benefits of the portlet model (and I suspect the reason it was chosen for the console) is that it is extensible. Multiple applications can be installed as necessary. This seems like it would be a desirable feature for a modular server like Geronimo. If there is no need for the EJB container it need not be included in the resultant image and therefore the portlets that administer the EJB container would not be deployed into the solution. I wasn't one of the authors of this console structure but I can see how it makes sense in the big picture even it is seems like overkill for now. to which Aaron added: Aaron Mulder wrote: Maybe the real answer to #1 is to actually integrate Pluto into Geronimo -- you know, so if you deploy a web app with portlet deployment descriptors then a PortletDeployer GBean "magically" wires it up and makes it available to Pluto, and then some other admin web site lets you arrange your portlets on the page... Gosh, this is sounding like a bigger effort already. I guess it would be a portal server module for Geronimo, as opposed to the current "static" Pluto configuration. Now that I've caught you all up on the discussion I was wondering if we can figure out what we are doing with the portlet container and portal framework for the console contribution. Since the container will most like be included as an optional element with Geronimo (even without the console) I think that raises the question of what should we do about a Portal framework around that container. What does this mean to the user? If the portlet container is integrated directly into Geronimo it will be visible to the user (actually, the user will know it's there when he sees the console anyway). Can a user deploy portlets into this container? If so, how are the portlets accessed (one at a time via URL?) and/or should we provide some type of generic Portal framework capabilities that include aggregation, navigation, persistence, etc? I know these are muddy waters, but I think the questions will come from the users as soon as we include the portlet container for the web console. We're not trying to compete/clash with JetSpeed but at the same time it appears that what they are creating is a bit too heavy weight for the web console needs alone. However, it might be just fine if the user wants to directly exploit the portal capabilities. With this in mind should we be looking to update the Web Console so that it can run either with the static Portal included as part of the console contribution or full JetSpeed depending upon the GBean configuration (assuming we include JetSpeed as an option)? Maybe I'm moving too fast here I guess the first question is are we planning to integrate Pluto directly into Geronimo or are we treating it as part of the Web Console contribution for now? If it's just part of the Web Console I guess we can declare that it's off-limits to the user (of course, with open source I guess they can really do anything they want to do :-) ). -Joe -- Joe Bohn [EMAIL PROTECTED] "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: possible bug/enhancement - Setting the log level
Not hearing any objections I went ahead and created a patch with what I described below. See JIRA http://issues.apache.org/jira/browse/GERONIMO-846 for the patch itself. Joe Bohn wrote: I'd like to go ahead and create a JIRA issue for this problem and then submit the fix to at least get this working as I believe it was originally intended to work that being the last update wins from either the Portlet or the file itself. That way things at least make some sense to an end user until we decide upon the ultimate end user experience that we would like to create for this and other config. settings. Details of the problem: Each update action from the LogManagerPortlet invokes the appropriate 3 methods on the SystemLog without checking for actual changes in the submitted values. For the refresh interval this isn't a problem because Log4JService checks itself to ensure the period has changed before updating the value. For the logging level this also isn't a problem because there is no ill effect to updating the level with the exact same level. However, when setting the ConfigFileName the Log4JService doesn't check the value and assumes that there really is a new file and therefore sets the lastChanged value to -1 to ensure that the file values will take effect on the next timer refresh. The result is that any change (including only a change to the logging level) from the console also guarantees that the file settings will be refreshed. Before I create the issue and submit a patch I'd like to see if anybody has any strong opinions on how this should be fixed. I see the following possibilities: 1) Change the LogManagerPortlet to ensure that the name or level has changed before updating the SystemLog (Log4JService) ... I'd also ensure that we check for changes in the refresh period as well just for good measure. 2) Change the Log4JService to always check for an actual change to the level and/or the configPathName before taking any real action (just as it does for refresh interval). 3) Both of the above. Of these I prefer #3 since it ensures that the same mistake won't happen again from something like a command line interface when interacting with the logging service and also cleans up the console code. Any comments before I create the JIRA and submit a patch? Dain Sundstrom wrote: On Jul 29, 2005, at 8:21 PM, Aaron Mulder wrote: On Fri, 29 Jul 2005, Dain Sundstrom wrote: Before Aaron got his hands on it you used to be able to modify the log4j configuration file via the management interface, but it looks like he remove that "feature". Aaron is a lot more clever than I am, so hopeful he can come up with something better than I did :) Now now, no crazy accusations. I don't believe I've removed anything, even the despised applet that lets you drop tables in the system database. :) :) I assumed the config file poller would only apply the config file if it had been updated. So that you could change things in the console, and if you then altered the config file it would overwrite your console change, but if you just wait for the poller timeout it wouldn't revert back to the config file version. Is that not correct? I'm OK with the "last change wins" style. I wouldn't be too happy if the file poller automatically reverted anything you did in the console. I actually was talking about the log service not the portlet. The service used to have a setConfiguration(String configuration) method that would overwrite the file. I know you love dangerous stuff like that :) The code is here: http://svn.apache.org/viewcvs.cgi/geronimo/trunk/modules/system/src/ java/org/apache/geronimo/system/logging/log4j/Log4jService.java? rev=57150&view=markup I'm really not sure what the best thing to do here. Another thing to think about is do we want these changes to be persistent. But the truth is, I don't think changing the overall system log level is all that useful -- I'd much rather see a feature that let you change the threshold for an individual appender (for example, to turn up or down the console output). I'm not sure about whether that should rewrite your config file or defaults for next time. I guess maybe it should update the default starting console log level, which as far as I know is coming from a static variable right now. We'll have to think that through -- we'd want to automatically disable the progress bar if the level was below WARN, for example. I agree that we really need more specific control then "global". I just have no idea what to do here; good thing it isn't my problem anymore :) -dain -- 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-848) Deployer ignores Geronimo URL host/port
[
http://issues.apache.org/jira/browse/GERONIMO-848?page=comments#action_12317541
]
Aaron Mulder commented on GERONIMO-848:
---
Here's the code (from DeploymentFactoryImpl):
if (uri.startsWith("jmx")) {
Map environment = new HashMap();
String[] credentials = new String[]{username, password};
environment.put(JMXConnector.CREDENTIALS, credentials);
try {
JMXServiceURL address = new JMXServiceURL("service:" + uri);
JMXConnector jmxConnector =
JMXConnectorFactory.connect(address, environment);
So I think it's a problem with the underlying JMX code, or else we're not
constructing the URL properly (again, our URL is
jmx:rmi://host:port/jndi/rmi:/JMXConnector which becomes
service:jmx:rmi://host:port/jndi/rmi:/JMXConnector)
I don't know who's responsible for the code that handles that URL
> Deployer ignores Geronimo URL host/port
> ---
>
> Key: GERONIMO-848
> URL: http://issues.apache.org/jira/browse/GERONIMO-848
> Project: Geronimo
> Type: Bug
> Components: deployment
> Versions: 1.0-M4
> Reporter: Aaron Mulder
> Fix For: 1.0-M5
>
> When the deployer connects to a server, it uses a URL of the form:
> deployer:geronimo:jmx:rmi://host:port/jndi/rmi:/JMXConnector
> Under the covers, this strips off the beginning and uses a connection of the
> form:
> jmx:rmi://host:port/jndi/rmi:/JMXConnector
> However, no matter what you use as the host and port, it connects to the
> standard port on localhost. It should actually attempt to connect to the
> host and port specified and give an error if they are not valid.
--
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-846) Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
[ http://issues.apache.org/jira/browse/GERONIMO-846?page=all ] Joe Bohn updated GERONIMO-846: -- Component: common Also indicated that the "common" component was affected since this changes the Log4JService. > Log Level set on Console is overridden by serverlog properties setting even > if the properties setting hasn't changed. > - > > Key: GERONIMO-846 > URL: http://issues.apache.org/jira/browse/GERONIMO-846 > Project: Geronimo > Type: Bug > Components: management, common > Versions: 1.0-M4 > Environment: Windows XP > Reporter: Joe Bohn > Attachments: logSettings.diff > > Each update action from the LogManagerPortlet invokes the appropriate 3 > methods on the SystemLog without checking for actual changes in the submitted > values. For the refresh interval this isn't a problem because Log4JService > checks itself to ensure the period has changed before updating the value. > For the logging level this also isn't a problem because there is no ill > effect to updating the level with the exact same level. However, when > setting the ConfigFileName the Log4JService doesn't check the value and > assumes that there really is a new file and therefore sets the lastChanged > value to -1 to ensure that the file values will take effect on the next timer > refresh. The result is that any change (including only a change to the > logging level) from the console also guarantees that the file settings will > be refreshed. > I propose the following: > 1) Change the LogManagerPortlet to ensure that the name or level has changed > before updating the SystemLog (Log4JService) ... I'd also ensure that we > check for changes in the refresh period as well just for good measure. This > way we won't was time setting things that haven't changed. > 2) Change the Log4JService to always check for an actual change to the level > and/or the configPathName before taking any real action (just as it does for > refresh interval today). This will clean things up so that another object > invoking this service unnecessarily doesn't create a similar problem. -- 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-846) Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
[ http://issues.apache.org/jira/browse/GERONIMO-846?page=all ] Joe Bohn updated GERONIMO-846: -- Attachment: logSettings.diff I've updated both the LogManagerPortlet to only invoke methods to change items in the Logger if a change has in fact been made at the console. I've also updated the Log4jService so that it will not attempt to make a change unless the value of the new attribute has in fact been changed. I did this for the root level, root properties file, and root refresh interval. We could/should probably make similar changes for the other loggers. The last update will now win (either from the GUI or via an edit on the properties file) and any changes made from the GUI will be active until the next recycle of the server (or change in the file). > Log Level set on Console is overridden by serverlog properties setting even > if the properties setting hasn't changed. > - > > Key: GERONIMO-846 > URL: http://issues.apache.org/jira/browse/GERONIMO-846 > Project: Geronimo > Type: Bug > Components: management, common > Versions: 1.0-M4 > Environment: Windows XP > Reporter: Joe Bohn > Attachments: logSettings.diff > > Each update action from the LogManagerPortlet invokes the appropriate 3 > methods on the SystemLog without checking for actual changes in the submitted > values. For the refresh interval this isn't a problem because Log4JService > checks itself to ensure the period has changed before updating the value. > For the logging level this also isn't a problem because there is no ill > effect to updating the level with the exact same level. However, when > setting the ConfigFileName the Log4JService doesn't check the value and > assumes that there really is a new file and therefore sets the lastChanged > value to -1 to ensure that the file values will take effect on the next timer > refresh. The result is that any change (including only a change to the > logging level) from the console also guarantees that the file settings will > be refreshed. > I propose the following: > 1) Change the LogManagerPortlet to ensure that the name or level has changed > before updating the SystemLog (Log4JService) ... I'd also ensure that we > check for changes in the refresh period as well just for good measure. This > way we won't was time setting things that haven't changed. > 2) Change the Log4JService to always check for an actual change to the level > and/or the configPathName before taking any real action (just as it does for > refresh interval today). This will clean things up so that another object > invoking this service unnecessarily doesn't create a similar problem. -- 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: milestone branching and taging (was Re: svn commit: r226882 - in /geronimo: branches/v1_0_M4-QA/ tags/v1_0_M4/)
On Aug 3, 2005, at 4:14 PM, David Blevins wrote: On Wed, Aug 03, 2005 at 09:04:22AM -0400, Geir Magnusson Jr. wrote: On Aug 2, 2005, at 9:41 PM, David Blevins wrote: On Mon, Aug 01, 2005 at 07:16:23PM -0400, Geir Magnusson Jr. wrote: no, you moved... we never want to move branches, but copy to make tags, and never modify the tags. That way, if we need to keep going on the branch, we have it. We agreed on this proceedure a month ago. Clearly we agreed on a mistake then. I didn't read it carefully. Sorry. We want to be able to branch, work on the branch, and then tag for a release (call it vX.0) Nothing in the tag is different from the branch it came from - it's effectively a pointer to a moment in time (revision) on the branch. Now, suppose we have a security issue for which we want to do an update on the thing we released. So we then must go back to the *branch*, fix the bug, tag again (vX.0.1). You've described my ideal setup for 1.0 and beyond, but we aren't doing dot releases yet. It shouldn't matter. There is never going to be another release from the M4-QA branch. It's a dead branch and shouldn't be updated after we vote to release the M4 binaries. Why wouldn't we set a process that's standard and stick with it? Further, it's entirely reasonable to keep our option open for a subsequent release of M4. Remember M3? And what if we find a major problem? We don't want to ram forward a M5 - we'd want to fix M4 and get that out there, retracting the problematic release, say a M4r1. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Commented: (GERONIMO-848) Deployer ignores Geronimo URL host/port
[ http://issues.apache.org/jira/browse/GERONIMO-848?page=comments#action_12317535 ] Jeremy Boynes commented on GERONIMO-848: I thought we just passed the URL down to the JMX connector - do you know if this is a problem with the deployer or a problem with MX4J? > Deployer ignores Geronimo URL host/port > --- > > Key: GERONIMO-848 > URL: http://issues.apache.org/jira/browse/GERONIMO-848 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4 > Reporter: Aaron Mulder > Fix For: 1.0-M5 > > When the deployer connects to a server, it uses a URL of the form: > deployer:geronimo:jmx:rmi://host:port/jndi/rmi:/JMXConnector > Under the covers, this strips off the beginning and uses a connection of the > form: > jmx:rmi://host:port/jndi/rmi:/JMXConnector > However, no matter what you use as the host and port, it connects to the > standard port on localhost. It should actually attempt to connect to the > host and port specified and give an error if they are not valid. -- 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: milestone branching and taging (was Re: svn commit: r226882 - in /geronimo: branches/v1_0_M4-QA/ tags/v1_0_M4/)
On Wed, 3 Aug 2005, David Blevins wrote: > You've described my ideal setup for 1.0 and beyond, but we aren't > doing dot releases yet. > > There is never going to be another release from the M4-QA branch. > It's a dead branch and shouldn't be updated after we vote to release > the M4 binaries. I'm OK with deleting a branch *after* the release has been voted and distributed. But since we have to make the tag before that, I really don't like deleting the branch when making the tag. Why do you object to making the tag a *copy* of the branch? Aaron
milestone branching and taging (was Re: svn commit: r226882 - in /geronimo: branches/v1_0_M4-QA/ tags/v1_0_M4/)
On Wed, Aug 03, 2005 at 09:04:22AM -0400, Geir Magnusson Jr. wrote: > > On Aug 2, 2005, at 9:41 PM, David Blevins wrote: > > >On Mon, Aug 01, 2005 at 07:16:23PM -0400, Geir Magnusson Jr. wrote: > > > >>no, you moved... > >> > >>we never want to move branches, but copy to make tags, and never > >>modify the tags. That way, if we need to keep going on the branch, > >>we have it. > >> > > > >We agreed on this proceedure a month ago. > > Clearly we agreed on a mistake then. I didn't read it carefully. > Sorry. > > We want to be able to branch, work on the branch, and then tag for a > release (call it vX.0) Nothing in the tag is different from the > branch it came from - it's effectively a pointer to a moment in time > (revision) on the branch. > > Now, suppose we have a security issue for which we want to do an > update on the thing we released. So we then must go back to the > *branch*, fix the bug, tag again (vX.0.1). > You've described my ideal setup for 1.0 and beyond, but we aren't doing dot releases yet. There is never going to be another release from the M4-QA branch. It's a dead branch and shouldn't be updated after we vote to release the M4 binaries. -David
Re: OSCON : Apache Geronimo BOF - Wednesday, Aug 3, 7:30pm
Ideas ahead of time? Matt can show off trade, we can talk about M4... what else? geir On Aug 3, 2005, at 2:06 PM, Geir Magnusson Jr. wrote: On Aug 3, 2005, at 1:41 PM, Geir Magnusson Jr. wrote: Sorry about the late notice : We've secured a slot for an Apache Geronimo BOF at OSCon Tonight - Wednesday, Aug 3 at 7:30 PM Check the BOF board by registration for room. Room is E148 geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: OSCON : Apache Geronimo BOF - Wednesday, Aug 3, 7:30pm
On Aug 3, 2005, at 1:41 PM, Geir Magnusson Jr. wrote: Sorry about the late notice : We've secured a slot for an Apache Geronimo BOF at OSCon Tonight - Wednesday, Aug 3 at 7:30 PM Check the BOF board by registration for room. Room is E148 geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Created: (GERONIMO-848) Deployer ignores Geronimo URL host/port
Deployer ignores Geronimo URL host/port --- Key: GERONIMO-848 URL: http://issues.apache.org/jira/browse/GERONIMO-848 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0-M5 When the deployer connects to a server, it uses a URL of the form: deployer:geronimo:jmx:rmi://host:port/jndi/rmi:/JMXConnector Under the covers, this strips off the beginning and uses a connection of the form: jmx:rmi://host:port/jndi/rmi:/JMXConnector However, no matter what you use as the host and port, it connects to the standard port on localhost. It should actually attempt to connect to the host and port specified and give an error if they are not valid. -- 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-847) Better error for unmapped resource reference
Better error for unmapped resource reference Key: GERONIMO-847 URL: http://issues.apache.org/jira/browse/GERONIMO-847 Project: Geronimo Type: Improvement Components: web, deployment, naming Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0-M5 When you add a resource-ref to web.xml but not geronimo-web.xml, you get an error like: Error: Unable to distribute foo.war: Unknown or ambiguous connection factory name query: geronimo.server:J2EEServer=geronimo,J2EEApplication=null,j2eeType=JCAManagedConnectionFactory, name=jms/TestConnectionFactory,* match count: 0 It would be better if the error said "Unable to resolve resource-ref 'jms/TestConnectionFactory'". I believe a similar change was made eslerwhere recently, just need to track down the specifics. -- 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
OSCON : Apache Geronimo BOF - Wednesday, Aug 3, 7:30pm
Sorry about the late notice : We've secured a slot for an Apache Geronimo BOF at OSCon Tonight - Wednesday, Aug 3 at 7:30 PM Check the BOF board by registration for room. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Geronimo Tooling Roadmap
As we prepare moving Geronimo tooling to its new home, here is an initial road map that I feel are the necessary first steps in creating a robust and useful tooling environment for Geronimo. (1) Build infrastructure - Since Eclipse has not fully converted all their plugins from an expanded directory structures to packaged jars it is not yet a reasonable approach to build the tooling pieces purely with Maven since dependency artifacts in Maven IIUC must be jars. So the approach I think that needs to be taken is that we use the integrated Eclipse build framework the PDE which can be invoked and run in a headless mode through ant. I can probably steal some time from the Eclipse folks to help get the necessary build scripts set up correctly. The PDE build will be able to build and package the plugins and their features. A source feature can also be created that will contain all the source as well. Then we can wrap the PDE build with a maven goal that can be run independently of the rest of the geronimo build. This way there is no additional overhead for developers concerned primarily with server development. So even if the decision is made to keep the source in the same branch, they will and should be built independently by default. (2) Jira Geronimo component needed for Tools. (Will need one of the committers help to get this created). (3) Generate the necessary EMF based infrastructure that can can be then used to build additional features ,editors, views for the server adapter. (In progress). EMF can be used to auto generate model code (similar concept to Bean's), edit, and editor code, all based on the deployment plan schema. The stubbed out and default implementations of the generated edit and editor code can then be modified to provided user friendly views, editors and context menu actions for and accessing deployment plan data. Once of the nice thing about EMF is that all the notification infrastructure is created with default implementations for you. So multiple views representing the same data in different ways will always be in sync... For example adding a resource ref in the deployment plan using the deployment plan editor will refresh and update a tree view in a completely separate window/view even workbench showing the list of resource refs. EMF also provides a concept of a change recorder where if multiple areas of the model have changed you can receive a change description with what changed, containing both old and new values. (4) Auto generation of deployment plan files at project creation. For example, if the the user chooses to create a web project and that web project is target to be deployed on Geronimo, then the geronimo-web.xml file should automatically be created. The user can then double click the geronimo-web.xml file and the deployment plan editor will appear. (Currently it is being created prior to deploy time). (5) Deployment via JSR-88 (Done). (6) Extensions to launch admin and debug console. (7) Remote deployment. Should be able to deploy applications running a remote server. (8) JSR-75 Annotations for deployment plans. Once these necessary initial steps are done, (1-6) I think the sky is the limit. Once the friendly views and editors are created, we can the focus on usability features helping to provide values for deployment plan elements. For example, we could have a browse button on certain entries in the deployment plan that would access the server for list of existing data sources, gbeans, etc..basically anything that can be found through JMX. So rather then modifying entries by hand which is very error prone, values could in situations be provided for you. I think alot of work can be done in the annotation space as well, creating processors that can run as invoked as part of the java compiler that will update the deployment plans. Alot of this infrastructure to be able to do this will be addressed by upcoming JSRs. Let me know your thoughts and or additional ideas and we can start prioritizing them. Thanks. Sachin.
[jira] Created: (GERONIMO-846) Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed. - Key: GERONIMO-846 URL: http://issues.apache.org/jira/browse/GERONIMO-846 Project: Geronimo Type: Bug Components: management Versions: 1.0-M4 Environment: Windows XP Reporter: Joe Bohn Each update action from the LogManagerPortlet invokes the appropriate 3 methods on the SystemLog without checking for actual changes in the submitted values. For the refresh interval this isn't a problem because Log4JService checks itself to ensure the period has changed before updating the value. For the logging level this also isn't a problem because there is no ill effect to updating the level with the exact same level. However, when setting the ConfigFileName the Log4JService doesn't check the value and assumes that there really is a new file and therefore sets the lastChanged value to -1 to ensure that the file values will take effect on the next timer refresh. The result is that any change (including only a change to the logging level) from the console also guarantees that the file settings will be refreshed. I propose the following: 1) Change the LogManagerPortlet to ensure that the name or level has changed before updating the SystemLog (Log4JService) ... I'd also ensure that we check for changes in the refresh period as well just for good measure. This way we won't was time setting things that haven't changed. 2) Change the Log4JService to always check for an actual change to the level and/or the configPathName before taking any real action (just as it does for refresh interval today). This will clean things up so that another object invoking this service unnecessarily doesn't create a similar problem. -- 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-794) List only installed applications that are not part of Geronimo itself
[ http://issues.apache.org/jira/browse/GERONIMO-794?page=comments#action_12317521 ] Joe Bohn commented on GERONIMO-794: --- I applied the patch and it does address a number of views that Aaron had requested. However, it doesn't really address the intent of this JIRA issue. The issue that I was raising was that the user should have a way to limit the view(s) of applications to see only applications that they cared about (ie. applications that they installed to run their business). Therefore, I would like to see a view where the list of "installed applications" restricted to only show the accounting or payroll applications that a business installed and not the applications that are just necessarily part of the Geronimo package itself (like the console, ActiveMQ, Deployer, etc...).We should provide an alternate view that could display either all "system applications" (for lack of a better term) or a complete list of all applications including both user and system. However, we should be able to simplify the view to only what the user cares about 99% of the time. > List only installed applications that are not part of Geronimo itself > - > > Key: GERONIMO-794 > URL: http://issues.apache.org/jira/browse/GERONIMO-794 > Project: Geronimo > Type: Improvement > Components: management > Versions: 1.0-M5 > Environment: all > Reporter: Joe Bohn > Attachments: console.diff > > A user should only see applications that they installed when accessing the > list of installed applications from the admin console. We can still show the > "system" applications but under an additional portet that by default is > minimized on the page. -- 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-845) Jetty support for virtual servers
[ http://issues.apache.org/jira/browse/GERONIMO-845?page=comments#action_12317517 ] David Jencks commented on GERONIMO-845: --- Does virtual server == virtual host? If so, there is an impedance mismatch between jetty and tomcat. Jetty allows you to set an array of virtual host names for a web app, whereas tomcat allows you to set a single host, and then add aliases to the host. Offhand I don't see how to reconcile these two models and think it may be better to respect the differences and include a custom xml element in the geronimo-web plan. In general I find the current extension method in geronimo-web unsatisfactory and think we need to evaluate putting an "any" element in with specialized xml builders or using schema inheritance to support multiple web containers. ps. I thought there already was an jira entry for this issue but can't find it at the moment. > Jetty support for virtual servers > - > > Key: GERONIMO-845 > URL: http://issues.apache.org/jira/browse/GERONIMO-845 > Project: Geronimo > Type: Improvement > Components: deployment, web > Versions: 1.0-M4 > Reporter: Aaron Mulder > Fix For: 1.0-M5 > > Currently, Tomcat provides virtual server support via a container-specific > configuration extension. However, our Jetty container implementation should > also support virtual servers, and then we should switch to using a top-level > XML element in geronimo-web.xml to hold the virtual server name. -- 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-845) Jetty support for virtual servers
Jetty support for virtual servers - Key: GERONIMO-845 URL: http://issues.apache.org/jira/browse/GERONIMO-845 Project: Geronimo Type: Improvement Components: deployment, web Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0-M5 Currently, Tomcat provides virtual server support via a container-specific configuration extension. However, our Jetty container implementation should also support virtual servers, and then we should switch to using a top-level XML element in geronimo-web.xml to hold the virtual server name. -- 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: Clustering (long)
Joe Bohn wrote: You can define an order to the semaphores when locking and thereby avoid a deadlock. Good idea - If I order the nodes according to some unique id and try for the lease on their bucket table in the same order, then multiple nodes trying at the same time should not deadlock... - it will take a little longer, since I will be acquiring locks sequentially, not concurrently, but ... I order locks in a single vm all the time, yet didn't make the mental leap to doing it in different vms without your pointing it out -Thanks :-) Jules If each node being added or terminating itself honors the order then you will never have a deadlock. However, you still need to deal with the case of an uncontrolled failure either adding or removing a note and possibly never releasing a lock. Joe Jules Gosnell wrote: hmm... hmmm... :-) more thoughts on (1) and (2)... When a node leaves/joins it needs to acquire a lease on the bucket tables of every node that it intends to move buckets from/to. If two nodes are doing this at the same time, their requirement will collide (deadlock) somewhere in the cluster. At this point they may be notified and e.g. compare ip addresses to decide who continues and who backs off for a while. So, (1) and (2), whilst being possible are probably more complex than I initially imagined. If we have Paxos for the more general purpose case (3) anyway, it would probably be smart just to go with this, until such optimisations becomes necessary, if at all. Jules Jules Gosnell wrote: hmmm... now I'm wondering about my solutions to (1) and (2) - if more than one node tries to join or leave at the same time I may be in trouble - so it may be safer to go straight to (3) for all cases... more thought needed :-) Jules Jules Gosnell wrote: I've had a look at the Lampson paper, but didn't take it all in on the first pass - I think it will need some serious concentration. The Paxos algorithm looks interesting, I will definitely pursue this avenue. I've also given a little thought to exactly why I need a Coordinator and how Paxos might be used to replace it. My use of a Coordinator and plans for its future do not actually seem that far from Paxos, on a preliminary reading. Given that WADI currently uses a distributed map of sessionId:sessionLocation, that this distribution is achieved by sharing out responsibility for the set number of buckets that comprise the map roughly evenly between the cluster members and that this is currently my most satisfying design, I can break my problem space (for bucket arrangement) down into 3 basic cases : 1) Node joins 2) Node leaves in controlled fashion 3) Node dies If the node under discussion is the only cluster member, then no bucket rearrangement is necessary - this node will either create or destroy the full set of buckets. I'll leave this set of subcases as trivial. 1) The joining node will need to assume responsibility for a number of buckets. If buckets-per-node is to be kept roughly the same for every node, it is likely that the joining node will require transfer of a small number of buckets from every current cluster member i.e. we are starting a bucket rearrangement that will involve every cluster member and only need be done if the join is successful. So, although we wish to avoid an SPoF, if that SPoF turns out to be the joining node, then I don't see it as a problem, If the node joining dies, then we no longer have to worry about rearranging our buckets (unless we have lost some that had already been transferred - see (3)). Thus the joining node may be used as a single Coordinator/Leader for this negotiation without fear of the SPoF problem. Are we on the same page here ? 2) The same argument may be applied in reverse to a node leaving in a controlled fashion. It will wish to evacuate its buckets roughly equally to all remaining cluster members. If it shuts down cleanly, this would form part of its shutdown protocol. If it dies before or during the execution of this protocol then we are back at (3), if not, then the SPoF issue may again be put to one side. 3) This is where things get tricky :-) Currently WADI has, for the sake of simplicity, one single algorithm / thread / point-of-failure which recalculates a complete bucket arrangement if it detects (1), (2) or (3). It would be simple enough to offload the work done for (1) and (2) to the node joining/leaving and this should reduce wadi's current vulnerability, but we still need to deal with catastrophic failure. Currently WADI rebuilds the missing buckets by querying the cluster for the locations of any sessions that fall within them, but it could equally carry a replicated backup and dust it off as part of this procedure. It's just a trade-off between work done up front and work done in exceptional circumstance... This is the place where the Paxos algorithm may come in handy - bucet recomposition
Re: interop-server-plan.xml and izpack installer questions
[EMAIL PROTECTED] wrote: I noticed that the izpack installer has an "EJB/IIOP Configuration" panel where the user can configure things such as: * Naming port * EJB port * IP addresses the server should accept EJB Client connections from * IIOP port * ORB port * CosNaming port Even though I am prompted for Corba config information, the org/apache/geronimo/InteropServer configuration isn't started when Geronimo is started, which isn't intuitive. Should we be starting the configurations that they configure in the installer? Should the Interop config be optional (have it as a pack you can select at the beginning) and the IIOP port, ORB port and CosNaming port on a separate screen? I also noticed that in the following change, the interop server was removed from the assembly. Can anyone give some more background on this? There were some dependenmcy issues a while ago. Development was suppposed to continue on the interop module, but had to be temp put on the back burner. Revision: 159233 Author: adc Date: 10:58:39 PM, Monday, 28 March 2005 Message: Temporarily turned off. Modified : /geronimo/trunk/modules/assembly/maven.xml Thanks, John
Re: interop-server-plan.xml and izpack installer questions
[EMAIL PROTECTED] wrote: David Jencks <[EMAIL PROTECTED]> wrote on 03/08/2005 01:17:40 AM: > > On Aug 2, 2005, at 6:35 AM, [EMAIL PROTECTED] wrote: > > > > > I noticed that the izpack installer has an "EJB/IIOP Configuration" > > panel where the user can configure things such as: > > > > * Naming port > > * EJB port > > * IP addresses the server should accept EJB Client connections from > > * IIOP port > > * ORB port > > * CosNaming port > > > > Even though I am prompted for Corba config information, the > > org/apache/geronimo/InteropServer configuration isn't started when > > Geronimo is started, which isn't intuitive. Should we be starting the > > configurations that they configure in the installer? > > The org/apache/geronimo/InteropServer relates to the code in the > geronimo interop module, which we aren't using at the moment. The > actual CORBA support is entirely in openejb and uses the Sun orb. Should we delete this plan to avoid users being confused (since the plans are available to users (who used the izpack installer) in the geronimo/installer-temp directory. Yes, we can delete the plan. Mark > > > > Should the Interop config be optional (have it as a pack you can > > select at the beginning) and the IIOP port, ORB port and CosNaming > > port on a separate screen? > > I think it would probably be appropriate to put the openejb corba > support in a separate corba module but it is most likely to be a > separate openejb corba module. At that time making it optional seems > reasonable. I doubt this will happen before 1.0 I'll raise a JIRA issue for 1.1 to separate the openejb corba module, so we don't forget. > > > > I also noticed that in the following change, the interop server was > > removed from the assembly. Can anyone give some more background on > > this? > > As noted above, we aren't using it for anything. The generated code > (using the IDL compiler) is now in a spec module. > > thanks > david jencks > > > > Revision: 159233 > > Author: adc > > Date: 10:58:39 PM, Monday, 28 March 2005 > > Message: > > Temporarily turned off. > > > > Modified : /geronimo/trunk/modules/assembly/maven.xml > > > > Thanks, > > > > John
Re: svn commit: r226882 - in /geronimo: branches/v1_0_M4-QA/ tags/v1_0_M4/
On Aug 2, 2005, at 9:41 PM, David Blevins wrote: On Mon, Aug 01, 2005 at 07:16:23PM -0400, Geir Magnusson Jr. wrote: no, you moved... we never want to move branches, but copy to make tags, and never modify the tags. That way, if we need to keep going on the branch, we have it. We agreed on this proceedure a month ago. Clearly we agreed on a mistake then. I didn't read it carefully. Sorry. We want to be able to branch, work on the branch, and then tag for a release (call it vX.0) Nothing in the tag is different from the branch it came from - it's effectively a pointer to a moment in time (revision) on the branch. Now, suppose we have a security issue for which we want to do an update on the thing we released. So we then must go back to the *branch*, fix the bug, tag again (vX.0.1). So the change I would suggest then is to not name our branch with any sort of modifier indicating state like "prep" or "QA" or whatever, but branch for version, from which one or more tags for release are created. geir On Jul 4, 2005, at 6:38 PM, Jeremy Boynes wrote: So basically, * create a branch now, say 1.0-M4-prep * do the stuff we talking about now on that branch * cut the final M4 distro * drop the 1.0-M4-prep branch -David geir On Aug 1, 2005, at 4:54 PM, [EMAIL PROTECTED] wrote: Author: dblevins Date: Mon Aug 1 13:54:20 2005 New Revision: 226882 URL: http://svn.apache.org/viewcvs?rev=226882&view=rev Log: Making the M4 tag from the branch. Added: geronimo/tags/v1_0_M4/ - copied from r226881, geronimo/branches/v1_0_M4-QA/ Removed: geronimo/branches/v1_0_M4-QA/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Web Console - JVM portlet
Do we need this type of detail about the JVM in an administrative portlet (see the JVM portlet under Server)? This seems to be a bit over the top. IMO this is especially true when listing the details on the OS, Sun (will this even work if we're not using the sun?) User, and Etc sections. I think this is all really useful data for us and possibly even for people building a server from the components of Geronimo. However, for the average user that is just going to pick up Geronimo, do some minor configuration, and deploy applications this seems a bit overwhelming. Also, it has been my experience that more extraneous information is not always a "good thing to have which can easily be ignored". Some users look at this and decide that the server is too complicated for their needs. Perhaps it would be better to reference this information during initialization and save it off to a file for reference when debugging a problem. Thoughts? -- Joe Bohn [EMAIL PROTECTED] "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Clustering (long)
You can define an order to the semaphores when locking and thereby avoid a deadlock. If each node being added or terminating itself honors the order then you will never have a deadlock. However, you still need to deal with the case of an uncontrolled failure either adding or removing a note and possibly never releasing a lock. Joe Jules Gosnell wrote: hmm... hmmm... :-) more thoughts on (1) and (2)... When a node leaves/joins it needs to acquire a lease on the bucket tables of every node that it intends to move buckets from/to. If two nodes are doing this at the same time, their requirement will collide (deadlock) somewhere in the cluster. At this point they may be notified and e.g. compare ip addresses to decide who continues and who backs off for a while. So, (1) and (2), whilst being possible are probably more complex than I initially imagined. If we have Paxos for the more general purpose case (3) anyway, it would probably be smart just to go with this, until such optimisations becomes necessary, if at all. Jules Jules Gosnell wrote: hmmm... now I'm wondering about my solutions to (1) and (2) - if more than one node tries to join or leave at the same time I may be in trouble - so it may be safer to go straight to (3) for all cases... more thought needed :-) Jules Jules Gosnell wrote: I've had a look at the Lampson paper, but didn't take it all in on the first pass - I think it will need some serious concentration. The Paxos algorithm looks interesting, I will definitely pursue this avenue. I've also given a little thought to exactly why I need a Coordinator and how Paxos might be used to replace it. My use of a Coordinator and plans for its future do not actually seem that far from Paxos, on a preliminary reading. Given that WADI currently uses a distributed map of sessionId:sessionLocation, that this distribution is achieved by sharing out responsibility for the set number of buckets that comprise the map roughly evenly between the cluster members and that this is currently my most satisfying design, I can break my problem space (for bucket arrangement) down into 3 basic cases : 1) Node joins 2) Node leaves in controlled fashion 3) Node dies If the node under discussion is the only cluster member, then no bucket rearrangement is necessary - this node will either create or destroy the full set of buckets. I'll leave this set of subcases as trivial. 1) The joining node will need to assume responsibility for a number of buckets. If buckets-per-node is to be kept roughly the same for every node, it is likely that the joining node will require transfer of a small number of buckets from every current cluster member i.e. we are starting a bucket rearrangement that will involve every cluster member and only need be done if the join is successful. So, although we wish to avoid an SPoF, if that SPoF turns out to be the joining node, then I don't see it as a problem, If the node joining dies, then we no longer have to worry about rearranging our buckets (unless we have lost some that had already been transferred - see (3)). Thus the joining node may be used as a single Coordinator/Leader for this negotiation without fear of the SPoF problem. Are we on the same page here ? 2) The same argument may be applied in reverse to a node leaving in a controlled fashion. It will wish to evacuate its buckets roughly equally to all remaining cluster members. If it shuts down cleanly, this would form part of its shutdown protocol. If it dies before or during the execution of this protocol then we are back at (3), if not, then the SPoF issue may again be put to one side. 3) This is where things get tricky :-) Currently WADI has, for the sake of simplicity, one single algorithm / thread / point-of-failure which recalculates a complete bucket arrangement if it detects (1), (2) or (3). It would be simple enough to offload the work done for (1) and (2) to the node joining/leaving and this should reduce wadi's current vulnerability, but we still need to deal with catastrophic failure. Currently WADI rebuilds the missing buckets by querying the cluster for the locations of any sessions that fall within them, but it could equally carry a replicated backup and dust it off as part of this procedure. It's just a trade-off between work done up front and work done in exceptional circumstance... This is the place where the Paxos algorithm may come in handy - bucet recomposition and rearrangement. I need to give this further thought. For the immediate future, however, I think WADI will stay with a single Coordinator in this situation, which fails-over if http://activecluster.codehaus.org says it should - I'm delegating the really thorny problem to James :-). I agree with you that this is an SPoF and that WADI's ability to recover from failure here depends directly on how we decide if a node is alive or dead - a very tricky thing to do.
Re: Clustering (long)
hmm... hmmm... :-) more thoughts on (1) and (2)... When a node leaves/joins it needs to acquire a lease on the bucket tables of every node that it intends to move buckets from/to. If two nodes are doing this at the same time, their requirement will collide (deadlock) somewhere in the cluster. At this point they may be notified and e.g. compare ip addresses to decide who continues and who backs off for a while. So, (1) and (2), whilst being possible are probably more complex than I initially imagined. If we have Paxos for the more general purpose case (3) anyway, it would probably be smart just to go with this, until such optimisations becomes necessary, if at all. Jules Jules Gosnell wrote: hmmm... now I'm wondering about my solutions to (1) and (2) - if more than one node tries to join or leave at the same time I may be in trouble - so it may be safer to go straight to (3) for all cases... more thought needed :-) Jules Jules Gosnell wrote: I've had a look at the Lampson paper, but didn't take it all in on the first pass - I think it will need some serious concentration. The Paxos algorithm looks interesting, I will definitely pursue this avenue. I've also given a little thought to exactly why I need a Coordinator and how Paxos might be used to replace it. My use of a Coordinator and plans for its future do not actually seem that far from Paxos, on a preliminary reading. Given that WADI currently uses a distributed map of sessionId:sessionLocation, that this distribution is achieved by sharing out responsibility for the set number of buckets that comprise the map roughly evenly between the cluster members and that this is currently my most satisfying design, I can break my problem space (for bucket arrangement) down into 3 basic cases : 1) Node joins 2) Node leaves in controlled fashion 3) Node dies If the node under discussion is the only cluster member, then no bucket rearrangement is necessary - this node will either create or destroy the full set of buckets. I'll leave this set of subcases as trivial. 1) The joining node will need to assume responsibility for a number of buckets. If buckets-per-node is to be kept roughly the same for every node, it is likely that the joining node will require transfer of a small number of buckets from every current cluster member i.e. we are starting a bucket rearrangement that will involve every cluster member and only need be done if the join is successful. So, although we wish to avoid an SPoF, if that SPoF turns out to be the joining node, then I don't see it as a problem, If the node joining dies, then we no longer have to worry about rearranging our buckets (unless we have lost some that had already been transferred - see (3)). Thus the joining node may be used as a single Coordinator/Leader for this negotiation without fear of the SPoF problem. Are we on the same page here ? 2) The same argument may be applied in reverse to a node leaving in a controlled fashion. It will wish to evacuate its buckets roughly equally to all remaining cluster members. If it shuts down cleanly, this would form part of its shutdown protocol. If it dies before or during the execution of this protocol then we are back at (3), if not, then the SPoF issue may again be put to one side. 3) This is where things get tricky :-) Currently WADI has, for the sake of simplicity, one single algorithm / thread / point-of-failure which recalculates a complete bucket arrangement if it detects (1), (2) or (3). It would be simple enough to offload the work done for (1) and (2) to the node joining/leaving and this should reduce wadi's current vulnerability, but we still need to deal with catastrophic failure. Currently WADI rebuilds the missing buckets by querying the cluster for the locations of any sessions that fall within them, but it could equally carry a replicated backup and dust it off as part of this procedure. It's just a trade-off between work done up front and work done in exceptional circumstance... This is the place where the Paxos algorithm may come in handy - bucet recomposition and rearrangement. I need to give this further thought. For the immediate future, however, I think WADI will stay with a single Coordinator in this situation, which fails-over if http://activecluster.codehaus.org says it should - I'm delegating the really thorny problem to James :-). I agree with you that this is an SPoF and that WADI's ability to recover from failure here depends directly on how we decide if a node is alive or dead - a very tricky thing to do. In conclusion then, I think that we have usefully identified a weakness that will become more relevant as the rest of WADI's features mature. The Lampson paper mentioned describes an algorithm for allowing nodes to reach a consensus on actions to be performed, in a redundant manner with no SPoF and I shall consider how this might replace WADI's currently singl
Build problems this moring.
I just pulled down a completely fresh build, and I'm getting errors trying to build it this morning. This is the error I get, which I'm getting on every build variation I've tried (m:build, m:rebuild-all, etc.). Is this a problem with my setup somehow, or is the build actually broken? test:test: [echo] NOTICE: Skipping tests; they seem to have passed already [echo] No tests to run. Copying: from 'C:\Geronimo\geronimo\modules\j2ee\target\geronimo-j2ee-1.0-SNAPSH OT.jar' to: 'C:\Documents and Settings\Administrator\.maven\repository\geronimo\ jars\geronimo-j2ee-1.0-SNAPSHOT.jar' Copying: from 'C:\Geronimo\geronimo\modules\j2ee\project.xml' to: 'C:\Documents and Settings\Administrator\.maven\repository\geronimo\poms\geronimo-j2ee-1.0-SNA PSHOT.pom' + | Executing default Geronimo :: J2EE Schema | Memory: 22M/29M + BUILD FAILED File.. C:\Documents and Settings\Administrator\.maven\cache\maven-multiproje ct-plugin-1.3.1\plugin.jelly Element... maven:reactor Line.. 217 Column 9 Unable to obtain goal [default] -- C:\Documents and Settings\Administrator\.mave n\cache\xmlbeans-maven-plugin-2.0.0-beta1\plugin.jelly:24:23: Missing req uired attribute: targetdir Total time: 47 seconds Finished at: Wed Aug 03 06:33:51 EDT 2005
Re: Security Role Mapping & Authentication
The one kludge solution here...to make your example geronimo-web.xml work...
If in the j2ee-server-plan.xml, we change the EngineGBean to read as
follows (concentrate on the initParams' name value):
name="className">org.apache.geronimo.tomcat.TomcatEngine
name=geronimo-properties-realm
defaultHost=${PlanServerHostname}
geronimo.server:j2eeType=Host,*
TomcatJAASRealm
FirstValve
This would effectively work.
Jeff
Aaron Mulder wrote:
Jeff,
I don't understand what you're saying about a realm GBean, and I'm
a little sketchy on the appName. Can I explain what I'm looking for and
then you can tell me if you think this is reasonable and whether it's in
place now?
- If you have a web app that uses a login (HTTP Basic, Form-based, etc.),
then the server needs to use some "security realm" to authenticate the
user name and password you provide.
- I would like that to always be a Geronimo SecurityRealm, regardless of
whether you're using Tomcat or Jetty or what.
- I would like that to always be the Geronimo security realm whose name
is listed in the elements of geronimo-web.xml (if
geronimo-web.xml was provided and if it has that element).
- I don't want you to have to declare *any* GBeans that are Tomcat or
Jetty specific. You must have declared the GenericSecurityRealm GBean
with the proper name, of course.
I assume Tomcat requires some sort of adapter to make a Geronimo
SecurityRealm look like a "Tomcat Security Realm". I'm speculating this
is the "RealmGBean" you mention, but I don't know. I would like to
automatically create that and set it on Tomcat during the deployment
process, so the user doesn't need to specifically declare it. So, for
example, this would be a totally sufficient geornimo-web.xml if you want
to refer to the default security realm configured in Geronimo (named
geronimo-properties-realm, of type GenericSecurityRealm, and configured in
j2ee-server-plan.xml):
http://geronimo.apache.org/xml/ns/web";
xmlns:naming="http://geronimo.apache.org/xml/ns/naming";
configId="MyConfigName"
parentId="ParentConfigName">
geronimo-properties-realm
So this says, "when any user logs in, resolve their username and
password against the properties file var/security/users.properties, and if
their username is 'system' then add them to the J2EE role 'AppUsers'".
If we implement what I've described above, then I believe this
same deployment plan should work with the same results for both Tomcat and
Jetty (and it doesn't have any settings or GBeans in it specific to either
Tomcat or Jetty).
Thanks,
Aaron
On Wed, 3 Aug 2005, Jeff Genender wrote:
Ok..even though I still stand by what I said below (and want to get some
feedback on this), I figured, it surely wouldn't hurt to allow the
be an override for the appName of the Tomcat
JAASRealm. If its not specified, it will default to the standard
methodology of how Tomcat looks for a realm (by name of the path/context
or Host or Engine depending upon where the Realm was declared). One
caveat...if you want the Realm to use the context's
, you must have a RealmGBean applied at the context
level in the geronimo-web.xml. If you do not...you will get the
following log:
WARN: security-realm-name was specified but no RealmGBean was configured
for this context. Ignoring security-realm-name.
and it will thus default to the Tomcat standard realm naming conventions
(i.e. the inherited Host or Engine name at which the Realm was supplied
- Engine by default).
So...its coded, unit tested, and checked in.
Jeff
Jeff Genender wrote:
Correct, Tomcat does not use the element from the
geronimo-web.xml.
How it works is...
The Tomcat realms take the name of the object it is associated with.
Tomcat objects inherit Realms from top down. If a Realm is associated
with an Engine, then the Host(s) and Context(s) inherit that realm. The
same goes for Hosts...if its associated with that host, then all
Contexts under that Host inherits the Realm. Here is the example...
There is typically a geronimo realm GBean that is created...lets use the
example of the one in the tomcat-config.xml. Notice the realmName
attribute is "Geronimo".
Then a TomcatRealm is attached either the Engine, Host, or Context
levels. In this instance we have the TomcatRealm attached to the server
(i.e. the Engine) Notice the Engine object in tomcat-config.xml has a
name parameter of "Geronimo". All Contexts under that Engine will
associate itself with the "Geronimo" realm name. So this is Server-wide.
If I wish to change a Context to specifically use its own specific
realm, its name is the context root/path name. So say I have created an
application that has a context root of "testme", then I can attach a
Realm object to it, and t
Re: Security Role Mapping & Authentication
Aaron Mulder wrote: Jeff, I don't understand what you're saying about a realm GBean, and I'm a little sketchy on the appName. Sorry about that...I was speaking Tomcat speak...and it can get very hairy at times. I was describing the Tomcat JAAS implementation and how it works...its very confusing. Can I explain what I'm looking for and then you can tell me if you think this is reasonable and whether it's in place now? Its basically in place now...but there is one small issue...see below. - If you have a web app that uses a login (HTTP Basic, Form-based, etc.), then the server needs to use some "security realm" to authenticate the user name and password you provide. - I would like that to always be a Geronimo SecurityRealm, regardless of whether you're using Tomcat or Jetty or what. - I would like that to always be the Geronimo security realm whose name is listed in the elements of geronimo-web.xml (if geronimo-web.xml was provided and if it has that element). - I don't want you to have to declare *any* GBeans that are Tomcat or Jetty specific. You must have declared the GenericSecurityRealm GBean with the proper name, of course. This will be a small problem. The adapter is the RealmGBean. If I declare the RealmGBean and attach it to the Engine (i.e. already configured in the j2ee-server-plan.xml), then the Engine Gbean's "name" initParam *must* match the Geronimo Realm you created - this is a Tomcat requirement. Thus all contexts (and hosts) underneath the engine will use that realm by that name. In otherwords...the RealmGBean adapter is inherited by all Hosts and Contexts that are children to the Engine (the Tomcat Server). Now, if I declare a RealmGBean in the geronimo-web.xml, it will automagically be attached to that web context...and will override the Engine version for that particular context. I am allowing the to be used. So...the following would be added to your geronimo-web.xml example below: TomcatJAASRealm name="className">org.apache.geronimo.tomcat.realm.TomcatJAASRealm userClassNames=org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal roleClassNames=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal The real addition here is the container-config and the Gbean. If this is a problem and we truly want this to be seemless for Jetty and Tomcat, then I really recommend we go back to the Sun paradigm of the login.config file and name the realms like the web application context roots or default names. I assume Tomcat requires some sort of adapter to make a Geronimo SecurityRealm look like a "Tomcat Security Realm". I'm speculating this is the "RealmGBean" you mention, but I don't know. I would like to automatically create that and set it on Tomcat during the deployment process, so the user doesn't need to specifically declare it. So, for example, this would be a totally sufficient geornimo-web.xml if you want to refer to the default security realm configured in Geronimo (named geronimo-properties-realm, of type GenericSecurityRealm, and configured in j2ee-server-plan.xml): http://geronimo.apache.org/xml/ns/web"; xmlns:naming="http://geronimo.apache.org/xml/ns/naming"; configId="MyConfigName" parentId="ParentConfigName"> geronimo-properties-realm So this says, "when any user logs in, resolve their username and password against the properties file var/security/users.properties, and if their username is 'system' then add them to the J2EE role 'AppUsers'". If we implement what I've described above, then I believe this same deployment plan should work with the same results for both Tomcat and Jetty (and it doesn't have any settings or GBeans in it specific to either Tomcat or Jetty). Thanks, Aaron On Wed, 3 Aug 2005, Jeff Genender wrote: Ok..even though I still stand by what I said below (and want to get some feedback on this), I figured, it surely wouldn't hurt to allow the be an override for the appName of the Tomcat JAASRealm. If its not specified, it will default to the standard methodology of how Tomcat looks for a realm (by name of the path/context or Host or Engine depending upon where the Realm was declared). One caveat...if you want the Realm to use the context's , you must have a RealmGBean applied at the context level in the geronimo-web.xml. If you do not...you will get the following log: WARN: security-realm-name was specified but no RealmGBean was configured for this context. Ignoring security-realm-name. and it will thus default to the Tomcat standard realm naming conventions (i.e. the inherited Host or Engine name at which the Realm was supplied - Engine by default). So...its coded, unit tested, and checked in. Jeff Jeff Genender wrote: Correct, Tomcat does not use the element from the geronimo-web.x
Re: Security Role Mapping & Authentication
Jeff,
I don't understand what you're saying about a realm GBean, and I'm
a little sketchy on the appName. Can I explain what I'm looking for and
then you can tell me if you think this is reasonable and whether it's in
place now?
- If you have a web app that uses a login (HTTP Basic, Form-based, etc.),
then the server needs to use some "security realm" to authenticate the
user name and password you provide.
- I would like that to always be a Geronimo SecurityRealm, regardless of
whether you're using Tomcat or Jetty or what.
- I would like that to always be the Geronimo security realm whose name
is listed in the elements of geronimo-web.xml (if
geronimo-web.xml was provided and if it has that element).
- I don't want you to have to declare *any* GBeans that are Tomcat or
Jetty specific. You must have declared the GenericSecurityRealm GBean
with the proper name, of course.
I assume Tomcat requires some sort of adapter to make a Geronimo
SecurityRealm look like a "Tomcat Security Realm". I'm speculating this
is the "RealmGBean" you mention, but I don't know. I would like to
automatically create that and set it on Tomcat during the deployment
process, so the user doesn't need to specifically declare it. So, for
example, this would be a totally sufficient geornimo-web.xml if you want
to refer to the default security realm configured in Geronimo (named
geronimo-properties-realm, of type GenericSecurityRealm, and configured in
j2ee-server-plan.xml):
http://geronimo.apache.org/xml/ns/web";
xmlns:naming="http://geronimo.apache.org/xml/ns/naming";
configId="MyConfigName"
parentId="ParentConfigName">
geronimo-properties-realm
So this says, "when any user logs in, resolve their username and
password against the properties file var/security/users.properties, and if
their username is 'system' then add them to the J2EE role 'AppUsers'".
If we implement what I've described above, then I believe this
same deployment plan should work with the same results for both Tomcat and
Jetty (and it doesn't have any settings or GBeans in it specific to either
Tomcat or Jetty).
Thanks,
Aaron
On Wed, 3 Aug 2005, Jeff Genender wrote:
> Ok..even though I still stand by what I said below (and want to get some
> feedback on this), I figured, it surely wouldn't hurt to allow the
> be an override for the appName of the Tomcat
> JAASRealm. If its not specified, it will default to the standard
> methodology of how Tomcat looks for a realm (by name of the path/context
> or Host or Engine depending upon where the Realm was declared). One
> caveat...if you want the Realm to use the context's
> , you must have a RealmGBean applied at the context
> level in the geronimo-web.xml. If you do not...you will get the
> following log:
>
> WARN: security-realm-name was specified but no RealmGBean was configured
> for this context. Ignoring security-realm-name.
>
> and it will thus default to the Tomcat standard realm naming conventions
> (i.e. the inherited Host or Engine name at which the Realm was supplied
> - Engine by default).
>
> So...its coded, unit tested, and checked in.
>
> Jeff
>
>
>
> Jeff Genender wrote:
> > Correct, Tomcat does not use the element from the
> > geronimo-web.xml.
> >
> > How it works is...
> >
> > The Tomcat realms take the name of the object it is associated with.
> > Tomcat objects inherit Realms from top down. If a Realm is associated
> > with an Engine, then the Host(s) and Context(s) inherit that realm. The
> > same goes for Hosts...if its associated with that host, then all
> > Contexts under that Host inherits the Realm. Here is the example...
> >
> > There is typically a geronimo realm GBean that is created...lets use the
> > example of the one in the tomcat-config.xml. Notice the realmName
> > attribute is "Geronimo".
> >
> > Then a TomcatRealm is attached either the Engine, Host, or Context
> > levels. In this instance we have the TomcatRealm attached to the server
> > (i.e. the Engine) Notice the Engine object in tomcat-config.xml has a
> > name parameter of "Geronimo". All Contexts under that Engine will
> > associate itself with the "Geronimo" realm name. So this is Server-wide.
> >
> > If I wish to change a Context to specifically use its own specific
> > realm, its name is the context root/path name. So say I have created an
> > application that has a context root of "testme", then I can attach a
> > Realm object to it, and this Realm object will expect to find a realm
> > called "testme".
> >
> > This is how standard tomcat realms work, and it is because normally,
> > J2EE/JAAS uses a login.config file, where we declare our realms with
> > login modules like this:
> >
> > {
> > ;
> > ;
> > };
> > (See http://tinyurl.com/dz6bz for more info)
> >
> > In Geronimo, since we don't use a login.c
