[jira] Commented: (GERONIMO-956) Remove "global JNDI space"
[ http://issues.apache.org/jira/browse/GERONIMO-956?page=comments#action_12320671 ] Jeremy Boynes commented on GERONIMO-956: There are quite a few applications out there that access the global JNDI directly to lookup resources. This is non-standard behaviour but for them we can either force them to change or provide a context they can use - this was meant to support them. This is probalby less essential now that we have a directory integrated, but on the other hand it probably is a lot lighter in weight. > Remove "global JNDI space" > -- > > Key: GERONIMO-956 > URL: http://issues.apache.org/jira/browse/GERONIMO-956 > Project: Geronimo > Type: Improvement > Components: connector, naming > Versions: 1.0-M4 > Reporter: Aaron Mulder > Fix For: 1.0 > > Geronimo has a "global" JNDI space under "geronimo:". However: > - it's only used by connectors, not EJBs > - it's not visible outside the current VM > It doesn't seem like this is really benefitting anyone. The effort necessary > to make it behave like JNDI behaves in other popular app servers seems to be > significant. After talking on IRC, David J and I are soliciting feedback on > removing this feature entirely for now. > Note: this is different than the JNDI space that OpenEJB uses to expose EJBs > to remote clients, which takes EJBs only and is obviously accessible to > remote clients. We are not proposing to change that at this time. -- 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-959) JaasLoginService object name should not be hard coded
[ http://issues.apache.org/jira/browse/GERONIMO-959?page=comments#action_12320669 ] Jeremy Boynes commented on GERONIMO-959: Replace by having a reference back to the login service that the GenericSecurityRealm can use to initialize an option passed to the login module Sendingmodules\assembly\src\plan\j2ee-secure-plan.xml Sendingmodules\assembly\src\plan\j2ee-server-plan.xml Sendingmodules\assembly\src\plan\tomcat-config.xml Sending modules\jetty\src\test\org\apache\geronimo\jetty\AbstractWebModuleTest.java Sending modules\security\src\java\org\apache\geronimo\security\jaas\JaasLoginCoordinator.java Sending modules\security\src\java\org\apache\geronimo\security\jaas\JaasLoginService.java Sending modules\security\src\java\org\apache\geronimo\security\jaas\JaasLoginServiceMBean.java Sending modules\security\src\java\org\apache\geronimo\security\jaas\ServerRealmConfigurationEntry.java Sending modules\security\src\java\org\apache\geronimo\security\realm\GenericSecurityRealm.java Sending modules\security\src\java\org\apache\geronimo\security\remoting\jmx\JaasLoginServiceRemotingServer.java Sending modules\security\src\test\org\apache\geronimo\security\AbstractTest.java Sending modules\security\src\test\org\apache\geronimo\security\jaas\ConfigurationEntryTest.java Sending modules\security\src\test\org\apache\geronimo\security\jaas\LoginPropertiesFileTest.java Sending modules\security\src\test\org\apache\geronimo\security\jaas\LoginSQLTest.java Sending modules\security\src\test\org\apache\geronimo\security\jaas\TimeoutTest.java Sending modules\tomcat\src\test\org\apache\geronimo\tomcat\AbstractWebModuleTest.java Sending modules\tomcat\src\test\org\apache\geronimo\tomcat\ContainerTest.java Transmitting file data . Committed revision 264948. > JaasLoginService object name should not be hard coded > - > > Key: GERONIMO-959 > URL: http://issues.apache.org/jira/browse/GERONIMO-959 > Project: Geronimo > Type: Bug > Components: security > Versions: 1.0-M4, 1.0-M5 > Reporter: Jeremy Boynes > Fix For: 1.0-M5 > > The name of the JaasLoginService should not be a hard-coded object name > containing e.g. the server config id -- 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-959) JaasLoginService object name should not be hard coded
[ http://issues.apache.org/jira/browse/GERONIMO-959?page=all ] Jeremy Boynes closed GERONIMO-959: -- Resolution: Fixed > JaasLoginService object name should not be hard coded > - > > Key: GERONIMO-959 > URL: http://issues.apache.org/jira/browse/GERONIMO-959 > Project: Geronimo > Type: Bug > Components: security > Versions: 1.0-M4, 1.0-M5 > Reporter: Jeremy Boynes > Fix For: 1.0-M5 > > The name of the JaasLoginService should not be a hard-coded object name > containing e.g. the server config id -- 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-959) JaasLoginService object name should not be hard coded
JaasLoginService object name should not be hard coded - Key: GERONIMO-959 URL: http://issues.apache.org/jira/browse/GERONIMO-959 Project: Geronimo Type: Bug Components: security Versions: 1.0-M4, 1.0-M5 Reporter: Jeremy Boynes Fix For: 1.0-M5 The name of the JaasLoginService should not be a hard-coded object name containing e.g. the server config id -- 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: Client Container seems a little... weird.
I agree. The whole thing is very weird, and I should know I wrote a lot of it. I remember having some cool ideas about how to handle client applications at the time, but none of them panned out. I personally would prefer that we drop any thing that isn't absolutely necessary so we can hopefully end up with a very simple and understandable configuration and code base that we can easily add new features to later. -dain On Aug 30, 2005, at 8:24 PM, Aaron Mulder wrote: In the client container, there's a distinction between the "configuration" (the client module) and the "client" (the client class itself that you ultimately want to run). You have to provide metadata for both. The Geronimo plan contains an ID and Parent for both the configuration and the client (configId, parentId, clientConfigId, clientParentId). The important thing is that the configuration gets into the server's config-store. At that point, the configuration seems to be irrelevant. You can stop the configuration, and the client still runs fine. In fact, you can even stop the server, and so long as the application client doesn't try to access an EJB or something, this is totally OK. Thsat behavior appears to occur because the client container runs its own kernel pointing at the same config store as the server. So as long as the client has been deployed there at some time, the client container is not really going to care about the server, at least until the client application tries to log in or access something from the server environment. This just seems weird to me. I don't terribly fancy both the client and server running kernels in different JVMs but pointing to the same config store, manageable attribute store, etc. Also, it contributes to the trouble we have running a client from a different Geronimo install (or on a different machine) than the server. Also, odd things happen if you actually start the "client" as you would any other configuration on the server side (which I guess means you're running the client container literally within the server environment, except the client app is not actually executed until you invoke the "main" GBean operation on it). David J mentioned the possibility of constructing a client container that accesses required code from the server via JNLP, for example. I think that would be pretty neat, and a way to avoid these issues. Basically create a standalone client container that downloads things it needs from the Geronimo server, and doesn't try to share the server's disk environment. That might also make the configuration/client distinction a little more meaningful. However, in the mean time, I still feel like we have too many configuration parameters. As far as configID goes, it's not clear why we can't produce a name for either the configuration and the client based on the other, so there's only one name to use regardless of whether you're trying to redeploy or run the client. As far as parentID goes, it seems like you might want to force certain things (such as EJBs) to be running in the server when the client is runnable (e.g. a parent for the configuration), but it doesn't seem like you'd ever want to set a parent on the actual client other than org/apache/geronimo/Client. So it would be nice IMHO to stick with the standard configId and parentId, where configId is used for both configuration and client (well, used for one, and the other becomes FooClient or whatever), and parentId is used only for configuration, and "clientConfigId" is always org/apache/geronimo/Client. So I guess I'd like to add two JIRA issues, one to support a remote client container, and one to eliminate the clientConfigId and clientParentId. Any thoughts would be appreciated. Thanks, Aaron
Re: Client Container seems a little... weird.
On Aug 30, 2005, at 9:01 PM, Aaron Mulder wrote: On Tue, 30 Aug 2005, David Jencks wrote: I think I'd like to find a classloader that actually lets you use jar:jar: urls, unlike the sun cl, and then just pack a mini-geronimo server with config-store, repo, etc into it and have that be the client jar. This could be served by jnlp but could also just be copied in place and run. But it would have to be dynamic, right? I mean, if you deploy an app client and then immediately run the client container from a remote machine, and we expect that remote machine to have your app client and all its dependencies in its local config store, then part of the client container process needs to be downloading fresh copies of the app client and any dependencies into the local config store. Or if the whole thing's going to be in a JAR, then the client continer needs to download a massive dynamically-generated JAR containing "all the right stuff" in the included config-store and so on. I was thinking the single-jar solution would be "you are responsible for getting the correct version of this jar onto all your client machines, and starting them with java -jar MyAppClient.jar." no jnlp, no nothin. I've never actually used jnlp so I don't know much about how convenient it is to use. I think I'd prefer to dispense with the client-side config store and just have a "lightweight" client environment that starts up, connects to the server, downloads a dynamically-generated JNLP file describing the client and its dependencies, sucks down a bunch of JARs, sets up a ClassLoader, and runs the thing locally. I'd prefer to avoid running a Kernel on the client at all, if we can, though I guess that's not very realistic since the client can run connectors and stuff in its local environment. I think the app client kernel is essential. I think that if someone want to run jetty in their app client we should let them. Also, if someone wants to do distributed transactions from the app client and use a real tx log, its fine with me. Hmmm... What if we provided a different implementation of ConfigStore for the client? Perhaps something that can suck things down from the server on demand, and read them directly from whatever package the server provides? If we build a CAR export tool, this could work hand-in-hand with that. The only question would be where on the local filesystem to store the stuff it downloaded (like a dot dir in your home directory, or in the directory you execute the client from, or what?). I like this idea, although I think a remote repository will be equally needed. Either way, I'd like to avoid client-only stuff showing up in the server's config store. It's pretty disconcerting to list-modules and see stuff there that you're not supposed to use, or to start the client container in the server and have it completely alter the Log4J configuration of the server, or whatever. I'm not sure what we can do about that. I don't see it as a problem. I think it might be useful in fact. If you set the clientParentId to some server configurations, and your "app client" has a swing gui, I think you would get a in-vm gui running in the server vm if you started the client configuration in the server. david jencks Aaron
Re: Client Container seems a little... weird.
On Tue, 30 Aug 2005, David Jencks wrote: > I think I'd like to find a classloader that actually lets you use > jar:jar: urls, unlike the sun cl, and then just pack a mini-geronimo > server with config-store, repo, etc into it and have that be the client > jar. This could be served by jnlp but could also just be copied in > place and run. But it would have to be dynamic, right? I mean, if you deploy an app client and then immediately run the client container from a remote machine, and we expect that remote machine to have your app client and all its dependencies in its local config store, then part of the client container process needs to be downloading fresh copies of the app client and any dependencies into the local config store. Or if the whole thing's going to be in a JAR, then the client continer needs to download a massive dynamically-generated JAR containing "all the right stuff" in the included config-store and so on. I think I'd prefer to dispense with the client-side config store and just have a "lightweight" client environment that starts up, connects to the server, downloads a dynamically-generated JNLP file describing the client and its dependencies, sucks down a bunch of JARs, sets up a ClassLoader, and runs the thing locally. I'd prefer to avoid running a Kernel on the client at all, if we can, though I guess that's not very realistic since the client can run connectors and stuff in its local environment. Hmmm... What if we provided a different implementation of ConfigStore for the client? Perhaps something that can suck things down from the server on demand, and read them directly from whatever package the server provides? If we build a CAR export tool, this could work hand-in-hand with that. The only question would be where on the local filesystem to store the stuff it downloaded (like a dot dir in your home directory, or in the directory you execute the client from, or what?). Either way, I'd like to avoid client-only stuff showing up in the server's config store. It's pretty disconcerting to list-modules and see stuff there that you're not supposed to use, or to start the client container in the server and have it completely alter the Log4J configuration of the server, or whatever. I'm not sure what we can do about that. Aaron
Re: M5 List Closure - J2EE Certification
Aaron Mulder wrote: Has anyone taken a stab at running the TCK on Tomcat yet? If not, I think it's going to be hard to agree on a sensible ETA. No...I can start it...but I really need some people to step up and help out here ;-) Jeff Aaron On Tue, 30 Aug 2005, David Blevins wrote: There was some discussion in M4 on possibly J2EE certifying that release or maybe M5. Can we get a clear consensus that: 1) this is what we want to do with M5 2) what is the ideal timeframe for completing that (in weeks, don't say soon).
Re: Client Container seems a little... weird.
On Aug 30, 2005, at 8:24 PM, Aaron Mulder wrote: In the client container, there's a distinction between the "configuration" (the client module) and the "client" (the client class itself that you ultimately want to run). You have to provide metadata for both. The Geronimo plan contains an ID and Parent for both the configuration and the client (configId, parentId, clientConfigId, clientParentId). This is partly due to jsr-77. We need to supply a gbean on the server that represents the app client module. This needs to be in a server configuration. Don't blame me :-) The important thing is that the configuration gets into the server's config-store. At that point, the configuration seems to be irrelevant. You can stop the configuration, and the client still runs fine. In fact, you can even stop the server, and so long as the application client doesn't try to access an EJB or something, this is totally OK. If you stop the server configuration, jsr-77 won't be able to find that all-important app client module gbean with all the important info in it (i.e. none :-) Thsat behavior appears to occur because the client container runs its own kernel pointing at the same config store as the server. So as long as the client has been deployed there at some time, the client container is not really going to care about the server, at least until the client application tries to log in or access something from the server environment. yes This just seems weird to me. I don't terribly fancy both the client and server running kernels in different JVMs but pointing to the same config store, manageable attribute store, etc. Also, it contributes to the trouble we have running a client from a different Geronimo install (or on a different machine) than the server. Also, odd things happen if you actually start the "client" as you would any other configuration on the server side (which I guess means you're running the client container literally within the server environment, except the client app is not actually executed until you invoke the "main" GBean operation on it). indeed. David J mentioned the possibility of constructing a client container that accesses required code from the server via JNLP, for example. I think that would be pretty neat, and a way to avoid these issues. Basically create a standalone client container that downloads things it needs from the Geronimo server, and doesn't try to share the server's disk environment. That might also make the configuration/client distinction a little more meaningful. I think I'd like to find a classloader that actually lets you use jar:jar: urls, unlike the sun cl, and then just pack a mini-geronimo server with config-store, repo, etc into it and have that be the client jar. This could be served by jnlp but could also just be copied in place and run. However, in the mean time, I still feel like we have too many configuration parameters. As far as configID goes, it's not clear why we can't produce a name for either the configuration and the client based on the other, so there's only one name to use regardless of whether you're trying to redeploy or run the client. As far as parentID goes, it seems like you might want to force certain things (such as EJBs) to be running in the server when the client is runnable (e.g. a parent for the configuration), but it doesn't seem like you'd ever want to set a parent on the actual client other than org/apache/geronimo/Client. So it would be nice IMHO to stick with the standard configId and parentId, where configId is used for both configuration and client (well, used for one, and the other becomes FooClient or whatever), and parentId is used only for configuration, and "clientConfigId" is always org/apache/geronimo/Client. It is sometimes necessary to specify all of these. The most important is clientParentId, now a URI[], which lets you add lots of client configurations to your client. For instance, you can set up a db or jms configuration and include it in your app client. This can be much easier than including the config plan in each and every app client plan. The clientConfigId lets you identify the client in the config store. The parentId, as you noted, can be used to get other apps running on the server. The configId needs to be unique and you may want to be able to set it. It is possible to generate defaults for all of these, witness the possibility of deploying an app client without a plan. However, they are all useful. So I guess I'd like to add two JIRA issues, one to support a remote client container, +1, although I thought there already was such a jira entry and one to eliminate the clientConfigId and clientParentId. -1, as I attempted to explain above. thanks david jencks Any thoughts would be appreciated. Thanks, Aaron
Client Container seems a little... weird.
In the client container, there's a distinction between the "configuration" (the client module) and the "client" (the client class itself that you ultimately want to run). You have to provide metadata for both. The Geronimo plan contains an ID and Parent for both the configuration and the client (configId, parentId, clientConfigId, clientParentId). The important thing is that the configuration gets into the server's config-store. At that point, the configuration seems to be irrelevant. You can stop the configuration, and the client still runs fine. In fact, you can even stop the server, and so long as the application client doesn't try to access an EJB or something, this is totally OK. Thsat behavior appears to occur because the client container runs its own kernel pointing at the same config store as the server. So as long as the client has been deployed there at some time, the client container is not really going to care about the server, at least until the client application tries to log in or access something from the server environment. This just seems weird to me. I don't terribly fancy both the client and server running kernels in different JVMs but pointing to the same config store, manageable attribute store, etc. Also, it contributes to the trouble we have running a client from a different Geronimo install (or on a different machine) than the server. Also, odd things happen if you actually start the "client" as you would any other configuration on the server side (which I guess means you're running the client container literally within the server environment, except the client app is not actually executed until you invoke the "main" GBean operation on it). David J mentioned the possibility of constructing a client container that accesses required code from the server via JNLP, for example. I think that would be pretty neat, and a way to avoid these issues. Basically create a standalone client container that downloads things it needs from the Geronimo server, and doesn't try to share the server's disk environment. That might also make the configuration/client distinction a little more meaningful. However, in the mean time, I still feel like we have too many configuration parameters. As far as configID goes, it's not clear why we can't produce a name for either the configuration and the client based on the other, so there's only one name to use regardless of whether you're trying to redeploy or run the client. As far as parentID goes, it seems like you might want to force certain things (such as EJBs) to be running in the server when the client is runnable (e.g. a parent for the configuration), but it doesn't seem like you'd ever want to set a parent on the actual client other than org/apache/geronimo/Client. So it would be nice IMHO to stick with the standard configId and parentId, where configId is used for both configuration and client (well, used for one, and the other becomes FooClient or whatever), and parentId is used only for configuration, and "clientConfigId" is always org/apache/geronimo/Client. So I guess I'd like to add two JIRA issues, one to support a remote client container, and one to eliminate the clientConfigId and clientParentId. Any thoughts would be appreciated. Thanks, Aaron
[jira] Commented: (GERONIMO-484) Repeated Deploys of WAR Generate OOM Exception
[ http://issues.apache.org/jira/browse/GERONIMO-484?page=comments#action_12320651 ] Jeff Genender commented on GERONIMO-484: Applied Kevan's patch...thanks. Please confirm this fixes any other leaks. if so, please close and mark as fixed fo M5. Sending modules/jetty/src/java/org/apache/geronimo/jetty/JettyWebAppContext.java Sending modules/tomcat/src/java/org/apache/geronimo/tomcat/TomcatWebAppContext.java Transmitting file data .. Committed revision 264928. > Repeated Deploys of WAR Generate OOM Exception > -- > > Key: GERONIMO-484 > URL: http://issues.apache.org/jira/browse/GERONIMO-484 > Project: Geronimo > Type: Bug > Components: web > Versions: 1.0-M3 > Environment: WinXP SP2, JDK 1.4.2_05 > Reporter: Seth Ladd > Assignee: David Jencks > Fix For: 1.0-M5 > Attachments: LogFactoryRelease.txt, minimaltest.war, over-and-over.sh > > Hello, > I have just run a test that tests Geronimo's ability to redeploy .war > files. The results don't look so good, but I'm hoping the info I've > collected will help expose the problem (whether the problem is with me > or the server :) > I've included the script, .war file, web.xml, and two exception traces > (one from the deploy client and one from the server) I apologize for > the length of this post. If there's a better way to include all this > information, please let me know. > It appears as if the server is running out of memory. Note that I did > not alter the native configuration of Geronimo in any way. This is a > stock M3 download, using JDK 1.4.2_05 on Windows XP SP2. > It's my expectation that the app server would stay up and running > indefinitely after redeploys of .war files. Especially this .war file > since it merely contains a single welcome.jsp. I hope this info is > helpful, and let me know what else you might need. I'll gladly send > the script and .war file to others that might want to test this. > Thanks, > Seth > My test script: > $ cat over-and-over.sh > while /bin/true; do > java -jar bin/deployer.jar --user system --password manager deploy > ../eclipse/wo > rkspace/MinimalWebapp/build/minimaltest.war > sleep 1 > wget -q -O - http://localhost:8080/minimaltest/welcome.jsp > /dev/null > java -jar bin/deployer.jar --user system --password manager undeploy > minimaltest > sleep 1 > done > Structure of minimaltest.war: > $ jar tf ../eclipse/workspace/MinimalWebapp/build/minimaltest.war > META-INF/ > META-INF/MANIFEST.MF > WEB-INF/ > welcome.jsp > WEB-INF/web.xml > Contents of web.xml: > $ cat ../eclipse/workspace/MinimalWebapp/web/WEB-INF/web.xml > > http://java.sun.com/xml/ns/j2ee"; >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee > http://java.sun.com/ > xml/ns/j2ee/web-app_2_4.xsd" >version="2.4"> > >welcome.jsp > > > So, as you can see, it's a very minimal webapp. It doesn't initialize > anything, nor does it include any 3rd party jars or libs. It doesn't > even load up any classes, and the welcome.jsp only says "Hello, > world!" > After 1434 deploy cycles, we receive this exception from the deploy client: > - > Deployment failed > Server reports: null > java.lang.IllegalStateException >at org.apache.geronimo.kernel.Kernel.stopConfiguration(Kernel.java:437) >at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:324) >at > mx4j.server.ReflectionMBeanInvoker.invokeImpl(ReflectionMBeanInvoker.java:152) >at > mx4j.server.ReflectionMBeanInvoker.doInvoke(ReflectionMBeanInvoker.java:119) >at > mx4j.server.ReflectionMBeanInvoker.invoke(ReflectionMBeanInvoker.java:54) >at > mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:235) >at > mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) >at > mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:86) >at > mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) >at > mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) >at > mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerInterceptor.java:205) >at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079) >at > mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:222) >at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source) >at > sun.
[jira] Commented: (GERONIMO-947) Configuration should have multiple parents
[ http://issues.apache.org/jira/browse/GERONIMO-947?page=comments#action_12320646 ] David Jencks commented on GERONIMO-947: --- Step 2b: use the MultiParentClassLoader in configurations. Step 3: the parentId attribute can again only hold a single parent, but you can use any number of import elements (schema type same as dependency) to list parents. Sending trunk/modules/client-builder/src/java/org/apache/geronimo/client/builder/AppClientModuleBuilder.java Sending trunk/modules/client-builder/src/schema/geronimo-application-client.xsd Sendingtrunk/modules/connector-builder/maven.xml Sending trunk/modules/connector-builder/src/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java Adding trunk/modules/connector-builder/src/schema/geronimo-connector.xsd Deleting trunk/modules/connector-builder/src/schema/geronimo-connector_1_5.xsd Sending trunk/modules/deployment/src/java/org/apache/geronimo/deployment/DeploymentContext.java Sending trunk/modules/j2ee-builder/src/java/org/apache/geronimo/j2ee/deployment/EARConfigBuilder.java Sendingtrunk/modules/j2ee-builder/src/schema/geronimo-application.xsd Sending trunk/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java Sending trunk/modules/kernel/src/java/org/apache/geronimo/kernel/config/Configuration.java Sending trunk/modules/kernel/src/java/org/apache/geronimo/kernel/config/MultiParentClassLoader.java Sending trunk/modules/kernel/src/test/org/apache/geronimo/kernel/ConfigTest.java Sending trunk/modules/kernel/src/test/org/apache/geronimo/kernel/config/MultiParentClassLoaderTest.java Sending trunk/modules/service-builder/src/java/org/apache/geronimo/deployment/service/ServiceConfigBuilder.java Sendingtrunk/modules/service-builder/src/schema/geronimo-config.xsd Adding trunk/modules/service-builder/src/test/org/apache/geronimo/deployment/service/ParentIDTest.java Sending trunk/modules/system/src/java/org/apache/geronimo/system/configuration/ExecutableConfigurationUtil.java Sending trunk/modules/tomcat-builder/src/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java Sendingtrunk/modules/web-builder/src/schema/geronimo-web.xsd Transmitting file data ... Committed revision 264914. Checking in modules/openejb-builder/src/java/org/openejb/deployment/OpenEJBModuleBuilder.java; new revision: 1.53; previous revision: 1.52 Checking in modules/openejb-builder/src/schema/openejb-jar.xsd; new revision: 1.25; previous revision: 1.24 > Configuration should have multiple parents > -- > > Key: GERONIMO-947 > URL: http://issues.apache.org/jira/browse/GERONIMO-947 > Project: Geronimo > Type: Bug > Components: kernel > Versions: 1.0-M5 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.0-M5 > > A configuration should have multiple parents. This is needed for many > reasons including to allow us to split our configurations into more > manageable pieces. Some discussion has produced this plan: > 1. change all the builder code to produce an URI[] instead of URI for > parentId using a parentId attribute with comma separated list of parents in > the plans > 2. Find a multi-parent classloader and use it in Configuration. Dain says he > has one and I think Eclipse has one. > 3. Change the plan xml to have multiple import elements for the parents > 4. split up our plans to take advantage of this feature. -- 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: eclipse Distribution site proposal
Geir, Since this is under cvs.apache.org and not www.apache.org/dist (and hence not mirrored), it isn't a problem. Nobody has had a problem with snapshots under cvs.apache.org/repository, AFAIK. - BrettOn 8/31/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: There's been concern elsewhere that the concept of "snapshot" that'sthen distributed is a way of circumventing the oversight of arelease. I want to be sure that the nightly-ness of this is clear,especially if the eclipse people are linking to it. On Aug 30, 2005, at 1:20 PM, Dain Sundstrom wrote:> Geir this code is in cvs.apache.org under a directory called> "unstable". This is exactly how we do nightly unstable "r"eleases. >> Regardless, if this is a real concern for you, simply delete the> directory as I instructed.>> -dain>> On Aug 30, 2005, at 9:55 AM, Geir Magnusson Jr. wrote:> >>> my concern is that this might be interpreted as a de-facto release>> of some sort. Can it be named something like "nightly" or such? On Aug 30, 2005, at 12:44 PM, Dain Sundstrom wrote: > Since on one objected I uploaded the site from GERONIMO-949 to here:>> http://cvs.apache.org/dist/geronimo/eclipse/unstable >> If any committer has an objection, just delete this directory on>>> people.apache.org:>> /www/cvs.apache.org/dist/geronimo/eclipse/unstable >> and then we can address the concerns.>> -dain>> On Aug 29, 2005, at 5:36 PM, Dain Sundstrom wrote:>> >> On Aug 29, 2005, at 4:52 PM, Sachin Patel wrote:> It may take some time to get the subproject website set up and > I'm still working on getting the plugins mavenized. In the> meantime could we either set up a distribute update site on> Geronimo or even easier just post the latest distribution zip > on the main site? I've already sent a note out to the WTP dev> list informing them that it will be posted on Apache soon.>> Thoughts? +1 I suggest we create the eclipse site here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If you can create the site and upload it to JIRA as a patch, I'll post it to the site (assuming no one objects). -dain>> >> -->> Geir Magnusson Jr +1-203-665-6437>> [EMAIL PROTECTED]--Geir Magnusson Jr +1-203-665-6437[EMAIL PROTECTED]
[jira] Closed: (GERONIMO-954) Assembly doesn't clean itself every time
[ http://issues.apache.org/jira/browse/GERONIMO-954?page=all ] Dain Sundstrom closed GERONIMO-954: --- Resolution: Fixed Sendingassembly/project.properties Transmitting file data . Committed revision 264904. > Assembly doesn't clean itself every time > > > Key: GERONIMO-954 > URL: http://issues.apache.org/jira/browse/GERONIMO-954 > Project: Geronimo > Type: Bug > Components: buildsystem > Versions: 1.0-M5 > Reporter: Aaron Mulder > Assignee: Dain Sundstrom > Priority: Critical > Fix For: 1.0-M5 > > Previously, every time you built the assembly module it deleted the target/ > directory first. > After the most recent changes, it does not do that any more. > I think it was better before. Now you can end up with things like a stale > catalina directory and multiple copies of each entry in the config-store, > which all make their way into the output ZIP. -- 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-958) When using the Console to inspect
When using the Console to inspect -- Key: GERONIMO-958 URL: http://issues.apache.org/jira/browse/GERONIMO-958 Project: Geronimo Type: Bug Versions: 1.0-M5 Environment: When DB2 is the underlying datasource the Console Blows its brains out... Reporter: Matt Hogstrom Stack trace too large to communicate via the Internet re: Intl Law. Looking into it. But here is a snippet: Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at java.lang.String.charAt(String.java:444) at org.apache.geronimo.console.databasemanager.DataSourceInfo.setJndiName(DataSourceInfo.java:59) at org.apache.geronimo.console.databasemanager.AbstractConnectionFactoryManagerPortlet.renderList(AbstractConnectionFactoryManagerPortlet.java:213) ... 121 more Nested Exception is java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at java.lang.String.charAt(String.java:444) at org.apache.geronimo.console.databasemanager.DataSourceInfo.setJndiName(DataSourceInfo.java:59) at org.apache.geronimo.console.databasemanager.AbstractConnectionFactoryManagerPortlet.renderList(AbstractConnectionFactoryManagerPortlet.java:213) at org.apache.geronimo.console.databasemanager.AbstractConnectionFactoryManagerPortlet.doView(AbstractConnectionFactoryManagerPortlet.java:186) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) Looking into it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
On Aug 30, 2005, at 4:42 PM, David Jencks wrote: On Aug 30, 2005, at 4:38 PM, Bruce Snyder wrote: On 8/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: In Apache Geronino and dependencies like OpenEJB, (and probably other projects at the ASF...) we are using an external project known as 'bouncycastle' (http://www.bouncycastle.org/) , a fairly well known implementation of crypto-related stuff in Java. Inside the distro jar from bouncycastle is an implementation of the IDEA algorithm. This algorithm is patented, and the patent holder, MediaCrypt, requires licenses for all implementations of IDEA, and there's no unfettered use - even non-commercial distribution requires some kind of correspondence with MediaCrypt. http://www.mediacrypt.com/ You have to find the license section... So, here's the problem - I don't believe either Geronimo or OpenEJB is using the algorithm explicitly but I can't be sure that it isn't invoked somewhere, and statements from the MediaCrypt site such as "Requests by freeware developers to obtain a royalty-free license to spread an application program containing the algorithm not for commercial purposes must be directed to MediaCrypt" make me believe that we have to do something to redistribute this software. (I can't help noting how the infinitive "to spread" makes the GPL's language on "distribution" look clear.. :) Of course, there are other terms for commercial users. So, what should we do? How about asking the Bouncy Castle people for some advice on what to do? They're distributing the artifacts affected by these statements from MediaCrypt, what do they recommend to their user base regarding redistribution and use? Good idea. Alternatively for our use, it looks like the directory project has its own asn1 implementation. IIUC that is all we use in the openejb corba code. Can we sidestep this problem by using the directory's asn1 implementation? Kresten, does the proposed Trifork ORB donation include the asn1 code necessary for CORBA security? -dain
[jira] Created: (GERONIMO-957) Add version numbers to Geronimo schemas
Add version numbers to Geronimo schemas --- Key: GERONIMO-957 URL: http://issues.apache.org/jira/browse/GERONIMO-957 Project: Geronimo Type: Improvement Components: deployment Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0-M5 The Geronimo & OpenEJB schemas currently have no version number in the namespace or the file name. This means that when we have multiple versions of Geronimo, * It will not be possible to store schemas from different versions in the same directory (e.g. to include new and old formats in the schemas/ dir or post them all at a web URL) * It will also not be possible to tell from reading a schema what version it applies to (unless perhaps we do this with comments?) * When writing an application plan, it won't be possible to indicate which version of the Geronimo schemas it complies with * When Geronimo is parsing a plan, it won't know if the plan was written to a current or older version of the schemas At a minimum, I'd like to add a version number to the schema file name. However, the greatest advantage is in adding it to the namespace as well. An alternative is to take the J2EE approach of leaving the namespace the same and adding a "version" attribute to the top-level element in every file. However, that seems less attractive to me since we have so many schema imports (security, naming, etc.) and it would be unfortunate to need to repeat the version on every ejb-ref tag and so on, or to automatically assume that all the imports follow the same version as the containing schema (especially for something like OpenEJB which is on a different version track than Geronimo). If we defer adding a version in any way for v1.0, I think we'll end up wanting to do it later, and it doesn't seem too nice to have "unversioned" mean "1.0" when all subsequent releases are versioned. -- 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: M5 List Closure - Time vs Features
On Aug 30, 2005, at 4:24 PM, Bruce Snyder wrote: On 8/30/05, David Blevins <[EMAIL PROTECTED]> wrote: 1) If we could deliver M5 in _2__ weeks, I would consider that a complete success. 2) I would not like M5 to take more than _3__ weeks. I don't think that taking any longer than three weeks is necessary. We don't need to fit everything into M5. We can have an M6 and M7 if necessary. In fact, I'd rather see more drops with smaller additions/changes than less drops with larger additions/changes. +1 Couldn't have said it better myself -dain
Re: M5 List Closure - GBeanName
On Aug 30, 2005, at 2:20 PM, David Blevins wrote: Ok, so what we need consensus on is whether we should for M5: 1) Complete GBeanName support and officially deprecate ObjectName use and convert fully post-M5. 2) Wait till post-M5 and do all at once. I vote we stick with ObjectName until Geronimo 2.0. I see no benefit from this change and only destabilization. -dain
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
David Jencks wrote:
On Aug 30, 2005, at 4:38 PM, Bruce Snyder wrote:
On 8/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
In Apache Geronino and dependencies like OpenEJB, (and probably other
projects at the ASF...) we are using an external project known as
'bouncycastle' (http://www.bouncycastle.org/) , a fairly well known
implementation of crypto-related stuff in Java.
Inside the distro jar from bouncycastle is an implementation of the
IDEA algorithm. This algorithm is patented, and the patent holder,
MediaCrypt, requires licenses for all implementations of IDEA, and
there's no unfettered use - even non-commercial distribution requires
some kind of correspondence with MediaCrypt.
http://www.mediacrypt.com/
You have to find the license section...
So, here's the problem - I don't believe either Geronimo or OpenEJB
is using the algorithm explicitly but I can't be sure that it isn't
invoked somewhere, and statements from the MediaCrypt site such as
"Requests by freeware developers to obtain a royalty-free license to
spread an application program containing the algorithm not for
commercial purposes must be directed to MediaCrypt"
make me believe that we have to do something to redistribute this
software.
(I can't help noting how the infinitive "to spread" makes the GPL's
language on "distribution" look clear.. :)
Of course, there are other terms for commercial users.
So, what should we do?
How about asking the Bouncy Castle people for some advice on what to
do? They're distributing the artifacts affected by these statements
from MediaCrypt, what do they recommend to their user base regarding
redistribution and use?
Good idea. Alternatively for our use, it looks like the directory
project has its own asn1 implementation. IIUC that is all we use in
the openejb corba code. Can we sidestep this problem by using the
directory's asn1 implementation?
The directory's asn1 implementation doesn't include support for X509
names, which is the really the only bit used by the corba code.
Also, the console is using the bouncycastle code to implement its
keystore. Unfortunately, the APIs used for that require the bc code to
be installed as a JCE security provider. A JCE security provider needs
to be in a signed jar, which pretty much precludes just snipping the
idea code from the jar file. This would have worked for the openejb
asn1 support, but not for every use.
Rick
david jencks
Bruce
--
perl -e 'print
unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
[jira] Closed: (GERONIMO-320) Geronimo Realm provider for existing Tomcat Realm implementations
[ http://issues.apache.org/jira/browse/GERONIMO-320?page=all ] Jeff Genender closed GERONIMO-320: -- Resolution: Fixed Not needed. The Tomcat realms can be used in Geronimo in the Tomcat Container only. We would have to write some sophisticated adapters to leverage the Tomcat pre-built realms to the rest of the container. We should use JAAS and JACC if we need to cross utilize secuity between components. > Geronimo Realm provider for existing Tomcat Realm implementations > - > > Key: GERONIMO-320 > URL: http://issues.apache.org/jira/browse/GERONIMO-320 > Project: Geronimo > Type: Task > Components: Tomcat, security > Versions: 1.0-M3, 1.0-M4 > Reporter: David Blevins > Assignee: Alan Cabrera > Priority: Minor > Fix For: 1.0 > > Create an adapter to leverage Tomcat Realm implementations as RealmProviders > in the Geronimo security framework. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
On Aug 30, 2005, at 4:38 PM, Bruce Snyder wrote:
On 8/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
In Apache Geronino and dependencies like OpenEJB, (and probably other
projects at the ASF...) we are using an external project known as
'bouncycastle' (http://www.bouncycastle.org/) , a fairly well known
implementation of crypto-related stuff in Java.
Inside the distro jar from bouncycastle is an implementation of the
IDEA algorithm. This algorithm is patented, and the patent holder,
MediaCrypt, requires licenses for all implementations of IDEA, and
there's no unfettered use - even non-commercial distribution requires
some kind of correspondence with MediaCrypt.
http://www.mediacrypt.com/
You have to find the license section...
So, here's the problem - I don't believe either Geronimo or OpenEJB
is using the algorithm explicitly but I can't be sure that it isn't
invoked somewhere, and statements from the MediaCrypt site such as
"Requests by freeware developers to obtain a royalty-free license to
spread an application program containing the algorithm not for
commercial purposes must be directed to MediaCrypt"
make me believe that we have to do something to redistribute this
software.
(I can't help noting how the infinitive "to spread" makes the GPL's
language on "distribution" look clear.. :)
Of course, there are other terms for commercial users.
So, what should we do?
How about asking the Bouncy Castle people for some advice on what to
do? They're distributing the artifacts affected by these statements
from MediaCrypt, what do they recommend to their user base regarding
redistribution and use?
Good idea. Alternatively for our use, it looks like the directory
project has its own asn1 implementation. IIUC that is all we use in
the openejb corba code. Can we sidestep this problem by using the
directory's asn1 implementation?
david jencks
Bruce
--
perl -e 'print
unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
On 8/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> In Apache Geronino and dependencies like OpenEJB, (and probably other
> projects at the ASF...) we are using an external project known as
> 'bouncycastle' (http://www.bouncycastle.org/) , a fairly well known
> implementation of crypto-related stuff in Java.
>
> Inside the distro jar from bouncycastle is an implementation of the
> IDEA algorithm. This algorithm is patented, and the patent holder,
> MediaCrypt, requires licenses for all implementations of IDEA, and
> there's no unfettered use - even non-commercial distribution requires
> some kind of correspondence with MediaCrypt.
>
> http://www.mediacrypt.com/
>
> You have to find the license section...
>
> So, here's the problem - I don't believe either Geronimo or OpenEJB
> is using the algorithm explicitly but I can't be sure that it isn't
> invoked somewhere, and statements from the MediaCrypt site such as
>
> "Requests by freeware developers to obtain a royalty-free license to
> spread an application program containing the algorithm not for
> commercial purposes must be directed to MediaCrypt"
>
> make me believe that we have to do something to redistribute this
> software.
>
> (I can't help noting how the infinitive "to spread" makes the GPL's
> language on "distribution" look clear.. :)
>
> Of course, there are other terms for commercial users.
>
> So, what should we do?
How about asking the Bouncy Castle people for some advice on what to
do? They're distributing the artifacts affected by these statements
from MediaCrypt, what do they recommend to their user base regarding
redistribution and use?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: [discuss/poll] advertising policy
On 8/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> How do we want to handle these kinds of things, in general?
> [X] Ask that they vet these kinds of things through the Geronimo PMC
> via the [EMAIL PROTECTED] list
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: M5 List Closure - Time vs Features
Aaron Mulder wrote: On Tue, 30 Aug 2005, David Blevins wrote: Ok, this is just an attempt to get people to voice their expectations about the release in general, not in regards to any feature or item in the release. 1) If we could deliver M5 in _5_ weeks, I would consider that a complete success. 2) I would not like M5 to take more than _8_ weeks. Basis for calculation: I would like to release 1.0 by ApacheCon (mid-Decembmer, 15 weeks) if at all possible. I figure at most half them time between now and then should be spent on M5. But in truth, I'd like at least 1 more release between M5 and final. :) If for some reason we can't get 1.0 out by ApacheCon, I'd like to have a 1.0 bug-fix-only beta release & branch by then. In other words, a stable platform for documentation. No great secret there. :) You mean a release candidate? ;-) Aaron
Re: M5 List Closure - Time vs Features
On 8/30/05, David Blevins <[EMAIL PROTECTED]> wrote:
> 1) If we could deliver M5 in _2__ weeks, I would consider that a
> complete success.
>
> 2) I would not like M5 to take more than _3__ weeks.
I don't think that taking any longer than three weeks is necessary. We
don't need to fit everything into M5. We can have an M6 and M7 if
necessary. In fact, I'd rather see more drops with smaller
additions/changes than less drops with larger additions/changes.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: M5 List Closure - Time vs Features
On Tue, 30 Aug 2005, David Blevins wrote: > Ok, this is just an attempt to get people to voice their expectations > about the release in general, not in regards to any feature or item > in the release. > > 1) If we could deliver M5 in _5_ weeks, I would consider that a > complete success. > > 2) I would not like M5 to take more than _8_ weeks. Basis for calculation: I would like to release 1.0 by ApacheCon (mid-Decembmer, 15 weeks) if at all possible. I figure at most half them time between now and then should be spent on M5. But in truth, I'd like at least 1 more release between M5 and final. :) If for some reason we can't get 1.0 out by ApacheCon, I'd like to have a 1.0 bug-fix-only beta release & branch by then. In other words, a stable platform for documentation. No great secret there. :) Aaron
Re: M5 List Closure - Time vs Features
On Aug 30, 2005, at 2:05 PM, David Blevins wrote:
Ok, this is just an attempt to get people to voice their expectations
about the release in general, not in regards to any feature or item in
the release.
1) If we could deliver M5 in __2_ weeks, I would consider that a
complete success.
2) I would not like M5 to take more than __2_ weeks.
david ("overly optimistic") jencks
Re: M5 List Closure - Time vs Features
Thanks David. everyone please respond so we can close this up. Jeff David Blevins wrote: Ok, this is just an attempt to get people to voice their expectations about the release in general, not in regards to any feature or item in the release. 1) If we could deliver M5 in ___ weeks, I would consider that a complete success. 2) I would not like M5 to take more than ___ weeks.
Re: [jira] Created: (GERONIMO-952) Eliminate digester log output
On Tue, 30 Aug 2005, Jeff Genender wrote: > Is this a log4j configuration issue? Yeah, I think our server log configuration file just needs an appropriate entry. Sorry I wasn't clearer on that! I've just been bitten by, um, "certain products" in the past where the default logging configuration produced 10's or 100's of MB per day thanks to things like Digester. I figure we have a lot of log tuning to do, but that one jumps right out at me. :) Aaron > Aaron Mulder (JIRA) wrote: > > Eliminate digester log output > > - > > > > Key: GERONIMO-952 > > URL: http://issues.apache.org/jira/browse/GERONIMO-952 > > Project: Geronimo > > Type: Bug > > Components: Tomcat > > Versions: 1.0-M4 > > Reporter: Aaron Mulder > > Fix For: 1.0-M5 > > > > > > Digester produces a grotesque amount of log output, and the Tomcat > > configuration uses Digester. We need to specifically set the Digester > > level to INFO or WARN in our server log configuration file. > > >
Re: [jira] Created: (GERONIMO-952) Eliminate digester log output
Is this a log4j configuration issue? Jeff Aaron Mulder (JIRA) wrote: Eliminate digester log output - Key: GERONIMO-952 URL: http://issues.apache.org/jira/browse/GERONIMO-952 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0-M5 Digester produces a grotesque amount of log output, and the Tomcat configuration uses Digester. We need to specifically set the Digester level to INFO or WARN in our server log configuration file.
[jira] Created: (GERONIMO-956) Remove "global JNDI space"
Remove "global JNDI space" -- Key: GERONIMO-956 URL: http://issues.apache.org/jira/browse/GERONIMO-956 Project: Geronimo Type: Improvement Components: connector, naming Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0 Geronimo has a "global" JNDI space under "geronimo:". However: - it's only used by connectors, not EJBs - it's not visible outside the current VM It doesn't seem like this is really benefitting anyone. The effort necessary to make it behave like JNDI behaves in other popular app servers seems to be significant. After talking on IRC, David J and I are soliciting feedback on removing this feature entirely for now. Note: this is different than the JNDI space that OpenEJB uses to expose EJBs to remote clients, which takes EJBs only and is obviously accessible to remote clients. We are not proposing to change that at this time. -- 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-879) The console inclusion of a license for JDBM is obsolete.
[ http://issues.apache.org/jira/browse/GERONIMO-879?page=comments#action_12320634 ] Jeff Genender commented on GERONIMO-879: JDBM is required for the directory module. Do not remove. > The console inclusion of a license for JDBM is obsolete. > > > Key: GERONIMO-879 > URL: http://issues.apache.org/jira/browse/GERONIMO-879 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0-M5 > Environment: All. > Reporter: Rick McGuire > Priority: Minor > Fix For: 1.0 > Attachments: jdbm.diff > > The about jsp page for the console includes a license link for JDBM. The > JDBM component is no longer a Geronimo dependency, so this should be removed > and the accompanying JDBM_license.txt file removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (GERONIMO-879) The console inclusion of a license for JDBM is obsolete.
Done. Aaron Mulder wrote: Can you put that comment on the JIRA issue? I guess the question becomes, do we want the console to show all licenses for all products that Geronimo uses, or just the licenses for the products that the console itself requires. Aaron On Tue, 30 Aug 2005, Jeff Genender wrote: Do not remove the jar.. The JDBM *is* a Geronimo dependency now...Apache Directory needs it. Aaron Mulder (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-879?page=all ] Aaron Mulder updated GERONIMO-879: -- Fix Version: 1.0 Currently the Geronimo repository does include JDBM: repository/jdbm/jars/jdbm-0.20-dev.jar We should probably remove the JAR and ensure it doesn't cause problems before removing the license. Do you know what JDBM was used for? The console inclusion of a license for JDBM is obsolete. Key: GERONIMO-879 URL: http://issues.apache.org/jira/browse/GERONIMO-879 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Environment: All. Reporter: Rick McGuire Priority: Minor Fix For: 1.0 Attachments: jdbm.diff The about jsp page for the console includes a license link for JDBM. The JDBM component is no longer a Geronimo dependency, so this should be removed and the accompanying JDBM_license.txt file removed.
Re: [jira] Updated: (GERONIMO-879) The console inclusion of a license for JDBM is obsolete.
Can you put that comment on the JIRA issue? I guess the question becomes, do we want the console to show all licenses for all products that Geronimo uses, or just the licenses for the products that the console itself requires. Aaron On Tue, 30 Aug 2005, Jeff Genender wrote: > Do not remove the jar.. > > The JDBM *is* a Geronimo dependency now...Apache Directory needs it. > > > > Aaron Mulder (JIRA) wrote: > > [ http://issues.apache.org/jira/browse/GERONIMO-879?page=all ] > > > > Aaron Mulder updated GERONIMO-879: > > -- > > > > Fix Version: 1.0 > > > > Currently the Geronimo repository does include JDBM: > > > > repository/jdbm/jars/jdbm-0.20-dev.jar > > > > We should probably remove the JAR and ensure it doesn't cause problems > > before removing the license. Do you know what JDBM was used for? > > > > > > > >>The console inclusion of a license for JDBM is obsolete. > >> > >> > >> Key: GERONIMO-879 > >> URL: http://issues.apache.org/jira/browse/GERONIMO-879 > >> Project: Geronimo > >>Type: Bug > >> Components: console > >>Versions: 1.0-M5 > >> Environment: All. > >>Reporter: Rick McGuire > >>Priority: Minor > >> Fix For: 1.0 > >> Attachments: jdbm.diff > >> > >>The about jsp page for the console includes a license link for JDBM. The > >>JDBM component is no longer a Geronimo dependency, so this should be > >>removed and the accompanying JDBM_license.txt file removed. > > > > >
Re: [jira] Updated: (GERONIMO-879) The console inclusion of a license for JDBM is obsolete.
Do not remove the jar.. The JDBM *is* a Geronimo dependency now...Apache Directory needs it. Aaron Mulder (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-879?page=all ] Aaron Mulder updated GERONIMO-879: -- Fix Version: 1.0 Currently the Geronimo repository does include JDBM: repository/jdbm/jars/jdbm-0.20-dev.jar We should probably remove the JAR and ensure it doesn't cause problems before removing the license. Do you know what JDBM was used for? The console inclusion of a license for JDBM is obsolete. Key: GERONIMO-879 URL: http://issues.apache.org/jira/browse/GERONIMO-879 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Environment: All. Reporter: Rick McGuire Priority: Minor Fix For: 1.0 Attachments: jdbm.diff The about jsp page for the console includes a license link for JDBM. The JDBM component is no longer a Geronimo dependency, so this should be removed and the accompanying JDBM_license.txt file removed.
[jira] Created: (GERONIMO-955) Provide separate client container distribution
Provide separate client container distribution -- Key: GERONIMO-955 URL: http://issues.apache.org/jira/browse/GERONIMO-955 Project: Geronimo Type: Improvement Components: application client Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0 It would be ideal if you could install a "client container only" which required less than the full 50+ MB of a Geronimo server. This would of course be for situations where the client was running on a different machine than the server, or where the user running the client app didn't have necessary file permissions on the server installation directory (e.g. to write a client log file). Perhaps one of the assemblies/ modules could do this; the trick will be to not include the JARs (in the repository, etc.) that aren't needed by the client container. -- 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-953) Exception calling getAvailableModules() on deployment manager
[ http://issues.apache.org/jira/browse/GERONIMO-953?page=all ] Aaron Mulder closed GERONIMO-953: - Resolution: Invalid Problem caused by stale JARs in a plugin lib directory; closing at Sachin's request. > Exception calling getAvailableModules() on deployment manager > - > > Key: GERONIMO-953 > URL: http://issues.apache.org/jira/browse/GERONIMO-953 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M5 > Reporter: Sachin Patel > Priority: Blocker > Fix For: 1.0-M5 > > I'm getting the following exception when calling getAvailableModules() on the > deployment manager. > java.rmi.UnmarshalException: error unmarshalling return; nested exception is: > java.io.InvalidClassException: > org.apache.geronimo.kernel.config.ConfigurationModuleType; local class > incompatible: stream classdesc serialVersionUID = -4121586344416418391, local > class serialVersionUID = 6296527685792707191 > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:180) > at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown > Source) > at mx4j.remote.rmi.ClientInvoker.invoke(ClientInvoker.java:207) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:62) > at java.lang.reflect.Method.invoke(Method.java:391) > at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) > at mx4j.remote.rmi.ClientUnmarshaller.chain(ClientUnmarshaller.java:65) > at mx4j.remote.rmi.ClientUnmarshaller.invoke(ClientUnmarshaller.java:54) > at $Proxy0.invoke(Unknown Source) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:62) > at java.lang.reflect.Method.invoke(Method.java:391) > at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) > at > mx4j.remote.rmi.ClientExceptionCatcher.invoke(ClientExceptionCatcher.java:40) > at $Proxy0.invoke(Unknown Source) > at > org.apache.geronimo.kernel.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:335) > at > org.apache.geronimo.kernel.jmx.KernelDelegate.invoke(KernelDelegate.java:180) > at > org.apache.geronimo.kernel.basic.KernelOperationInvoker.invoke(KernelOperationInvoker.java:46) > at > org.apache.geronimo.kernel.jmx.JMXProxyMethodInterceptor.intercept(JMXProxyMethodInterceptor.java:90) > at > org.apache.geronimo.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$7d33ec65.listConfigurations() > at > org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getModules(JMXDeploymentManager.java:150) > at > org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getAvailableModules(JMXDeploymentManager.java:115) > at > org.apache.geronimo.core.internal.GeronimoServerBehaviour.getTargetModuleID(GeronimoServerBehaviour.java:447) > at > org.apache.geronimo.core.internal.GeronimoServerBehaviour.doReploy(GeronimoServerBehaviour.java:409) > at > org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:359) > at > org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:267) > at > org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:633) > at > org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:686) > at > org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:587) > at > org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:705) > at org.eclipse.wst.server.core.internal.Server.publish(Server.java:692) > at > org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) > Caused by: java.io.InvalidClassException: > org.apache.geronimo.kernel.config.ConfigurationModuleType; local class > incompatible: stream classdesc serialVersionUID = -4121586344416418391, local > class serialVersionUID = 6296527685792707191 > at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:591) > at > java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1554) > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1468) > at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1659) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1307) > at > java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1877) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1801
[jira] Created: (GERONIMO-954) Assembly doesn't clean itself every time
Assembly doesn't clean itself every time Key: GERONIMO-954 URL: http://issues.apache.org/jira/browse/GERONIMO-954 Project: Geronimo Type: Bug Components: buildsystem Versions: 1.0-M5 Reporter: Aaron Mulder Assigned to: Dain Sundstrom Priority: Critical Fix For: 1.0-M5 Previously, every time you built the assembly module it deleted the target/ directory first. After the most recent changes, it does not do that any more. I think it was better before. Now you can end up with things like a stale catalina directory and multiple copies of each entry in the config-store, which all make their way into the output ZIP. -- 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-879) The console inclusion of a license for JDBM is obsolete.
[ http://issues.apache.org/jira/browse/GERONIMO-879?page=all ] Aaron Mulder updated GERONIMO-879: -- Fix Version: 1.0 Currently the Geronimo repository does include JDBM: repository/jdbm/jars/jdbm-0.20-dev.jar We should probably remove the JAR and ensure it doesn't cause problems before removing the license. Do you know what JDBM was used for? > The console inclusion of a license for JDBM is obsolete. > > > Key: GERONIMO-879 > URL: http://issues.apache.org/jira/browse/GERONIMO-879 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0-M5 > Environment: All. > Reporter: Rick McGuire > Priority: Minor > Fix For: 1.0 > Attachments: jdbm.diff > > The about jsp page for the console includes a license link for JDBM. The > JDBM component is no longer a Geronimo dependency, so this should be removed > and the accompanying JDBM_license.txt file removed. -- 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-656) Invalid Login in deployer should not print the stack trace
[ http://issues.apache.org/jira/browse/GERONIMO-656?page=all ] Aaron Mulder closed GERONIMO-656: - Fix Version: 1.0-M5 Resolution: Cannot Reproduce Appears to have been fixed previously. Current output is: Error: Login Failed > Invalid Login in deployer should not print the stack trace > -- > > Key: GERONIMO-656 > URL: http://issues.apache.org/jira/browse/GERONIMO-656 > Project: Geronimo > Type: Bug > Versions: 1.0-M4 > Environment: All environments > Reporter: anita kulshreshtha > Priority: Trivial > Fix For: 1.0-M5 > > The deployer should not print out the following stack trace for invalid > logins caused by null/bad Username/Password. Just an invalid login message > should be enough. > Username: > Password: > Error: Unable to connect to server > org.apache.geronimo.deployment.plugin.factories.AuthenticationFailedException: > Invalid login. > at > org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl.getDeploymentManager(DeploymentFactoryI > mpl.java:87) > at > javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManag > er.java:109) > at > org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:182) > at > org.apache.geronimo.deployment.cli.ServerConnection.doAuthPromptAndRetry(ServerConnection.java:238) > at > org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:185) > at > org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:147) > at > org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:111) > at > org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:254) > Caused by: java.lang.SecurityException: Invalid login > at > org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:61) > at javax.management.remote.rmi.RMIServerImpl.newClient(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) > at sun.rmi.transport.Transport$1.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Unknown Source) > at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown > Source) > at java.lang.Thread.run(Unknown Source) > at > sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Unknown Source) > at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source) > at sun.rmi.server.UnicastRef.invoke(Unknown Source) > at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown > Source) > at javax.management.remote.rmi.RMIConnector.getConnection(Unknown > Source) > at javax.management.remote.rmi.RMIConnector.connect(Unknown Source) > at javax.management.remote.JMXConnectorFactory.connect(Unknown Source) > at > org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl.getDeploymentManager(DeploymentFactoryI > mpl.java:81) > ... 7 more -- 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-904) Upgrade from commons-jelly-1.0-beta-4 to released 1.0 level
[ http://issues.apache.org/jira/browse/GERONIMO-904?page=all ] Aaron Mulder closed GERONIMO-904: - Fix Version: 1.0-M5 Resolution: Fixed > Upgrade from commons-jelly-1.0-beta-4 to released 1.0 level > --- > > Key: GERONIMO-904 > URL: http://issues.apache.org/jira/browse/GERONIMO-904 > Project: Geronimo > Type: Bug > Components: buildsystem > Versions: 1.0-M5 > Environment: all > Reporter: Donald Woods > Priority: Minor > Fix For: 1.0-M5 > > Upgrade to the released commons-jelly version, which is 1.0 from 6/16/05 and > is available to maven on ibiblio - > http://www.ibiblio.org/maven/commons-jelly/jars/commons-jelly-1.0.jar > The following files need to be updated to use the released version - > etc\project.properties >commons_jelly_version=1.0-beta-4 --> 1.0 > openejb\etc\project.properties >commons_jelly_version=1.0-beta-4 --> 1.0 > plugins/maven-xpom-plugin/project.xml >commons-jelly-1.0-beta-4 --> 1.0 -- 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: Assembly Deployment Speed
On Aug 30, 2005, at 2:48 PM, Aaron Mulder wrote: On Tue, 30 Aug 2005, David Jencks wrote: dain made as many as possible of the deployments done online and with the maven plugin rather than with the deployer.jar Is that faster just because it doesn't start a new VM for every deployment? AFAIK yes. There might be other missing overhead, but I don't know what it would be. david jencks Aaron On Aug 30, 2005, at 2:39 PM, Aaron Mulder wrote: I just ran the assembly module, and the phase where it deploys a bunch of modules to a running server went tremendously fast -- actually the whole assembly module is a lot faster, even with the new checksum calculations. Wow! What was changed? Aaron
Re: Assembly Deployment Speed
On Tue, 30 Aug 2005, David Jencks wrote: > dain made as many as possible of the deployments done online and with > the maven plugin rather than with the deployer.jar Is that faster just because it doesn't start a new VM for every deployment? Aaron > On Aug 30, 2005, at 2:39 PM, Aaron Mulder wrote: > > > I just ran the assembly module, and the phase where it deploys > > a bunch of modules to a running server went tremendously fast -- > > actually > > the whole assembly module is a lot faster, even with the new checksum > > calculations. Wow! What was changed? > > > > Aaron > > > >
Re: M5 List Closure - GBeanName
On Aug 30, 2005, at 2:20 PM, David Blevins wrote: On Aug 30, 2005, at 2:17 PM, Aaron Mulder wrote: On Tue, 30 Aug 2005, David Blevins wrote: I think the full conversion of "all ObjectNames to GBeanNames and all queries to GBeanQuery's" can wait for post-M5. Ok, you're confusing me. The message "post-M5" is exactly where I thought that conversation ended up. What part shouldn't wait for post-M5? This part: Uh, no. I think we should make GBeanName satisfactory, and put all the plumbing into GBeanQuery to support the queries we want and deprecate the kernel ObjectName query methods. Ok, so what we need consensus on is whether we should for M5: 1) Complete GBeanName support and officially deprecate ObjectName use and convert fully post-M5. I'd prefer this if possible. 2) Wait till post-M5 and do all at once. this would be my second choice. david jencks
Re: Assembly Deployment Speed
dain made as many as possible of the deployments done online and with the maven plugin rather than with the deployer.jar david jencks On Aug 30, 2005, at 2:39 PM, Aaron Mulder wrote: I just ran the assembly module, and the phase where it deploys a bunch of modules to a running server went tremendously fast -- actually the whole assembly module is a lot faster, even with the new checksum calculations. Wow! What was changed? Aaron
[jira] Updated: (GERONIMO-953) Exception calling getAvailableModules() on deployment manager
[ http://issues.apache.org/jira/browse/GERONIMO-953?page=all ] Aaron Mulder updated GERONIMO-953: -- Fix Version: 1.0-M5 > Exception calling getAvailableModules() on deployment manager > - > > Key: GERONIMO-953 > URL: http://issues.apache.org/jira/browse/GERONIMO-953 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M5 > Reporter: Sachin Patel > Priority: Blocker > Fix For: 1.0-M5 > > I'm getting the following exception when calling getAvailableModules() on the > deployment manager. > java.rmi.UnmarshalException: error unmarshalling return; nested exception is: > java.io.InvalidClassException: > org.apache.geronimo.kernel.config.ConfigurationModuleType; local class > incompatible: stream classdesc serialVersionUID = -4121586344416418391, local > class serialVersionUID = 6296527685792707191 > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:180) > at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown > Source) > at mx4j.remote.rmi.ClientInvoker.invoke(ClientInvoker.java:207) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:62) > at java.lang.reflect.Method.invoke(Method.java:391) > at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) > at mx4j.remote.rmi.ClientUnmarshaller.chain(ClientUnmarshaller.java:65) > at mx4j.remote.rmi.ClientUnmarshaller.invoke(ClientUnmarshaller.java:54) > at $Proxy0.invoke(Unknown Source) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:62) > at java.lang.reflect.Method.invoke(Method.java:391) > at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) > at > mx4j.remote.rmi.ClientExceptionCatcher.invoke(ClientExceptionCatcher.java:40) > at $Proxy0.invoke(Unknown Source) > at > org.apache.geronimo.kernel.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:335) > at > org.apache.geronimo.kernel.jmx.KernelDelegate.invoke(KernelDelegate.java:180) > at > org.apache.geronimo.kernel.basic.KernelOperationInvoker.invoke(KernelOperationInvoker.java:46) > at > org.apache.geronimo.kernel.jmx.JMXProxyMethodInterceptor.intercept(JMXProxyMethodInterceptor.java:90) > at > org.apache.geronimo.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$7d33ec65.listConfigurations() > at > org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getModules(JMXDeploymentManager.java:150) > at > org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getAvailableModules(JMXDeploymentManager.java:115) > at > org.apache.geronimo.core.internal.GeronimoServerBehaviour.getTargetModuleID(GeronimoServerBehaviour.java:447) > at > org.apache.geronimo.core.internal.GeronimoServerBehaviour.doReploy(GeronimoServerBehaviour.java:409) > at > org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:359) > at > org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:267) > at > org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:633) > at > org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:686) > at > org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:587) > at > org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:705) > at org.eclipse.wst.server.core.internal.Server.publish(Server.java:692) > at > org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) > Caused by: java.io.InvalidClassException: > org.apache.geronimo.kernel.config.ConfigurationModuleType; local class > incompatible: stream classdesc serialVersionUID = -4121586344416418391, local > class serialVersionUID = 6296527685792707191 > at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:591) > at > java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1554) > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1468) > at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1659) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1307) > at > java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1877) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1801) > at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1679)
Assembly Deployment Speed
I just ran the assembly module, and the phase where it deploys a bunch of modules to a running server went tremendously fast -- actually the whole assembly module is a lot faster, even with the new checksum calculations. Wow! What was changed? Aaron
Re: M5 List Closure - GBeanName
On Aug 30, 2005, at 2:17 PM, Aaron Mulder wrote: On Tue, 30 Aug 2005, David Blevins wrote: I think the full conversion of "all ObjectNames to GBeanNames and all queries to GBeanQuery's" can wait for post-M5. Ok, you're confusing me. The message "post-M5" is exactly where I thought that conversation ended up. What part shouldn't wait for post-M5? This part: Uh, no. I think we should make GBeanName satisfactory, and put all the plumbing into GBeanQuery to support the queries we want and deprecate the kernel ObjectName query methods. Ok, so what we need consensus on is whether we should for M5: 1) Complete GBeanName support and officially deprecate ObjectName use and convert fully post-M5. 2) Wait till post-M5 and do all at once.
[jira] Updated: (GERONIMO-903) Update Log4J usage from 1.2.8 to latest maintenance version of 1.2.11
[ http://issues.apache.org/jira/browse/GERONIMO-903?page=all ] Aaron Mulder updated GERONIMO-903: -- Fix Version: 1.0 > Update Log4J usage from 1.2.8 to latest maintenance version of 1.2.11 > - > > Key: GERONIMO-903 > URL: http://issues.apache.org/jira/browse/GERONIMO-903 > Project: Geronimo > Type: Improvement > Components: common > Versions: 1.0-M5 > Environment: All > Reporter: Donald Woods > Priority: Trivial > Fix For: 1.0 > > Upgrade to the latest log4j maintenance version, which is 1.2.11and is > available to maven on ibiblio - > http://www.ibiblio.org/maven/log4j/jars/log4j-1.2.11.jar > Updates required in project.properties for Geronimo and OpenEJB and any > project.xml which is currently hardcoded to use log4j-1.2.8 -- 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: M5 List Closure - Time vs Features
Ok, this is just an attempt to get people to voice their expectations about the release in general, not in regards to any feature or item in the release. 1) If we could deliver M5 in ___ weeks, I would consider that a complete success. 2) I would not like M5 to take more than ___ weeks.
[jira] Updated: (GERONIMO-615) RMIClassLoaderSpiImpl.normalizeCodebase(..) generates MalformedURLExceptions unnecessarily
[ http://issues.apache.org/jira/browse/GERONIMO-615?page=all ] Aaron Mulder updated GERONIMO-615: -- Fix Version: 1.0-M5 Description: org.apache.geronimo.system.rmi.RMIClassLoaderSpiImpl.normalizeCodebase(..) unnecessarily causes MalformedURLExceptions to be generated and caught. The exceptions are due to the delimiter tokens (e.g. a space character) being passed to the URL constructor. This occurs because "true" flag being passed on the call to the StringTokenizer constructor in the body of the normalizeCodebase method(..). In my debug session, in one invocation of normalizeCodebase(..), over 40 MalformedURLExceptions were generated. was: org.apache.geronimo.system.rmi.RMIClassLoaderSpiImpl.normalizeCodebase(..) unnecessarily causes MalformedURLExceptions to be generated and caught. The exceptions are due to the delimiter tokens (e.g. a space character) being passed to the URL constructor. This occurs because "true" flag being passed on the call to the StringTokenizer constructor in the body of the normalizeCodebase method(..). In my debug session, in one invocation of normalizeCodebase(..), over 40 MalformedURLExceptions were generated. Environment: > RMIClassLoaderSpiImpl.normalizeCodebase(..) generates MalformedURLExceptions > unnecessarily > -- > > Key: GERONIMO-615 > URL: http://issues.apache.org/jira/browse/GERONIMO-615 > Project: Geronimo > Type: Bug > Reporter: John Sisson > Assignee: John Sisson > Priority: Trivial > Fix For: 1.0-M5 > Attachments: RMIClassLoaderSpiImpl_patch.txt > > org.apache.geronimo.system.rmi.RMIClassLoaderSpiImpl.normalizeCodebase(..) > unnecessarily causes MalformedURLExceptions to be generated and caught. > The exceptions are due to the delimiter tokens (e.g. a space character) being > passed to the URL constructor. > This occurs because "true" flag being passed on the call to the > StringTokenizer constructor in the body of the normalizeCodebase method(..). > In my debug session, in one invocation of normalizeCodebase(..), over 40 > MalformedURLExceptions were generated. -- 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-641) Compile fails using forked compiler when directory contains spaces
[ http://issues.apache.org/jira/browse/GERONIMO-641?page=all ]
Aaron Mulder updated GERONIMO-641:
--
Fix Version: 1.0-M5
Description:
Using forked compiler in causes compile to fail. The following is
encountered during the build of j2ee-builder/maven.xml.
/***
setupEar:
[javac] Compiling 20 source files to C:\Documents and Settings\Geronimo
Team\My
Documents\test\geronimo\modules\j2ee-builder\target\test-ear14\test-ejb-jar
[javac] javac: invalid flag: C:\Documents
[javac] Usage: javac
*/
The maven file:
Comment by Brett Porter [07/May/04 08:54 PM]
looks like we need to wait for the Ant upgrade in future versions of Maven
This is an issue with maven. See http://jira.codehaus.org/browse/MPJAVA-4
was:
Using forked compiler in causes compile to fail. The following is
encountered during the build of j2ee-builder/maven.xml.
/***
setupEar:
[javac] Compiling 20 source files to C:\Documents and Settings\Geronimo
Team\My
Documents\test\geronimo\modules\j2ee-builder\target\test-ear14\test-ejb-jar
[javac] javac: invalid flag: C:\Documents
[javac] Usage: javac
*/
The maven file:
Comment by Brett Porter [07/May/04 08:54 PM]
looks like we need to wait for the Ant upgrade in future versions of Maven
This is an issue with maven. See http://jira.codehaus.org/browse/MPJAVA-4
Can someone with a Windows machine check whether our build fails if the source
directory has spaces in the name? If not, I think this issue should be closed.
Thanks.
> Compile fails using forked compiler when directory contains spaces
> --
>
> Key: GERONIMO-641
> URL: http://issues.apache.org/jira/browse/GERONIMO-641
> Project: Geronimo
> Type: Task
> Components: buildsystem
> Versions: 1.0-M3
> Environment: Windoze, but generic env applies
> Reporter: Waimun Yeow
> Priority: Trivial
> Fix For: 1.0-M5
>
> Using forked compiler in causes compile to fail. The following is
> encountered during the build of j2ee-builder/maven.xml.
> /***
> setupEar:
> [javac] Compiling 20 source files to C:\Documents and Settings\Geronimo
> Team\My
> Documents\test\geronimo\modules\j2ee-builder\target\test-ear14\test-ejb-jar
> [javac] javac: invalid flag: C:\Documents
> [javac] Usage: javac
> */
> The maven file:
> destdir="${ear.target.base.dir}/test-ejb-jar"
> source="${maven.compile.source}"
> target="${maven.compile.target}"
> debug="on"
> fork="true">
>
> Comment by Brett Porter [07/May/04 08:54 PM]
> looks like we need to wait for the Ant upgrade in future versions of Maven
> This is an issue with maven. See http://jira.codehaus.org/browse/MPJAVA-4
--
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-936) Reconfigure plugin .classpath to follow Maven convention
[ http://issues.apache.org/jira/browse/GERONIMO-936?page=all ] Aaron Mulder updated GERONIMO-936: -- Fix Version: 1.0 > Reconfigure plugin .classpath to follow Maven convention > > > Key: GERONIMO-936 > URL: http://issues.apache.org/jira/browse/GERONIMO-936 > Project: Geronimo > Type: Bug > Components: eclipse-plugin > Versions: 1.0-M5 > Reporter: Sachin Patel > Priority: Minor > Fix For: 1.0 > Attachments: patch.txt > > Each plugin .classpath file should be reconfigured to follow Maven > conventions with output in target/classes. This will keep and use the same > output folder when building with Maven or within Eclipse IDE. -- 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-629) Misleading error when ra.xml is included in the RAR jar as well as the RAR
[ http://issues.apache.org/jira/browse/GERONIMO-629?page=all ] Aaron Mulder updated GERONIMO-629: -- Fix Version: 1.0 Description: If someone accidentlly builds a jar with the ra.xml included and then includes that jar in a rar and tries to deploy it, the following error occurs - Caused by: java.lang.ClassFormatError: Repetitive interface name in class file org/mule/ra/MuleConnectionFactory$$Enhanc erByCGLIB$$3a4c63ea at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) ... 64 more While the ra.xml should not be in the jar in the first place, a more meaningful error could be given. was: If someone accidentlly builds a jar with the ra.xml included and then includes that jar in a rar and tries to deploy it, the following error occurs - Caused by: java.lang.ClassFormatError: Repetitive interface name in class file org/mule/ra/MuleConnectionFactory$$Enhanc erByCGLIB$$3a4c63ea at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) ... 64 more While the ra.xml should not be in the jar in the first place, a more meaningful error could be given. Environment: > Misleading error when ra.xml is included in the RAR jar as well as the RAR > -- > > Key: GERONIMO-629 > URL: http://issues.apache.org/jira/browse/GERONIMO-629 > Project: Geronimo > Type: Bug > Components: connector > Versions: 1.0-M3 > Reporter: Ross Mason > Assignee: David Jencks > Priority: Minor > Fix For: 1.0 > > If someone accidentlly builds a jar with the ra.xml included and then > includes that jar in a rar and tries to deploy it, the following error occurs > - > Caused by: java.lang.ClassFormatError: Repetitive interface name in class > file org/mule/ra/MuleConnectionFactory$$Enhanc > erByCGLIB$$3a4c63ea > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(Unknown Source) > ... 64 more > > While the ra.xml should not be in the jar in the first place, a more > meaningful error could be given. -- 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: M5 List Closure - GBeanName
On Tue, 30 Aug 2005, David Blevins wrote: > > > > I think the full conversion of "all ObjectNames to GBeanNames and > > all queries to GBeanQuery's" can wait for post-M5. > > Ok, you're confusing me. The message "post-M5" is exactly where I > thought that conversation ended up. What part shouldn't wait for > post-M5? This part: > Uh, no. I think we should make GBeanName satisfactory, and put > all the plumbing into GBeanQuery to support the queries we want and > deprecate the kernel ObjectName query methods. Aaron
Re: M5 List Closure - GBeanName
On Aug 30, 2005, at 2:05 PM, Aaron Mulder wrote: On Tue, 30 Aug 2005, David Blevins wrote: It seems this fizzled out into a partial agreement that this was too big for this release. Is this ok with everyone? Uh, no. I think we should make GBeanName satisfactory, and put all the plumbing into GBeanQuery to support the queries we want and deprecate the kernel ObjectName query methods. I think the full conversion of "all ObjectNames to GBeanNames and all queries to GBeanQuery's" can wait for post-M5. Ok, you're confusing me. The message "post-M5" is exactly where I thought that conversation ended up. What part shouldn't wait for post-M5? -David
[jira] Updated: (GERONIMO-898) [PATCH] Remove multiple circular dependencies in GBeanInstance thru interfaces
[ http://issues.apache.org/jira/browse/GERONIMO-898?page=all ] Aaron Mulder updated GERONIMO-898: -- Fix Version: Wish List Why is this relevant? It doesn't seem like making GBeanInstance an interface is advantageous as far as the code or architecture goes. Is there some IDE that can't compile it? > [PATCH] Remove multiple circular dependencies in GBeanInstance thru interfaces > -- > > Key: GERONIMO-898 > URL: http://issues.apache.org/jira/browse/GERONIMO-898 > Project: Geronimo > Type: Improvement > Components: kernel > Versions: 1.0-M4 > Reporter: Dave Brosius > Priority: Minor > Fix For: Wish List > Attachments: GBeanInstanceImpl.java, GBeanInstance_nocd.diff, > GBeanRuntimeInstance.java > > GBeanInstance has several circular build dependencies with other classes. > This patch fixes this by promoting GBeanInstance to an interface, and > reworking the references. -- 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: M5 List Closure - J2EE Certification
On Aug 30, 2005, at 1:17 PM, Geir Magnusson Jr. wrote: 2) what is the ideal timeframe for completing that (in weeks, don't say soon). I'll try to do the research re what is involved beyond the automated test suite. Great. We can make a list of steps required and factor it in. I phrased the question badly, though, sorry. My response to Aaron clarifies. -David
Re: M5 List Closure - GBeanName
On Tue, 30 Aug 2005, David Blevins wrote: > It seems this fizzled out into a partial agreement that this was too > big for this release. > > Is this ok with everyone? Uh, no. I think we should make GBeanName satisfactory, and put all the plumbing into GBeanQuery to support the queries we want and deprecate the kernel ObjectName query methods. I think the full conversion of "all ObjectNames to GBeanNames and all queries to GBeanQuery's" can wait for post-M5. Aaron
[jira] Created: (GERONIMO-953) Exception calling getAvailableModules() on deployment manager
Exception calling getAvailableModules() on deployment manager - Key: GERONIMO-953 URL: http://issues.apache.org/jira/browse/GERONIMO-953 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M5 Reporter: Sachin Patel Priority: Blocker I'm getting the following exception when calling getAvailableModules() on the deployment manager. java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.io.InvalidClassException: org.apache.geronimo.kernel.config.ConfigurationModuleType; local class incompatible: stream classdesc serialVersionUID = -4121586344416418391, local class serialVersionUID = 6296527685792707191 at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:180) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at mx4j.remote.rmi.ClientInvoker.invoke(ClientInvoker.java:207) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:62) at java.lang.reflect.Method.invoke(Method.java:391) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientUnmarshaller.chain(ClientUnmarshaller.java:65) at mx4j.remote.rmi.ClientUnmarshaller.invoke(ClientUnmarshaller.java:54) at $Proxy0.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:62) at java.lang.reflect.Method.invoke(Method.java:391) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientExceptionCatcher.invoke(ClientExceptionCatcher.java:40) at $Proxy0.invoke(Unknown Source) at org.apache.geronimo.kernel.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:335) at org.apache.geronimo.kernel.jmx.KernelDelegate.invoke(KernelDelegate.java:180) at org.apache.geronimo.kernel.basic.KernelOperationInvoker.invoke(KernelOperationInvoker.java:46) at org.apache.geronimo.kernel.jmx.JMXProxyMethodInterceptor.intercept(JMXProxyMethodInterceptor.java:90) at org.apache.geronimo.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$7d33ec65.listConfigurations() at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getModules(JMXDeploymentManager.java:150) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getAvailableModules(JMXDeploymentManager.java:115) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.getTargetModuleID(GeronimoServerBehaviour.java:447) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doReploy(GeronimoServerBehaviour.java:409) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:359) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:267) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:633) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:686) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:587) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:705) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:692) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) Caused by: java.io.InvalidClassException: org.apache.geronimo.kernel.config.ConfigurationModuleType; local class incompatible: stream classdesc serialVersionUID = -4121586344416418391, local class serialVersionUID = 6296527685792707191 at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:591) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1554) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1468) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1659) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1307) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1877) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1801) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1679) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1307) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:357) at java.util.ArrayList.readObject(ArrayList.java:581) at sun.reflect.NativeMethodAccessorImpl.invoke0(Na
[jira] Updated: (GERONIMO-693) Need startup scripts in bin directory
[ http://issues.apache.org/jira/browse/GERONIMO-693?page=all ] Aaron Mulder updated GERONIMO-693: -- Fix Version: 1.0 Version: 1.0-M4 > Need startup scripts in bin directory > - > > Key: GERONIMO-693 > URL: http://issues.apache.org/jira/browse/GERONIMO-693 > Project: Geronimo > Type: New Feature > Components: usability > Versions: 1.0-M4 > Environment: Windows, Linux, Mac OS X > Reporter: Erin Mulder > Assignee: John Sisson > Priority: Minor > Fix For: 1.0 > Attachments: wrapper.tar.gz > > It would be nice to have obvious startup.sh and startup.bat scripts in the > bin directory so that the user doesn't need to look at the README file to > figure out how to start the server. (java -jar bin/server.jar isn't hard -- > it's just not quite as brainless as a script called "startup"). -- 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-948) Need reference counting on load/start of configurations
[ http://issues.apache.org/jira/browse/GERONIMO-948?page=all ] David Jencks updated GERONIMO-948: -- Fix Version: Wish List (was: 1.0-M5) This is too hard and will require a lot of thought. Implementing unloadRecursive, startRecursive, stopRecursive in ConfigurationManager is easy, but figuring out what should happen if someone calls unloadRecursive on a configuration that is in use by other configurations or is started or calling unloadRecursive twice is going to take a lot of thought. > Need reference counting on load/start of configurations > --- > > Key: GERONIMO-948 > URL: http://issues.apache.org/jira/browse/GERONIMO-948 > Project: Geronimo > Type: Bug > Components: kernel > Versions: 1.0-M5 > Reporter: David Jencks > Assignee: David Jencks > Fix For: Wish List > > When you load/start a configuration, it loads and starts its ancestors and > keeps track of what it loaded and what it started, and undoes this when you > stop/unload it. This will create big problems if you > load A > load B (with a common parent) > unload A (unloading common parent of B) > unload B > Solution appears to be to count how many descendants use a config and only > stop/unload if count reaches 0. Code to do this should probably be in the > ConfigurationManager. -- 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: M5 List Closure - GBeanName
On Aug 27, 2005, at 11:41 AM, Aaron Mulder wrote: How about a must have to implement GBeanName according to the previous notes on the mailing list? On Aug 27, 2005, at 11:36 AM, Dain Sundstrom wrote: Does this include modifying all code to use GBeanName instead of object name? [] Finally, we have not addressed ObjectName queries, which are a required component of the framework and are used through the code base. [] On Aug 27, 2005, at 1:48 PM, Dain Sundstrom wrote: We use ObjectName pattern queries. If we eliminate ObjectNames, what will we use for queries? On Aug 27, 2005, at 2:11 PM, Aaron Mulder wrote: Interfaces and GBean Name components. I imagine, for example, the GBeanQuery would take a String (interface name) and/or a Map (key=value pairs to query on). I guess the domain too. Jeremy mentioned wanting to support a "query language", which among other things would let you specify ands and ors and so on, but I don't think that needs to be in the first release. It seems this fizzled out into a partial agreement that this was too big for this release. Is this ok with everyone? -David
[jira] Updated: (GERONIMO-271) PetStore deployment
[ http://issues.apache.org/jira/browse/GERONIMO-271?page=all ] Aaron Mulder updated GERONIMO-271: -- Component: sample apps Fix Version: 1.0 Description: It's finally the time to see PetStore running on Geronimo. This task is to track the progress. Instruction available at http://wiki.apache.org/geronimo/PetStore (was: It's finally the time to see PetStore running on Geronimo. This task is to track the progress. Instruction available at http://wiki.apache.org/geronimo/PetStore) Version: 1.0-M4 Environment: > PetStore deployment > --- > > Key: GERONIMO-271 > URL: http://issues.apache.org/jira/browse/GERONIMO-271 > Project: Geronimo > Type: Task > Components: sample apps > Versions: 1.0-M4 > Reporter: Jacek Laskowski > Assignee: Jacek Laskowski > Priority: Minor > Fix For: 1.0 > > It's finally the time to see PetStore running on Geronimo. This task is to > track the progress. Instruction available at > http://wiki.apache.org/geronimo/PetStore -- 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-829) undeploy of components leaves web-inf\lib directory and jars in config-store
[ http://issues.apache.org/jira/browse/GERONIMO-829?page=all ] Aaron Mulder updated GERONIMO-829: -- Fix Version: 1.0 > undeploy of components leaves web-inf\lib directory and jars in config-store > > > Key: GERONIMO-829 > URL: http://issues.apache.org/jira/browse/GERONIMO-829 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4 > Environment: windows xp > Reporter: Joe Bohn > Priority: Minor > Fix For: 1.0 > > Deploy a component, undeploy the component. The config-store\##\WEB-INF\lib > is ever deleted. Repeatedly deploying and undeploying a component (as I > think happens with an upgrade as well) causes an ever increasing disk > footprint with multiple copies of the jars hanging around. -- 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-947) Configuration should have multiple parents
[ http://issues.apache.org/jira/browse/GERONIMO-947?page=comments#action_12320617 ] Dain Sundstrom commented on GERONIMO-947: - Step 2: Adding kernel/src/java/org/apache/geronimo/kernel/config/MultiParentClassLoader.java Adding kernel/src/test/org/apache/geronimo/kernel/config/MultiParentClassLoaderTest.java Transmitting file data .. Committed revision 264851. > Configuration should have multiple parents > -- > > Key: GERONIMO-947 > URL: http://issues.apache.org/jira/browse/GERONIMO-947 > Project: Geronimo > Type: Bug > Components: kernel > Versions: 1.0-M5 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.0-M5 > > A configuration should have multiple parents. This is needed for many > reasons including to allow us to split our configurations into more > manageable pieces. Some discussion has produced this plan: > 1. change all the builder code to produce an URI[] instead of URI for > parentId using a parentId attribute with comma separated list of parents in > the plans > 2. Find a multi-parent classloader and use it in Configuration. Dain says he > has one and I think Eclipse has one. > 3. Change the plan xml to have multiple import elements for the parents > 4. split up our plans to take advantage of this feature. -- 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-825) schemaLocation attribute values in deployment plans contain problematic "schema\" prefix.
[ http://issues.apache.org/jira/browse/GERONIMO-825?page=all ] Aaron Mulder updated GERONIMO-825: -- Fix Version: 1.0 I'd also like to make sure that our schemas that we put in assembly/target/.../schema don't have any weird directories in the path since they're all together in the same directory. We have (or had) some code in maven.xml to rewrite the imports to achieve this, but I'm not sure it's fully working at present. > schemaLocation attribute values in deployment plans contain problematic > "schema\" prefix. > - > > Key: GERONIMO-825 > URL: http://issues.apache.org/jira/browse/GERONIMO-825 > Project: Geronimo > Type: Bug > Versions: 1.0-M4 > Reporter: Sachin Patel > Priority: Minor > Fix For: 1.0 > > From IRC conversation... > [16:33] sppatel: I'm looking at the deployment plan schemas, and noticed > something odd. Could someone explain > why the path "/schema" is being included in some the schemaLocations in > several of the xsd files > where other schemas are being imported. This looks like an error to me. > For example geronimo-web.xsd imports > http://geronimo.apache.org/xml/ns/security"; > schemaLocation="schema/geronimo-security.xsd"/> > > whereas geronimo-application.xsd references the same schema but its > schemaLocation="geronimo-security.xsd" > > Why is the "schema/" prefix being included? > [16:45] djencks: sppatel: I think one of those is an error, but I'm not sure > which > [16:46] djencks: it's using an entity resolver in the xmlbeans2 maven plugin > that looks in the classpath jars for the xsd file > [16:46] sppatel: djencks: I'm attempting to generate EMF models for the > deployment plans, and was forced to remove the prefix /schema in all > scheamaLocations for it to correctly resolve > [16:46] djencks: what is emf? > [16:46] djencks: don't think is is electromotive force :-) > [16:47] sppatel: Eclipse Modeling Framework:) > [16:47] sppatel: I'm working on providing deployment plan editors for the > Geronimo Server Adapter > [16:47] djencks: cool > [16:47] djencks: where are you getting the schemas from? > [16:48] sppatel: from the schema folder in a install image > [16:48] sppatel: since their bundled all togather, the "schema/ prefx doesn't > make sense > [16:48] djencks: can you read them out of a classpath using a classloader? > [16:49] djencks: not critical, just asking > [16:49] sppatel: not sure how to do that > [16:49] djencks: it would be a useful capability I think for the EMF > [16:50] djencks: well, there are at least 2 solutions I can think of: > [16:50] djencks: 1. figure out a way so xmlbeans doesn't need the prefix... > this may be actually more in line with what xmlbeans wants to do anyway > [16:51] djencks: 2. modify the copies of the schemas to remove the /schema > prefix > [16:51] djencks: can you file a JIRA issue? > [16:51] sppatel: sure, np. 2 is fine with me for now... just wanted to bring > it up > [16:52] *** sbailliez has joined #geronimo. > [16:52] djencks: Is this blocking your progress? Can you remove the prefix by > hand until we figure out what to do? I would prefer (1) if it works > [16:53] sppatel: no its not blocking, i'm changing the refs by hand. yeah 1 > would be ideal, especially if the scheams are going to be changing in the > future > [16:54] djencks: well, we are hoping that we will have stabilized them by 1.0 > to a n, n-2 support model :-) -- 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-778) Geronimo XDoclet 1.2.2 module contribution
[ http://issues.apache.org/jira/browse/GERONIMO-778?page=all ] Aaron Mulder updated GERONIMO-778: -- Component: deployment Fix Version: 1.0 Version: 1.0-M4 I'm personally in favor of maintaining this code in Geronimo until it's stable and relatively complete. John, when we create the forthcoming "Development Tools" subproject, can you create a module for this in that area and get it running there? I think we'll need some thought in the build process to avoid requiring the XDoclet source if possible, but maybe that's not possible. > Geronimo XDoclet 1.2.2 module contribution > -- > > Key: GERONIMO-778 > URL: http://issues.apache.org/jira/browse/GERONIMO-778 > Project: Geronimo > Type: New Feature > Components: deployment > Versions: 1.0-M4 > Reporter: John Sisson > Assignee: John Sisson > Priority: Minor > Fix For: 1.0 > Attachments: geronimo-xdoclet.zip > > In December 2004 I did done some work on XDoclet 1.2.2 support for Geronimo > but did not get around to contributing it. Currently it supports the > generation of the openejb-jar.xml file for session and message-driven beans. > See the following mail thread for discussion on this contribution. > http://marc.theaimsgroup.com/?t=11200245871&r=1&w=2 > Note that there are a number of issues discussed below that need to be > resolved before this is ready to be included with Geronimo releases. In > other words, it isn't complete :-). > How to build > === > 1. Download the appropriate (zip/tar) xdoclet-src-1.2.2 file from > http://sourceforge.net/project/showfiles.php?group_id=31602: > 2. Extract the xdoclet-src-1.2.2-* file you downloaded > 3. Copy the geronimo directory (in the attached zip file) to the > xdoclet-1.2.2\modules directory > 4. Build the XDoclet code by running ant ( ant 1.5 works, later versions get > an error) in the xdoclet-1.2.2 directory. After the build has completed the > xdoclet-1.2.2\target\lib directory should contain > xdoclet-geronimo-module-1.2.2.jar . > 5. Generate the html documentation (it will be placed in the > xdoclet-1.2.2\target\docs directory) by issuing the command "maven > site:generate" in the xdoclet-1.2.2 directory. After the documentation has > been generated you should be able to see the documentation for the geronimo > XDoclet tags in the file xdoclet-1.2.2/target/docs/tags/geronimo-tags.html . > Note that a link to the geronimo tags is not added to the main XDoclet page ( > xdoclet-1.2.2/target/docs/index.html ) so it seems the link has to be added > manually. > Issues to discuss > == > * how to integrate into Geronimo build. Currently to build the Geronimo > XDoclet module, it requires the XDoclet source code to be available. It may > be possible to write some ant/maven build files that can build the geronimo > XDoclet module without requiring the Xdoclet source code download (although I > haven't seen any other projects build an XDoclet module this way yet). > * create test application utilising the geronimo XDoclet tags > * currently the configId attribute must be specified in the ant file when > invoking the geronimo subtask. The configId value is placed in the generated > plan. The parentId attribute can also be optionally specified. Is this the > best way? See documentation in the file > xdoclet-1.2.2/target/docs/ant/xdoclet/modules/geronimo/ejb/GeronimoSubTask.html > . > * the tag parameter names match the xml element names in the deployment plan, > but for the parameters used to specify portions of jsr-77 object names (e.g. > domain, server, application, module, ..), I have prefixed the parameter with > objname- to make it clearer that they are part of a group. > *Should the parameter names (e.g. the ref-name parameter of the > @geronimo.resource-ref tag) should be more consistent with the parameters of > the @ejb tags (e.g. the res-refname parameter of the @ejb.resource-ref tag). > * Should we be trying to have unique parameter names so that it is easier to > search for the particular parameter. For example, currently the ref-name > parameter is used on the @geronimo.ejb-local-ref , @geronimo.ejb-ref and > @geronimo.resource-ref tags. If we do change the parameter names to be > unique it will mean the parameter names will no longer match the generated > XML element names (this may make troubleshooting generated XML harder). > Further work to be done > > the following contributions/help by others are welcome :-) : > - Improvements to the tag documentation ( > xdoclet-1.2.2/target/docs/tags/geronimo-tags.html ) > - web support > - web services support > - entity beans support > - GBeans support > - Corba support > - Testing with Eclipse WTP and other IDEs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact
Re: M5 Time ;-)
On Aug 30, 2005, at 12:48 PM, Geir Magnusson Jr. wrote: On Aug 30, 2005, at 3:37 PM, David Blevins wrote: On Aug 27, 2005, at 10:15 AM, Geir Magnusson Jr. wrote: On Aug 27, 2005, at 10:33 AM, Jeremy Boynes wrote: Runtime, please? :) We covered this in M4. We agreed on separate builds of Jetty and Tomcat rather than one build with Jetty as the default. relax. Was just hoping... :) It's fine if we want to reconsider. I know everyone kind of informally wants to get the the point where we can swap stuff in and out at runtime. Don't know how close we are. -David
[jira] Updated: (GERONIMO-596) PermissionManager can be sparser
[ http://issues.apache.org/jira/browse/GERONIMO-596?page=all ] Aaron Mulder updated GERONIMO-596: -- Fix Version: 1.0 Environment: Assign To: Alan Cabrera This issue report is pretty sparse. :) Alan, can you explain in more detail? Thanks. > PermissionManager can be sparser > > > Key: GERONIMO-596 > URL: http://issues.apache.org/jira/browse/GERONIMO-596 > Project: Geronimo > Type: Improvement > Components: security > Reporter: Alan Cabrera > Assignee: Alan Cabrera > Priority: Minor > Fix For: 1.0 > > PermissionManager can be sparser per row due to the fact that not all of > those methods will be permission checked. -- 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: M5 List Closure - J2EE Certification
On Aug 30, 2005, at 1:13 PM, Aaron Mulder wrote: Has anyone taken a stab at running the TCK on Tomcat yet? If not, I think it's going to be hard to agree on a sensible ETA. Not looking for a sensible ETA, more of a "how long are we willing to allow for it, ideally" kind of thing. For example, post M3 we always thought the ETA for passing the CTS was weeks away when it turned out to be 12 months away. We should have been explicit with our expectations of how long we were willing to give it before reconsidering the goal. Not saying we should reconsider the goal now, just define what "ASAP" or "soon" should be ideally. -David Aaron On Tue, 30 Aug 2005, David Blevins wrote: There was some discussion in M4 on possibly J2EE certifying that release or maybe M5. Can we get a clear consensus that: 1) this is what we want to do with M5 2) what is the ideal timeframe for completing that (in weeks, don't say soon).
[jira] Updated: (GERONIMO-239) Should be able to dump .car file
[ http://issues.apache.org/jira/browse/GERONIMO-239?page=all ] Aaron Mulder updated GERONIMO-239: -- Fix Version: 1.0 Environment: > Should be able to dump .car file > > > Key: GERONIMO-239 > URL: http://issues.apache.org/jira/browse/GERONIMO-239 > Project: Geronimo > Type: Improvement > Versions: 1.0-M1 > Reporter: Jeremy Boynes > Priority: Minor > Fix For: 1.0 > > The configuration contains a binary .ser file with GBean instance data - > there should be a tool to dump 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
[jira] Created: (GERONIMO-952) Eliminate digester log output
Eliminate digester log output - Key: GERONIMO-952 URL: http://issues.apache.org/jira/browse/GERONIMO-952 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0-M5 Digester produces a grotesque amount of log output, and the Tomcat configuration uses Digester. We need to specifically set the Digester level to INFO or WARN in our server log configuration file. -- 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: M5 List Closure - Console Support
thanks for doing this. Would it make sense to start separate threads? my mailer treats them all as the same thread... On Aug 30, 2005, at 4:14 PM, David Blevins wrote: Some discussion has occurred on how we want to role out the console in M5. On Aug 26, 2005, at 5:54 PM, Aaron Mulder wrote: So I updated the console status on the Wiki: http://wiki.apache.org/geronimo/Web_Console Basically, there's a lot of work yet to go. I've put some work into web server, logging, and JMS server portlets so far, and Joe's pitched in a bit as well, but I don't think I'd really say there's any page there that's fully working and satisfactory. As far as M5 goes, I think we'll do what we do in the time frame we end up having. I think it's going to be a "technology preview" in every sense. I don't think it makes sense to hold M5 until the console is "done" or to try to cut down the console to the stuff that actually works right. Still, it wouldn't break my heart if M5 took a while so we could get more done on the console. :) On Aug 26, 2005, at 7:02 PM, Aaron Mulder wrote: Well, OK, after talking about this a bit more, it seems like there's some interest in picking certain features we'd defintiely like to have in the console for M5. On Aug 27, 2005, at 11:15 AM, Dain Sundstrom wrote: I think we should clearly state that the console is a "Technology Preview", and point the users to JIRA to file feature requests. I assume there would be no arguments against clearly communicating (via labeling, some page in the console, release notes, or all of the above and more) that the console is a "Technology Preview." So what looks like what still is open for consensus is do we: 1) Take the time pick certain features and hold the release till they are done. 2) Do what we do in the time frame we end up having. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: M5 List Closure - J2EE Certification
On Aug 30, 2005, at 3:54 PM, David Blevins wrote: There was some discussion in M4 on possibly J2EE certifying that release or maybe M5. Can we get a clear consensus that: 1) this is what we want to do with M5 I would be happy with that. 2) what is the ideal timeframe for completing that (in weeks, don't say soon). I'll try to do the research re what is involved beyond the automated test suite. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Updated: (GERONIMO-242) Keep history of running configurations
[ http://issues.apache.org/jira/browse/GERONIMO-242?page=all ] Aaron Mulder updated GERONIMO-242: -- Fix Version: 1.0 Environment: If we currently overwrite the file, we can take the approach of 1) write new file 2) delete backup file, if present 3) rename current file to backup file 4) rename new file to current file > Keep history of running configurations > -- > > Key: GERONIMO-242 > URL: http://issues.apache.org/jira/browse/GERONIMO-242 > Project: Geronimo > Type: Improvement > Components: management > Versions: 1.0-M2 > Reporter: Jeremy Boynes > Priority: Minor > Fix For: 1.0 > > The server should keep a list of previously known running configurations > rather than just the last one (just in case it it broken or gets corrupted > during 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: M5 List Closure - Console Support
Some discussion has occurred on how we want to role out the console in M5. On Aug 26, 2005, at 5:54 PM, Aaron Mulder wrote: So I updated the console status on the Wiki: http://wiki.apache.org/geronimo/Web_Console Basically, there's a lot of work yet to go. I've put some work into web server, logging, and JMS server portlets so far, and Joe's pitched in a bit as well, but I don't think I'd really say there's any page there that's fully working and satisfactory. As far as M5 goes, I think we'll do what we do in the time frame we end up having. I think it's going to be a "technology preview" in every sense. I don't think it makes sense to hold M5 until the console is "done" or to try to cut down the console to the stuff that actually works right. Still, it wouldn't break my heart if M5 took a while so we could get more done on the console. :) On Aug 26, 2005, at 7:02 PM, Aaron Mulder wrote: Well, OK, after talking about this a bit more, it seems like there's some interest in picking certain features we'd defintiely like to have in the console for M5. On Aug 27, 2005, at 11:15 AM, Dain Sundstrom wrote: I think we should clearly state that the console is a "Technology Preview", and point the users to JIRA to file feature requests. I assume there would be no arguments against clearly communicating (via labeling, some page in the console, release notes, or all of the above and more) that the console is a "Technology Preview." So what looks like what still is open for consensus is do we: 1) Take the time pick certain features and hold the release till they are done. 2) Do what we do in the time frame we end up having.
[jira] Updated: (GERONIMO-287) Control-C termination overwrites log files created with log4j.xml
[ http://issues.apache.org/jira/browse/GERONIMO-287?page=all ] Aaron Mulder updated GERONIMO-287: -- Fix Version: 1.0-M5 Description: When running with a log4j.xml parameter file, and terminating Geronimo with a Control-C, the log files are overwritten starting with the time of termination. The final log only contains entries AFTER the control-C was issued, all the content prior to the Control-C is lost. Since Control-C is the only way to shut down at the moment, this is an issue to be aware of. If I get the chance, I will try to track it down, but ... was: When running with a log4j.xml parameter file, and terminating Geronimo with a Control-C, the log files are overwritten starting with the time of termination. The final log only contains entries AFTER the control-C was issued, all the content prior to the Control-C is lost. Since Control-C is the only way to shut down at the moment, this is an issue to be aware of. If I get the chance, I will try to track it down, but ... This behavior does not currently occur, but we have append=true. We should test with append=false for M5, and if the described behavior is accurate, at least put a comment in our config file to the effect of "don't change this under any circumstances!". > Control-C termination overwrites log files created with log4j.xml > - > > Key: GERONIMO-287 > URL: http://issues.apache.org/jira/browse/GERONIMO-287 > Project: Geronimo > Type: Bug > Components: core > Environment: Windows 2000, Java 1.4.2_04, and Java 1.5.0-beta2, CVS of Aug > 8, 2004 > Reporter: David Farb > Assignee: Gianny Damour > Priority: Minor > Fix For: 1.0-M5 > > When running with a log4j.xml parameter file, and terminating Geronimo with a > Control-C, the log files are overwritten starting with the time of > termination. > The final log only contains entries AFTER the control-C was issued, all the > content prior to the Control-C is lost. > Since Control-C is the only way to shut down at the moment, this is an issue > to be aware of. > If I get the chance, I will try to track it down, but ... -- 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: M5 List Closure - J2EE Certification
Has anyone taken a stab at running the TCK on Tomcat yet? If not, I think it's going to be hard to agree on a sensible ETA. Aaron On Tue, 30 Aug 2005, David Blevins wrote: > There was some discussion in M4 on possibly J2EE certifying that > release or maybe M5. Can we get a clear consensus that: > > 1) this is what we want to do with M5 > > 2) what is the ideal timeframe for completing that (in weeks, don't > say soon). > > > > >
[jira] Updated: (GERONIMO-950) JVM portlet shouid display all system property values
[ http://issues.apache.org/jira/browse/GERONIMO-950?page=all ] Aaron Mulder updated GERONIMO-950: -- Fix Version: 1.0 > JVM portlet shouid display all system property values > - > > Key: GERONIMO-950 > URL: http://issues.apache.org/jira/browse/GERONIMO-950 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0-M5 > Reporter: Jeremy Boynes > Fix For: 1.0 > > Only selected system properties are displayed. The "etc" section should > display all remaining properties. > E.g. if you start the server with java -Dfoo=bar then there should be a row > |foo|bar| -- 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: M5 List Closure - J2EE Certification
There was some discussion in M4 on possibly J2EE certifying that release or maybe M5. Can we get a clear consensus that: 1) this is what we want to do with M5 2) what is the ideal timeframe for completing that (in weeks, don't say soon).
Re: M5 Time ;-)
On Aug 30, 2005, at 3:37 PM, David Blevins wrote: On Aug 27, 2005, at 10:15 AM, Geir Magnusson Jr. wrote: On Aug 27, 2005, at 10:33 AM, Jeremy Boynes wrote: Jeff Genender wrote: 2) What do we want as part of the M5 release. I ask that we break this down into A) Must haves, B) Nice to haves, C) Fuhgetaboutit. A) Must haves * Simpler way to configure the server for Jetty vs. Tomcat. I think this includes breaking the Jetty & Tomcat components out of the huge o/a/g/Server plan into separate ones Runtime, please? :) We covered this in M4. We agreed on separate builds of Jetty and Tomcat rather than one build with Jetty as the default. relax. Was just hoping... geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: M5 List Closure
On Aug 30, 2005, at 10:15 AM, Jeff Genender wrote: I want to propose that tomorrow (8/31) at midnite PDT, the list for new M5 features will be closed, and we can begin to agree on the final QA cut and M5 release date...this is with a 36:45 hour notice. If anyone has a problem with this, then please state your preferred list lock down date/time. If you cannot give a new date/time, then this date/time will stand. "I don't know yet" is not acceptable ;-) I noticed a few things in the first M5 thread that didn't really close. Going to split them out into sub-threads and we can reach explicit consensus. -David
Re: M5 Time ;-)
On Aug 27, 2005, at 10:15 AM, Geir Magnusson Jr. wrote: On Aug 27, 2005, at 10:33 AM, Jeremy Boynes wrote: Jeff Genender wrote: 2) What do we want as part of the M5 release. I ask that we break this down into A) Must haves, B) Nice to haves, C) Fuhgetaboutit. A) Must haves * Simpler way to configure the server for Jetty vs. Tomcat. I think this includes breaking the Jetty & Tomcat components out of the huge o/a/g/Server plan into separate ones Runtime, please? :) We covered this in M4. We agreed on separate builds of Jetty and Tomcat rather than one build with Jetty as the default. -David
Please add news to Geronimo web
Geir, Could you please add that Apache Directory Server has been added to G on the web page? Thanks, Jeff
[jira] Commented: (GERONIMO-484) Repeated Deploys of WAR Generate OOM Exception
[ http://issues.apache.org/jira/browse/GERONIMO-484?page=comments#action_12320608 ] Kevan Miller commented on GERONIMO-484: --- Assuming the doStop() changes are correct, the same changes should be added to doFail(), also... > Repeated Deploys of WAR Generate OOM Exception > -- > > Key: GERONIMO-484 > URL: http://issues.apache.org/jira/browse/GERONIMO-484 > Project: Geronimo > Type: Bug > Components: web > Versions: 1.0-M3 > Environment: WinXP SP2, JDK 1.4.2_05 > Reporter: Seth Ladd > Assignee: David Jencks > Fix For: 1.0-M5 > Attachments: LogFactoryRelease.txt, minimaltest.war, over-and-over.sh > > Hello, > I have just run a test that tests Geronimo's ability to redeploy .war > files. The results don't look so good, but I'm hoping the info I've > collected will help expose the problem (whether the problem is with me > or the server :) > I've included the script, .war file, web.xml, and two exception traces > (one from the deploy client and one from the server) I apologize for > the length of this post. If there's a better way to include all this > information, please let me know. > It appears as if the server is running out of memory. Note that I did > not alter the native configuration of Geronimo in any way. This is a > stock M3 download, using JDK 1.4.2_05 on Windows XP SP2. > It's my expectation that the app server would stay up and running > indefinitely after redeploys of .war files. Especially this .war file > since it merely contains a single welcome.jsp. I hope this info is > helpful, and let me know what else you might need. I'll gladly send > the script and .war file to others that might want to test this. > Thanks, > Seth > My test script: > $ cat over-and-over.sh > while /bin/true; do > java -jar bin/deployer.jar --user system --password manager deploy > ../eclipse/wo > rkspace/MinimalWebapp/build/minimaltest.war > sleep 1 > wget -q -O - http://localhost:8080/minimaltest/welcome.jsp > /dev/null > java -jar bin/deployer.jar --user system --password manager undeploy > minimaltest > sleep 1 > done > Structure of minimaltest.war: > $ jar tf ../eclipse/workspace/MinimalWebapp/build/minimaltest.war > META-INF/ > META-INF/MANIFEST.MF > WEB-INF/ > welcome.jsp > WEB-INF/web.xml > Contents of web.xml: > $ cat ../eclipse/workspace/MinimalWebapp/web/WEB-INF/web.xml > > http://java.sun.com/xml/ns/j2ee"; >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee > http://java.sun.com/ > xml/ns/j2ee/web-app_2_4.xsd" >version="2.4"> > >welcome.jsp > > > So, as you can see, it's a very minimal webapp. It doesn't initialize > anything, nor does it include any 3rd party jars or libs. It doesn't > even load up any classes, and the welcome.jsp only says "Hello, > world!" > After 1434 deploy cycles, we receive this exception from the deploy client: > - > Deployment failed > Server reports: null > java.lang.IllegalStateException >at org.apache.geronimo.kernel.Kernel.stopConfiguration(Kernel.java:437) >at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:324) >at > mx4j.server.ReflectionMBeanInvoker.invokeImpl(ReflectionMBeanInvoker.java:152) >at > mx4j.server.ReflectionMBeanInvoker.doInvoke(ReflectionMBeanInvoker.java:119) >at > mx4j.server.ReflectionMBeanInvoker.invoke(ReflectionMBeanInvoker.java:54) >at > mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:235) >at > mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) >at > mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:86) >at > mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) >at > mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) >at > mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerInterceptor.java:205) >at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079) >at > mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:222) >at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:324) >at > mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:36) >at > mx4j.remote.rmi.RMIC
Re: eclipse Distribution site proposal
I'm not sure what would would make the nightly-ness of this more clear. It was named unstable to match the existing naming conventions, which IIRC was named unstable since we do not do these each night. If it would make you more comfortable to rename this nightly (or anything else for that matter), then by all means please feel free to make this change yourself. If you would rather that we didn't publish this at this point, then simply delete the directory. -dain On Aug 30, 2005, at 10:33 AM, Geir Magnusson Jr. wrote: There's been concern elsewhere that the concept of "snapshot" that's then distributed is a way of circumventing the oversight of a release. I want to be sure that the nightly-ness of this is clear, especially if the eclipse people are linking to it. On Aug 30, 2005, at 1:20 PM, Dain Sundstrom wrote: Geir this code is in cvs.apache.org under a directory called "unstable". This is exactly how we do nightly unstable "r"eleases. Regardless, if this is a real concern for you, simply delete the directory as I instructed. -dain On Aug 30, 2005, at 9:55 AM, Geir Magnusson Jr. wrote: my concern is that this might be interpreted as a de-facto release of some sort. Can it be named something like "nightly" or such? On Aug 30, 2005, at 12:44 PM, Dain Sundstrom wrote: Since on one objected I uploaded the site from GERONIMO-949 to here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If any committer has an objection, just delete this directory on people.apache.org: /www/cvs.apache.org/dist/geronimo/eclipse/unstable and then we can address the concerns. -dain On Aug 29, 2005, at 5:36 PM, Dain Sundstrom wrote: On Aug 29, 2005, at 4:52 PM, Sachin Patel wrote: It may take some time to get the subproject website set up and I'm still working on getting the plugins mavenized. In the meantime could we either set up a distribute update site on Geronimo or even easier just post the latest distribution zip on the main site? I've already sent a note out to the WTP dev list informing them that it will be posted on Apache soon. Thoughts? +1 I suggest we create the eclipse site here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If you can create the site and upload it to JIRA as a patch, I'll post it to the site (assuming no one objects). -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: eclipse Distribution site proposal
Keep in mind that the use of the eclipse update manager isn't a means of pulling down daily builds, but only should only should be used to post milestone or official releases. Daily builds should be available as a download as an extractable zip, and not through the update manager. Geir Magnusson Jr. wrote: There's been concern elsewhere that the concept of "snapshot" that's then distributed is a way of circumventing the oversight of a release. I want to be sure that the nightly-ness of this is clear, especially if the eclipse people are linking to it. On Aug 30, 2005, at 1:20 PM, Dain Sundstrom wrote: Geir this code is in cvs.apache.org under a directory called "unstable". This is exactly how we do nightly unstable "r"eleases. Regardless, if this is a real concern for you, simply delete the directory as I instructed. -dain On Aug 30, 2005, at 9:55 AM, Geir Magnusson Jr. wrote: my concern is that this might be interpreted as a de-facto release of some sort. Can it be named something like "nightly" or such? On Aug 30, 2005, at 12:44 PM, Dain Sundstrom wrote: Since on one objected I uploaded the site from GERONIMO-949 to here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If any committer has an objection, just delete this directory on people.apache.org: /www/cvs.apache.org/dist/geronimo/eclipse/unstable and then we can address the concerns. -dain On Aug 29, 2005, at 5:36 PM, Dain Sundstrom wrote: On Aug 29, 2005, at 4:52 PM, Sachin Patel wrote: It may take some time to get the subproject website set up and I'm still working on getting the plugins mavenized. In the meantime could we either set up a distribute update site on Geronimo or even easier just post the latest distribution zip on the main site? I've already sent a note out to the WTP dev list informing them that it will be posted on Apache soon. Thoughts? +1 I suggest we create the eclipse site here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If you can create the site and upload it to JIRA as a patch, I'll post it to the site (assuming no one objects). -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: eclipse Distribution site proposal
There's been concern elsewhere that the concept of "snapshot" that's then distributed is a way of circumventing the oversight of a release. I want to be sure that the nightly-ness of this is clear, especially if the eclipse people are linking to it. On Aug 30, 2005, at 1:20 PM, Dain Sundstrom wrote: Geir this code is in cvs.apache.org under a directory called "unstable". This is exactly how we do nightly unstable "r"eleases. Regardless, if this is a real concern for you, simply delete the directory as I instructed. -dain On Aug 30, 2005, at 9:55 AM, Geir Magnusson Jr. wrote: my concern is that this might be interpreted as a de-facto release of some sort. Can it be named something like "nightly" or such? On Aug 30, 2005, at 12:44 PM, Dain Sundstrom wrote: Since on one objected I uploaded the site from GERONIMO-949 to here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If any committer has an objection, just delete this directory on people.apache.org: /www/cvs.apache.org/dist/geronimo/eclipse/unstable and then we can address the concerns. -dain On Aug 29, 2005, at 5:36 PM, Dain Sundstrom wrote: On Aug 29, 2005, at 4:52 PM, Sachin Patel wrote: It may take some time to get the subproject website set up and I'm still working on getting the plugins mavenized. In the meantime could we either set up a distribute update site on Geronimo or even easier just post the latest distribution zip on the main site? I've already sent a note out to the WTP dev list informing them that it will be posted on Apache soon. Thoughts? +1 I suggest we create the eclipse site here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If you can create the site and upload it to JIRA as a patch, I'll post it to the site (assuming no one objects). -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: eclipse Distribution site proposal
Geir this code is in cvs.apache.org under a directory called "unstable". This is exactly how we do nightly unstable "r"eleases. Regardless, if this is a real concern for you, simply delete the directory as I instructed. -dain On Aug 30, 2005, at 9:55 AM, Geir Magnusson Jr. wrote: my concern is that this might be interpreted as a de-facto release of some sort. Can it be named something like "nightly" or such? On Aug 30, 2005, at 12:44 PM, Dain Sundstrom wrote: Since on one objected I uploaded the site from GERONIMO-949 to here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If any committer has an objection, just delete this directory on people.apache.org: /www/cvs.apache.org/dist/geronimo/eclipse/unstable and then we can address the concerns. -dain On Aug 29, 2005, at 5:36 PM, Dain Sundstrom wrote: On Aug 29, 2005, at 4:52 PM, Sachin Patel wrote: It may take some time to get the subproject website set up and I'm still working on getting the plugins mavenized. In the meantime could we either set up a distribute update site on Geronimo or even easier just post the latest distribution zip on the main site? I've already sent a note out to the WTP dev list informing them that it will be posted on Apache soon. Thoughts? +1 I suggest we create the eclipse site here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If you can create the site and upload it to JIRA as a patch, I'll post it to the site (assuming no one objects). -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
M5 List Closure
I want to propose that tomorrow (8/31) at midnite PDT, the list for new M5 features will be closed, and we can begin to agree on the final QA cut and M5 release date...this is with a 36:45 hour notice. If anyone has a problem with this, then please state your preferred list lock down date/time. If you cannot give a new date/time, then this date/time will stand. "I don't know yet" is not acceptable ;-) Jeff
Re: [discuss/poll] advertising policy
[X] Ask that they vet these kinds of things through the Geronimo PMC via the [EMAIL PROTECTED] list On Aug 30, 2005, at 6:01 AM, Geir Magnusson Jr. wrote: NOTE : The following was *NOT* motivated by Calvin's recent post. However, I couldn't write this message without mentioning it, since it was so recent...] Recently, we had a post from Calvin that talked about a contest his company is running for testing. I didn't think there was any problem as while it was commercial in origin, it was something that the Geronimo community might be interested in. However I did hear questions about the appropriateness of this from individuals. Now, the company I work for, IBM, has a contest that is specifically targeted to the Geronimo community. How do we want to handle these kinds of things, in general? [ ] Just let people post things like that to the list [ ] Ask that they vet these kinds of things through the Geronimo PMC via the [EMAIL PROTECTED] list [ ] Other : -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Powered By & other web site questions
On Aug 30, 2005, at 9:45 AM, Aaron Mulder wrote: Our front page has a broken link to powered by. What's that all about? Probably a bug? :) I'll fix. BTW, do you want chariot listed as a provider of support or services for Geronimo? That's what the page is supposed to be for. Also, how often does the JavaDoc on the web site get updated? It's manual. I guess I should respin and put the M4 version up. Also, we should make sure to review the Road Map / TODO after M5. Yes Also, the Related Projects list is terribly short. I think we should either add in the other 574 projects or adjust the language a bit. Yah. Maybe a language change. I wasn't intending that we list every dependency, but just the major collaborating communities that provide the major functionality of the stack. geir Aaron -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: eclipse Distribution site proposal
Thanks Dain. As soon as I get a chance I'll through some screenshots/installation instructions on the Wiki. Dain Sundstrom wrote: Since on one objected I uploaded the site from GERONIMO-949 to here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If any committer has an objection, just delete this directory on people.apache.org: /www/cvs.apache.org/dist/geronimo/eclipse/unstable and then we can address the concerns. -dain On Aug 29, 2005, at 5:36 PM, Dain Sundstrom wrote: On Aug 29, 2005, at 4:52 PM, Sachin Patel wrote: It may take some time to get the subproject website set up and I'm still working on getting the plugins mavenized. In the meantime could we either set up a distribute update site on Geronimo or even easier just post the latest distribution zip on the main site? I've already sent a note out to the WTP dev list informing them that it will be posted on Apache soon. Thoughts? +1 I suggest we create the eclipse site here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If you can create the site and upload it to JIRA as a patch, I'll post it to the site (assuming no one objects). -dain
Re: eclipse Distribution site proposal
my concern is that this might be interpreted as a de-facto release of some sort. Can it be named something like "nightly" or such? On Aug 30, 2005, at 12:44 PM, Dain Sundstrom wrote: Since on one objected I uploaded the site from GERONIMO-949 to here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If any committer has an objection, just delete this directory on people.apache.org: /www/cvs.apache.org/dist/geronimo/eclipse/unstable and then we can address the concerns. -dain On Aug 29, 2005, at 5:36 PM, Dain Sundstrom wrote: On Aug 29, 2005, at 4:52 PM, Sachin Patel wrote: It may take some time to get the subproject website set up and I'm still working on getting the plugins mavenized. In the meantime could we either set up a distribute update site on Geronimo or even easier just post the latest distribution zip on the main site? I've already sent a note out to the WTP dev list informing them that it will be posted on Apache soon. Thoughts? +1 I suggest we create the eclipse site here: http://cvs.apache.org/dist/geronimo/eclipse/unstable If you can create the site and upload it to JIRA as a patch, I'll post it to the site (assuming no one objects). -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Created: (GERONIMO-951) Change assembly module to create both geronimo-tomcat and geronimo-jetty distributions
Change assembly module to create both geronimo-tomcat and geronimo-jetty distributions -- Key: GERONIMO-951 URL: http://issues.apache.org/jira/browse/GERONIMO-951 Project: Geronimo Type: Improvement Components: buildsystem Reporter: Dain Sundstrom Assigned to: Dain Sundstrom Fix For: 1.0-M5 It is difficult to switch between testing geronimo-jetty and geronimo-tomcat. It would be nice to create both in the assembly module so testing can be as simple as changing a flag. -- 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-949) Update site
[ http://issues.apache.org/jira/browse/GERONIMO-949?page=all ] Dain Sundstrom closed GERONIMO-949: --- Fix Version: 1.0-M5 Resolution: Fixed Site was uploaded to http://cvs.apache.org/dist/geronimo/eclipse/unstable/ > Update site > --- > > Key: GERONIMO-949 > URL: http://issues.apache.org/jira/browse/GERONIMO-949 > Project: Geronimo > Type: Bug > Components: eclipse-plugin > Versions: 1.0 > Reporter: Sachin Patel > Assignee: Dain Sundstrom > Fix For: 1.0-M5 > Attachments: site.zip > > Create a temporary update site for the wtp server adapter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-949) Update site
[ http://issues.apache.org/jira/browse/GERONIMO-949?page=all ] Dain Sundstrom reassigned GERONIMO-949: --- Assign To: Dain Sundstrom > Update site > --- > > Key: GERONIMO-949 > URL: http://issues.apache.org/jira/browse/GERONIMO-949 > Project: Geronimo > Type: Bug > Components: eclipse-plugin > Versions: 1.0 > Reporter: Sachin Patel > Assignee: Dain Sundstrom > Attachments: site.zip > > Create a temporary update site for the wtp server adapter -- 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: Build failed...
Sachin Patel wrote: I'm keep getting the following build error, even on a fresh checkout and build. Any ideas? I've commented out the in-build packaging until we can get to the bottom of this. -- Jeremy
