Re: support for shared libraries/classes in Geronimo 1.1
--- John Sisson <[EMAIL PROTECTED]> wrote: > Aaron Mulder wrote: > > I'm not really following your description of how > this will work, but > > this is my thought: > > > > - We pick a shared library directory > (var/shared/lib is fine with me) > > and make that the standard. I don't think shared > classes are even > > necessary, though I don't object to having a > directory for that too. > > > A shared classes directory may be useful for things > such as property > files that people may want to be able to easily edit > without needing to > jar it up. > > John That's what WEB-INF/classes is for. Wade
Re: Update on Long Paths
It would be good if we could use precompiled jsps so the server is always responsive - that first time hit often happens when you are running a demo :-) John Prasad Kashyap wrote: I could not use the ant task to precompile jsps. Using the following, simply nothing happens. So by passing a few more args to our existing execution, I was able to generate the xml file too. Using the option addWebXmlMappings, I tried to merge the web.xmls but JspC cried that it was a unrecognized option. Looking at the JspC code, http://svn.apache.org/repos/asf/tomcat/jasper/branches/tc5.0.x/jasper2/src/share/org/apache/jasper/JspC.java it seems like you can't pass addWebXmlMappings in a java command line argument. It is not recognized or set by the setArgs(). Seems like a jasper bug ? So I added another goal to our deployment plugin called "mergeWebXML". This goal merges the generated web.xml fragment with the existing one from source. When I spoke to the Tomcat guys, they feel that precompiling JSPs doesn't buy us anything anymore, except for that first time hit. The request mapper is supposedly fixed in 5.5.x versions and thus we shouldn't see any other performance hit. Anyways, I have uploaded the patch to http://issues.apache.org/jira/browse/GERONIMO-1844 Cheers Prasad On 4/14/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: OK. I'll take care of the JSP pages. I am done with jar'ing the generated class files. I shall look into generating a web.xml and merging it. Cheers Prasad On 4/13/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Prasad got the patch working on all web applications. The next big offenders left are the auto generated WebServices wrapper class and the precompiled JSP pages. David Jencks has a patch for the WebServices class, but we are waiting to get the TCK running so we can judge the impact. I disabled precompiled JSP pages, as they didn't work anyway. We generate the classes and compile them, but we never added them to the class path and we are not merging generated- web.xml into our web.xml. I'm hoping Prasad has time to tackle this one. With these patches in, except for the WS class, the longest paths including server name is 224 and 217 characters: geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-jetty- streamer-client/1.1-SNAPSHOT/daytrader-derby-jetty-streamer- client-1.1-SNAPSHOT.car/activemq/activemq-ra/3.2.4-SNAPSHOT/rar/ activemq-optional-3.2.4-SNAPSHOT.jar geronimo-1.1-SNAPSHOT/repository/geronimo/webconsole-jetty/1.1- SNAPSHOT/webconsole-jetty-1.1-SNAPSHOT.car/geronimo-console- framework-1.1-SNAPSHOT.war/WEB-INF/config/services/ PortletDefinitionRegistryService.properties These will become 179 and 189 characters when we drop -SNAPSHOT from all of the version numbers. I'm also hoping we can change the name daytrader-derby-jetty-streamer-client to something shorter. This is a lot better and will allow for at least 50 characters of head room, which I hope is plenty for windows users. As for next steps, I'd like to get the hot deploy service working better. With the addition of the in-place deployment feature from Gianny and the timestamp I added to the configuration, we should be able to write a much better service. Once we have the better hot deploy service, we will be able to implement the flat deployment model that Hernan and others have suggested. -dain
Re: support for shared libraries/classes in Geronimo 1.1
Aaron Mulder wrote: I'm not really following your description of how this will work, but this is my thought: - We pick a shared library directory (var/shared/lib is fine with me) and make that the standard. I don't think shared classes are even necessary, though I don't object to having a directory for that too. A shared classes directory may be useful for things such as property files that people may want to be able to easily edit without needing to jar it up. John - If the directory is not present during startup, we create it - By default, application deployments do not see shared libraries - If you put an in the in your plan, then the shared libraries are added to the application class loader I'm imaging there's one "shared library GBean" in the whole server and you set the directory on that in the j2ee-server plan and we don't encourage people to change it (though they could in config.xml I suppose). Is that what you have or are you thinking of one GBean per application deployment? Thanks, Aaron On 4/14/06, Joe Bohn <[EMAIL PROTECTED]> wrote: Dain added some initial support for shared libraries in 1.1 and (with the help of David Jencks) I have a configuration and gbean to make the feature available to applications to use. I'll create a patch for this today for Geronimo 1.1. However, I have a question about how "public" we want this function to be. There has been some concern that we shouldn't encourage the use of shared libraries. The thought is that it is better to use the repository and explicit dependencies. If we include the gbean in the configuration for an assembly then the any specified shared library(ies) or class directory(ies) must exist or an exception is thrown. At the moment I'm using var/shared/lib and var/shared/classes as the defaults. If we just add the gbean to the assemblies without the default libraries then the user will have to update the configuration to use the feature and specify the attributes for the libs or classes. That isn't very user friendly and doesn't provide a "default" location. On the other hand, adding in defaults requires that we also add in the empty directories which is a bit of an advertisement to use them. At the moment, I'm leaning toward adding the default directories. Any recommendations before I create the patch? Joe -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
[jira] Created: (GERONIMO-1854) Coordinate list of started configs for Jetty,Tomcat for 1.1
Coordinate list of started configs for Jetty,Tomcat for 1.1 --- Key: GERONIMO-1854 URL: http://issues.apache.org/jira/browse/GERONIMO-1854 Project: Geronimo Type: Bug Security: public (Regular issues) Components: general Versions: 1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1 Before the 1.1 release, we have to agree on what configurations to distribute and what to enable and make sure Tomcat and Jetty are consistent. I would prefer to omit all the sample applications and just provide the download link for them in the console (and/or a URL forward in the welcome app that takes you to an install prompt if you visit where they'd normally be). So the only apps I prefer to ship are Welcome and Console. I think it'll be better to have a lighter distribution and it'll prevent issues like the failure of Daytrader on 1.5. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1851) Proxy logic busted
[ http://issues.apache.org/jira/browse/GERONIMO-1851?page=all ]
Aaron Mulder resolved GERONIMO-1851:
Resolution: Fixed
> Proxy logic busted
> --
>
> Key: GERONIMO-1851
> URL: http://issues.apache.org/jira/browse/GERONIMO-1851
> Project: Geronimo
> Type: Bug
> Security: public(Regular issues)
> Components: kernel
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Dain Sundstrom
> Priority: Critical
> Fix For: 1.1
>
> If you go to the Import/Export portlet in 1.1, you get this:
> UNEXPECTED ERROR for class
> org.apache.geronimo.jetty.JettyWebAppContext$$EnhancerByCGLIB$$1b72c5bb
> (geronimo/welcome-jetty/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=geronimo/welcome-jetty/1.1-SNAPSHOT/car)
> java.lang.ArrayIndexOutOfBoundsException: -1
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.createGBeanInvokers(ProxyMethodInterceptor.java:116)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.(ProxyMethodInterceptor.java:70)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager.getMethodInterceptor(BasicProxyManager.java:317)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactory.createProxy(BasicProxyManager.java:290)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicProxyManager.java:179)
> at
> org.apache.geronimo.console.util.KernelManagementHelper.getModuleForConfiguration(KernelManagementHelper.java:850)
> The error is generated at the last line of this snippet of
> ProxyMethodInterceptor:
> invokers[getSuperIndex(proxyType, proxyType.getMethod("equals",
> new Class[]{Object.class}))] = new EqualsInvoke(kernel);
> invokers[getSuperIndex(proxyType, proxyType.getMethod("hashCode",
> null))] = new HashCodeInvoke();
> invokers[getSuperIndex(proxyType, proxyType.getMethod("toString",
> null))] = new ToStringInvoke(proxyType.getName());
> if(GeronimoManagedBean.class.isAssignableFrom(proxyType)) {
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getState", null))] = new GetStateInvoke(kernel);
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getStateInstance", null))] = new
> GetStateInstanceInvoke(kernel);
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("start", null))] = new StartInvoke(kernel);
> In other words, it is returning a -1 from getSuperIndex on the "start()"
> method for the proxyType. However, the "if" statement established that
> ProxyType is assignable to GeronimoManagedBean, which has a "start()" method.
> So it seems like the logic that constructs the invokers and/or whatever
> getSuperIndex uses is not finding all the methods that the proxy exposes, or
> else there are some classloader issues causing identical methods to be
> detected as different, etc.
> The logic displayed above is unchanged from HEAD where the same portlet
> works, though the portlet code has changed significantly. I'm not sure
> what's different elsewhere in the ProxyMethodInterceptor class or the rest of
> the proxy infrastructure.
> To replicate this, start Geronimo, and click the "Plugins" entry in the
> console.
--
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-1851) Proxy logic busted
[
http://issues.apache.org/jira/browse/GERONIMO-1851?page=comments#action_12374589
]
Aaron Mulder commented on GERONIMO-1851:
That is, appears to be caused by *a change to*
BasicProxyManager.createProxy(name, ClassLoader) to include classes with an
empty constructor in addition to interfaces (this was a change made in 1.1 but
not HEAD). So I'm changing the behavior back to match HEAD. (I'm not touching
the method where you give it a class or interface and it builds a proxy for
exactly that.)
The 1.1 behavior also had the side effect (in the console) of a lot of
complaints that "interface 'concrete-class-name' could not be found in the
specified class loader". I'll be just as happy to eliminate those by making
this change.
Assigned this issue to Dain because we discussed the issue previously before I
realized that it had actual harmful side effects and I'd like him to review the
change.
(PostScript: Spoke to Dain and he blessed the change).
> Proxy logic busted
> --
>
> Key: GERONIMO-1851
> URL: http://issues.apache.org/jira/browse/GERONIMO-1851
> Project: Geronimo
> Type: Bug
> Security: public(Regular issues)
> Components: kernel
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Dain Sundstrom
> Priority: Critical
> Fix For: 1.1
>
> If you go to the Import/Export portlet in 1.1, you get this:
> UNEXPECTED ERROR for class
> org.apache.geronimo.jetty.JettyWebAppContext$$EnhancerByCGLIB$$1b72c5bb
> (geronimo/welcome-jetty/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=geronimo/welcome-jetty/1.1-SNAPSHOT/car)
> java.lang.ArrayIndexOutOfBoundsException: -1
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.createGBeanInvokers(ProxyMethodInterceptor.java:116)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.(ProxyMethodInterceptor.java:70)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager.getMethodInterceptor(BasicProxyManager.java:317)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactory.createProxy(BasicProxyManager.java:290)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicProxyManager.java:179)
> at
> org.apache.geronimo.console.util.KernelManagementHelper.getModuleForConfiguration(KernelManagementHelper.java:850)
> The error is generated at the last line of this snippet of
> ProxyMethodInterceptor:
> invokers[getSuperIndex(proxyType, proxyType.getMethod("equals",
> new Class[]{Object.class}))] = new EqualsInvoke(kernel);
> invokers[getSuperIndex(proxyType, proxyType.getMethod("hashCode",
> null))] = new HashCodeInvoke();
> invokers[getSuperIndex(proxyType, proxyType.getMethod("toString",
> null))] = new ToStringInvoke(proxyType.getName());
> if(GeronimoManagedBean.class.isAssignableFrom(proxyType)) {
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getState", null))] = new GetStateInvoke(kernel);
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getStateInstance", null))] = new
> GetStateInstanceInvoke(kernel);
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("start", null))] = new StartInvoke(kernel);
> In other words, it is returning a -1 from getSuperIndex on the "start()"
> method for the proxyType. However, the "if" statement established that
> ProxyType is assignable to GeronimoManagedBean, which has a "start()" method.
> So it seems like the logic that constructs the invokers and/or whatever
> getSuperIndex uses is not finding all the methods that the proxy exposes, or
> else there are some classloader issues causing identical methods to be
> detected as different, etc.
> The logic displayed above is unchanged from HEAD where the same portlet
> works, though the portlet code has changed significantly. I'm not sure
> what's different elsewhere in the ProxyMethodInterceptor class or the rest of
> the proxy infrastructure.
> To replicate this, start Geronimo, and click the "Plugins" entry in the
> console.
--
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-1851) Proxy logic busted
[ http://issues.apache.org/jira/browse/GERONIMO-1851?page=all ]
Aaron Mulder reassigned GERONIMO-1851:
--
Assign To: Dain Sundstrom
> Proxy logic busted
> --
>
> Key: GERONIMO-1851
> URL: http://issues.apache.org/jira/browse/GERONIMO-1851
> Project: Geronimo
> Type: Bug
> Security: public(Regular issues)
> Components: kernel
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Dain Sundstrom
> Priority: Critical
> Fix For: 1.1
>
> If you go to the Import/Export portlet in 1.1, you get this:
> UNEXPECTED ERROR for class
> org.apache.geronimo.jetty.JettyWebAppContext$$EnhancerByCGLIB$$1b72c5bb
> (geronimo/welcome-jetty/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=geronimo/welcome-jetty/1.1-SNAPSHOT/car)
> java.lang.ArrayIndexOutOfBoundsException: -1
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.createGBeanInvokers(ProxyMethodInterceptor.java:116)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.(ProxyMethodInterceptor.java:70)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager.getMethodInterceptor(BasicProxyManager.java:317)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactory.createProxy(BasicProxyManager.java:290)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicProxyManager.java:179)
> at
> org.apache.geronimo.console.util.KernelManagementHelper.getModuleForConfiguration(KernelManagementHelper.java:850)
> The error is generated at the last line of this snippet of
> ProxyMethodInterceptor:
> invokers[getSuperIndex(proxyType, proxyType.getMethod("equals",
> new Class[]{Object.class}))] = new EqualsInvoke(kernel);
> invokers[getSuperIndex(proxyType, proxyType.getMethod("hashCode",
> null))] = new HashCodeInvoke();
> invokers[getSuperIndex(proxyType, proxyType.getMethod("toString",
> null))] = new ToStringInvoke(proxyType.getName());
> if(GeronimoManagedBean.class.isAssignableFrom(proxyType)) {
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getState", null))] = new GetStateInvoke(kernel);
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getStateInstance", null))] = new
> GetStateInstanceInvoke(kernel);
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("start", null))] = new StartInvoke(kernel);
> In other words, it is returning a -1 from getSuperIndex on the "start()"
> method for the proxyType. However, the "if" statement established that
> ProxyType is assignable to GeronimoManagedBean, which has a "start()" method.
> So it seems like the logic that constructs the invokers and/or whatever
> getSuperIndex uses is not finding all the methods that the proxy exposes, or
> else there are some classloader issues causing identical methods to be
> detected as different, etc.
> The logic displayed above is unchanged from HEAD where the same portlet
> works, though the portlet code has changed significantly. I'm not sure
> what's different elsewhere in the ProxyMethodInterceptor class or the rest of
> the proxy infrastructure.
> To replicate this, start Geronimo, and click the "Plugins" entry in the
> console.
--
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-1851) Proxy logic busted
[
http://issues.apache.org/jira/browse/GERONIMO-1851?page=comments#action_12374585
]
Aaron Mulder commented on GERONIMO-1851:
Appears to be caused by BasicProxyManager.createProxy(name, ClassLoader) to
include classes with an empty constructor in addition to interfaces. I'm
removing the bit about classes with empty constructors and doing a full build
with tests, and if it works, checking it in.
> Proxy logic busted
> --
>
> Key: GERONIMO-1851
> URL: http://issues.apache.org/jira/browse/GERONIMO-1851
> Project: Geronimo
> Type: Bug
> Security: public(Regular issues)
> Components: kernel
> Versions: 1.1
> Reporter: Aaron Mulder
> Priority: Critical
> Fix For: 1.1
>
> If you go to the Import/Export portlet in 1.1, you get this:
> UNEXPECTED ERROR for class
> org.apache.geronimo.jetty.JettyWebAppContext$$EnhancerByCGLIB$$1b72c5bb
> (geronimo/welcome-jetty/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=geronimo/welcome-jetty/1.1-SNAPSHOT/car)
> java.lang.ArrayIndexOutOfBoundsException: -1
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.createGBeanInvokers(ProxyMethodInterceptor.java:116)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.(ProxyMethodInterceptor.java:70)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager.getMethodInterceptor(BasicProxyManager.java:317)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactory.createProxy(BasicProxyManager.java:290)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicProxyManager.java:179)
> at
> org.apache.geronimo.console.util.KernelManagementHelper.getModuleForConfiguration(KernelManagementHelper.java:850)
> The error is generated at the last line of this snippet of
> ProxyMethodInterceptor:
> invokers[getSuperIndex(proxyType, proxyType.getMethod("equals",
> new Class[]{Object.class}))] = new EqualsInvoke(kernel);
> invokers[getSuperIndex(proxyType, proxyType.getMethod("hashCode",
> null))] = new HashCodeInvoke();
> invokers[getSuperIndex(proxyType, proxyType.getMethod("toString",
> null))] = new ToStringInvoke(proxyType.getName());
> if(GeronimoManagedBean.class.isAssignableFrom(proxyType)) {
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getState", null))] = new GetStateInvoke(kernel);
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getStateInstance", null))] = new
> GetStateInstanceInvoke(kernel);
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("start", null))] = new StartInvoke(kernel);
> In other words, it is returning a -1 from getSuperIndex on the "start()"
> method for the proxyType. However, the "if" statement established that
> ProxyType is assignable to GeronimoManagedBean, which has a "start()" method.
> So it seems like the logic that constructs the invokers and/or whatever
> getSuperIndex uses is not finding all the methods that the proxy exposes, or
> else there are some classloader issues causing identical methods to be
> detected as different, etc.
> The logic displayed above is unchanged from HEAD where the same portlet
> works, though the portlet code has changed significantly. I'm not sure
> what's different elsewhere in the ProxyMethodInterceptor class or the rest of
> the proxy infrastructure.
> To replicate this, start Geronimo, and click the "Plugins" entry in the
> console.
--
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-1851) Proxy logic busted
[
http://issues.apache.org/jira/browse/GERONIMO-1851?page=comments#action_12374584
]
Aaron Mulder commented on GERONIMO-1851:
Appears to be caused by the proxy including implementation methods as well as
interface methods -- JettyWebAppContext extends org.mortbay.util.Container
which has a start() method, and that's getting found in preference to the
start() method in the GeronimoManagedBean interface.
> Proxy logic busted
> --
>
> Key: GERONIMO-1851
> URL: http://issues.apache.org/jira/browse/GERONIMO-1851
> Project: Geronimo
> Type: Bug
> Security: public(Regular issues)
> Components: kernel
> Versions: 1.1
> Reporter: Aaron Mulder
> Priority: Critical
> Fix For: 1.1
>
> If you go to the Import/Export portlet in 1.1, you get this:
> UNEXPECTED ERROR for class
> org.apache.geronimo.jetty.JettyWebAppContext$$EnhancerByCGLIB$$1b72c5bb
> (geronimo/welcome-jetty/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=geronimo/welcome-jetty/1.1-SNAPSHOT/car)
> java.lang.ArrayIndexOutOfBoundsException: -1
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.createGBeanInvokers(ProxyMethodInterceptor.java:116)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.(ProxyMethodInterceptor.java:70)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager.getMethodInterceptor(BasicProxyManager.java:317)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactory.createProxy(BasicProxyManager.java:290)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicProxyManager.java:179)
> at
> org.apache.geronimo.console.util.KernelManagementHelper.getModuleForConfiguration(KernelManagementHelper.java:850)
> The error is generated at the last line of this snippet of
> ProxyMethodInterceptor:
> invokers[getSuperIndex(proxyType, proxyType.getMethod("equals",
> new Class[]{Object.class}))] = new EqualsInvoke(kernel);
> invokers[getSuperIndex(proxyType, proxyType.getMethod("hashCode",
> null))] = new HashCodeInvoke();
> invokers[getSuperIndex(proxyType, proxyType.getMethod("toString",
> null))] = new ToStringInvoke(proxyType.getName());
> if(GeronimoManagedBean.class.isAssignableFrom(proxyType)) {
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getState", null))] = new GetStateInvoke(kernel);
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getStateInstance", null))] = new
> GetStateInstanceInvoke(kernel);
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("start", null))] = new StartInvoke(kernel);
> In other words, it is returning a -1 from getSuperIndex on the "start()"
> method for the proxyType. However, the "if" statement established that
> ProxyType is assignable to GeronimoManagedBean, which has a "start()" method.
> So it seems like the logic that constructs the invokers and/or whatever
> getSuperIndex uses is not finding all the methods that the proxy exposes, or
> else there are some classloader issues causing identical methods to be
> detected as different, etc.
> The logic displayed above is unchanged from HEAD where the same portlet
> works, though the portlet code has changed significantly. I'm not sure
> what's different elsewhere in the ProxyMethodInterceptor class or the rest of
> the proxy infrastructure.
> To replicate this, start Geronimo, and click the "Plugins" entry in the
> console.
--
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-1853) modules/j2ee DomainTest failure
modules/j2ee DomainTest failure --- Key: GERONIMO-1853 URL: http://issues.apache.org/jira/browse/GERONIMO-1853 Project: Geronimo Type: Bug Security: public (Regular issues) Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1 Looks like the components in the AbstractNames are being transposed -- the errors are is not equal to -- 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-1852) Configuration and Kernel may differ on what gbeans are installed
Configuration and Kernel may differ on what gbeans are installed Key: GERONIMO-1852 URL: http://issues.apache.org/jira/browse/GERONIMO-1852 Project: Geronimo Type: Bug Security: public (Regular issues) Components: kernel Versions: 1.1 Reporter: David Jencks Assigned to: Dain Sundstrom Fix For: 1.1 A configuration always says it contains the gbeans that it was configured with (possibly adding more dynamically) and does not take into account the modifications (load='false" to remove, or added gbeans) from the local attribute store. This messes up attempts to resolve single valued references. One possible solution would be to supply the attribute manager to the configuration constructor and let it mess with the gbeans right then and there. -- 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-1851) Proxy logic busted
Proxy logic busted
--
Key: GERONIMO-1851
URL: http://issues.apache.org/jira/browse/GERONIMO-1851
Project: Geronimo
Type: Bug
Security: public (Regular issues)
Components: kernel
Versions: 1.1
Reporter: Aaron Mulder
Priority: Critical
Fix For: 1.1
If you go to the Import/Export portlet in 1.1, you get this:
UNEXPECTED ERROR for class
org.apache.geronimo.jetty.JettyWebAppContext$$EnhancerByCGLIB$$1b72c5bb
(geronimo/welcome-jetty/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=geronimo/welcome-jetty/1.1-SNAPSHOT/car)
java.lang.ArrayIndexOutOfBoundsException: -1
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.createGBeanInvokers(ProxyMethodInterceptor.java:116)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.(ProxyMethodInterceptor.java:70)
at
org.apache.geronimo.kernel.basic.BasicProxyManager.getMethodInterceptor(BasicProxyManager.java:317)
at
org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactory.createProxy(BasicProxyManager.java:290)
at
org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicProxyManager.java:179)
at
org.apache.geronimo.console.util.KernelManagementHelper.getModuleForConfiguration(KernelManagementHelper.java:850)
The error is generated at the last line of this snippet of
ProxyMethodInterceptor:
invokers[getSuperIndex(proxyType, proxyType.getMethod("equals", new
Class[]{Object.class}))] = new EqualsInvoke(kernel);
invokers[getSuperIndex(proxyType, proxyType.getMethod("hashCode",
null))] = new HashCodeInvoke();
invokers[getSuperIndex(proxyType, proxyType.getMethod("toString",
null))] = new ToStringInvoke(proxyType.getName());
if(GeronimoManagedBean.class.isAssignableFrom(proxyType)) {
invokers[getSuperIndex(proxyType,
proxyType.getMethod("getState", null))] = new GetStateInvoke(kernel);
invokers[getSuperIndex(proxyType,
proxyType.getMethod("getStateInstance", null))] = new
GetStateInstanceInvoke(kernel);
invokers[getSuperIndex(proxyType, proxyType.getMethod("start",
null))] = new StartInvoke(kernel);
In other words, it is returning a -1 from getSuperIndex on the "start()" method
for the proxyType. However, the "if" statement established that ProxyType is
assignable to GeronimoManagedBean, which has a "start()" method.
So it seems like the logic that constructs the invokers and/or whatever
getSuperIndex uses is not finding all the methods that the proxy exposes, or
else there are some classloader issues causing identical methods to be detected
as different, etc.
The logic displayed above is unchanged from HEAD where the same portlet works,
though the portlet code has changed significantly. I'm not sure what's
different elsewhere in the ProxyMethodInterceptor class or the rest of the
proxy infrastructure.
To replicate this, start Geronimo, and click the "Plugins" entry in the console.
--
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-1850) environment merge problem between ear and ejb modules (at least)
environment merge problem between ear and ejb modules (at least) Key: GERONIMO-1850 URL: http://issues.apache.org/jira/browse/GERONIMO-1850 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 something's wrong with merging the environment from an ejb module back into the environment for the ear that contains it: the imports from the ejb module aren't showing up in the ear imports. -- 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-1849) Attribute Manager broken WRT Reference
Attribute Manager broken WRT Reference -- Key: GERONIMO-1849 URL: http://issues.apache.org/jira/browse/GERONIMO-1849 Project: Geronimo Type: Bug Security: public (Regular issues) Components: kernel Versions: 1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1 Discovered for a new GBean generated at runtime with a reference. For a reference to ServerInfo (a single-valued reference, which can use the exact abstract name of the target), you get this: AbstractName used as the value of the reference: geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ServerInfo Reference to ServerInfo written into the GBean definition in config.xml: geronimo j2ee-system 1.1-SNAPSHOT car ServerInfo geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ServerInfo# Note these things: - The AbstractNameQuery is written as plain text after the with a # on the end - The pattern chunks do not hold the ServiceModule (though it could be calculated) or j2eeType (which would just be lost), so they cannot be used to reconstruct the full AbstractName / AbstractNameQuery / Pattern - The code also looks for a "module" in the AbstractName to write a element in the pattern, but there is not "module" in the AbstractName in question (should that be the ServiceModule?) - Many abstract names hold significantly more components than the ServiceName does due to JSR-77 requirements (application name, parent component name, parent component type, etc.), so it's not clear that any hardcoded set of elements can capture the variety of possible abstract names - The schema at modules/system/src/schema/local-attribute.xsd bears little relation to the syntax currently used in the generated config.xml file, which is not validated when written or read To reproduce this, start Geronimo, go to the "Keystores" portlet in the console, click "New Keystore", enter a file name and password, submit it, and wait a few seconds for it to be written to config.xml (there will be a new FileKeystoreInstance GBean in the j2ee-security configuration). -- 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
1.1 Update
Looks like were making good progress in shaking out the bugs in 1.1. I was hoping to code freeze today but it doesn't look like we're going to make it as there are lots of bugs still to chase. I think the timeline for the release is still the end of April assuming we can get all the testing and certification completed. Please refrain from updating packages and versions until we get trhough a good CTS run. Thanks for chugging guys. Matt
Re: Geronimo peak performance
Whoops from: http://blogs.sun.com/roller/page/travi?entry=ultrasparc_t1_utilization_explained The script I was referring to was corestat. Thanks, Jeff Rainer Jung wrote: > When preparing for the test, have a look at the very interesting > cpustat/cputrack. Without this you won't really be able to judge on the > cpu usage. Classical tools like sar/vmstat/prstat easily lead to wrong > results (the amount of work a single strand [hardware thread] is able to > do is not fixed. It really shares the core with the other strands. If > they stall, it will execute on every cycle, if all 4 strands are busy > each one will only execute on every 4th cycle. So the cpu power > available to a strand is dynamic, but tools like prstat are not able to > show that. > > For memory bus usage busstat is the way to go. > > If you need more info, you could start an off topic thread or mail me > directly. > > Rainer > > Jeff Genender wrote: >> Yep...each core will handle 4 hardware threads. It was built for >> multiple threads and a JVM (multithreaded of course) is made for this >> box. For an appserver under load, I think the numbers should be >> impressive on this box. >> >> The cool thing about this machine is, each core is viewed as 4 cpus. >> That means this box looks like it has 16 CPUs running (4 cores x 4 >> hardware threads)! >> >> I can't wait to pound on this and see what it can do. I am going to >> have T2000->T2000 trials going on to maximize the throughput for CPU. >> They come with 4 1 Ghz Ethernet ports each, so I am going to pipe these >> up and hopefully there will be zero bottleneck on IO.
Re: Geronimo peak performance
Rainer, Would you have a perl script similar to this?: http://blogs.sun.com/roller/page/travi?entry=ultrasparc_t1_utilization_explained The guy describes, it but doesn't offer it. Thanks, Jeff Rainer Jung wrote: > When preparing for the test, have a look at the very interesting > cpustat/cputrack. Without this you won't really be able to judge on the > cpu usage. Classical tools like sar/vmstat/prstat easily lead to wrong > results (the amount of work a single strand [hardware thread] is able to > do is not fixed. It really shares the core with the other strands. If > they stall, it will execute on every cycle, if all 4 strands are busy > each one will only execute on every 4th cycle. So the cpu power > available to a strand is dynamic, but tools like prstat are not able to > show that. > > For memory bus usage busstat is the way to go. > > If you need more info, you could start an off topic thread or mail me > directly. > > Rainer > > Jeff Genender wrote: >> Yep...each core will handle 4 hardware threads. It was built for >> multiple threads and a JVM (multithreaded of course) is made for this >> box. For an appserver under load, I think the numbers should be >> impressive on this box. >> >> The cool thing about this machine is, each core is viewed as 4 cpus. >> That means this box looks like it has 16 CPUs running (4 cores x 4 >> hardware threads)! >> >> I can't wait to pound on this and see what it can do. I am going to >> have T2000->T2000 trials going on to maximize the throughput for CPU. >> They come with 4 1 Ghz Ethernet ports each, so I am going to pipe these >> up and hopefully there will be zero bottleneck on IO.
Unable to deploy simple Tapestry app.
Hello... I'm having some issues deploying a simple Tapestry application to Geronimo. I'm trying to keep it as simple as I can... no geronimo-web.xml. So, Tapestry is tightly coupled with Hivemind, and Hivemind is complaining... telling me "Module hivemind is duplicated!". It would appear to me that this seems like a class loading issue with Geronimo. Evidently, the hivemind-1.1.jar library that's bundled in the war is getting deployed twice or something like that. To give you an brief idea of what's going on here, the Tapestry bootstrap process is attempting to get all of these hivemodule.xml files loaded by iterating over a Collection of them. That is what's happening every time 'RegistryInfrastructureConstructor.addModuleDescriptor' is getting called. So, right before I get the following stack strace, I see some debug level logging coming out of the hivemind code saying '12:54:13,609 DEBUG [RegistryBuilder] Processing module hivemind'. That is the 2nd time I see that, hence the problem...it got it loaded the 1st time, and is now puking. Here's the stacktrace. I'm gonna post to the Tapestry list as well and see if they've got anything to say about it. Thanks in advance for any thoughts org.apache.hivemind.ApplicationRuntimeException: Error: Module hivemind is duplicated! Definition in jar:file:/C:/tools/geronimo-1.2-SNAPSHOT/config-store/42/war/WEB-INF/lib/hivemind-1.1.jar!/META-INF/hivemodule.xml has been ignored in favor of existing definition from jar:file:/C:/tools/geronimo-1.2-SNAPSHOT/config-store/42/war/WEB-INF/lib/hivemind-1.1.jar!/META-INF/hivemodule.xml. org.apache.hivemind.impl.StrictErrorHandler.error(StrictErrorHandler.java:39) org.apache.hivemind.impl.RegistryInfrastructureConstructor.addModuleDescriptor(RegistryInfrastructureConstructor.java:202) org.apache.hivemind.impl.RegistryBuilder.processModuleDescriptorProvider(RegistryBuilder.java:168) org.apache.hivemind.impl.RegistryBuilder.constructRegistry(RegistryBuilder.java:143) org.apache.tapestry.ApplicationServlet.constructRegistry(ApplicationServlet.java:253) org.apache.tapestry.ApplicationServlet.init(ApplicationServlet.java:194) org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105) org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3915) org.apache.catalina.core.StandardContext.start(StandardContext.java:4176) org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:66) org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:270) org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:185) org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287) org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke() net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$7af7fb0d.addContext() org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:416) org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke() net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) org.apache.geronimo.gbean.runtime.GBeanInstance.inv
Re: Geronimo Documentation update
lol, yup, we will not be blowing anyting :D Thanks for the quick reply Cheers! Hernan [EMAIL PROTECTED] wrote: Under "Sample Application" In this article we will be exploding Geronimo's Struts support by building and deploying the JPetStore 5.0 sample application. I assume that we are actually *exploring* Geronimo's Struts support, and that no incendiary devices are involved in this tutorial... Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 Hernan Cunico <[EMAIL PROTECTED]To: dev , user@geronimo.apache.org m> cc: Subject: Geronimo Documentation update 04/14/2006 03:12 PM Please respond to dev Hi All, Here is an update to the documentation. I found surprisingly easy to deploy JPetstore/Struts. It would be great to add more dev related details about using this framework, any volunteers? :) http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Struts Cheers! Hernan
Re: Geronimo Documentation update
Under "Sample Application" In this article we will be exploding Geronimo's Struts support by building and deploying the JPetStore 5.0 sample application. I assume that we are actually *exploring* Geronimo's Struts support, and that no incendiary devices are involved in this tutorial... Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 Hernan Cunico <[EMAIL PROTECTED]To: dev , user@geronimo.apache.org m> cc: Subject: Geronimo Documentation update 04/14/2006 03:12 PM Please respond to dev Hi All, Here is an update to the documentation. I found surprisingly easy to deploy JPetstore/Struts. It would be great to add more dev related details about using this framework, any volunteers? :) http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Struts Cheers! Hernan
Geronimo Documentation update
Hi All, Here is an update to the documentation. I found surprisingly easy to deploy JPetstore/Struts. It would be great to add more dev related details about using this framework, any volunteers? :) http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Struts Cheers! Hernan
[jira] Commented: (GERONIMO-1844) Precompile jsp pages in console
[ http://issues.apache.org/jira/browse/GERONIMO-1844?page=comments#action_12374557 ] Prasad Kashyap commented on GERONIMO-1844: -- http://www.mail-archive.com/dev@geronimo.apache.org/msg20607.html > Precompile jsp pages in console > --- > > Key: GERONIMO-1844 > URL: http://issues.apache.org/jira/browse/GERONIMO-1844 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: console > Reporter: Dain Sundstrom > Assignee: Prasad Kashyap > Fix For: 1.1 > Attachments: jsp-precompile.patch > > The maven script for precompiling jsp pages in console-framework and > console-standard is broken so I commented it out. The following article > explains how to use jsp precompliation: > http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html > In addition to this, we need to jar the compiled files to reduce the overall > path length. -- 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-1844) Precompile jsp pages in console
[ http://issues.apache.org/jira/browse/GERONIMO-1844?page=all ] Prasad Kashyap updated GERONIMO-1844: - Attachment: jsp-precompile.patch > Precompile jsp pages in console > --- > > Key: GERONIMO-1844 > URL: http://issues.apache.org/jira/browse/GERONIMO-1844 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: console > Reporter: Dain Sundstrom > Assignee: Prasad Kashyap > Fix For: 1.1 > Attachments: jsp-precompile.patch > > The maven script for precompiling jsp pages in console-framework and > console-standard is broken so I commented it out. The following article > explains how to use jsp precompliation: > http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html > In addition to this, we need to jar the compiled files to reduce the overall > path length. -- 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: Update on Long Paths
I could not use the ant task to precompile jsps. Using the following, simply nothing happens. So by passing a few more args to our existing execution, I was able to generate the xml file too. Using the option addWebXmlMappings, I tried to merge the web.xmls but JspC cried that it was a unrecognized option. Looking at the JspC code, http://svn.apache.org/repos/asf/tomcat/jasper/branches/tc5.0.x/jasper2/src/share/org/apache/jasper/JspC.java it seems like you can't pass addWebXmlMappings in a java command line argument. It is not recognized or set by the setArgs(). Seems like a jasper bug ? So I added another goal to our deployment plugin called "mergeWebXML". This goal merges the generated web.xml fragment with the existing one from source. When I spoke to the Tomcat guys, they feel that precompiling JSPs doesn't buy us anything anymore, except for that first time hit. The request mapper is supposedly fixed in 5.5.x versions and thus we shouldn't see any other performance hit. Anyways, I have uploaded the patch to http://issues.apache.org/jira/browse/GERONIMO-1844 Cheers Prasad On 4/14/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > OK. I'll take care of the JSP pages. I am done with jar'ing the > generated class files. I shall look into generating a web.xml and > merging it. > > Cheers > Prasad > > On 4/13/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > > Prasad got the patch working on all web applications. The next big > > offenders left are the auto generated WebServices wrapper class and > > the precompiled JSP pages. David Jencks has a patch for the > > WebServices class, but we are waiting to get the TCK running so we > > can judge the impact. I disabled precompiled JSP pages, as they > > didn't work anyway. We generate the classes and compile them, but we > > never added them to the class path and we are not merging generated- > > web.xml into our web.xml. I'm hoping Prasad has time to tackle this > > one. > > > > With these patches in, except for the WS class, the longest paths > > including server name is 224 and 217 characters: > > > > geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-jetty- > > streamer-client/1.1-SNAPSHOT/daytrader-derby-jetty-streamer- > > client-1.1-SNAPSHOT.car/activemq/activemq-ra/3.2.4-SNAPSHOT/rar/ > > activemq-optional-3.2.4-SNAPSHOT.jar > > geronimo-1.1-SNAPSHOT/repository/geronimo/webconsole-jetty/1.1- > > SNAPSHOT/webconsole-jetty-1.1-SNAPSHOT.car/geronimo-console- > > framework-1.1-SNAPSHOT.war/WEB-INF/config/services/ > > PortletDefinitionRegistryService.properties > > > > These will become 179 and 189 characters when we drop -SNAPSHOT from > > all of the version numbers. I'm also hoping we can change the name > > daytrader-derby-jetty-streamer-client to something shorter. > > > > This is a lot better and will allow for at least 50 characters of > > head room, which I hope is plenty for windows users. > > > > > > As for next steps, I'd like to get the hot deploy service working > > better. With the addition of the in-place deployment feature from > > Gianny and the timestamp I added to the configuration, we should be > > able to write a much better service. Once we have the better hot > > deploy service, we will be able to implement the flat deployment > > model that Hernan and others have suggested. > > > > -dain > > > > > > > > > > > > > > >
[jira] Created: (GERONIMO-1848) Shared Library support via a GBean
Shared Library support via a GBean -- Key: GERONIMO-1848 URL: http://issues.apache.org/jira/browse/GERONIMO-1848 Project: Geronimo Type: New Feature Security: public (Regular issues) Components: deployment Versions: 1.1 Environment: all Reporter: Joe Bohn Assigned to: Joe Bohn Fix For: 1.1 Expose the functionality that Dain introduced for shared libraries extending the MultiParentClassLoader. This particular change introduces a GBean (sharedlib) that accepts parameters to extend the multiparent class loader with the location of jars or classes. The GBean calls out rmi-naming as a parent dependency to pull in as few extraneous classes as possible. An application would exploit this function by creating a parent dependency on the sharedlib GBean and add the common jars/classes to the shared directories (by default var/shared/lib and var/shared/classes). The config.xml can be updated to point to different or additional locations for shared content. -- 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: XML indent
same for me - sachin On Apr 14, 2006, at 1:41 PM, Jacek Laskowski wrote: On 4/14/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Why are all of the m2 pom.xml indented with 2 spaces instead of the 4 spaces as the conventions specify? I believe we should follow the conventions that have been set and use 4 spaces. I believe it's me for I set up Eclipse this way. Will fix it in the next commit. Sorry and thanks for a head-up! --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: XML indent
On 4/14/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > Why are all of the m2 pom.xml indented with 2 spaces instead of the 4 > spaces as the conventions specify? > > I believe we should follow the conventions that have been set and use > 4 spaces. I believe it's me for I set up Eclipse this way. Will fix it in the next commit. Sorry and thanks for a head-up! > --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Openwire C client issue
Most of the effort has been focused on the C++ impl lately. :( On 4/13/06, Dhawan, Vikram (LNG-DAY) <[EMAIL PROTECTED]> wrote: > Hi Hiram, > > Is any one maintaining working copy of that code now? I tried to add that > command type in the header that didn't worked either. > > Thanks! > > Vik > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram > Chirino > Sent: Thursday, April 13, 2006 1:09 PM > To: activemq-dev@geronimo.apache.org > Subject: Re: Openwire C client issue > > looks like some new command types were added but we forgot to add them > to the header file that defines the id of command types. > > On 4/13/06, Dhawan, Vikram (LNG-DAY) <[EMAIL PROTECTED]> wrote: > > Hi Hiram, > > > > I saw that it was your initiative to write the openwire C client. For the > > following issue I was kind of hoping a direction. I am not sure if you > > delegated this responsibility to some other team member. > > > > I will really appreciate if I can get a help in understanding what is > > happening in this code. > > > > Thanks! > > > > Vik > > -Original Message- > > From: vik Dhawan [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 12, 2006 1:36 AM > > To: activemq-dev@geronimo.apache.org > > Subject: Openwire C client issue > > > > > > Hi, > > > > When i am trying to build Openwire C client i am getting following errors > in > > ow_commands_v1.c. > > > > CC -mt -D_REENTRANT -DNO_SSL -DSAPI_LINUX -DOS_LINUX_2_2 -DEFX -DLINUX > > -D_GNU_SOURCE -DADDR_SRV -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 > > -DHTREE -I../libactivemq -I../libopenwire -I/usr/local/apr/include/apr-1 > > -L/usr/local/apr/lib-c -o ow_commands_v1.o > > ../libopenwire/ow_commands_v1.c > > "../libopenwire/ow_commands_v1.c", line 416: Error: OW_FLUSHCOMMAND_TYPE > is > > not defined. > > "../libopenwire/ow_commands_v1.c", line 416: Error: An integer constant > > expression is required for a case label. > > "../libopenwire/ow_commands_v1.c", line 1580: Error: OW_FLUSHCOMMAND_TYPE > is > > not defined. > > "../libopenwire/ow_commands_v1.c", line 1580: Error: An integer constant > > expression is required for a case label. > > "../libopenwire/ow_commands_v1.c", line 1591: Error: OW_FLUSHCOMMAND_TYPE > is > > not defined. > > "../libopenwire/ow_commands_v1.c", line 2533: Error: OW_FLUSHCOMMAND_TYPE > is > > not defined. > > "../libopenwire/ow_commands_v1.c", line 2533: Error: An integer constant > > expression is required for a case label. > > "../libopenwire/ow_commands_v1.c", line 2533: Error: Case label defined > > twice. > > "../libopenwire/ow_commands_v1.c", line 2586: Error: OW_FLUSHCOMMAND_TYPE > is > > not defined. > > "../libopenwire/ow_commands_v1.c", line 2586: Error: An integer constant > > expression is required for a case label. > > "../libopenwire/ow_commands_v1.c", line 2586: Error: Case label defined > > twice. > > "../libopenwire/ow_commands_v1.c", line 2639: Error: OW_FLUSHCOMMAND_TYPE > is > > not defined. > > "../libopenwire/ow_commands_v1.c", line 2639: Error: An integer constant > > expression is required for a case label. > > "../libopenwire/ow_commands_v1.c", line 2639: Error: Case label defined > > twice. > > "../libopenwire/ow_commands_v1.c", line 2692: Error: OW_FLUSHCOMMAND_TYPE > is > > not defined. > > "../libopenwire/ow_commands_v1.c", line 2692: Error: An integer constant > > expression is required for a case label. > > "../libopenwire/ow_commands_v1.c", line 2692: Error: Case label defined > > twice. > > > > > > Any insight > > > > Thanks! > > > > -- > > View this message in context: > > http://www.nabble.com/Openwire-C-client-issue-t1436230.html#a3875953 > > Sent from the ActiveMQ - Dev forum at Nabble.com. > > > > > -- > Regards, > Hiram > -- Regards, Hiram
RE: STOMP bytes messages
Oops ... sorry about that :). I'm at work right now and don't have access to the code - I'll get it to you this evening. Do you have an eclipse environment with the CDT for building C++ projects? ... otherwise I can throw some makefiles together if that's easier for you. Unfortunately, the current version of the code only works with a pthread environment - hopefully you're not on windoze :). Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, April 14, 2006 11:53 AM To: activemq-dev@geronimo.apache.org Subject: Re: STOMP bytes messages Howdy.. now eclipse project files were included in the tar :( On 4/14/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > yep got.. just got a little swamped. Will look into it asap. > > On 4/14/06, Nathan Mittler <[EMAIL PROTECTED]> wrote: > > Hey Hiram, > > Just wanted to see if you received the code I sent you (the first try was > > rejected by the server because of the file size). Let me know if you have > > any trouble compiling/etc. > > > > Nate > > > > > > > -- > Regards, > Hiram > -- Regards, Hiram
[jira] Closed: (GERONIMO-1838) Deploy from CLI throws javax.management.MalformedObjectNameException
[ http://issues.apache.org/jira/browse/GERONIMO-1838?page=all ] David Jencks closed GERONIMO-1838: -- Resolution: Duplicate Duplicates GERONIMO-1828 > Deploy from CLI throws javax.management.MalformedObjectNameException > > > Key: GERONIMO-1838 > URL: http://issues.apache.org/jira/browse/GERONIMO-1838 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Reporter: Dain Sundstrom > Assignee: Aaron Mulder > > $ java -jar > ../../assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/bin/deployer.jar > deploy target/geronimo-welcome-1.1-SNAPSHOT.war > javax.management.MalformedObjectNameException: Invalid value: > 'geronimo.config:name="Unspecified/geronimo-welcome-1.1-SNAPSHOT/1/car"' > at javax.management.ObjectName.parsePropertyValue(ObjectName.java:571) > at > javax.management.ObjectName.convertStringToProperties(ObjectName.java:462) > at javax.management.ObjectName.parse(ObjectName.java:399) > at javax.management.ObjectName.(ObjectName.java:76) > at > org.apache.geronimo.deployment.plugin.local.CommandSupport.loadChildren(CommandSupport.java:326) > at > org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:70) > at java.lang.Thread.run(Thread.java:552) > Error: Operation failed: Invalid value: > 'geronimo.config:name="Unspecified/geronimo-welcome-1.1-SNAPSHOT/1/car"' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [jira] Commented: (AMQ-688) Avoid blocking producers
Rob, Thanks for the heads up. This is a matter of significant interest for us. I'm going to be out until mid next week, but I'd like to hear some more about your plans, so that we can better understand how we can most effectively work together towards this common goal. I'll ping you again next week. Cheers, Chris > -Original Message- > From: Rob Davies (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 13, 2006 3:35 PM > To: activemq-dev@geronimo.apache.org > Subject: [jira] Commented: (AMQ-688) Avoid blocking producers > > [ > https://issues.apache.org/activemq/browse/AMQ-688?page=comment s#action_36051 ] > > Rob Davies commented on AMQ-688: > > > We are investigating changing the model for persisting > messages for 4.1 - at the moment there is a tight coupling > between producers and consumers and we want to de-couple this > - particularly for the persistent messages. The aim is to > have a staged eventing, where messages will be pulled from > storage to fill to a staging area before being dispatched. > This will have an impact on this particular issue, in that > the dispatch models will be separated for persistent and > non-persistent (including non-durable topic subscribers of > persistent messages). - Just wanted to give you a heads up :) > > > Avoid blocking producers > > > > > > Key: AMQ-688 > > URL: https://issues.apache.org/activemq/browse/AMQ-688 > > Project: ActiveMQ > > Type: New Feature > > > Components: Broker > > Versions: 4.0 RC 2 > > Reporter: Christopher A. Larrieu > > Assignee: Christopher A. Larrieu > > Fix For: incubation > > > > > Original Estimate: 8 weeks > > Remaining: 8 weeks > > > > Our main goal > > is to avoid stalled producers by addressing the main > culprit: too many > > undispatched messages in the broker's memory. Our motivation is to > > handle significant --though temporary-- imbalances between > production and consumption rates. > > Reaching this goal entails specific broker modifications: > > 1. When memory gets tight, start dropping undispatched > non-persistent > > messages. This is the first-cut attempt to maintain > throughput of persistent messages. > > Unlike the approach documented at > > http://docs.codehaus.org/display/ACTIVEMQ/Slow+Consumer+Handling, > > the message dropping will only occur after the UsageManager reaches > > capacity. Non-persistent messages in dispatch lists will > be dropped > > according to per-destination policy. Subscriptions can > purge their own messages triggered via callback from the UsageManager. > > 2. Evict messages if memory remains tight, to be fetched > from backing store prior to dispatch. > > ActiveMQ already supports this for persistent messages on > Topics with durable subscriptions. > > If a consumer's prefetch buffer is full, the splash-over messages > > remain as IndirectMessageReference objects in the dispatch > list, with > > the actual message body loaded from store on demand. I > believe we can extend this approach for Queues as well. > > 3. Improve the efficiency with which evicted messages are > loaded back into memory. > > Currently, they are loaded one at a time as needed. It would make > > sense to batch-load message sets periodically. This will require a > > significant shift in responsibilities between objects, since an > > IndirectMessageReference doesn't know about other instances > that can be loaded in mass. > > > > The goal will be to keep each subscription dispatch list > stocked with > > a decent number of messages in-memory to reasonably > trade-off between > > it's consumer's performance and resource usage in the > broker. As with > > everything else, we can implement this as a strategy class with the > > first cut implementing a simple resource allocation > strategy: divvy up > > available memory amongst all subscriptions and keep that > memory filled with messages for dispatch. I envision a > worker task assuming responsibility for keeping these lists filled. > > 4. Even with the above modifications, we still can't entirely avoid > > blocked producers, so we'd like to add client-configurable > time-outs > > to provide a bound for the time a producer can remain stalled. > > Maybe this should be a new attribute of ActiveMQConnection: > > maxProducerFlowControlWait. Calls to UsageManager.waitForSpace can > > take this quantity as an argument. Failure to reach > sufficient space > > for the new message will throw an exception back up the > stack and across the wire, letting the producer know that the > message was not delivered. > > 5. Finally, we need to extend disk support for Topics that > have only > > non-durable subscribers, otherwise their dispatch lists can fill up > > with persistent messages. In order to maintain compliance > with JMS, it would be nice to provide some a
Re: STOMP bytes messages
Howdy.. now eclipse project files were included in the tar :( On 4/14/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > yep got.. just got a little swamped. Will look into it asap. > > On 4/14/06, Nathan Mittler <[EMAIL PROTECTED]> wrote: > > Hey Hiram, > > Just wanted to see if you received the code I sent you (the first try was > > rejected by the server because of the file size). Let me know if you have > > any trouble compiling/etc. > > > > Nate > > > > > > > -- > Regards, > Hiram > -- Regards, Hiram
Re: support for shared libraries/classes in Geronimo 1.1
Some additional information in the description below Joe Bohn wrote: Sorry, I should have described the function a little better. There is one shared library gbean that will enhance the classpath with the jars from any number of shared libraries or shared class directories. It updates the classloader by appending the sharedlibs to the multiparentclassloader (the new sharedlib class and the interaction with the multiparentclassloader is what Dain had already created). The gbean is a child of rmi-naming. An application that wants to use the shared library would call out a dependency on the sharedlib config. Joe Aaron Mulder wrote: I'm not really following your description of how this will work, but this is my thought: - We pick a shared library directory (var/shared/lib is fine with me) and make that the standard. I don't think shared classes are even necessary, though I don't object to having a directory for that too. - If the directory is not present during startup, we create it - By default, application deployments do not see shared libraries - If you put an in the in your plan, then the shared libraries are added to the application class loader I'm imaging there's one "shared library GBean" in the whole server and you set the directory on that in the j2ee-server plan and we don't encourage people to change it (though they could in config.xml I suppose). Is that what you have or are you thinking of one GBean per application deployment? Thanks, Aaron On 4/14/06, Joe Bohn <[EMAIL PROTECTED]> wrote: Dain added some initial support for shared libraries in 1.1 and (with the help of David Jencks) I have a configuration and gbean to make the feature available to applications to use. I'll create a patch for this today for Geronimo 1.1. However, I have a question about how "public" we want this function to be. There has been some concern that we shouldn't encourage the use of shared libraries. The thought is that it is better to use the repository and explicit dependencies. If we include the gbean in the configuration for an assembly then the any specified shared library(ies) or class directory(ies) must exist or an exception is thrown. At the moment I'm using var/shared/lib and var/shared/classes as the defaults. If we just add the gbean to the assemblies without the default libraries then the user will have to update the configuration to use the feature and specify the attributes for the libs or classes. That isn't very user friendly and doesn't provide a "default" location. On the other hand, adding in defaults requires that we also add in the empty directories which is a bit of an advertisement to use them. At the moment, I'm leaning toward adding the default directories. Any recommendations before I create the patch? Joe -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: support for shared libraries/classes in Geronimo 1.1
Sorry, I should have described the function a little better. There is one shared library gbean that will enhance the classpath with the jars from any number of shared libraries or shared class directories. The gbean is a child of rmi-naming. An application that wants to use the shared library would call out a dependency on the sharedlib config. Joe Aaron Mulder wrote: I'm not really following your description of how this will work, but this is my thought: - We pick a shared library directory (var/shared/lib is fine with me) and make that the standard. I don't think shared classes are even necessary, though I don't object to having a directory for that too. - If the directory is not present during startup, we create it - By default, application deployments do not see shared libraries - If you put an in the in your plan, then the shared libraries are added to the application class loader I'm imaging there's one "shared library GBean" in the whole server and you set the directory on that in the j2ee-server plan and we don't encourage people to change it (though they could in config.xml I suppose). Is that what you have or are you thinking of one GBean per application deployment? Thanks, Aaron On 4/14/06, Joe Bohn <[EMAIL PROTECTED]> wrote: Dain added some initial support for shared libraries in 1.1 and (with the help of David Jencks) I have a configuration and gbean to make the feature available to applications to use. I'll create a patch for this today for Geronimo 1.1. However, I have a question about how "public" we want this function to be. There has been some concern that we shouldn't encourage the use of shared libraries. The thought is that it is better to use the repository and explicit dependencies. If we include the gbean in the configuration for an assembly then the any specified shared library(ies) or class directory(ies) must exist or an exception is thrown. At the moment I'm using var/shared/lib and var/shared/classes as the defaults. If we just add the gbean to the assemblies without the default libraries then the user will have to update the configuration to use the feature and specify the attributes for the libs or classes. That isn't very user friendly and doesn't provide a "default" location. On the other hand, adding in defaults requires that we also add in the empty directories which is a bit of an advertisement to use them. At the moment, I'm leaning toward adding the default directories. Any recommendations before I create the patch? Joe -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
[jira] Updated: (GERONIMO-1845) Add minimal-tomcat-server assembly (little-G) to Geronimo 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1845?page=all ] Joe Bohn updated GERONIMO-1845: --- Attachment: 1845_littleG.patch1 geronimo-default After applying the patch the binary file geronimo-default must also be added under assemblies/minimal-tomcat-server/src/var/security/keystores ( I didn't know how to add a binary file to the patch). Please note, this patch only adds the new assembly and some configurations only used by that assembly. It should not affect any other assembly or the tck tests. I'll create a second jira and patch for the configuration changes that make little-G "little" by removing unncessary dependencies. > Add minimal-tomcat-server assembly (little-G) to Geronimo 1.1 > - > > Key: GERONIMO-1845 > URL: http://issues.apache.org/jira/browse/GERONIMO-1845 > Project: Geronimo > Type: New Feature > Security: public(Regular issues) > Components: general > Versions: 1.1 > Environment: all > Reporter: Joe Bohn > Assignee: Joe Bohn > Fix For: 1.1 > Attachments: 1845_littleG.patch1, geronimo-default > > Add minimal-tomcat-server to geronimo 1.1 > This initial jira just adds the assembly, configurations, and other changes > necessary for the basic structure. I'll create another update later with > changes to the various configurations to eliminate unnecessary dependencies > so that the resultant image is closer to 15 meg rather than 30 meg. -- 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: support for shared libraries/classes in Geronimo 1.1
I'm not really following your description of how this will work, but this is my thought: - We pick a shared library directory (var/shared/lib is fine with me) and make that the standard. I don't think shared classes are even necessary, though I don't object to having a directory for that too. - If the directory is not present during startup, we create it - By default, application deployments do not see shared libraries - If you put an in the in your plan, then the shared libraries are added to the application class loader I'm imaging there's one "shared library GBean" in the whole server and you set the directory on that in the j2ee-server plan and we don't encourage people to change it (though they could in config.xml I suppose). Is that what you have or are you thinking of one GBean per application deployment? Thanks, Aaron On 4/14/06, Joe Bohn <[EMAIL PROTECTED]> wrote: > > Dain added some initial support for shared libraries in 1.1 and (with > the help of David Jencks) I have a configuration and gbean to make the > feature available to applications to use. I'll create a patch for this > today for Geronimo 1.1. > > However, I have a question about how "public" we want this function to > be. There has been some concern that we shouldn't encourage the use of > shared libraries. The thought is that it is better to use the > repository and explicit dependencies. > > If we include the gbean in the configuration for an assembly then the > any specified shared library(ies) or class directory(ies) must exist or > an exception is thrown. At the moment I'm using var/shared/lib and > var/shared/classes as the defaults. > > If we just add the gbean to the assemblies without the default libraries > then the user will have to update the configuration to use the feature > and specify the attributes for the libs or classes. That isn't very > user friendly and doesn't provide a "default" location. On the other > hand, adding in defaults requires that we also add in the empty > directories which is a bit of an advertisement to use them. > > At the moment, I'm leaning toward adding the default directories. Any > recommendations before I create the patch? > > Joe > > > -- > Joe Bohn > joe.bohn at earthlink.net > > "He is no fool who gives what he cannot keep, to gain what he cannot > lose." -- Jim Elliot >
Re: unit test failures
Hi Jacek, > It seems not to be a problem any more since we can be ensured you'll > back up our efforts, won't you? ;) Ok, I will try. :) Currently, ApacheDS guys argue about this bug: does it really ApacheDS bug? You may see the discussion at http://issues.apache.org/jira/browse/DIRSERVER-607 2006/4/11, Jacek Laskowski <[EMAIL PROTECTED]>: > On 4/11/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > > However, they use different API since ApacheDS 1.0 > > RC1, some packages are renamed. Some efforts will be required to > > rewrite the Geronimo portion of the code. > > Hi Alexei, > > It seems not to be a problem any more since we can be ensured you'll > back up our efforts, won't you? ;) > > Do you happen to know when they're going to release the fixed version? > Any estimates? > > Jacek -- Alexei Zakharov, Intel Middleware Product Division
support for shared libraries/classes in Geronimo 1.1
Dain added some initial support for shared libraries in 1.1 and (with the help of David Jencks) I have a configuration and gbean to make the feature available to applications to use. I'll create a patch for this today for Geronimo 1.1. However, I have a question about how "public" we want this function to be. There has been some concern that we shouldn't encourage the use of shared libraries. The thought is that it is better to use the repository and explicit dependencies. If we include the gbean in the configuration for an assembly then the any specified shared library(ies) or class directory(ies) must exist or an exception is thrown. At the moment I'm using var/shared/lib and var/shared/classes as the defaults. If we just add the gbean to the assemblies without the default libraries then the user will have to update the configuration to use the feature and specify the attributes for the libs or classes. That isn't very user friendly and doesn't provide a "default" location. On the other hand, adding in defaults requires that we also add in the empty directories which is a bit of an advertisement to use them. At the moment, I'm leaning toward adding the default directories. Any recommendations before I create the patch? Joe -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: ConfigurationInstaller - InvalidConfigurationException in Geronimo 1.1
OK, should start properly now, except I had to disable the Jetty HTTPS connector until I get the keystore configuration straightened out. Thanks, Aaron On 4/14/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > No, it's that the GBeanInfo uses the wrong type for the reference. > But fixing that only led to the next problem which is that the new > entries in config.xml aren't valid. It'll be a minute. > > Thanks, > Aaron > > On 4/14/06, Joe Bohn <[EMAIL PROTECTED]> wrote: > > Scratch that suggestion ... I sent it too soon. > > WriteableListableRepository extends WriteableRepository so that isn't > > the problem. > > > > Joe > > > > Joe Bohn wrote: > > > :-) Hey ... for 2:30 in the morning I'm impressed that it compiles! > > > > > > I think the problem is that the Maven2Repository class implements the > > > WriteableListableRepository interface but not WriteableRepository > > > interface the ConfigurationInstaller gbean needs. > > > > > > Joe > > > > > > > > > Aaron Mulder wrote: > > > > > >> Well come on, man, it builds, what more do you want? > > >> > > >> Aaron > > >> > > >> On 4/14/06, Joe Bohn <[EMAIL PROTECTED]> wrote: > > >> > > >>> I'm getting the following error attempting to start a server with the > > >>> latest 1.1 image. Seems to be related to some changes introduced last > > >>> night for a ConfigurationInstaller gbean. > > >>> > > >>> Booting Geronimo Kernel (in Java 1.4.2_08)... > > >>> [ ] 0% 1s Startup failed > > >>> org.apache.geronimo.kernel.config.InvalidConfigException: Unable to > > >>> resolve reference named Repository in gbean > > >>> geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod > > >>> ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) > > >>> > > >>> at > > >>> org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) > > >>> at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) > > >>> at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) > > >>> Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches > > >>> for referencePatterns: > > >>> [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo > > >>> sitory.WriteableRepository] > > >>> at > > >>> org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) > > >>> > > >>> ... 6 more > > >>> org.apache.geronimo.kernel.config.InvalidConfigException: Unable to > > >>> resolve reference named Repository in gbean > > >>> geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod > > >>> ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) > > >>> > > >>> at > > >>> org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) > > >>> at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) > > >>> at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) > > >>> Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches > > >>> for referencePatterns: > > >>> [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo > > >>> sitory.WriteableRepository] > > >>> at > > >>> org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) > > >>> > > >>> at > > >>> org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) > > >>> > > >>> at > > >>> org.apache.g
[jira] Resolved: (AMQ-661) Bug in FUSE installation
[ http://jira.activemq.org/jira//browse/AMQ-661?page=all ] Rob Davies resolved AMQ-661: Resolution: Won't Fix Unfortunately Apache ActiveMQ is not the right forum for LogicBlaze fuse. Please re-direct any support requests to LogicBlaze directly. > Bug in FUSE installation > > > Key: AMQ-661 > URL: http://jira.activemq.org/jira//browse/AMQ-661 > Project: ActiveMQ > Type: Bug > Environment: I got this error while doing fuse installation.. It seems the > jetty integration with ActiveMQ has some issues > Reporter: Gaurav Agarwal > Attachments: g > > > I got an Unknownhost exception while trying to install FUSE. I could not > figure out where this information was missing. Am attaching the installation > log. Do let me know if anybody can help me with this.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ConfigurationInstaller - InvalidConfigurationException in Geronimo 1.1
No, it's that the GBeanInfo uses the wrong type for the reference. But fixing that only led to the next problem which is that the new entries in config.xml aren't valid. It'll be a minute. Thanks, Aaron On 4/14/06, Joe Bohn <[EMAIL PROTECTED]> wrote: > Scratch that suggestion ... I sent it too soon. > WriteableListableRepository extends WriteableRepository so that isn't > the problem. > > Joe > > Joe Bohn wrote: > > :-) Hey ... for 2:30 in the morning I'm impressed that it compiles! > > > > I think the problem is that the Maven2Repository class implements the > > WriteableListableRepository interface but not WriteableRepository > > interface the ConfigurationInstaller gbean needs. > > > > Joe > > > > > > Aaron Mulder wrote: > > > >> Well come on, man, it builds, what more do you want? > >> > >> Aaron > >> > >> On 4/14/06, Joe Bohn <[EMAIL PROTECTED]> wrote: > >> > >>> I'm getting the following error attempting to start a server with the > >>> latest 1.1 image. Seems to be related to some changes introduced last > >>> night for a ConfigurationInstaller gbean. > >>> > >>> Booting Geronimo Kernel (in Java 1.4.2_08)... > >>> [ ] 0% 1s Startup failed > >>> org.apache.geronimo.kernel.config.InvalidConfigException: Unable to > >>> resolve reference named Repository in gbean > >>> geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod > >>> ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller > >>> > >>> at > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) > >>> > >>> at > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) > >>> > >>> at > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) > >>> > >>> at > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) > >>> > >>> at > >>> org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) > >>> at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) > >>> at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) > >>> Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches > >>> for referencePatterns: > >>> [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo > >>> sitory.WriteableRepository] > >>> at > >>> org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) > >>> > >>> at > >>> org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) > >>> > >>> at > >>> org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) > >>> > >>> at > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) > >>> > >>> ... 6 more > >>> org.apache.geronimo.kernel.config.InvalidConfigException: Unable to > >>> resolve reference named Repository in gbean > >>> geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod > >>> ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller > >>> > >>> at > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) > >>> > >>> at > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) > >>> > >>> at > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) > >>> > >>> at > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) > >>> > >>> at > >>> org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) > >>> at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) > >>> at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) > >>> Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches > >>> for referencePatterns: > >>> [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo > >>> sitory.WriteableRepository] > >>> at > >>> org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) > >>> > >>> at > >>> org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) > >>> > >>> at > >>> org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) > >>> > >>> at > >>> org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) > >>> > >>> ... 6 more > >>> Server shutdown begun > >>> Server shutdown completed > >>> > >>> -- > >>> Joe Bohn > >>> joe.bohn at earthlink.net > >>> > >>> "He is no fool who gives what he cannot keep, to gain what he cannot > >>> lose." -- Jim Elliot > >>> > >> > >> > >> > > > > -- > Joe Bohn > joe.bohn at earthlink.net > > "He i
Re: ConfigurationInstaller - InvalidConfigurationException in Geronimo 1.1
Scratch that suggestion ... I sent it too soon. WriteableListableRepository extends WriteableRepository so that isn't the problem. Joe Joe Bohn wrote: :-) Hey ... for 2:30 in the morning I'm impressed that it compiles! I think the problem is that the Maven2Repository class implements the WriteableListableRepository interface but not WriteableRepository interface the ConfigurationInstaller gbean needs. Joe Aaron Mulder wrote: Well come on, man, it builds, what more do you want? Aaron On 4/14/06, Joe Bohn <[EMAIL PROTECTED]> wrote: I'm getting the following error attempting to start a server with the latest 1.1 image. Seems to be related to some changes introduced last night for a ConfigurationInstaller gbean. Booting Geronimo Kernel (in Java 1.4.2_08)... [ ] 0% 1s Startup failed org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference named Repository in gbean geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo sitory.WriteableRepository] at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) ... 6 more org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference named Repository in gbean geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo sitory.WriteableRepository] at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) ... 6 more Server shutdown begun Server shutdown completed -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: ConfigurationInstaller - InvalidConfigurationException in Geronimo 1.1
:-) Hey ... for 2:30 in the morning I'm impressed that it compiles! I think the problem is that the Maven2Repository class implements the WriteableListableRepository interface but not WriteableRepository interface the ConfigurationInstaller gbean needs. Joe Aaron Mulder wrote: Well come on, man, it builds, what more do you want? Aaron On 4/14/06, Joe Bohn <[EMAIL PROTECTED]> wrote: I'm getting the following error attempting to start a server with the latest 1.1 image. Seems to be related to some changes introduced last night for a ConfigurationInstaller gbean. Booting Geronimo Kernel (in Java 1.4.2_08)... [ ] 0% 1s Startup failed org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference named Repository in gbean geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo sitory.WriteableRepository] at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) ... 6 more org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference named Repository in gbean geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo sitory.WriteableRepository] at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) ... 6 more Server shutdown begun Server shutdown completed -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Tomcat version in G1.1 for clustering
IIRC, 5.5.15 went to backward compatibility... http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED] Perhaps Filip can fill us in on this. If I remember right, the 5.5.9 clustering GBeans will work on forward versions. So I don't think there is a problem there. HEAD has been set to 5.5.15 for quite some time. Nevertheless, it doesn't hurt to try em out ;-) Jeff Dave Colasurdo wrote: > Jeff (et al.), > > Will G1.1 definitely be upgraded to Tomcat 5.5.15? > > IIRC, the clustering deployment plans were quite different for 5.5.9 > -vs- 5.5.12. If we upgrade to 5.5.15, we will likely need a new plan > that accounts for both the webcontainer upgrade as well as the new G1.1 > plan format.. > > Thanks > -Dave- > > Jeff Genender wrote: >> Thanks Rainer. But I think 5.5.15 will be the one for 1.1. But >> possibly 5.5.17 for 1.2 ;-) >> >> Jeff >> >> Rainer Jung wrote: >>> Just for your information: 5.5.16 was released a couple of weeks ago, >>> but has some problems with de delivered packaginf of examples app under >>> windows. >>> >>> 5.5.17 is expected to be cut on friday and voted stable eventually 1-2 >>> weeks later. >>> >>> Jeff Genender wrote: Yep...need to update the plan. Its updated in trunk. Dave Colasurdo wrote: > It appears that G1.1 is still using Tomcat 5.5.9 > > http://svn.apache.org/repos/asf/geronimo/branches/1.1/etc/project.properties > > > > > > Wasn't a tomcat upgrade to 5.5.15 in plan for G1.1?? Perhaps I am > confused with the plans for trunk.. ?? > > Thanks > -Dave- >> >>
Re: ConfigurationInstaller - InvalidConfigurationException in Geronimo 1.1
Well come on, man, it builds, what more do you want? Aaron On 4/14/06, Joe Bohn <[EMAIL PROTECTED]> wrote: > I'm getting the following error attempting to start a server with the > latest 1.1 image. Seems to be related to some changes introduced last > night for a ConfigurationInstaller gbean. > > Booting Geronimo Kernel (in Java 1.4.2_08)... > [ ] 0% 1s Startup failed > org.apache.geronimo.kernel.config.InvalidConfigException: Unable to > resolve reference named Repository in gbean > geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod > ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller > at > org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) > at > org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) > at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) > at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) > Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches > for referencePatterns: > [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo > sitory.WriteableRepository] > at > org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) > at > org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) > at > org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) > ... 6 more > org.apache.geronimo.kernel.config.InvalidConfigException: Unable to > resolve reference named Repository in gbean > geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod > ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller > at > org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) > at > org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) > at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) > at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) > Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches > for referencePatterns: > [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo > sitory.WriteableRepository] > at > org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) > at > org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) > at > org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) > ... 6 more > Server shutdown begun > Server shutdown completed > > -- > Joe Bohn > joe.bohn at earthlink.net > > "He is no fool who gives what he cannot keep, to gain what he cannot > lose." -- Jim Elliot >
ConfigurationInstaller - InvalidConfigurationException in Geronimo 1.1
I'm getting the following error attempting to start a server with the latest 1.1 image. Seems to be related to some changes introduced last night for a ConfigurationInstaller gbean. Booting Geronimo Kernel (in Java 1.4.2_08)... [ ] 0% 1s Startup failed org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference named Repository in gbean geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo sitory.WriteableRepository] at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) ... 6 more org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference named Repository in gbean geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo sitory.WriteableRepository] at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) ... 6 more Server shutdown begun Server shutdown completed -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Tomcat version in G1.1 for clustering
Jeff (et al.), Will G1.1 definitely be upgraded to Tomcat 5.5.15? IIRC, the clustering deployment plans were quite different for 5.5.9 -vs- 5.5.12. If we upgrade to 5.5.15, we will likely need a new plan that accounts for both the webcontainer upgrade as well as the new G1.1 plan format.. Thanks -Dave- Jeff Genender wrote: Thanks Rainer. But I think 5.5.15 will be the one for 1.1. But possibly 5.5.17 for 1.2 ;-) Jeff Rainer Jung wrote: Just for your information: 5.5.16 was released a couple of weeks ago, but has some problems with de delivered packaginf of examples app under windows. 5.5.17 is expected to be cut on friday and voted stable eventually 1-2 weeks later. Jeff Genender wrote: Yep...need to update the plan. Its updated in trunk. Dave Colasurdo wrote: It appears that G1.1 is still using Tomcat 5.5.9 http://svn.apache.org/repos/asf/geronimo/branches/1.1/etc/project.properties Wasn't a tomcat upgrade to 5.5.15 in plan for G1.1?? Perhaps I am confused with the plans for trunk.. ?? Thanks -Dave-
Issues Closed: week of 04-14-2006
Project: Apache Geronimo Status: Resolved, Closed (21 items) Updated In Last: Week (7 days) ** New Feature * [GERONIMO-1259] reduce the size of the combined deployment plan: package deployment plans in a jar and pass this jar to the deployer ** Bug * [GERONIMO-1847] FileNotFoundException when installing car into repository with packaging plugin when parent directories not created. * [GERONIMO-1831] Need to package console WEB-INF/classes into a JAR * [GERONIMO-1843] Error attempting to deploy web applications to tomcat without a geronimo plan * [GERONIMO-1452] Config.xml refers to the wrong JMX remote service gbean (Fix included) * [GERONIMO-1830] Need to add Environment to DConfigBeans * [GERONIMO-1824] geronimo-config-1.0.xsd incorrectly documents that classes can be comma-separated inside a filter element * [GERONIMO-1825] Only one filter element can be specified inside a hidden-classes or non-overridable-classes element in plans * [GERONIMO-1836] Packaging plugin expects does not handle the environment element being in namespaces other than the deployer namespace * [GERONIMO-1827] deployment-1.1.xsd missing * [GERONIMO-1820] corrupted config.ser may cause NPE in ProgressBarStartupMonitor.repaint() * [GERONIMO-1789] Exceptions while adding SQL Realm thru Admin Console * [GERONIMO-1316] Create JMS destination pretty darn broken * [GERONIMO-1097] (Patch) Keystore Portlet should point to the default keystore file instead of ssl-keystore-1 * [GERONIMO-1768] bad group for console has no error page that allows user logout/correction ** Improvement * [GERONIMO-1837] Uninstalling an ear should cascade-uninstall all application clients * [GERONIMO-1430] Create TimedConfigStore (config store that timestamps deployments) * [GERONIMO-1664] Export / Import configurations capability * [GERONIMO-1771] Console should create links for all sections including the "current section" * [GERONIMO-1770] Console should create links for all sections including the "current section" ** Task * [GERONIMO-1800] SPECjAppServer2004 Deployment Descriptors
