Re: building error
If this occurred while building configs client-corba or j2ee-corba, I
have found the problem. You can fix it locally by including
dependency
groupIdgeronimo/groupId
artifactIdaxis-deployer/artifactId
version${geronimo_version}/version
typecar/type
properties
packaging.config.order4/packaging.config.order
/properties
/dependency
in your project.xml. I expect to commit this when svn revives.
If this doesn't fix the problem please let us know and indicate what
was being built at the time of the failure.
Incidentally I'd be curious to know what system you are running on: I
think the configs are getting built in a different order than on
everyone elses build machine.
Many thanks
david jencks
On May 11, 2006, at 10:00 PM, Rakesh Ranjan wrote:
Hi all,
When i building the Geronimo-1.1-SNAPSHOP, i get the following
exception :
27010 [main] ERROR
org.apache.geronimo.plugin.packaging.PackageBuilder -
org.apache.geronimo.kernel.config.LifecycleException: start of
geronimo/openejb-deployer/1.1-SNAPSHOT/car failed
org.apache.geronimo.kernel.config.LifecycleException: start of
geronimo/openejb-deployer/1.1-SNAPSHOT/car failed
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf
iguration(SimpleConfigurationManager.java :522)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf
iguration(SimpleConfigurationManager.java:486)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager$
$FastClassByCGLIB$$ce77a924.invoke (generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
(FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
(GBeanOperation.java:122)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
(GBeanInstance.java:817)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
(ProxyMethodInterceptor.java:96)
at org.apache.geronimo.kernel.config.ConfigurationManager$
$EnhancerByCGLIB$$39bce10d.startConfiguration (generated)
at
org.apache.geronimo.plugin.packaging.PackageBuilder.execute
(PackageBuilder.java:286)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.geronimo.plugin.packaging.PackageBuilderShell.execute
(PackageBuilderShell.java:251)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.commons.jelly.impl.DynamicBeanTag.doTag
(DynamicBeanTag.java:230)
at org.apache.commons.jelly.impl.StaticTagScript.run
(StaticTagScript.java:145)
at org.apache.commons.jelly.impl.ScriptBlock.run
(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag
$MavenGoalAction.performAction (MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain (Goal.java:573)
at com.werken.werkz.WerkzProject.attainGoal
(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag
(MavenAttainGoalTag.java:127)
at org.apache.commons.jelly.impl.TagScript.run
(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run
(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag
$MavenGoalAction.performAction (MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at org.apache.maven.plugin.PluginManager.attainGoals
(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals
(MavenSession.java:263)
at org.apache.maven.jelly.tags.maven.ReactorTag.doTag
(ReactorTag.java:368)
at org.apache.commons.jelly.impl.TagScript.run
(TagScript.java:279)
at
[jira] Commented: (GERONIMO-2002) OpenEJB CORBA SSL should use Keystore GBean
[ http://issues.apache.org/jira/browse/GERONIMO-2002?page=comments#action_12383183 ] Rick McGuire commented on GERONIMO-2002: Is anybody working on this? I'm willing to take a crack at it if not. I do have a couple of questions on how it should be implemented. The socket factory used to create the SSLSockets is instantiated by the ORB based on a property value, rather than instantiated by the Geronimo configurator code. This means that socket factory code needs to call back into G. to somehow retrieve the KeyStore information. What's the appropriate mechanism to retrieve the Keystore GBean? Is is safe to assume this is a singleton, or can different ORB instances be configured to use different keystores? OpenEJB CORBA SSL should use Keystore GBean --- Key: GERONIMO-2002 URL: http://issues.apache.org/jira/browse/GERONIMO-2002 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: security, CORBA Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1 OpenEJB initializes CORBA using a plain SSL socket factory and therefore only sees SSL keystore/trust store settings configured as system properties. We should change this to use the KeystoreManager API instead. -- 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: (SM-430) Self-first classloader fails when used with a shared library
Self-first classloader fails when used with a shared library Key: SM-430 URL: https://issues.apache.org/activemq/browse/SM-430 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 2.0.2 Reporter: Michael Horwitz The self-first classloader delegates correctly as long as it is not used with a shared library. As soon as a shared library is added, it delegated to the shared library before trying to load the class itself. As I read the JBI specification this is not correct. Path in source - SelfFirstClassLoader calls findClass() on InstallationClassLoader, which searches shared libraries before delegating to the URLClassLoader parent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Where should M2 conversion be done? or Should/Will the trunk be abandoned completely?
On 5/12/06, Prasad Kashyap [EMAIL PROTECTED] wrote: Are there any major pros and cons of moving to 1.1 as opposed to moving to the new trunk ? I don't see any. At present, I think we could wait till after we ship 1.1 and create this new trunk. But if somebody sees any some advantages, I'd appreciate their insight. Well, I've been thinking about it for a while and he's my take on it. It's a bunch of loosy-coupled views of mine on it so please bear with me gently ;) It's about how many people can work for Geronimo. Most of us are working in their free time and it's clearly visible that the team who really contributes a code is too small. It's way too small comparing to the features we're about to implement. The word about Geronimo needs to flow and it requires more people involved who could speak about it, i.e. understand it. I see 1.1 as a big change and it could well be named 2.0 to put it straight to our users. Lots of changes are on their way, which is also clearly visible in merging 1.1 and the trunk and it s pain to implement. So, my point to move on with the m2 migration/conversion is about engaging more people in much simpler tasks around Geronimo that could help them to get started and contribute. The M2 conversion touches Geronimo in many areas so it's one way to engage future contributors. Some people want to code rather then perform tests, which is the moment we're in with 1.1 (well, not exactly, but that *might* not be a right moment to jump in and expect help when everybody is so focused to push 1.1 out the door). On the other hand, I wonder how many people are around lurking and scratching their head where to contribute their time and who would benefit with the m2 conversion as an entry point. Remember that at one point there were 4 people working on the conversion and only one of them was a committer. It's one way to become a Geronimo committer and once you are contributing to Geronimo it will become easier even more. Prasad Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Updated: (GERONIMO-1557) When you enter the url of a web serv?ce ?n the console You should get a page show?ng the serv?ce name
[ http://issues.apache.org/jira/browse/GERONIMO-1557?page=all ] Manu T George updated GERONIMO-1557: Attachment: AxisWebServiceContainer.patch AxisServiceBuilder.patch Added the same behaviour as in axis using the axis properties. For a service HelloService the following message will be shown HelloService Hi there, this is an AXIS service! Perhaps there will be a form for invoking the service here... This is the same message that is shown in axis. Did not add a geronimo specific message as there is no message handling api in geronimo thru property files. Also the axis jars have this property file When you enter the url of a web serv?ce ?n the console You should get a page show?ng the serv?ce name - Key: GERONIMO-1557 URL: http://issues.apache.org/jira/browse/GERONIMO-1557 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: webservices Versions: 1.0 Environment: All Reporter: Manu T George Priority: Minor Attachments: AxisServiceBuilder.patch, AxisWebServiceContainer.patch When you type the URL of a web service in a browser without the ?wsdl parameter what happens is that a SOAPFault is thrown. Instead we should show a HTML page with the message This is a web service followed by the service name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
KeystoreManager API incomplete?
I've been taking a look at Jira GERONIMO-2002, which discusses using the Geronimo KeystoreManager API to create the SSL sockets. The KeystoreManager API implements a createSSLFactory() method (which really should be createSSLServerFactory()) to create an SSLServerSocketFactory instance. The CORBA code, however, will require both SSLServerSocketFactory and SSLSocketFactory instances to implement the server and client ends of the secure connection. Is there some reason why this was only implemented for the server end other than that was the only piece needed at the time? I'd like to rename the existing method and create a new method that creates a client-side socket factory as well. Rick
[jira] Commented: (GERONIMO-2002) OpenEJB CORBA SSL should use Keystore GBean
[ http://issues.apache.org/jira/browse/GERONIMO-2002?page=comments#action_12383187 ] Rick McGuire commented on GERONIMO-2002: Ok, another question as I drill a little deeper into this. The server side of the CORBA connection requires creating an SSLServerSocketFactory instance (which KeystoreManager handles). The client side requires creating an SSLSocketFactory instance (which is not currently handled by the KeystoreManager API, but I'll add that). The client and server ends do not necessarily need to be configured with the same truststore and keystore values (but they can be). Which approach should be used here: 1) Single set of properties used to configure both the client-side and server-side connections. Note that an ORB may require both types since it can be acting as both a server and a client to access remote references. 2) Different properties for the client and server. 3) Some other approach I've not considered? OpenEJB CORBA SSL should use Keystore GBean --- Key: GERONIMO-2002 URL: http://issues.apache.org/jira/browse/GERONIMO-2002 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: security, CORBA Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1 OpenEJB initializes CORBA using a plain SSL socket factory and therefore only sees SSL keystore/trust store settings configured as system properties. We should change this to use the KeystoreManager API instead. -- 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-2014) Geronimo uses outdated version of ApacheDS
Geronimo uses outdated version of ApacheDS -- Key: GERONIMO-2014 URL: http://issues.apache.org/jira/browse/GERONIMO-2014 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: naming Versions: 1.2 Environment: P4 3.0Ghz 2Gb WinXP Reporter: Alexei Zakharov Outdated version of Apache Directory Server is currently used by Geronimo. This is a cause of GERONIMO-1805 bug and probably some other issues. Attached patches port Geronimo directory module to ApachedDS 1.0 RC2. It is applicable to maven2 version of config files since ADS 1.0 RCx jars available for m2 repo only. -- 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-2014) Geronimo uses outdated version of ApacheDS
[ http://issues.apache.org/jira/browse/GERONIMO-2014?page=all ] Alexei Zakharov updated GERONIMO-2014: -- Attachment: geronimo-1.2_to_apacheds-1.0-RC2.patch Geronimo uses outdated version of ApacheDS -- Key: GERONIMO-2014 URL: http://issues.apache.org/jira/browse/GERONIMO-2014 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: naming Versions: 1.2 Environment: P4 3.0Ghz 2Gb WinXP Reporter: Alexei Zakharov Attachments: geronimo-1.2_to_apacheds-1.0-RC2.patch Outdated version of Apache Directory Server is currently used by Geronimo. This is a cause of GERONIMO-1805 bug and probably some other issues. Attached patches port Geronimo directory module to ApachedDS 1.0 RC2. It is applicable to maven2 version of config files since ADS 1.0 RCx jars available for m2 repo only. -- 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-2014) Geronimo uses outdated version of ApacheDS
[ http://issues.apache.org/jira/browse/GERONIMO-2014?page=all ] Alexei Zakharov updated GERONIMO-2014: -- Attachment: geronimo-1.2_to_apacheds-1.0-RC2_modules_directory_pom_xml.patch Both patches should be applied. Geronimo uses outdated version of ApacheDS -- Key: GERONIMO-2014 URL: http://issues.apache.org/jira/browse/GERONIMO-2014 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: naming Versions: 1.2 Environment: P4 3.0Ghz 2Gb WinXP Reporter: Alexei Zakharov Attachments: geronimo-1.2_to_apacheds-1.0-RC2.patch, geronimo-1.2_to_apacheds-1.0-RC2_modules_directory_pom_xml.patch Outdated version of Apache Directory Server is currently used by Geronimo. This is a cause of GERONIMO-1805 bug and probably some other issues. Attached patches port Geronimo directory module to ApachedDS 1.0 RC2. It is applicable to maven2 version of config files since ADS 1.0 RCx jars available for m2 repo only. -- 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
Issues Closed: week of 05-12-2006
Project: Apache Geronimo Status: Resolved, Closed (25 items) Updated In Last: Week (7 days) ** New Feature * [GERONIMO-1979] Add custom class loader that does not leave open file locks ** Bug * [GERONIMO-1974] Can't redeploy a copy of an application using a different version in the module ID * [GERONIMO-1475] Configs needing updated to not include Xerces files in the Repository as duplicates to lib\endorsed * [GERONIMO-436] JSR-88: Targets Ignored * [GERONIMO-1902] Console does not allow editing of Tomcat Connector Attributes * [GERONIMO-2005] redeploying console EAR fails * [GERONIMO-2003] Remove geronimo-config-1.1.xsd * [GERONIMO-1899] Build includes J2EE 1.1-SNAPSHOT spec * [GERONIMO-1782] Properties File Login module fails after editing through Admin Console * [GERONIMO-2001] Eliminate unnecessary CRs in deployment and other messages * [GERONIMO-1947] Repeat hot deployment of WARs with no Geronimo plan * [GERONIMO-1893] Corba failures on startup * [GERONIMO-1971] Redeployment of webapp without geronimo plan fails * [GERONIMO-594] Begin on TransactionManager always fails when thread is associated with a Tx * [GERONIMO-1140] Bad component query building logic (JCAResourceImpl finds no JCAConnectionFactories) * [GERONIMO-1998] tomcat connector gbean sets wrong attribute * [GERONIMO-1925] JSP Example Plugin Install/Uninstall/Install doesn't work * [GERONIMO-1815] Remove empty config-store directory * [GERONIMO-1751] Deployment of ear with external plan using Deploy New console option caused FileNotFoundException * [GERONIMO-1994] geronimo-installer-1.1-SNAPSHOT.jar cannot be launched * [GERONIMO-1977] Remove corba spec javamail spec from rmi-naming * [GERONIMO-1975] security builder should trim everything ** Improvement * [GERONIMO-1405] support more than one config-store ** Task * [GERONIMO-1666] Console issues resulting from configID changes
Re: Directory Update (Jeff?)
Ok. The patch to port maven2 version of G directory module to ApacheDS 1.0 RC2 is available here: http://issues.apache.org/jira/browse/GERONIMO-2014 It patches pom.xml's as well as java source code and the test. Thanks, 2006/5/11, Alex Karasulu [EMAIL PROTECTED]: Alexei, Sorry but we have not looked back after the M2 conversion. Our poms have changed much since then because of transitive deps so it would take a significant effort to produce the M1 poms again. Really wish we had a tool for this. Regards, Alex Alexei Zakharov wrote: BTW, Alex, are there plans to propagate ADS jars to maven1 repo? Geronimo 1.1 currently supports maven1 only. Thanks, 2006/5/6, Alexei Zakharov [EMAIL PROTECTED]: Alex, Oh, I've been searching in old directory and directory-network groups rather than org/apache/directory/server/apacheds-core. Thank you for pointing the right group id. 2006/5/5, Alex Karasulu [EMAIL PROTECTED]: Alexei Zakharov wrote: Hi, I have created a patch to move the G directory module to ApacheDS 1.0 RC2. But I didn't find necessary 1.0 RCx jars at ibiblio neither at /maven nor at /maven2. The most recent version is 0.9.3. The same situation for MINA. So I can't post the patch right now since it will not work without these jars. Alex, I just want to let you know about this situation. Hmmm I'm seeing the RC2 jars just fine. Take a look here at the core jar for example: http://www.ibiblio.org/maven2/org/apache/directory/server/apacheds-core/1.0-RC2/ Also MINA stuff is here: http://www.ibiblio.org/maven2/org/apache/directory/mina/mina-core/0.9.4/ HTH, Alex 2006/4/24, Alex Karasulu [EMAIL PROTECTED]: Aaron Mulder wrote: I know 0.9.3 is there (in the /maven2 repo). Not sure about the RC's. Ya all including RC1 should be in the M2 repo if not let me know. Alex Thanks, Aaron On 4/24/06, Jeff Genender [EMAIL PROTECTED] wrote: Alex, Can you get the jars in ibiblio and I can get the integration going? I am only seeing 0.9.2 in ibiblio at the moment. Thanks, Jeff Alex Karasulu wrote: Jeff Genender wrote: If the changes are not huge, I can probably do it. Alex, are the updates significant? Since 0.9.2 I'd say RC1 is a significant update. There are package name changes to comply with Directory's TLP domain name which are perhaps the most significant changes. There are changes to a couple dependencies. For the most part the code has been cleaned up and several *severe* bugs have been corrected and tested. RC1 is also an order of magnitude faster. We plan to get another 1.0 release candidate (RC2) out soon perhaps by the end of this week coming week or week there after. But looking at emails out there from Dain and Aaron it sounds to me like the update to G can take place any time after the 1.1 release. Let us know if you have any problems or need a hand while performing an upgrade either to RC1 or RC2 when it comes out. Regards, Alex -- Alexei Zakharov, Intel Middleware Product Division
modules terminology in the admin console
The tasks in the admin console are broken up into five categories: Server, Services, Applications, Security, and Embedded DB. The tasks under the Applications category allow you to start, stop, or uninstall deployed ears, wars, rars, etc. To go along with the new module terminology I think that the name for htis category change to Modules, and that the embedded help for these tasks should use the new module terminology as well. Do others agree/disagree? Paul
Using the KeystoreManager for CORBA SSL support
I'm looking at implementing KeystoreManager support in the openejb CORBA
TLS layer (see Jira GERONIMO-2002), and I'm having trouble deciding how
best to do this. The KeystoreManager GBean merely manages access to the
keystores and the creating of SSLSocket factories for creating
connections (and currently, it only supports SSLServerSockets, but it's
a fairly trivial matter to add SSLSocketFactory support too). In order
to use the KeystoreManager to create a socket, the caller must provide a
number of additional pieces of information, such as the truststore and
keystore names, and the key alias. For example, here's the
configuration for the HTTPSConnector used to configure Jetty:
gbean name=JettySSLConnector
class=org.apache.geronimo.jetty.connector.HTTPSConnector
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanHTTPSPort}/attribute
attribute name=keyStoregeronimo-default/attribute
attribute name=keyAliasgeronimo/attribute
attribute name=trustStoregeronimo-default/attribute
attribute name=clientAuthRequiredfalse/attribute
attribute name=algorithmDefault/attribute
attribute name=secureProtocolTLS/attribute
attribute name=maxThreads150/attribute
attribute name=minThreads25/attribute
reference name=JettyContainer
nameJettyWebContainer/name
/reference
reference name=KeystoreManager
nameKeystoreManager/name
/reference
/gbean
In this case, the keyStore, keyAlias, trustStore, algorithm,
secureProtocol, and KeystoreManager values are all needed to create the
SSLServerSocketFactory instance that will be used to create the SSL
connection.
Now, to enable this support for CORBA, the two beans that create the ORB
instances (CORBABean and CSSBean) will need the same set of attributes
(and those attributes will need to be propagated to a couple of other
objects, which would start to get pretty messy). Alternatively, it
might make sense to have an SSLFactoryGBean, which is configured with
all of the attributes above, and which has methods for creating an
SSLSocket and a SSLServerSocket, and/or retrieving an appropriately
configured socket factory. This seems to me like a simpler
implementation, allowing the two CORBA beans to just be initialized with
the SSLFactoryGBean instance. It might make sense to rework the
HTTPSConnector too to use the same pattern.
So, which model should be used here:
1) Current model employed with HTTPSConnector where all KeystoreManager
users expose/manage all of the attributes necessary to create SSL
connections using the KeystoreManager, or
2) Have an SSLFactory GBean where the SSL characteristics are
configured separately from the SSL consumer?
Rick
Re: Geronimo documentation - upcoming look feel
I just used the same banner we have in the web site, we could make it thinner if needed. As for the bread-crumbs height, I think that's pretty standard. Although I have not fully tested it, the templates used to automatically export the content to HTML accepts embedded css so we could potentially customize a lot more. Cheers! Hernan Jason Dillon wrote: On 5/11/06, Hernan Cunico [EMAIL PROTECTED] wrote: Hi All, I just wanted to give you guys a heads up on how the Geronimo's confluence wiki may look like once cwiki.apache.org jumps in production. ... http://people.apache.org/~hcunico/cwiki/documentation.html Comments, questions, suggestions are welcomed :) Anyway we can figure how to reduce some of the logo/bread-crumbs/ toolbar height? --jason
[jira] Resolved: (GERONIMO-1951) config.xml settings should be applied to newer versions
[ http://issues.apache.org/jira/browse/GERONIMO-1951?page=all ] Prasad Kashyap resolved GERONIMO-1951: -- Resolution: Fixed Assign To: Aaron Mulder I believe this issue has been fixed in G-1974. See Dain's comments here : http://issues.apache.org/jira/browse/GERONIMO-1974#action_12378538 I also changed the version number for the sharedlib module from 1.1 to 1.2 and redeployed it using the command deploy --user system --password manager redeploy C:\Apache\geronimo\configs\sharedlib\target\plan\plan.xml The configuration block in the config.xml migrated appropriately. Please reopn this issue if you still feel something needs to be addressed. config.xml settings should be applied to newer versions --- Key: GERONIMO-1951 URL: http://issues.apache.org/jira/browse/GERONIMO-1951 Project: Geronimo Type: Bug Security: public(Regular issues) Components: kernel Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 If you deploy a module with no version number, it gets one during deployment and any config.xml settings are written using that version number. Then if you redeploy, the app gets a newer version, and a new entry is written to config.xml. It should transfer the old settings to the new configuration (checking to make sure each is still valid) rather than writing a whole new configuration block. The same is true if you deploy an updated version of a core Geronimo service, e.g. updating geronimo/jetty/1.1.2/car to geronimo/jetty/1.1.3/car -- it should not forget any custom ports assigned, etc. -- 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: New Feature Wednesday
I think Joe has raised a valid point here... Providing ongoing unstable builds is quite useful. However, if there is no simple link to them from the Geronimo website then how will users find them? Why not add a simple link to the unstable builds (or at least the location of the most recent 1.1 build) on the Geronimo main download page? This will encourage user participation and feedback for 1.1.. -Dave- Joe Bohn wrote: I agree with everyone else that it is really great to have these unstable builds being produced and posted on a regular basis! It will help encourage users to pick up the latest more quickly and provide us with quicker feedback. How is it expected that users will find these unstable builds? Is there some way to get to the unstable builds from the geronimo web site? I think more people would find it and use it if there was a link from the downloads page to http://cvs.apache.org/dist/geronimo/unstable/ . One more question: How long will these builds hang around? I see that there are still builds from 1.0 out there. Just a nit - but it would be nice if we could put the most recent build at the top of the list. Joe David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Latest +Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David
Re: KeystoreManager API incomplete?
that was the only piece needed at the time Thanks, Aaron On 5/12/06, Rick McGuire [EMAIL PROTECTED] wrote: I've been taking a look at Jira GERONIMO-2002, which discusses using the Geronimo KeystoreManager API to create the SSL sockets. The KeystoreManager API implements a createSSLFactory() method (which really should be createSSLServerFactory()) to create an SSLServerSocketFactory instance. The CORBA code, however, will require both SSLServerSocketFactory and SSLSocketFactory instances to implement the server and client ends of the secure connection. Is there some reason why this was only implemented for the server end other than that was the only piece needed at the time? I'd like to rename the existing method and create a new method that creates a client-side socket factory as well. Rick
[jira] Created: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type
Let's replace JKS to PKCS12 key store type -- Key: GERONIMO-2015 URL: http://issues.apache.org/jira/browse/GERONIMO-2015 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: security Reporter: Nikolay Chugunov Hello Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key store and Geronimo may not work on non-Sun VMs. To fix this problem I have created the patch for Geronimo sources. In brief the patch (attached) replaces JKS to PKCS12 key store type in configurations files. PKCS12 format of key store file is not java-specific and can be created and read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is Sun specific key store and does not exist in Bouncy Castle. Also it is needed to replace JKS to PKCS12 keystore file (attached) to assemblies/j2ee-tomcat-server/src/var/security, assemblies/j2ee-installer/src/var/security, assemblies/j2ee-jetty-server/src/var/security directories. Key store file was generating using JKSToPKCS12 class (attached). This class transfers key and certificate of Geronimo from JKS to PKCS12. After I apply this patch to Geronimo 1.0 sources and build Geronimo I can login to Geronimo console over https. -- 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-2015) Let's replace JKS to PKCS12 key store type
[ http://issues.apache.org/jira/browse/GERONIMO-2015?page=all ] Nikolay Chugunov updated GERONIMO-2015: --- Attachment: JKSToPKCS12.java Let's replace JKS to PKCS12 key store type -- Key: GERONIMO-2015 URL: http://issues.apache.org/jira/browse/GERONIMO-2015 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: security Reporter: Nikolay Chugunov Attachments: JKSToPKCS12.java, keystore Hello Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key store and Geronimo may not work on non-Sun VMs. To fix this problem I have created the patch for Geronimo sources. In brief the patch (attached) replaces JKS to PKCS12 key store type in configurations files. PKCS12 format of key store file is not java-specific and can be created and read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is Sun specific key store and does not exist in Bouncy Castle. Also it is needed to replace JKS to PKCS12 keystore file (attached) to assemblies/j2ee-tomcat-server/src/var/security, assemblies/j2ee-installer/src/var/security, assemblies/j2ee-jetty-server/src/var/security directories. Key store file was generating using JKSToPKCS12 class (attached). This class transfers key and certificate of Geronimo from JKS to PKCS12. After I apply this patch to Geronimo 1.0 sources and build Geronimo I can login to Geronimo console over https. -- 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-2015) Let's replace JKS to PKCS12 key store type
[ http://issues.apache.org/jira/browse/GERONIMO-2015?page=all ] Nikolay Chugunov updated GERONIMO-2015: --- Attachment: keystore Let's replace JKS to PKCS12 key store type -- Key: GERONIMO-2015 URL: http://issues.apache.org/jira/browse/GERONIMO-2015 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: security Reporter: Nikolay Chugunov Attachments: JKSToPKCS12.java, keystore Hello Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key store and Geronimo may not work on non-Sun VMs. To fix this problem I have created the patch for Geronimo sources. In brief the patch (attached) replaces JKS to PKCS12 key store type in configurations files. PKCS12 format of key store file is not java-specific and can be created and read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is Sun specific key store and does not exist in Bouncy Castle. Also it is needed to replace JKS to PKCS12 keystore file (attached) to assemblies/j2ee-tomcat-server/src/var/security, assemblies/j2ee-installer/src/var/security, assemblies/j2ee-jetty-server/src/var/security directories. Key store file was generating using JKSToPKCS12 class (attached). This class transfers key and certificate of Geronimo from JKS to PKCS12. After I apply this patch to Geronimo 1.0 sources and build Geronimo I can login to Geronimo console over https. -- 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: Using the KeystoreManager for CORBA SSL support
You can't have a single GBean hold all that information and make it
the same for every SSL client/server. For example, the client needs
no keystore if it's not using client auth, and needs a separate
keystore if it is. The protocol and algorithm can probably be
configured at the JVM level -- I'm not sure about the rest. It's
plausible that you might want two different SSL connectors with
different key/trust/client auth settings, one for internal clients and
one for external clients.
Thanks,
Aaron
On 5/12/06, Rick McGuire [EMAIL PROTECTED] wrote:
I'm looking at implementing KeystoreManager support in the openejb CORBA
TLS layer (see Jira GERONIMO-2002), and I'm having trouble deciding how
best to do this. The KeystoreManager GBean merely manages access to the
keystores and the creating of SSLSocket factories for creating
connections (and currently, it only supports SSLServerSockets, but it's
a fairly trivial matter to add SSLSocketFactory support too). In order
to use the KeystoreManager to create a socket, the caller must provide a
number of additional pieces of information, such as the truststore and
keystore names, and the key alias. For example, here's the
configuration for the HTTPSConnector used to configure Jetty:
gbean name=JettySSLConnector
class=org.apache.geronimo.jetty.connector.HTTPSConnector
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanHTTPSPort}/attribute
attribute name=keyStoregeronimo-default/attribute
attribute name=keyAliasgeronimo/attribute
attribute name=trustStoregeronimo-default/attribute
attribute name=clientAuthRequiredfalse/attribute
attribute name=algorithmDefault/attribute
attribute name=secureProtocolTLS/attribute
attribute name=maxThreads150/attribute
attribute name=minThreads25/attribute
reference name=JettyContainer
nameJettyWebContainer/name
/reference
reference name=KeystoreManager
nameKeystoreManager/name
/reference
/gbean
In this case, the keyStore, keyAlias, trustStore, algorithm,
secureProtocol, and KeystoreManager values are all needed to create the
SSLServerSocketFactory instance that will be used to create the SSL
connection.
Now, to enable this support for CORBA, the two beans that create the ORB
instances (CORBABean and CSSBean) will need the same set of attributes
(and those attributes will need to be propagated to a couple of other
objects, which would start to get pretty messy). Alternatively, it
might make sense to have an SSLFactoryGBean, which is configured with
all of the attributes above, and which has methods for creating an
SSLSocket and a SSLServerSocket, and/or retrieving an appropriately
configured socket factory. This seems to me like a simpler
implementation, allowing the two CORBA beans to just be initialized with
the SSLFactoryGBean instance. It might make sense to rework the
HTTPSConnector too to use the same pattern.
So, which model should be used here:
1) Current model employed with HTTPSConnector where all KeystoreManager
users expose/manage all of the attributes necessary to create SSL
connections using the KeystoreManager, or
2) Have an SSLFactory GBean where the SSL characteristics are
configured separately from the SSL consumer?
Rick
Re: modules terminology in the admin console
I think the overall category header is clearer as Applications. If you're not familiar with the terminology, applications ought to jump out at you, whereas I'm not sure modules would. We do have the modules word in there for the System Modules subcategory to at least help link up the concepts. Thanks, Aaron On 5/12/06, Paul McMahan [EMAIL PROTECTED] wrote: The tasks in the admin console are broken up into five categories: Server, Services, Applications, Security, and Embedded DB. The tasks under the Applications category allow you to start, stop, or uninstall deployed ears, wars, rars, etc. To go along with the new module terminology I think that the name for htis category change to Modules, and that the embedded help for these tasks should use the new module terminology as well. Do others agree/disagree? Paul
Re: Using the KeystoreManager for CORBA SSL support
OK... I guess I'm just having trouble seeing what this would look
like. Can you show what the SSL configuration would look like for the
new GBean and the same Jetty SSL server if you use the scheme you're
proposing? (Or a CORBA component, if you're suggesting something that
would be applicable to CORBA only.)
Thanks,
Aaron
On 5/12/06, Rick McGuire [EMAIL PROTECTED] wrote:
I wasn't proposing having a single GBean instance to hold all of the
information, but a common GBean class that is used to configure things
and centralize the information/use of the information. For example, the
CSSBean and CORBABean classes use a common config adaptor that
encapsulates a number of the ORB implementation specifics from the
instantiating code. This config adapator will need the SSL connector to
set up the ORB socket factory. This task becomes a lot simpler if there
is a single class that carries the information and can be used to
retrieve the appropriate socket factories. These classes can even
encapsulate the default fallback logic for when there is no explicit
store configured.
For example, the client needs
no keystore if it's not using client auth, and needs a separate
keystore if it is. The protocol and algorithm can probably be
configured at the JVM level -- I'm not sure about the rest. It's
plausible that you might want two different SSL connectors with
different key/trust/client auth settings, one for internal clients and
one for external clients.
Thanks,
Aaron
On 5/12/06, Rick McGuire [EMAIL PROTECTED] wrote:
I'm looking at implementing KeystoreManager support in the openejb CORBA
TLS layer (see Jira GERONIMO-2002), and I'm having trouble deciding how
best to do this. The KeystoreManager GBean merely manages access to the
keystores and the creating of SSLSocket factories for creating
connections (and currently, it only supports SSLServerSockets, but it's
a fairly trivial matter to add SSLSocketFactory support too). In order
to use the KeystoreManager to create a socket, the caller must provide a
number of additional pieces of information, such as the truststore and
keystore names, and the key alias. For example, here's the
configuration for the HTTPSConnector used to configure Jetty:
gbean name=JettySSLConnector
class=org.apache.geronimo.jetty.connector.HTTPSConnector
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanHTTPSPort}/attribute
attribute name=keyStoregeronimo-default/attribute
attribute name=keyAliasgeronimo/attribute
attribute name=trustStoregeronimo-default/attribute
attribute name=clientAuthRequiredfalse/attribute
attribute name=algorithmDefault/attribute
attribute name=secureProtocolTLS/attribute
attribute name=maxThreads150/attribute
attribute name=minThreads25/attribute
reference name=JettyContainer
nameJettyWebContainer/name
/reference
reference name=KeystoreManager
nameKeystoreManager/name
/reference
/gbean
In this case, the keyStore, keyAlias, trustStore, algorithm,
secureProtocol, and KeystoreManager values are all needed to create the
SSLServerSocketFactory instance that will be used to create the SSL
connection.
Now, to enable this support for CORBA, the two beans that create the ORB
instances (CORBABean and CSSBean) will need the same set of attributes
(and those attributes will need to be propagated to a couple of other
objects, which would start to get pretty messy). Alternatively, it
might make sense to have an SSLFactoryGBean, which is configured with
all of the attributes above, and which has methods for creating an
SSLSocket and a SSLServerSocket, and/or retrieving an appropriately
configured socket factory. This seems to me like a simpler
implementation, allowing the two CORBA beans to just be initialized with
the SSLFactoryGBean instance. It might make sense to rework the
HTTPSConnector too to use the same pattern.
So, which model should be used here:
1) Current model employed with HTTPSConnector where all KeystoreManager
users expose/manage all of the attributes necessary to create SSL
connections using the KeystoreManager, or
2) Have an SSLFactory GBean where the SSL characteristics are
configured separately from the SSL consumer?
Rick
Re: Geronimo documentation - upcoming look feel
I agree, it would be a really nice hit if we can include it in the distribution which, BTW, it rises again the call for volunteers to contribute with the project's documentation. If anybody is able to contribute with the project's documentation, in any possible way, this is the time for doing it :) Please feel free to ping me with any questions, concerns, suggestions. Cheers! Hernan Jacek Laskowski wrote: On 5/11/06, Hernan Cunico [EMAIL PROTECTED] wrote: Hi All, I just wanted to give you guys a heads up on how the Geronimo's confluence wiki may look like once cwiki.apache.org jumps in production. ... http://people.apache.org/~hcunico/cwiki/documentation.html Comments, questions, suggestions are welcomed :) Whow, that looks pretty! If it becomes part of our distribution it will surely be a major differentiator against other application servers, esp. open source ones. I have always liked BEA WebLogic for their astonishing documentation online so when people realize we've got alike we're winners! Thanks Hernan! Hernan Jacek
Re: New Feature Wednesday
On May 12, 2006, at 7:32 AM, Dave Colasurdo wrote: Why not add a simple link to the unstable builds (or at least the location of the most recent 1.1 build) on the Geronimo main download page? That'd be great, thanks! This will encourage user participation and feedback for 1.1.. Definitely. -David -Dave- Joe Bohn wrote: I agree with everyone else that it is really great to have these unstable builds being produced and posted on a regular basis! It will help encourage users to pick up the latest more quickly and provide us with quicker feedback. How is it expected that users will find these unstable builds? Is there some way to get to the unstable builds from the geronimo web site? I think more people would find it and use it if there was a link from the downloads page to http://cvs.apache.org/dist/ geronimo/unstable/ . One more question: How long will these builds hang around? I see that there are still builds from 1.0 out there. Just a nit - but it would be nice if we could put the most recent build at the top of the list. Joe David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Latest +Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David
Re: Using the KeystoreManager for CORBA SSL support
Well, I don't like it much for Jetty, since it seems to just split off
pertinent settings into another bean. If you're sure that CORBA will
have many objects with exactly the same settings, that's fine with me.
I'd have thought you would just set up one TSS and one CSS (which
would need different SSL factories even in your proposal) and point
all your CORBA users to one of those, but I haven't used CORBA in J2EE
in practice, so I'll defer to others on whether they're likely to have
a lot of overlap or not.
Thanks,
Aaron
On 5/12/06, Rick McGuire [EMAIL PROTECTED] wrote:
Aaron Mulder wrote:
OK... I guess I'm just having trouble seeing what this would look
like. Can you show what the SSL configuration would look like for the
new GBean and the same Jetty SSL server if you use the scheme you're
proposing? (Or a CORBA component, if you're suggesting something that
would be applicable to CORBA only.)
Ok, here's the currently Jetty config entry:
gbean name=JettySSLConnector
class=org.apache.geronimo.jetty.connector.HTTPSConnector
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanHTTPSPort}/attribute
attribute name=keyStoregeronimo-default/attribute
attribute name=keyAliasgeronimo/attribute
attribute name=trustStoregeronimo-default/attribute
attribute name=clientAuthRequiredfalse/attribute
attribute name=algorithmDefault/attribute
attribute name=secureProtocolTLS/attribute
attribute name=maxThreads150/attribute
attribute name=minThreads25/attribute
reference name=JettyContainer
nameJettyWebContainer/name
/reference
reference name=KeystoreManager
nameKeystoreManager/name
/reference
/gbean
My proposed new structure:
gbean name=JettySSLFactory
class=org.apache.geronimo.security.SSLFactoryGBean
attribute name=keyStoregeronimo-default/attribute
attribute name=keyAliasgeronimo/attribute
attribute name=trustStoregeronimo-default/attribute
attribute name=algorithmDefault/attribute
attribute name=protocolTLS/attribute
reference name=KeystoreManager
nameKeystoreManager/name
/reference
/gbean
gbean name=JettySSLConnector
class=org.apache.geronimo.jetty.connector.HTTPSConnector
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanHTTPSPort}/attribute
attribute name=clientAuthRequiredfalse/attribute
reference name=JettyContainer
nameJettyWebContainer/name
/reference
reference name=JettySSLFactory
nameJettySSLFactory/name
/reference
/gbean
This is probably less of an issue for the Jetty config, but it is very
likely that the various CORBA beans will share a common configuration,
so it makes sense to specify that part of the configuration in just one
place and reference it in multiple places.
The SSLFactoryGBean will also implement an interface for retrieving the
socket factories, again to centralize the common logic involved.
Rick
Thanks,
Aaron
On 5/12/06, Rick McGuire [EMAIL PROTECTED] wrote:
I wasn't proposing having a single GBean instance to hold all of the
information, but a common GBean class that is used to configure things
and centralize the information/use of the information. For example, the
CSSBean and CORBABean classes use a common config adaptor that
encapsulates a number of the ORB implementation specifics from the
instantiating code. This config adapator will need the SSL connector to
set up the ORB socket factory. This task becomes a lot simpler if there
is a single class that carries the information and can be used to
retrieve the appropriate socket factories. These classes can even
encapsulate the default fallback logic for when there is no explicit
store configured.
For example, the client needs
no keystore if it's not using client auth, and needs a separate
keystore if it is. The protocol and algorithm can probably be
configured at the JVM level -- I'm not sure about the rest. It's
plausible that you might want two different SSL connectors with
different key/trust/client auth settings, one for internal clients and
one for external clients.
Thanks,
Aaron
On 5/12/06, Rick McGuire [EMAIL PROTECTED] wrote:
I'm looking at implementing KeystoreManager support in the openejb
CORBA
TLS layer (see Jira GERONIMO-2002), and I'm having trouble
deciding how
best to do this. The KeystoreManager GBean merely manages access
to the
keystores and the creating of SSLSocket factories for creating
connections (and currently, it only supports SSLServerSockets, but
it's
a fairly trivial matter to add SSLSocketFactory support too). In
order
to use the KeystoreManager to create a socket, the caller must
provide a
number of additional pieces of information, such as the truststore
Re: New Feature Wednesday
On May 11, 2006, at 6:01 AM, Joe Bohn wrote: I agree with everyone else that it is really great to have these unstable builds being produced and posted on a regular basis! It will help encourage users to pick up the latest more quickly and provide us with quicker feedback. Definitely a good start. It takes group participation to really take advantage. How is it expected that users will find these unstable builds? We can link the Latest Unstable wiki page from the website. We can also mention them when we fix problems, I submitted/comitted a patch for this and it will be available in next Wednesday's build! (post link) Or when people have problems building, Give the latest unstable a try and see how it goes. (post link) Is there some way to get to the unstable builds from the geronimo web site? I think more people would find it and use it if there was a link from the downloads page to http://cvs.apache.org/dist/ geronimo/unstable/ . Absolutely. One more question: How long will these builds hang around? I see that there are still builds from 1.0 out there. The script arbitrarily keeps 14 past builds -- can be whatever number we choose. Just a nit - but it would be nice if we could put the most recent build at the top of the list. Sure. Most people don't notice that page is sortable. We can link it that way for convenience. http://cvs.apache.org/dist/geronimo/unstable/?C=M;O=D -David Joe David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Latest +Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David -- 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
Please try out the upgrade jar
I put the upgrade jar at http://people.apache.org/~djencks/geronimo-upgrade-1.1-SNAPSHOT.jar It would be very helpful to find out to what extent this works in real life. It's supposed to include all the classes it needs (that's why its so big) usage: java -jar geronimo-upgrade-1.1-SNAPSHOT.jar path to source plan [path to target plan] if you leave out the target, you'll get output in the same directory as the source. thanks david jencks
[jira] Commented: (GERONIMO-2004) Hot deployment of welcome app failed
[ http://issues.apache.org/jira/browse/GERONIMO-2004?page=comments#action_12383226 ] Prasad Kashyap commented on GERONIMO-2004: -- Observations: - Recreated Anita's steps and reproduced the problem by dropping the welcome-jetty-1.1-SNAPSHOT.car file into the deploy dir. It wanted a plan file. Then I exploded the car and dropped a geronimo-web.xml plan into the WEB-INF dir. It complained with the error - Sum file already exists Then I deleted the checksum file (META-INF/config.sha1). It deployed successfully ! Questions: 1) should we still need a plan.xml when we already have the config info serialized ? 2) should we barf when we find an existing checksum file ? Hot deployment of welcome app failed Key: GERONIMO-2004 URL: http://issues.apache.org/jira/browse/GERONIMO-2004 Project: Geronimo Type: Bug Security: public(Regular issues) Components: Hot Deploy Dir Versions: 1.1 Environment: All Reporter: Anita Kulshreshtha Fix For: 1.1 This is for rev 405570 and a freshly built j2ee-tomcat-server. The following trace can be produced by - 1. start the server 2. uninstall geronimo/welcome-tomcat/---/car using console. The uninstall was successful. 3. hot deploy 08:44:02,359 INFO [Hot Deployer] Deploying welcome-tomcat-1.1-SNAPSHOT.car 08:44:03,046 WARN [TomcatModuleBuilder] Web application . does not contain a WEB-INF/geronimo-web.x ml deployment plan. This may or may not be a problem, depending on whether you have things like res ource references that need to be resolved. You can also give the deployer a separate deployment pla n file on the command line. 08:44:03,921 ERROR [Deployer] Deployment failed due to java.io.IOException: Sum file already exists at org.apache.geronimo.system.configuration.ConfigurationStoreUtil.writeChecksumFor(Configur ationStoreUtil.java:46) at org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(E xecutableConfigurationUtil.java:156) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryC onfigurationStore.java:319) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:308) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:119) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeploy Command.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java: 60) at java.lang.Thread.run(Thread.java:534) 08:44:04,031 ERROR [Hot Deployer] Unable to deploy: java.io.IOException: Sum file already exists org.apache.geronimo.common.DeploymentException: java.io.IOException: Sum file already exists at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:349) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:119) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeploy Command.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java: 60) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.IOException: Sum file already exists at org.apache.geronimo.system.configuration.ConfigurationStoreUtil.writeChecksumFor(Configur ationStoreUtil.java:46) at org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(E xecutableConfigurationUtil.java:156) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryC onfigurationStore.java:319) at
[jira] Created: (GERONIMO-2016) Provide source module info in UnresolvedReferenceException
Provide source module info in UnresolvedReferenceException -- Key: GERONIMO-2016 URL: http://issues.apache.org/jira/browse/GERONIMO-2016 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 Make UnresolvedReferenceException tell you what module the reference was in to help you figure out what is wrong. -- 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-2016) Provide source module info in UnresolvedReferenceException
[ http://issues.apache.org/jira/browse/GERONIMO-2016?page=all ] David Jencks updated GERONIMO-2016: --- Attachment: 2016_unresolvedRef_improvement.diff will apply when svn revives. Provide source module info in UnresolvedReferenceException -- Key: GERONIMO-2016 URL: http://issues.apache.org/jira/browse/GERONIMO-2016 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 Attachments: 2016_unresolvedRef_improvement.diff Make UnresolvedReferenceException tell you what module the reference was in to help you figure out what is wrong. -- 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: Geronimo documentation - upcoming look feel
I meant more like rearranging things to reduce the space. Anyways not a big deal. Can always tweak it later. --jason -Original Message- From: Hernan Cunico [EMAIL PROTECTED] Date: Fri, 12 May 2006 10:19:22 To:dev@geronimo.apache.org Subject: Re: Geronimo documentation - upcoming look feel I just used the same banner we have in the web site, we could make it thinner if needed. As for the bread-crumbs height, I think that's pretty standard. Although I have not fully tested it, the templates used to automatically export the content to HTML accepts embedded css so we could potentially customize a lot more. Cheers! Hernan Jason Dillon wrote: On 5/11/06, Hernan Cunico [EMAIL PROTECTED] wrote: Hi All, I just wanted to give you guys a heads up on how the Geronimo's confluence wiki may look like once cwiki.apache.org jumps in production. ... http://people.apache.org/~hcunico/cwiki/documentation.html Comments, questions, suggestions are welcomed :) Anyway we can figure how to reduce some of the logo/bread-crumbs/ toolbar height? --jason
Re: Please try out the upgrade jar
Thanks David! It seems to run fine on the simple plans that I have tried though I do have a few quick comments and observations.. 1) Should the version in the schema name be updated (from 1.0 - 1.1) for both jetty and tomcat plans? For example, the following line is unchanged when the tool is run.. web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0; 2) When using a unicode file as input (on windows platform) the output file isn't created in unicode format. 3) On windows platform, it seems that CR (x'0D') is inserted on the end of every line.. This appears as a musical note in my editor :) -Dave- David Jencks wrote: I put the upgrade jar at http://people.apache.org/~djencks/geronimo-upgrade-1.1-SNAPSHOT.jar It would be very helpful to find out to what extent this works in real life. It's supposed to include all the classes it needs (that's why its so big) usage: java -jar geronimo-upgrade-1.1-SNAPSHOT.jar path to source plan [path to target plan] if you leave out the target, you'll get output in the same directory as the source. thanks david jencks
[jira] Created: (GBUILD-18) We should be able to automatically boot up an image for a specific os on demand in any host in the gbuild network.
We should be able to automatically boot up an image for a specific os on demand in any host in the gbuild network. -- Key: GBUILD-18 URL: http://issues.apache.org/jira/browse/GBUILD-18 Project: GBuild Type: New Feature Reporter: David Blevins Assigned to: David Blevins Use VMWare for testing on other operating systems -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2016) Provide source module info in UnresolvedReferenceException
[ http://issues.apache.org/jira/browse/GERONIMO-2016?page=all ] David Jencks closed GERONIMO-2016: -- Resolution: Fixed applied rev 405869 Provide source module info in UnresolvedReferenceException -- Key: GERONIMO-2016 URL: http://issues.apache.org/jira/browse/GERONIMO-2016 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 Attachments: 2016_unresolvedRef_improvement.diff Make UnresolvedReferenceException tell you what module the reference was in to help you figure out what is wrong. -- 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-2017) MEJB should not extend Management because it extends EJBObject pulling in requirements for the ejb-spec
MEJB should not extend Management because it extends EJBObject pulling in requirements for the ejb-spec --- Key: GERONIMO-2017 URL: http://issues.apache.org/jira/browse/GERONIMO-2017 Project: Geronimo Type: Bug Security: public (Regular issues) Components: management Versions: 1.1 Environment: all Reporter: Joe Bohn Assigned to: David Jencks Fix For: 1.1 Attempting to remove the open-ejb spec dependency from the config\rmi-naming I received a ClassDefNotFound error on EJBObject. David Jencks dug into this and figured the problem was due to the fact that MEJB had a requirement on EJBObject because it was implementing the Management interface which extends EJBObject. IIUC this was making it a requirement that we include the EJBObject class from the ejb spec in j2ee-server. There is no need for MEJB to implement management since anyone using it as a gbean isn't likely to have ejbs available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2013) make upgrader into a command line tool
[ http://issues.apache.org/jira/browse/GERONIMO-2013?page=all ] David Jencks closed GERONIMO-2013: -- Resolution: Fixed applied in rev 405877 make upgrader into a command line tool -- Key: GERONIMO-2013 URL: http://issues.apache.org/jira/browse/GERONIMO-2013 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 Attachments: 2013_upgrade_commandline.diff Upgrade functionality needs to be exposed somehow. One way is as a command line tool. Current version is a 5M standalone jar: I'm not sure what other choices there are. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1861) Assembly plugin should make a backup original copy of the config.xml file
[ http://issues.apache.org/jira/browse/GERONIMO-1861?page=all ] David Jencks closed GERONIMO-1861: -- Resolution: Fixed applied as part of rev 405881 Assembly plugin should make a backup original copy of the config.xml file --- Key: GERONIMO-1861 URL: http://issues.apache.org/jira/browse/GERONIMO-1861 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: buildsystem Reporter: Dain Sundstrom Assignee: David Jencks Fix For: 1.1 Attachments: assembly-plugin.patch, assembly-version-change-openejb.patch, change-assembly-version.patch The assembly plugin should create a config.xml.original (config.xml.factory-defaults) file next to the config.xml file. This way if you really mess up your system, you can restore factory-defaults, or diff the two files. The current config.bak file is fairly useless since the server overwrites it after every change, which only gives you one level of undo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1507) prototype offline deploy tool
[ http://issues.apache.org/jira/browse/GERONIMO-1507?page=all ] David Jencks closed GERONIMO-1507: -- Fix Version: 1.1 Resolution: Fixed rev 405881. prototype offline deploy tool - Key: GERONIMO-1507 URL: http://issues.apache.org/jira/browse/GERONIMO-1507 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: deployment Versions: 1.1 Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Geronimo 1.0 branch, Reporter: toby cabot Assignee: David Jencks Priority: Minor Fix For: 1.1 Attachments: 1507_offline-deployer.diff, offline-patch.txt Here's a prototype offline deploy tool. It has only one command, for offline distribution of applications. It's basically a clone of the online tool so it works in a similar way, but for the distribute-offline command it uses a hacked version of the packaging plugin's PackageBuilder class to start a kernel, load some configurations, and then call the deployer. It has one serious bug at the moment: it doesn't switch between tomcat and jetty. Not sure why, but I can look into it more. It has some missing features: - it should get dependencies from somewhere (maybe download them from an online Maven repo) - it should be able to manipulate config.xml - it needs more commands (at least undistribute) - it needs to allow the user to specify the config-store to write to There's probably a lot of unused code there, too, since I haven't figured out what everything does yet. But it's a start. You can use it like the online tool. The jar is $GERONIMO_HOME/bin/offline.jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2009) JarFileResourceFinder ResourceEnumeration can't count.
[ http://issues.apache.org/jira/browse/GERONIMO-2009?page=all ] David Jencks closed GERONIMO-2009: -- Resolution: Fixed applied rev 405886 JarFileResourceFinder ResourceEnumeration can't count. -- Key: GERONIMO-2009 URL: http://issues.apache.org/jira/browse/GERONIMO-2009 Project: Geronimo Type: Bug Security: public(Regular issues) Components: kernel Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 Attachments: 2009_JarFileResourceFinder.diff JarFileResourceFinder.ResourceEnumeration always advances its iterator when you call hasMoreElements() and nextElement(), so in a typical loop you only get half the elements. I'll apply the patch when svn revives. -- 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-2017) MEJB should not extend Management because it extends EJBObject pulling in requirements for the ejb-spec
[ http://issues.apache.org/jira/browse/GERONIMO-2017?page=comments#action_12383311 ] David Jencks commented on GERONIMO-2017: This is all true but unfortunately rmi-naming has to include the j2ee management and ejb specs anyway since the thread pool requires (theoretically anyway) the Stats class from management. MEJB should not extend Management because it extends EJBObject pulling in requirements for the ejb-spec --- Key: GERONIMO-2017 URL: http://issues.apache.org/jira/browse/GERONIMO-2017 Project: Geronimo Type: Bug Security: public(Regular issues) Components: management Versions: 1.1 Environment: all Reporter: Joe Bohn Assignee: David Jencks Fix For: 1.1 Attempting to remove the open-ejb spec dependency from the config\rmi-naming I received a ClassDefNotFound error on EJBObject. David Jencks dug into this and figured the problem was due to the fact that MEJB had a requirement on EJBObject because it was implementing the Management interface which extends EJBObject. IIUC this was making it a requirement that we include the EJBObject class from the ejb spec in j2ee-server. There is no need for MEJB to implement management since anyone using it as a gbean isn't likely to have ejbs available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1636) Support optional version number on dependencies
[ http://issues.apache.org/jira/browse/GERONIMO-1636?page=all ] David Jencks closed GERONIMO-1636: -- Resolution: Fixed I think this is working well enough to close, any problems should get their own jiiras. Support optional version number on dependencies --- Key: GERONIMO-1636 URL: http://issues.apache.org/jira/browse/GERONIMO-1636 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: kernel Versions: 1.0 Reporter: Dain Sundstrom Assignee: David Jencks Fix For: 1.1 Add support for making the version number of a dependency optional. In the case of a missing version number a pluggable strategy should choose the actual version to load. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1472) packaging plugin creates client cars with wrong version
[ http://issues.apache.org/jira/browse/GERONIMO-1472?page=all ] David Jencks closed GERONIMO-1472: -- Fix Version: (was: 1.2) Resolution: Fixed This is no longer happening in 1.1 with the version independence changes. packaging plugin creates client cars with wrong version --- Key: GERONIMO-1472 URL: http://issues.apache.org/jira/browse/GERONIMO-1472 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1, 1.2 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 In branch 1.0.1-SNAPSHOT, starting with daytrader ear 1.0, we get the main car at 1.0.1-SNAPSHOT but the client car at 1.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1459) service builder should require name or gbeanName
[ http://issues.apache.org/jira/browse/GERONIMO-1459?page=all ] David Jencks closed GERONIMO-1459: -- Fix Version: 1.1 (was: 1.2) Resolution: Fixed I don't think we need to track this further. service builder should require name or gbeanName Key: GERONIMO-1459 URL: http://issues.apache.org/jira/browse/GERONIMO-1459 Project: Geronimo Type: Bug Security: public(Regular issues) Components: buildsystem Versions: 1.2 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 The service config builder should provide a good error message if you try to give it something like gbean class=foo.bar.Foo/ If we can make the schema detect this that would be even better. Thanks to Alex Andrushchak for discivering this problem -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2008) JarFileClassLoader creates jar urls for plain old files
[ http://issues.apache.org/jira/browse/GERONIMO-2008?page=all ]
Dain Sundstrom updated GERONIMO-2008:
-
Summary: JarFileClassLoader creates jar urls for plain old files (was:
Deployment of war with config file on classpath root fails due to '!' in url)
Component: kernel
(was: deployment)
Fix Version: 1.1
JarFileClassLoader creates jar urls for plain old files
---
Key: GERONIMO-2008
URL: http://issues.apache.org/jira/browse/GERONIMO-2008
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: kernel
Versions: 1.1
Environment: Windows XP - Geronimo 1.1 SNAPSHOT
Reporter: Bryan Noll
Assignee: Dain Sundstrom
Priority: Blocker
Fix For: 1.1
Geronimo fails to properly deploy a webapp that uses Hibernate due to a
configuration file named 'ehcache.xml' that lives on the root of the
classpath. See the following for details. The most likely cause of the
issue is the existence of a '!' in the url... but the fact that a directory
named '!' does not actually exist on the file system under
'repository/default/...'.
logging output:
DEBUG [Configurator] Configuring ehcache from ehcache.xml found in the
classpath:
jar:file:/C:/go11/repository/default/equinox-jsf/1147295851453/equinox-jsf-1147295851453.war/WEB-INF/classes/!/ehcache.xml
I think the thing to notice there is the directory named '!'.
It doesn't actually exist on the file system.
The root exception I'm getting says:
org.hibernate.cache.CacheException: net.sf.ehcache.CacheException: Cannot
configure CacheManager: Access is denied
ehcache code:
public void configure(final Object bean)
throws Exception {
final SAXParser parser = SAXParserFactory.newInstance().newSAXParser();
final BeanHandler handler = new BeanHandler(bean);
URL url = getClass().getResource(DEFAULT_CLASSPATH_CONFIGURATION_FILE);
if (url != null) {
if (LOG.isDebugEnabled()) {
LOG.debug(Configuring ehcache from ehcache.xml found in the
classpath: + url);
}
} else {
url = getClass().getResource(FAILSAFE_CLASSPATH_CONFIGURATION_FILE);
if (LOG.isWarnEnabled()) {
LOG.warn(No configuration found. Configuring ehcache from
ehcache-failsafe.xml
+ found in the classpath: + url);
}
}
parser.parse(url.toExternalForm(), handler);
}
...
where DEFAULT_CLASSPATH_CONFIGURATION_FILE is:
private static final String DEFAULT_CLASSPATH_CONFIGURATION_FILE =
/ehcache.xml;
...
A previous snapshot (had from the last week of April sometime) WORKED and
produced this debug msg.
15:49:26,765 DEBUG [Configurator] Configuring ehcache from ehcache.xml found
in the classpath:
file:/C:/good/repository/default/equinox-jsf/1/equinox-jsf-1.car/WEB-INF/classes/ehcache.xml
A snapshot had from 5/8/06 (give or take a day or two... sorry for the lack
of precision here) produced this debug msg... and this is the one that DOES
NOT WORK. Notice the '!'
15:17:36,765 DEBUG [Configurator] Configuring ehcache from ehcache.xml found
in the classpath:
jar:file:/C:/go11/repository/default/equinox-jsf/1147295851453/equinox-jsf-1147295851453.war/WEB-INF/classes/!/ehcache.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2008) JarFileClassLoader creates jar urls for plain old files
[ http://issues.apache.org/jira/browse/GERONIMO-2008?page=all ]
Dain Sundstrom closed GERONIMO-2008:
Resolution: Fixed
Committed revision 405948.
JarFileClassLoader creates jar urls for plain old files
---
Key: GERONIMO-2008
URL: http://issues.apache.org/jira/browse/GERONIMO-2008
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: kernel
Versions: 1.1
Environment: Windows XP - Geronimo 1.1 SNAPSHOT
Reporter: Bryan Noll
Assignee: Dain Sundstrom
Priority: Blocker
Fix For: 1.1
Geronimo fails to properly deploy a webapp that uses Hibernate due to a
configuration file named 'ehcache.xml' that lives on the root of the
classpath. See the following for details. The most likely cause of the
issue is the existence of a '!' in the url... but the fact that a directory
named '!' does not actually exist on the file system under
'repository/default/...'.
logging output:
DEBUG [Configurator] Configuring ehcache from ehcache.xml found in the
classpath:
jar:file:/C:/go11/repository/default/equinox-jsf/1147295851453/equinox-jsf-1147295851453.war/WEB-INF/classes/!/ehcache.xml
I think the thing to notice there is the directory named '!'.
It doesn't actually exist on the file system.
The root exception I'm getting says:
org.hibernate.cache.CacheException: net.sf.ehcache.CacheException: Cannot
configure CacheManager: Access is denied
ehcache code:
public void configure(final Object bean)
throws Exception {
final SAXParser parser = SAXParserFactory.newInstance().newSAXParser();
final BeanHandler handler = new BeanHandler(bean);
URL url = getClass().getResource(DEFAULT_CLASSPATH_CONFIGURATION_FILE);
if (url != null) {
if (LOG.isDebugEnabled()) {
LOG.debug(Configuring ehcache from ehcache.xml found in the
classpath: + url);
}
} else {
url = getClass().getResource(FAILSAFE_CLASSPATH_CONFIGURATION_FILE);
if (LOG.isWarnEnabled()) {
LOG.warn(No configuration found. Configuring ehcache from
ehcache-failsafe.xml
+ found in the classpath: + url);
}
}
parser.parse(url.toExternalForm(), handler);
}
...
where DEFAULT_CLASSPATH_CONFIGURATION_FILE is:
private static final String DEFAULT_CLASSPATH_CONFIGURATION_FILE =
/ehcache.xml;
...
A previous snapshot (had from the last week of April sometime) WORKED and
produced this debug msg.
15:49:26,765 DEBUG [Configurator] Configuring ehcache from ehcache.xml found
in the classpath:
file:/C:/good/repository/default/equinox-jsf/1/equinox-jsf-1.car/WEB-INF/classes/ehcache.xml
A snapshot had from 5/8/06 (give or take a day or two... sorry for the lack
of precision here) produced this debug msg... and this is the one that DOES
NOT WORK. Notice the '!'
15:17:36,765 DEBUG [Configurator] Configuring ehcache from ehcache.xml found
in the classpath:
jar:file:/C:/go11/repository/default/equinox-jsf/1147295851453/equinox-jsf-1147295851453.war/WEB-INF/classes/!/ehcache.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2010) Simplify the assemblies
[ http://issues.apache.org/jira/browse/GERONIMO-2010?page=all ] David Jencks closed GERONIMO-2010: -- Resolution: Fixed Applied in rev 405974 Simplify the assemblies --- Key: GERONIMO-2010 URL: http://issues.apache.org/jira/browse/GERONIMO-2010 Project: Geronimo Type: Bug Security: public(Regular issues) Components: general Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Assignee: David Jencks Priority: Minor Fix For: 1.1 Attachments: 2010_RemoveDeps.patch Per a recommendation of David Jencks, I removed the explicit inclusion of the specs in the repository for the various geronimo assemblies. This way, a spec will only be included in the assembly if it is in fact needed. My test with this patch indicated that it did not change the end result of the geronimo images. Apparently all of the specs included in each assembly were also included in the necessary configurations.Therefore, I think we should remove the dependencies from the assemblies to avoid confusion and future complications.I also included in this patch a change recommended by Anita remove build dependencies on jetty from rmi-naming and system-database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2017) MEJB should not extend Management because it extends EJBObject pulling in requirements for the ejb-spec
[ http://issues.apache.org/jira/browse/GERONIMO-2017?page=all ] David Jencks closed GERONIMO-2017: -- Resolution: Won't Fix after trying a lot of things I don't think we can make any dependency changes related to this without moving gbeans around, in particular moving the thread pool out of rmi-naming. I'm not sure that move would be a good idea. MEJB should not extend Management because it extends EJBObject pulling in requirements for the ejb-spec --- Key: GERONIMO-2017 URL: http://issues.apache.org/jira/browse/GERONIMO-2017 Project: Geronimo Type: Bug Security: public(Regular issues) Components: management Versions: 1.1 Environment: all Reporter: Joe Bohn Assignee: David Jencks Fix For: 1.1 Attempting to remove the open-ejb spec dependency from the config\rmi-naming I received a ClassDefNotFound error on EJBObject. David Jencks dug into this and figured the problem was due to the fact that MEJB had a requirement on EJBObject because it was implementing the Management interface which extends EJBObject. IIUC this was making it a requirement that we include the EJBObject class from the ejb spec in j2ee-server. There is no need for MEJB to implement management since anyone using it as a gbean isn't likely to have ejbs available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2017) MEJB should not extend Management because it extends EJBObject pulling in requirements for the ejb-spec
[ http://issues.apache.org/jira/browse/GERONIMO-2017?page=comments#action_12383345 ] Aaron Mulder commented on GERONIMO-2017: It's not just theoretical -- there's a page in the console that shows all the activity for a thread pool using the stats provided by the thread pool. The reason there's a thread pool is in the plugin installer uses it. I'd actually like to move the thread pool and plugin installer up to the system module, but that didn't work either. The core, system, and mangement modules have become pretty interdependent. It would be nice to strategically reconsider what goes where, and lay out the expectations for what can go into each level of the server assembly. MEJB should not extend Management because it extends EJBObject pulling in requirements for the ejb-spec --- Key: GERONIMO-2017 URL: http://issues.apache.org/jira/browse/GERONIMO-2017 Project: Geronimo Type: Bug Security: public(Regular issues) Components: management Versions: 1.1 Environment: all Reporter: Joe Bohn Assignee: David Jencks Fix For: 1.1 Attempting to remove the open-ejb spec dependency from the config\rmi-naming I received a ClassDefNotFound error on EJBObject. David Jencks dug into this and figured the problem was due to the fact that MEJB had a requirement on EJBObject because it was implementing the Management interface which extends EJBObject. IIUC this was making it a requirement that we include the EJBObject class from the ejb spec in j2ee-server. There is no need for MEJB to implement management since anyone using it as a gbean isn't likely to have ejbs available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2018) Change temporary system proerty flags to start with X
Change temporary system proerty flags to start with X --- Key: GERONIMO-2018 URL: http://issues.apache.org/jira/browse/GERONIMO-2018 Project: Geronimo Type: Improvement Security: public (Regular issues) Reporter: Dain Sundstrom Assigned to: Dain Sundstrom Priority: Blocker Fix For: 1.1 org.apache.geronimo.gbean.NoProxy in AbstractGBeanReference org.apache.geronimo.kernel.config.Marshaler in ConfigurationUtil -- 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-1854) Coordinate list of started configs for Jetty,Tomcat for 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1854?page=all ] Aaron Mulder resolved GERONIMO-1854: Resolution: Fixed 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 Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: g-1854.patch 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] Commented: (GERONIMO-1889) Changing pooling parameters for connector does not persist to config.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1889?page=comments#action_12383358 ] Aaron Mulder commented on GERONIMO-1889: I checked and the ActiveMQ patch has been applied already. Changing pooling parameters for connector does not persist to config.xml Key: GERONIMO-1889 URL: http://issues.apache.org/jira/browse/GERONIMO-1889 Project: Geronimo Type: Bug Security: public(Regular issues) Components: connector, kernel, console Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: ACTIVEMQ-gbean.patch, GERONIMO-1889.patch, GERONIMO-1889.patch.2 To replicate: Open the console Select Database Pools Click the edit link to the right of System Datasource Change pool max size to 119 Click Save Click the edit link to the right of System Datasource Confirm that it shows a pool max size of 119 Shut down the server Grep config.xml for 119, it does not appear Start the server Edit the System Datasource again, confirm that the pool max size is NOT 119 Also need to check whether changing the data connection properties is persisted. -- 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
