RE: How to change KeyStore type?
Vamsi, Thanks a lot for the patch! I'm voting for getting the change into the nearest release, as it allows Geronimo to run on Harmony and maybe other VMs - current release can't do that, and adding this feature is a good bonus to Geronimo flexibility and compatibility. Thanks, Vasily From: Vamsavardhana Reddy [mailto:[EMAIL PROTECTED] Sent: Monday, January 28, 2008 4:23 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? Here is an essence of the fix that went in to trunk (2.1): o Allow creation of all possible keystore types supported. Keystore type is no longer restricted to JKS. o Added a type parameter to create keystore methods. o Keystores portlet will now allow creating and managing all types of keystores. o This revision will simplify the configuration changes required to run G on a JVM that does not support JKS keystores (for e.g., Harmony). o Allow selecting any keystore type supported by the JVM in Tomcat HTTPS Connector pages. As this feature required some interface changes, for e.g. KeystoreManager, KeystoreInstance etc., I would like to hear from others on considering this for branches\2.0 as it may break compatibility. ++Vamsi On Jan 21, 2008 11:21 PM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Vamsi, Thanks for the detailed analysis. The problem indeed looks non-trivial. Step 1. This looks pretty simple, and I'm now creating a patch for that. This change seems very important to me, how about getting it to v2.0.3/2.1? Step 2. This change also seems very important, but less critical than the first one, and it requires essential interface changes, so I tend to agree it certainly should wait till 2.1 or later. As of pitfalls, they seem unavoidable. Sure we want compatibility, but any compatibility has its limits. I suppose that changing JDK under a particular running installation of Geronimo is not a feature in great demand, and in a rare case when such a change would be necessary, a keystore conversion could be done manually (e.g. JKS-PKCS12 conversion can be done in Sun, PKCS12-BKS conversion can be done in Harmony etc.) Vasily From: Vamsavardhana Reddy [mailto:[EMAIL PROTECTED] Sent: Monday, January 21, 2008 8:23 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? Providing a keystoreType attribute does not seem to be a big deal. But, if the Keystores portlet has to allow creating all types of keystores, it gets really messy. Here is one more observation. IBMJDK does not allow storing an empty PKCS12 keystore to disk. This prevents creating an empty PKCS12 keystore and then adding which ever keys and certificates the user wants to. Here is the approach I want to take. Step 1. Provide a keystoreType attribute in FileKeystoreInstance. Step 2. Update KeyStores portlet to allow creation of all keystore types that the JDK allows to store an empty keystore to disk. Step 1 will allow the users to replace a keystore file of one type with that of another type, change the keystoreType in config.xml and get the server running. Step 2 will allow users to manage all keystore types using Keystores portlet and there is no hard-coding of any keystoreType except for geronimo-default keystore which is JKS. Now to some pitfalls. 1. If keystore type other than JKS is in use, the user may not be able to switch JDK's for reasons like PKCS12 keystore created using IBMJDK are not readble using SUNJDK. 2. Though IBMJDK does not allow creating an empty PKCS12 (and a few other types) keystore as a starting point for managing a PKCS12 keystore, the users can always add a PKCS12 keystore to var/security/keystores and the gbean definition to config.xml. This will make the keystore manageable through KeyStores portlet as long as the keystore is not empty. This will require a change in org.apache.geronimo.management.geronimo.KeystoreManager interface, etc. I doubt if we can consider this change for branches\2.0. Comments? ++Vamsi On Jan 18, 2008 1:37 AM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Yes, sure, I fully agree. I've filed GERONIMO-3757 for this issue and now thinking of the patch to the trunk that would provide the necessary customization - unless any objections arise. As of GERONIMO-2015, I think we may close it, as there're objective reasons (stated there by Vamsavardhana Reddy) to not move from JKS on Sun. Vasily -Original Message- From: Alexey Petrenko [mailto: [EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 1:37 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? I think we should add PKCS12 to Geronimo. If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose what keystore to use? We can specify keystore in configs or choose type from available on current VM. SY, Alexey 2008/1/15, Zakharov, Vasily M [EMAIL
RE: Hang on shutdown on Harmony
Rick, Thanks for the detailed analysys, I'll investigate it. Vasily -Original Message- From: Rick McGuire [mailto:[EMAIL PROTECTED] Sent: Friday, January 25, 2008 1:56 PM To: dev@geronimo.apache.org Subject: Re: Hang on shutdown on Harmony I'm not sure I understand how this stack trace is occurring. Is it possible that there's an error in Harmony exception handling? Here's what's supposed to be happening here. At ORB shutdown, the socket that acceptor has issued the accept() call is closed. That's line 111 in Acceptor_impl. This should cause an I/O exception, which is what the stack trace is showing. However, there's a catch for that IOException at line 125 in Acceptor_impl that should be turning that into a org.omg.CORBA.COMM_FAILURE exception. That exception in turn should be caught GIOPServerStartedThreaded.starterRun(), which detects at that point that this is a shutdown situation and terminates the run loop on the thread. The loop that Jarek mentioned in ORBControl is waiting for the server threads to finish shutting down, but if that IOException is not getting trapped properly, this thread goes away without cleanuing up its state. I am a little puzzled about how completeServerShutdown can get caught in a loop, since it appears to have a cap on how many times it will go around that loop. Rick Zakharov, Vasily M wrote: Hi, all, I observe the following stack trace when shutting down Geronimo (branches/2.0) running on Harmony, and then Geronimo stops responding forever. Otherwise, Geronimo runs pretty well on Harmony, see [1], details are at [2]. What is interesting is exactly similar stack and hang are observed when running org.apache.geronimo.yoko.TSSConfigEditorTest test on Harmony, I already wrote about it, see [3]. For now I couldn't find out the cause for this behavior, so if someone has any ideas on where to look, I'd be grateful. Thanks! [] received stop signal Jan 24, 2008 5:34:18 PM org.apache.yoko.orb.OCI.IIOP.Acceptor_impl accept SEVERE: Failure accepting connection for host=ecwm0vmzakhar/192.168.16.2, port=2001 Throwable occurred: java.io.IOException: Connection was closed at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake(SSLSocke tImpl.java:760) at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake(SSLSo cketImpl.java:438) at org.apache.harmony.xnet.provider.jsse.SSLServerSocketImpl.accept(SSLServ erSocketImpl.java:256) at org.apache.yoko.orb.OCI.IIOP.Acceptor_impl.accept(Acceptor_impl.java:111 ) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded.starterRun(GIOPServerSt arterThreaded.java:195) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded$StarterThread.run(GIOPS erverStarterThreaded.java:34) [1] http://thread.gmane.org/gmane.comp.java.geronimo.devel/57921 [2] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony [3] http://thread.gmane.org/gmane.comp.java.geronimo.devel/57396 Vasily Zakharov, Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Hang on shutdown on Harmony
Hi, all, I observe the following stack trace when shutting down Geronimo (branches/2.0) running on Harmony, and then Geronimo stops responding forever. Otherwise, Geronimo runs pretty well on Harmony, see [1], details are at [2]. What is interesting is exactly similar stack and hang are observed when running org.apache.geronimo.yoko.TSSConfigEditorTest test on Harmony, I already wrote about it, see [3]. For now I couldn't find out the cause for this behavior, so if someone has any ideas on where to look, I'd be grateful. Thanks! [] received stop signal Jan 24, 2008 5:34:18 PM org.apache.yoko.orb.OCI.IIOP.Acceptor_impl accept SEVERE: Failure accepting connection for host=ecwm0vmzakhar/192.168.16.2, port=2001 Throwable occurred: java.io.IOException: Connection was closed at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake(SSLSocke tImpl.java:760) at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake(SSLSo cketImpl.java:438) at org.apache.harmony.xnet.provider.jsse.SSLServerSocketImpl.accept(SSLServ erSocketImpl.java:256) at org.apache.yoko.orb.OCI.IIOP.Acceptor_impl.accept(Acceptor_impl.java:111 ) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded.starterRun(GIOPServerSt arterThreaded.java:195) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded$StarterThread.run(GIOPS erverStarterThreaded.java:34) [1] http://thread.gmane.org/gmane.comp.java.geronimo.devel/57921 [2] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony [3] http://thread.gmane.org/gmane.comp.java.geronimo.devel/57396 Vasily Zakharov, Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
RE: Hang on shutdown on Harmony
Jarek, Thanks! I'll check that. Vasily -Original Message- From: Jarek Gawor [mailto:[EMAIL PROTECTED] Sent: Thursday, January 24, 2008 9:24 PM To: dev@geronimo.apache.org Subject: Re: Hang on shutdown on Harmony I'm trying to remember but once I managed to get Harmony running in a debugger (while debugging the TSSConfigEditorTest test issue) I've noticed that it was stuck in a loop in ORBControl.completeServerShutdown() (http://svn.apache.org/viewvc/geronimo/yoko/trunk/core/src/main/java/org /apache/yoko/orb/OB/ORBControl.java?view=markup) Jarek On Jan 24, 2008 11:19 AM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Hi, all, I observe the following stack trace when shutting down Geronimo (branches/2.0) running on Harmony, and then Geronimo stops responding forever. Otherwise, Geronimo runs pretty well on Harmony, see [1], details are at [2]. What is interesting is exactly similar stack and hang are observed when running org.apache.geronimo.yoko.TSSConfigEditorTest test on Harmony, I already wrote about it, see [3]. For now I couldn't find out the cause for this behavior, so if someone has any ideas on where to look, I'd be grateful. Thanks! [] received stop signal Jan 24, 2008 5:34:18 PM org.apache.yoko.orb.OCI.IIOP.Acceptor_impl accept SEVERE: Failure accepting connection for host=ecwm0vmzakhar/192.168.16.2, port=2001 Throwable occurred: java.io.IOException: Connection was closed at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake(SSLSocke tImpl.java:760) at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake(SSLSo cketImpl.java:438) at org.apache.harmony.xnet.provider.jsse.SSLServerSocketImpl.accept(SSLServ erSocketImpl.java:256) at org.apache.yoko.orb.OCI.IIOP.Acceptor_impl.accept(Acceptor_impl.java:111 ) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded.starterRun(GIOPServerSt arterThreaded.java:195) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded$StarterThread.run(GIOPS erverStarterThreaded.java:34) [1] http://thread.gmane.org/gmane.comp.java.geronimo.devel/57921 [2] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony [3] http://thread.gmane.org/gmane.comp.java.geronimo.devel/57396 Vasily Zakharov, Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
RE: How to change KeyStore type?
Vamsi, Thanks for the detailed analysis. The problem indeed looks non-trivial. Step 1. This looks pretty simple, and I'm now creating a patch for that. This change seems very important to me, how about getting it to v2.0.3/2.1? Step 2. This change also seems very important, but less critical than the first one, and it requires essential interface changes, so I tend to agree it certainly should wait till 2.1 or later. As of pitfalls, they seem unavoidable. Sure we want compatibility, but any compatibility has its limits. I suppose that changing JDK under a particular running installation of Geronimo is not a feature in great demand, and in a rare case when such a change would be necessary, a keystore conversion could be done manually (e.g. JKS-PKCS12 conversion can be done in Sun, PKCS12-BKS conversion can be done in Harmony etc.) Vasily From: Vamsavardhana Reddy [mailto:[EMAIL PROTECTED] Sent: Monday, January 21, 2008 8:23 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? Providing a keystoreType attribute does not seem to be a big deal. But, if the Keystores portlet has to allow creating all types of keystores, it gets really messy. Here is one more observation. IBMJDK does not allow storing an empty PKCS12 keystore to disk. This prevents creating an empty PKCS12 keystore and then adding which ever keys and certificates the user wants to. Here is the approach I want to take. Step 1. Provide a keystoreType attribute in FileKeystoreInstance. Step 2. Update KeyStores portlet to allow creation of all keystore types that the JDK allows to store an empty keystore to disk. Step 1 will allow the users to replace a keystore file of one type with that of another type, change the keystoreType in config.xml and get the server running. Step 2 will allow users to manage all keystore types using Keystores portlet and there is no hard-coding of any keystoreType except for geronimo-default keystore which is JKS. Now to some pitfalls. 1. If keystore type other than JKS is in use, the user may not be able to switch JDK's for reasons like PKCS12 keystore created using IBMJDK are not readble using SUNJDK. 2. Though IBMJDK does not allow creating an empty PKCS12 (and a few other types) keystore as a starting point for managing a PKCS12 keystore, the users can always add a PKCS12 keystore to var/security/keystores and the gbean definition to config.xml. This will make the keystore manageable through KeyStores portlet as long as the keystore is not empty. This will require a change in org.apache.geronimo.management.geronimo.KeystoreManager interface, etc. I doubt if we can consider this change for branches\2.0. Comments? ++Vamsi On Jan 18, 2008 1:37 AM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Yes, sure, I fully agree. I've filed GERONIMO-3757 for this issue and now thinking of the patch to the trunk that would provide the necessary customization - unless any objections arise. As of GERONIMO-2015, I think we may close it, as there're objective reasons (stated there by Vamsavardhana Reddy) to not move from JKS on Sun. Vasily -Original Message- From: Alexey Petrenko [mailto: [EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 1:37 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? I think we should add PKCS12 to Geronimo. If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose what keystore to use? We can specify keystore in configs or choose type from available on current VM. SY, Alexey 2008/1/15, Zakharov, Vasily M [EMAIL PROTECTED]: Hi, all, Is there a way to change the geronimo-default keystore from JKS to, say, PKCS12 without patching the org.apache.geronimo.security.keystore.FileKeystore* classes? That way of patching sources is suggested at GERONIMO-2015, and it works, but it's probably not the best idea. I see the reasons of not making PKCS12 a default keystore type, but what about making it possible to change keystore type using config.xml, without source recompilation? I've browsed through the configuration options of geronimo-security gbean, a found no way for that. Should I provide a patch for that to be possible, would that be appropriate? Thank you! Vasily Zakharov Intel ESSD ---
RE: Geronimo 2.0.2 starts on Harmony!
What do you mean by HTTP interface works badly? Slow? Exceptions? It only shows the left frame. The HTML source of the page seems truncated at some point. I couldn't find any entries in the log concerning this problem, I'd investigate further. What platform are you using? Linux or Windows? Windows XP Pro on my notebook. As far as I understood you already got a patch for GERONIMO-3757. If so could you please attach it to the issue? :) What I have now is not a patch, but a hotfix workaround. Sure, I'll try to make a valid patch out of it. What I'm not sure is how should I check the patch before it can be considered valid - sure I can run GUT on Sun and Harmony, but otherwise there's so many Geronimo release bundles and platforms that it would be difficult to make sure I didn't break anything in complex Geronimo structure. I also think that it would be nice to add the list of Harmony and Geronimo issues related to Geronimo on Harmony to the wiki page you have created. Well, I have all the actual issues mentioned there. Do you mean it makes sense to have a separate listing of JIRA numbers somewhere? Do you mean only actual open issues, or fixed/closed also? Vasily -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 2:57 AM To: dev@geronimo.apache.org Subject: Re: Geronimo 2.0.2 starts on Harmony! Great news, Vasily! What do you mean by HTTP interface works badly? Slow? Exceptions? What platform are you using? Linux or Windows? As far as I understood you already got a patch for GERONIMO-3757. If so could you please attach it to the issue? :) I also think that it would be nice to add the list of Harmony and Geronimo issues related to Geronimo on Harmony to the wiki page you have created. Thanks in advance. SY, Alexey 2008/1/18, Zakharov, Vasily M [EMAIL PROTECTED]: Hi, all, Well, finally I can say Geronimo 2.0.2 starts and works on Apache Harmony! Some steps yet need to be taken for that to happen - see [1] for details. Some issues were overcome, some workarounded, and some just hotfixed and wait for their proper resolution, like GERONIMO-3757. Three important problems that still need investigation are: - HTTP interface works badly (HTTPS works fine). - The application takes up all the CPU resources on both cores I have available so the machine is 100% busy. - The application takes up all the memory specified in -Xms option. Otherwise, I was able to browse the console freely and even deploy SPECjAppServer2004. No serious load was tested however. Vasily Zakharov Intel ESSD [1] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony
RE: Geronimo 2.0.2 starts on Harmony!
It's not the latest, but rather recent - I used r610339. Hmm, good idea, thanks! :) Vasily -Original Message- From: Jarek Gawor [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 2:49 AM To: dev@geronimo.apache.org Subject: Re: Geronimo 2.0.2 starts on Harmony! Cool! Is this with latest Harmony snapshot? Also, if you rename or remove the bin/jpa.jar you should be able to use the Geronimo scripts to start up the server. Jarek On Jan 17, 2008 6:15 PM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Hi, all, Well, finally I can say Geronimo 2.0.2 starts and works on Apache Harmony! Some steps yet need to be taken for that to happen - see [1] for details. Some issues were overcome, some workarounded, and some just hotfixed and wait for their proper resolution, like GERONIMO-3757. Three important problems that still need investigation are: - HTTP interface works badly (HTTPS works fine). - The application takes up all the CPU resources on both cores I have available so the machine is 100% busy. - The application takes up all the memory specified in -Xms option. Otherwise, I was able to browse the console freely and even deploy SPECjAppServer2004. No serious load was tested however. Vasily Zakharov Intel ESSD [1] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
RE: MailGBean/JNDI problem on Harmony
Yes, sure. I had to replace the keystore, patch the geronimo-security
sources
and make other adjustments. See [1] for the details.
And anyway Geronimo doesn't work very good for now, still many problems
are visible (e .g., the console almost doesn't work) and need to be
investigated and fixed.
Vasily
[1] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony
-Original Message-
From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 17, 2008 11:24 AM
To: dev@geronimo.apache.org
Subject: Re: MailGBean/JNDI problem on Harmony
Nice. But it starts with patched key store as far as I understand...
right?
SY, Alexey
https://issues.apache.org/jira/browse/GERONIMO-2015
2008/1/16, Zakharov, Vasily M [EMAIL PROTECTED]:
Sorry for disturbing, I've just found out the cause for this issue - I
had one extra property in config.xml. If namingFactoryInitial
specification is removed, and namingFactoryUrlPkgs specification is
retained, the problem is resolved, and Geronimo starts fine on
Harmony.
Vasily
-Original Message-
From: Zakharov, Vasily M [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 16, 2008 8:53 PM
To: dev@geronimo.apache.org
Subject: MailGBean/JNDI problem on Harmony
Hi, all,
I'm found a problem with MailGBean on Harmony due to of JNDI
configuration, and I'm asking for help to understand how to deal with
that problem. The problem would occur on any JDK lacking Sun
implementation of JNDI RMI Registry provider
(com.sun.jndi.rmi.registry.RegistryContext). The problem occurs at
startup and looks as follows:
java.lang.IllegalArgumentException: Cannot bind to RMI Registry object
that is neither Remote nor Reference nor Referenceable
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.getStateTo
Bind(RegistryContext.java:618)
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
tryContext.java:266)
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
tryContext.java:280)
at javax.naming.InitialContext.bind(InitialContext.java:411)
at
org.apache.geronimo.mail.MailGBean.doStart(MailGBean.java:385)
The investigation shows the following difference of MailGBean code
operation on Sun and Harmony:
On Sun, the InitialContext.getEnvironment() is empty, and
InitialContext.lookup() returns
org.apache.geronimo.gjndi.GlobalContextGBean, and
InitialContext.getNameParser() returns
org.apache.xbean.naming.context.ContextUtil$SimpleNameParser.
On Harmony, this works much differently -
InitialContext.getEnvironment() contains the JNDI properties specified
in config.xml, and InitialContext.lookup() returns
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext, and
InitialContext.getNameParser() returns
org.apache.harmony.jndi.provider.rmi.registry.AtomicNameParser.
This causes the error above.
I had to specify the respective JNDI properties in config.xml for
JMXConnector to start normally, as follows:
module name=org.apache.geronimo.configs/rmi-naming/2.0.2/car
gbean name=NamingProperties
attribute
name=namingFactoryInitialorg.apache.harmony.jndi.provider.rmi.registr
y.RegistryContextFactory/attribute
attribute
name=namingFactoryUrlPkgsorg.apache.harmony.jndi.provider/attribute
attribute
name=namingProviderUrlrmi://${ServerHostname}:${NamingPort
+ PortOffset}/attribute
/gbean
Probably this is wrong to configure JNDI this way, as it overrides
Geronimo internal naming mechanisms?
Maybe org.apache.geronimo.gjndi.GlobalContextGBean needs to be tweaked
to find the proper JNDI RMI Registry provider by other means than
standard JNDI properties?
I'd be happy to hear any ideas, considerations or suggestions on this
issue.
Thank you very much!
Vasily Zakharov
Intel ESSD
---
RE: How to change KeyStore type?
Yes, sure, I fully agree. I've filed GERONIMO-3757 for this issue and now thinking of the patch to the trunk that would provide the necessary customization - unless any objections arise. As of GERONIMO-2015, I think we may close it, as there're objective reasons (stated there by Vamsavardhana Reddy) to not move from JKS on Sun. Vasily -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 1:37 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? I think we should add PKCS12 to Geronimo. If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose what keystore to use? We can specify keystore in configs or choose type from available on current VM. SY, Alexey 2008/1/15, Zakharov, Vasily M [EMAIL PROTECTED]: Hi, all, Is there a way to change the geronimo-default keystore from JKS to, say, PKCS12 without patching the org.apache.geronimo.security.keystore.FileKeystore* classes? That way of patching sources is suggested at GERONIMO-2015, and it works, but it's probably not the best idea. I see the reasons of not making PKCS12 a default keystore type, but what about making it possible to change keystore type using config.xml, without source recompilation? I've browsed through the configuration options of geronimo-security gbean, a found no way for that. Should I provide a patch for that to be possible, would that be appropriate? Thank you! Vasily Zakharov Intel ESSD ---
Geronimo 2.0.2 starts on Harmony!
Hi, all, Well, finally I can say Geronimo 2.0.2 starts and works on Apache Harmony! Some steps yet need to be taken for that to happen - see [1] for details. Some issues were overcome, some workarounded, and some just hotfixed and wait for their proper resolution, like GERONIMO-3757. Three important problems that still need investigation are: - HTTP interface works badly (HTTPS works fine). - The application takes up all the CPU resources on both cores I have available so the machine is 100% busy. - The application takes up all the memory specified in -Xms option. Otherwise, I was able to browse the console freely and even deploy SPECjAppServer2004. No serious load was tested however. Vasily Zakharov Intel ESSD [1] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony
RE: Geronimo 2.0.2 starts on Harmony!
Strange about the behavior under HTTP... I'm amazed too. I thought it was critical problem until I tried HTTPS to make sure SSL is working - and bingo, it was fine that way. Some stupid problem in Harmony, I suppose. Vasily -Original Message- From: Kevan Miller [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 2:26 AM To: dev@geronimo.apache.org Subject: Re: Geronimo 2.0.2 starts on Harmony! On Jan 17, 2008, at 6:15 PM, Zakharov, Vasily M wrote: Hi, all, Well, finally I can say Geronimo 2.0.2 starts and works on Apache Harmony! Some steps yet need to be taken for that to happen - see [1] for details. Some issues were overcome, some workarounded, and some just hotfixed and wait for their proper resolution, like GERONIMO-3757. Three important problems that still need investigation are: - HTTP interface works badly (HTTPS works fine). - The application takes up all the CPU resources on both cores I have available so the machine is 100% busy. - The application takes up all the memory specified in -Xms option. Otherwise, I was able to browse the console freely and even deploy SPECjAppServer2004. No serious load was tested however. Nice. Congrats Vasily. Sounds like we have a little ways to go... Let us know what you find about memory and CPU consumption... Strange about the behavior under HTTP... --kevan
MailGBean/JNDI problem on Harmony
Hi, all,
I'm found a problem with MailGBean on Harmony due to of JNDI
configuration, and I'm asking for help to understand how to deal with
that problem. The problem would occur on any JDK lacking Sun
implementation of JNDI RMI Registry provider
(com.sun.jndi.rmi.registry.RegistryContext). The problem occurs at
startup and looks as follows:
java.lang.IllegalArgumentException: Cannot bind to RMI Registry object
that is neither Remote nor Reference nor Referenceable
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.getStateTo
Bind(RegistryContext.java:618)
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
tryContext.java:266)
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
tryContext.java:280)
at javax.naming.InitialContext.bind(InitialContext.java:411)
at
org.apache.geronimo.mail.MailGBean.doStart(MailGBean.java:385)
The investigation shows the following difference of MailGBean code
operation on Sun and Harmony:
On Sun, the InitialContext.getEnvironment() is empty, and
InitialContext.lookup() returns
org.apache.geronimo.gjndi.GlobalContextGBean, and
InitialContext.getNameParser() returns
org.apache.xbean.naming.context.ContextUtil$SimpleNameParser.
On Harmony, this works much differently -
InitialContext.getEnvironment() contains the JNDI properties specified
in config.xml, and InitialContext.lookup() returns
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext, and
InitialContext.getNameParser() returns
org.apache.harmony.jndi.provider.rmi.registry.AtomicNameParser.
This causes the error above.
I had to specify the respective JNDI properties in config.xml for
JMXConnector to start normally, as follows:
module name=org.apache.geronimo.configs/rmi-naming/2.0.2/car
gbean name=NamingProperties
attribute
name=namingFactoryInitialorg.apache.harmony.jndi.provider.rmi.registr
y.RegistryContextFactory/attribute
attribute
name=namingFactoryUrlPkgsorg.apache.harmony.jndi.provider/attribute
attribute name=namingProviderUrlrmi://${ServerHostname}:${NamingPort
+ PortOffset}/attribute
/gbean
Probably this is wrong to configure JNDI this way, as it overrides
Geronimo internal naming mechanisms?
Maybe org.apache.geronimo.gjndi.GlobalContextGBean needs to be tweaked
to find the proper JNDI RMI Registry provider by other means than
standard JNDI properties?
I'd be happy to hear any ideas, considerations or suggestions on this
issue.
Thank you very much!
Vasily Zakharov
Intel ESSD
---
RE: MailGBean/JNDI problem on Harmony
Sorry for disturbing, I've just found out the cause for this issue - I
had one extra property in config.xml. If namingFactoryInitial
specification is removed, and namingFactoryUrlPkgs specification is
retained, the problem is resolved, and Geronimo starts fine on Harmony.
Vasily
-Original Message-
From: Zakharov, Vasily M [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 16, 2008 8:53 PM
To: dev@geronimo.apache.org
Subject: MailGBean/JNDI problem on Harmony
Hi, all,
I'm found a problem with MailGBean on Harmony due to of JNDI
configuration, and I'm asking for help to understand how to deal with
that problem. The problem would occur on any JDK lacking Sun
implementation of JNDI RMI Registry provider
(com.sun.jndi.rmi.registry.RegistryContext). The problem occurs at
startup and looks as follows:
java.lang.IllegalArgumentException: Cannot bind to RMI Registry object
that is neither Remote nor Reference nor Referenceable
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.getStateTo
Bind(RegistryContext.java:618)
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
tryContext.java:266)
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
tryContext.java:280)
at javax.naming.InitialContext.bind(InitialContext.java:411)
at
org.apache.geronimo.mail.MailGBean.doStart(MailGBean.java:385)
The investigation shows the following difference of MailGBean code
operation on Sun and Harmony:
On Sun, the InitialContext.getEnvironment() is empty, and
InitialContext.lookup() returns
org.apache.geronimo.gjndi.GlobalContextGBean, and
InitialContext.getNameParser() returns
org.apache.xbean.naming.context.ContextUtil$SimpleNameParser.
On Harmony, this works much differently -
InitialContext.getEnvironment() contains the JNDI properties specified
in config.xml, and InitialContext.lookup() returns
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext, and
InitialContext.getNameParser() returns
org.apache.harmony.jndi.provider.rmi.registry.AtomicNameParser.
This causes the error above.
I had to specify the respective JNDI properties in config.xml for
JMXConnector to start normally, as follows:
module name=org.apache.geronimo.configs/rmi-naming/2.0.2/car
gbean name=NamingProperties
attribute
name=namingFactoryInitialorg.apache.harmony.jndi.provider.rmi.registr
y.RegistryContextFactory/attribute
attribute
name=namingFactoryUrlPkgsorg.apache.harmony.jndi.provider/attribute
attribute name=namingProviderUrlrmi://${ServerHostname}:${NamingPort
+ PortOffset}/attribute
/gbean
Probably this is wrong to configure JNDI this way, as it overrides
Geronimo internal naming mechanisms?
Maybe org.apache.geronimo.gjndi.GlobalContextGBean needs to be tweaked
to find the proper JNDI RMI Registry provider by other means than
standard JNDI properties?
I'd be happy to hear any ideas, considerations or suggestions on this
issue.
Thank you very much!
Vasily Zakharov
Intel ESSD
---
How to change KeyStore type?
Hi, all, Is there a way to change the geronimo-default keystore from JKS to, say, PKCS12 without patching the org.apache.geronimo.security.keystore.FileKeystore* classes? That way of patching sources is suggested at GERONIMO-2015, and it works, but it's probably not the best idea. I see the reasons of not making PKCS12 a default keystore type, but what about making it possible to change keystore type using config.xml, without source recompilation? I've browsed through the configuration options of geronimo-security gbean, a found no way for that. Should I provide a patch for that to be possible, would that be appropriate? Thank you! Vasily Zakharov Intel ESSD ---
RE: TSSConfigEditorTest requires SSL?
Jarek, Yes, it hangs. It seems the client part does something wrong and stops, while the server part waits for the connection for some time and then (after a while) throws the exception mentioned. Vasily -Original Message- From: Jarek Gawor [mailto:[EMAIL PROTECTED] Sent: Thursday, January 10, 2008 6:13 PM To: dev@geronimo.apache.org Subject: Re: TSSConfigEditorTest requires SSL? Vasily, When I tried to run this test with Harmony, it seemed to hang for me. Didn't really investigate more than that why but I was curious if you get that IOException error right away or after a while (e.g. after a timeout). Jarek On Jan 10, 2008 6:09 AM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Jarek, Thanks for the suggestion, unfortunately that didn't help, the stack remains the same. It seems the problem lies elsewhere. Thanks anyway! Vasily -Original Message- From: Jarek Gawor [mailto:[EMAIL PROTECTED] Sent: Saturday, December 29, 2007 2:28 AM To: dev@geronimo.apache.org Subject: Re: TSSConfigEditorTest requires SSL? Try adding the following line to this test: corbaBean.getSslConfig().setProtocol(TLS); so the code looks like: corbaBean.setTssConfig(tss); corbaBean.getSslConfig().setProtocol(TLS); Jarek On Dec 27, 2007 12:48 PM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: David, Yes, Harmony supports TLS, but looking at the test code and configuration I couldn't guess a way how the test could be reconfigured for TLS. One of the reasons I'm asking is I now have greater than 99% pass rate for GUT v2.0.2 on Harmony, and this test is the last one about which I'm not sure if we have a bug in Harmony, or a bug in the test or it's just because Harmony doesn't have SSL and that's a known issue. Vasily -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Thursday, December 27, 2007 8:37 PM To: dev@geronimo.apache.org Subject: Re: TSSConfigEditorTest requires SSL? It has been a long time since I've worked with this test but I'm pretty sure that you are correct, the test sets up an SSL socket. I seem to recall that Harmony supports TLS?? From the stack trace I wonder if the problem is in Yoko. I'm definitely not a TLS expert, do you have any advice on how to fix this? thanks david jencks On Dec 27, 2007, at 10:33 AM, Zakharov, Vasily M wrote: Hi, all, I wonder if org.apache.geronimo.yoko.TSSConfigEditorTest test is SSL dependent? I'm trying to run Geronimo Unit Tests on Apache Harmony, and this test fails (with the stack below) for the reason I couldn't find out. Could that be because Harmony has no SSL implementation? SEVERE: Failure accepting connection for host=ecwm0vmzakhar/172.28.118.8, port=8050 java.io.IOException: Connection was closed at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake (SSLSocke tImpl.java:760) at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake (SSLSo cketImpl.java:438) at org.apache.harmony.xnet.provider.jsse.SSLServerSocketImpl.accept (SSLServ erSocketImpl.java:256) at org.apache.yoko.orb.OCI.IIOP.Acceptor_impl.accept (Acceptor_impl.java:111 ) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded.starterRun (GIOPServerSt arterThreaded.java:195) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded$StarterThread.run (GIOPS erverStarterThreaded.java:34) Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient
RE: TSSConfigEditorTest requires SSL?
Jarek, Thanks for the suggestion, unfortunately that didn't help, the stack remains the same. It seems the problem lies elsewhere. Thanks anyway! Vasily -Original Message- From: Jarek Gawor [mailto:[EMAIL PROTECTED] Sent: Saturday, December 29, 2007 2:28 AM To: dev@geronimo.apache.org Subject: Re: TSSConfigEditorTest requires SSL? Try adding the following line to this test: corbaBean.getSslConfig().setProtocol(TLS); so the code looks like: corbaBean.setTssConfig(tss); corbaBean.getSslConfig().setProtocol(TLS); Jarek On Dec 27, 2007 12:48 PM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: David, Yes, Harmony supports TLS, but looking at the test code and configuration I couldn't guess a way how the test could be reconfigured for TLS. One of the reasons I'm asking is I now have greater than 99% pass rate for GUT v2.0.2 on Harmony, and this test is the last one about which I'm not sure if we have a bug in Harmony, or a bug in the test or it's just because Harmony doesn't have SSL and that's a known issue. Vasily -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Thursday, December 27, 2007 8:37 PM To: dev@geronimo.apache.org Subject: Re: TSSConfigEditorTest requires SSL? It has been a long time since I've worked with this test but I'm pretty sure that you are correct, the test sets up an SSL socket. I seem to recall that Harmony supports TLS?? From the stack trace I wonder if the problem is in Yoko. I'm definitely not a TLS expert, do you have any advice on how to fix this? thanks david jencks On Dec 27, 2007, at 10:33 AM, Zakharov, Vasily M wrote: Hi, all, I wonder if org.apache.geronimo.yoko.TSSConfigEditorTest test is SSL dependent? I'm trying to run Geronimo Unit Tests on Apache Harmony, and this test fails (with the stack below) for the reason I couldn't find out. Could that be because Harmony has no SSL implementation? SEVERE: Failure accepting connection for host=ecwm0vmzakhar/172.28.118.8, port=8050 java.io.IOException: Connection was closed at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake (SSLSocke tImpl.java:760) at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake (SSLSo cketImpl.java:438) at org.apache.harmony.xnet.provider.jsse.SSLServerSocketImpl.accept (SSLServ erSocketImpl.java:256) at org.apache.yoko.orb.OCI.IIOP.Acceptor_impl.accept (Acceptor_impl.java:111 ) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded.starterRun (GIOPServerSt arterThreaded.java:195) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded$StarterThread.run (GIOPS erverStarterThreaded.java:34) Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
PKCS12 keystore support
Hi, all, What is the current situation with the PKCS12 support in Geronimo? I see the GERONIMO-2015 issue has a year-and-a-half history, it was targeted at v2.0, but now v2.0.2 is already out there. It looks like parts of the proposed functionality are already there, and otherwise the patches are obsolete as they don't use the keystore gbean. Is it worth providing newer patches on this, are there any plans to integrate them? For now, Geronimo still doesn't start if JKS implementation is not available, e. g. on Harmony (see the stack below). Vasily Zakharov Intel ESSD java.io.IOException: Unable to create server SSL socket factory: Unable to create SSL Context at org.apache.geronimo.yoko.SocketFactory.getServerSocketFactory(SocketFact ory.java:407) at org.apache.geronimo.yoko.SocketFactory.createServerSocket(SocketFactory. java:317) at org.apache.yoko.orb.OCI.IIOP.Acceptor_impl.init(Acceptor_impl.java:461 ) at org.apache.yoko.orb.OCI.IIOP.AccFactory_impl.create_acceptor(AccFactory_ impl.java:157) at org.apache.yoko.orb.OBPortableServer.POAManagerFactory_impl.create_POAMa nager(POAManagerFactory_impl.java:251) at org.apache.yoko.orb.OB.ORBControl.initializeRootPOA(ORBControl.java:516) at org.apache.yoko.orb.OBCORBA.ORB_impl.resolve_initial_references(ORB_impl .java:1095) at org.apache.geronimo.corba.CORBABean.doStart(CORBABean.java:243) ... Caused by: org.apache.geronimo.management.geronimo.KeystoreException: Unable to create SSL Context at org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLConte xt(FileKeystoreManager.java:354) at org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServe rFactory(FileKeystoreManager.java:296) at org.apache.geronimo.security.keystore.FileKeystoreManager$$FastClassByCG LIB$$4d9d2a71.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInv oker.java:38) ... Caused by: org.apache.geronimo.management.geronimo.KeystoreException: Unable to open keystore with provided password at org.apache.geronimo.security.keystore.FileKeystoreInstance.loadKeystoreD ata(FileKeystoreInstance.java:606) at org.apache.geronimo.security.keystore.FileKeystoreInstance.ensureLoaded( FileKeystoreInstance.java:650) at org.apache.geronimo.security.keystore.FileKeystoreInstance.getKeyManager (FileKeystoreInstance.java:444) at org.apache.geronimo.security.keystore.FileKeystoreInstance$$FastClassByC GLIB$$7fc5d251.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) ... Caused by: java.security.KeyStoreException: KeyStore JKS implementation not found at java.security.KeyStore.getInstance(KeyStore.java:94) at org.apache.geronimo.security.keystore.FileKeystoreInstance.loadKeystoreD ata(FileKeystoreInstance.java:586) at org.apache.geronimo.security.keystore.FileKeystoreInstance.ensureLoaded( FileKeystoreInstance.java:650) ... 65 more Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
TSSConfigEditorTest requires SSL?
Hi, all, I wonder if org.apache.geronimo.yoko.TSSConfigEditorTest test is SSL dependent? I'm trying to run Geronimo Unit Tests on Apache Harmony, and this test fails (with the stack below) for the reason I couldn't find out. Could that be because Harmony has no SSL implementation? SEVERE: Failure accepting connection for host=ecwm0vmzakhar/172.28.118.8, port=8050 java.io.IOException: Connection was closed at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake(SSLSocke tImpl.java:760) at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake(SSLSo cketImpl.java:438) at org.apache.harmony.xnet.provider.jsse.SSLServerSocketImpl.accept(SSLServ erSocketImpl.java:256) at org.apache.yoko.orb.OCI.IIOP.Acceptor_impl.accept(Acceptor_impl.java:111 ) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded.starterRun(GIOPServerSt arterThreaded.java:195) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded$StarterThread.run(GIOPS erverStarterThreaded.java:34) Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
RE: TSSConfigEditorTest requires SSL?
David, Yes, Harmony supports TLS, but looking at the test code and configuration I couldn't guess a way how the test could be reconfigured for TLS. One of the reasons I'm asking is I now have greater than 99% pass rate for GUT v2.0.2 on Harmony, and this test is the last one about which I'm not sure if we have a bug in Harmony, or a bug in the test or it's just because Harmony doesn't have SSL and that's a known issue. Vasily -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Thursday, December 27, 2007 8:37 PM To: dev@geronimo.apache.org Subject: Re: TSSConfigEditorTest requires SSL? It has been a long time since I've worked with this test but I'm pretty sure that you are correct, the test sets up an SSL socket. I seem to recall that Harmony supports TLS?? From the stack trace I wonder if the problem is in Yoko. I'm definitely not a TLS expert, do you have any advice on how to fix this? thanks david jencks On Dec 27, 2007, at 10:33 AM, Zakharov, Vasily M wrote: Hi, all, I wonder if org.apache.geronimo.yoko.TSSConfigEditorTest test is SSL dependent? I'm trying to run Geronimo Unit Tests on Apache Harmony, and this test fails (with the stack below) for the reason I couldn't find out. Could that be because Harmony has no SSL implementation? SEVERE: Failure accepting connection for host=ecwm0vmzakhar/172.28.118.8, port=8050 java.io.IOException: Connection was closed at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake (SSLSocke tImpl.java:760) at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake (SSLSo cketImpl.java:438) at org.apache.harmony.xnet.provider.jsse.SSLServerSocketImpl.accept (SSLServ erSocketImpl.java:256) at org.apache.yoko.orb.OCI.IIOP.Acceptor_impl.accept (Acceptor_impl.java:111 ) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded.starterRun (GIOPServerSt arterThreaded.java:195) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded$StarterThread.run (GIOPS erverStarterThreaded.java:34) Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
XStream/Harmony problem
Hi, all, Geronimo v2.0.2 uses XStream 1.1.3, while the latest version is 1.2.2. I'd like to ask, are there any plans for moving to a newer version? I'm trying to run Geronimo Unit Test v2.0.2 on Apache Harmony, and encounter errors like these: http://jira.codehaus.org/browse/XSTR-189, http://jira.codehaus.org/browse/XSTR-379 Investigations show that the problems are caused by old XStream version - I've tried the latest XStream 1.2.2, and it seems both problems are resolved there. So moving to the latest XStream would ease making Geronimo run on Harmony. What do you think? Thanks! Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
RE: XStream/Harmony problem
Great, thanks! Vasily -Original Message- From: Joe Bohn [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 27, 2007 12:08 AM To: dev@geronimo.apache.org Subject: Re: XStream/Harmony problem Zakharov, Vasily M wrote: Hi, all, Geronimo v2.0.2 uses XStream 1.1.3, while the latest version is 1.2.2. I'd like to ask, are there any plans for moving to a newer version? Yes, Geronimo trunk (2.1-SNAPSHOT) is currently using XStream 1.2.2. Joe Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
RE: Moving to TranQL 1.4 ?
Whoa, that's great! If there's anything I could do to help - I'd gladly do. Thank you! Vasily -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 14, 2007 9:36 PM To: dev@geronimo.apache.org Subject: Re: Moving to TranQL 1.4 ? Hi Vasiliy, I put a draft out about two weeks ago and need to publish the final. I'd expect with Thanksgiving and some other stuff I'd be able to get going in early December. On Nov 13, 2007, at 10:40 PM, Zakharov, Vasily M wrote: Matt, Are there any news on that? :) Thanks! Vasily -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 8:48 AM To: dev@geronimo.apache.org Subject: Re: Moving to TranQL 1.4 ? Excellent ... I'm finishing some other performance work. When I get that completed I'd like to get this tested. It will be nice to finally run the monster ;-P On Oct 4, 2007, at 11:29 PM, Zakharov, Vasily M wrote: Hi, Matt, Great to hear from you, and great to hear the news! I've tried to update the deployment plans to G2.0.1 as best as I could, here's what I have now: http://cwiki.apache.org/confluence/download/attachments/64828/sjas- app.x ml http://cwiki.apache.org/confluence/download/attachments/64828/sjas- db.xm l http://cwiki.apache.org/confluence/download/attachments/64828/sjas- jms.x ml http://cwiki.apache.org/confluence/display/GMOxDOC20/ SPECjAppServer2004 It has issues working (e. g. for now I can't lookup the beans through JNDI externally), but at least it deploys with no errors. I assume some things there are anyway obsolete and have to be replaced. Please also note issues OPENEJB-700 and OPENEJB-701 filed while trying to make the things above work, adjustments were made to workaround OPENEJB-701. Thanks alot for your help! Vasily -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 6:56 AM To: dev@geronimo.apache.org Subject: Re: Moving to TranQL 1.4 ? Vasily, We've moved from TranQL for the support of CMP to OpenJPA. Dain provided a neat bridge so we can use the same technology for EJB 3 and EJB 2.x. At this point you can achieve the desired results using the orm.xml and OpenJPA configuration. I'd be interested in helping you out on this. Do you have a current set of DDs your working from or are these the same ones as we had back in http://svn.apache.org/ repos/asf/geronimo/sandbox/specjappserver2004/ On Oct 4, 2007, at 8:57 PM, Zakharov, Vasily M wrote: Hi, Are there any plans of moving to the next version of TranQL, 1.3.1 or maybe 1.4-SNAPSHOT? Both seem to be available at http://dist.codehaus.org/tranql/jars/ When I was working with G1.x last year, it was found that a critical flaw exists in TranQL 1.3, that prevents SPECjAppServer2004 from successfuly running on Geronimo - SjAS requires a support of READ_COMMITTED and REPEATABLE_READ transaction isolation levels in XA mode, and TranQL 1.3 only supports READ_UNCOMMITTED level. Issue GERONIMO-2128 http://issues.apache.org/jira/browse/ GERONIMO-2128 is related to this issue, and it's still open. At that time Matt Hostrom said he has plans to add the necessary support in TranQL 1.3.1 or 1.4, but as I can see, G2.0.1 still uses TranQL 1.3: http://article.gmane.org/gmane.comp.java.geronimo.user/3427 http://thread.gmane.org/gmane.comp.java.openejb.devel/3926 Matt, could you, or anyone else, please shed some light on the current situation with this issue? Thank you very much! Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact
RE: Moving to TranQL 1.4 ?
Matt, Are there any news on that? :) Thanks! Vasily -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 8:48 AM To: dev@geronimo.apache.org Subject: Re: Moving to TranQL 1.4 ? Excellent ... I'm finishing some other performance work. When I get that completed I'd like to get this tested. It will be nice to finally run the monster ;-P On Oct 4, 2007, at 11:29 PM, Zakharov, Vasily M wrote: Hi, Matt, Great to hear from you, and great to hear the news! I've tried to update the deployment plans to G2.0.1 as best as I could, here's what I have now: http://cwiki.apache.org/confluence/download/attachments/64828/sjas- app.x ml http://cwiki.apache.org/confluence/download/attachments/64828/sjas- db.xm l http://cwiki.apache.org/confluence/download/attachments/64828/sjas- jms.x ml http://cwiki.apache.org/confluence/display/GMOxDOC20/ SPECjAppServer2004 It has issues working (e. g. for now I can't lookup the beans through JNDI externally), but at least it deploys with no errors. I assume some things there are anyway obsolete and have to be replaced. Please also note issues OPENEJB-700 and OPENEJB-701 filed while trying to make the things above work, adjustments were made to workaround OPENEJB-701. Thanks alot for your help! Vasily -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 6:56 AM To: dev@geronimo.apache.org Subject: Re: Moving to TranQL 1.4 ? Vasily, We've moved from TranQL for the support of CMP to OpenJPA. Dain provided a neat bridge so we can use the same technology for EJB 3 and EJB 2.x. At this point you can achieve the desired results using the orm.xml and OpenJPA configuration. I'd be interested in helping you out on this. Do you have a current set of DDs your working from or are these the same ones as we had back in http://svn.apache.org/ repos/asf/geronimo/sandbox/specjappserver2004/ On Oct 4, 2007, at 8:57 PM, Zakharov, Vasily M wrote: Hi, Are there any plans of moving to the next version of TranQL, 1.3.1 or maybe 1.4-SNAPSHOT? Both seem to be available at http://dist.codehaus.org/tranql/jars/ When I was working with G1.x last year, it was found that a critical flaw exists in TranQL 1.3, that prevents SPECjAppServer2004 from successfuly running on Geronimo - SjAS requires a support of READ_COMMITTED and REPEATABLE_READ transaction isolation levels in XA mode, and TranQL 1.3 only supports READ_UNCOMMITTED level. Issue GERONIMO-2128 http://issues.apache.org/jira/browse/ GERONIMO-2128 is related to this issue, and it's still open. At that time Matt Hostrom said he has plans to add the necessary support in TranQL 1.3.1 or 1.4, but as I can see, G2.0.1 still uses TranQL 1.3: http://article.gmane.org/gmane.comp.java.geronimo.user/3427 http://thread.gmane.org/gmane.comp.java.openejb.devel/3926 Matt, could you, or anyone else, please shed some light on the current situation with this issue? Thank you very much! Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
RE: ClassCastException at Derby EmbeddedDataSource
Hi, Lin,
I don't see any org.apache.geronimo.* entries in Driver JAR selection.
May this be a problem?
And anyway, selecting non-Derby JAR for Derby access is
counterintuitive, isn't it?
Taking into account that I'm connecting not to the SystemDatabase, but
to another database I've created through Console DB Manager.
Is there a case when choosing an org.apache.derby/derby*/*/jar for
Embedded Derby connection would be a valid choice?
Maybe there's some sense in limiting the list of available JARs after
Database Type is selected?
As for now creating the operational connector to the embedded database
seems impossible without asking questions and editing deployment plans
manually.
Thank you!
Vasily
-Original Message-
From: Lin Sun [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 10:36 PM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi,
You should see org.apache.geronimo.configs/system-database/{version}/car
there on the list of driver Jar. (I think it was there when I used it
last time on 2.0.1.) You want to select it instead of
org.apache.derby/derby/10.2.2.0/jar to avoid your ClassCastException.
Lin
Zakharov, Vasily M wrote:
Hi David,
Yes, this actually helped, thank you very much!
However, the deployment plan I provided was generated by database pool
wizard in the console, as follows:
Console Navigation - Services - Database Pools
Create a new database pool: Using the Geronimo database pool wizard
Database Type: Derby embedded XA
Driver JAR: org.apache.derby/derby/10.2.2.0/jar
This seems to be a logical and trivial way.
And org.apache.geronimo.configs is absent in the Driver JAR list.
So, maybe there's a problem with database pool wizard that generates a
deployment plan that doesn't work as expected?
Vasily
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 4:16 AM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
when you use a derby datasource you have to make sure you get the
derby classes from the same classloader as the embedded derby
database. You normally do this by replacing the derby dependency in
your plan with something like
dep:dependency
dep:groupIdorg.apache.geronimo.configs/dep:groupId
dep:artifactIdsystem-database/dep:artifactId
dep:typecar/dep:type
/dep:dependency
Hope this helps
david jencks
On Oct 9, 2007, at 2:16 PM, Zakharov, Vasily M wrote:
Hi, all,
I've come into a strange situation, that looks like maybe a bug,
while
working on SPECjAppServer2004 deployment on G2.0.1.
When working with Embedded XA TranQL connector to internal Derby
database, class org.apache.geronimo.jdbc.DelegatingDriver (implements
java.sql.Driver) comes out in a place where either
org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver)
or
org.apache.derby.jdbc.InternalDriver (implements
org.apache.derby.iapi.services.monitor.ModuleControl) is expected,
and
this causes a ClassCastException on server side:
java.lang.ClassCastException:
org.apache.geronimo.jdbc.DelegatingDriver
at
org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter
(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown
Source)
at
org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnectio
n(
AbstractXADataSourceMCF.java:74)
at
org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection
(Embedde
dXAMCF.java:52)
at
org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCon
ne
ction(MCFConnectionInterceptor.java:48)
at
org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterce
pt
or.getConnection(LocalXAResourceInsertionInterceptor.java:41)
at
org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor
.i
nternalGetConnection(SinglePoolConnectionInterceptor.java:67)
at
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInt
er
ceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78)
at
org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor
.g
etConnection(TransactionEnlistingInterceptor.java:46)
at
org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.g
et
Connection(TransactionCachingInterceptor.java:88)
at
org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.get
Co
nnection(ConnectionHandleInterceptor.java:43
RE: ClassCastException at Derby EmbeddedDataSource
Ok, I see, thank you very much for the clarification.
Ok, let's wait for G2.0.2/2.1. :)
Vasily
-Original Message-
From: Lin Sun [mailto:[EMAIL PROTECTED]
Sent: Friday, October 12, 2007 1:00 AM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
I went back to the commit list... looks like the last min fix aren't
pulled into geronimo 2.0.1, but they should be avail in the upcoming
geronimo 2.0.2. Sorry about the confusion.
No, for derby, we recommend people to select systemdatabase instead, as
it already has org.apache.derby/derby*/*/jar as the dependency. This
was a change made since geronimo 1.1 and here is some doc about it
(http://cwiki.apache.org/GMOxDOC11/migrating-applications-from-geronimo-
v10.html,
check 2) Manually convert the derby jar dependencies to
system-datasource).
David Jencks has worked on limiting the list of available JARs on the
portlet, but I think his change is only in trunk (which will be geronimo
2.1).
HTH,
Lin
Zakharov, Vasily M wrote:
Hi, Lin,
I don't see any org.apache.geronimo.* entries in Driver JAR
selection.
May this be a problem?
And anyway, selecting non-Derby JAR for Derby access is
counterintuitive, isn't it?
Taking into account that I'm connecting not to the SystemDatabase, but
to another database I've created through Console DB Manager.
Is there a case when choosing an org.apache.derby/derby*/*/jar for
Embedded Derby connection would be a valid choice?
Maybe there's some sense in limiting the list of available JARs after
Database Type is selected?
As for now creating the operational connector to the embedded database
seems impossible without asking questions and editing deployment plans
manually.
Thank you!
Vasily
-Original Message-
From: Lin Sun [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 10:36 PM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi,
You should see
org.apache.geronimo.configs/system-database/{version}/car
there on the list of driver Jar. (I think it was there when I used it
last time on 2.0.1.) You want to select it instead of
org.apache.derby/derby/10.2.2.0/jar to avoid your ClassCastException.
Lin
Zakharov, Vasily M wrote:
Hi David,
Yes, this actually helped, thank you very much!
However, the deployment plan I provided was generated by database
pool
wizard in the console, as follows:
Console Navigation - Services - Database Pools
Create a new database pool: Using the Geronimo database pool wizard
Database Type: Derby embedded XA
Driver JAR: org.apache.derby/derby/10.2.2.0/jar
This seems to be a logical and trivial way.
And org.apache.geronimo.configs is absent in the Driver JAR list.
So, maybe there's a problem with database pool wizard that generates
a
deployment plan that doesn't work as expected?
Vasily
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 4:16 AM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
when you use a derby datasource you have to make sure you get the
derby classes from the same classloader as the embedded derby
database. You normally do this by replacing the derby dependency in
your plan with something like
dep:dependency
dep:groupIdorg.apache.geronimo.configs/dep:groupId
dep:artifactIdsystem-database/dep:artifactId
dep:typecar/dep:type
/dep:dependency
Hope this helps
david jencks
On Oct 9, 2007, at 2:16 PM, Zakharov, Vasily M wrote:
Hi, all,
I've come into a strange situation, that looks like maybe a bug,
while
working on SPECjAppServer2004 deployment on G2.0.1.
When working with Embedded XA TranQL connector to internal Derby
database, class org.apache.geronimo.jdbc.DelegatingDriver
(implements
java.sql.Driver) comes out in a place where either
org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver)
or
org.apache.derby.jdbc.InternalDriver (implements
org.apache.derby.iapi.services.monitor.ModuleControl) is expected,
and
this causes a ClassCastException on server side:
java.lang.ClassCastException:
org.apache.geronimo.jdbc.DelegatingDriver
at
org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter
(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown
Source)
at
org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnectio
n(
AbstractXADataSourceMCF.java:74)
at
org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection
(Embedde
RE: ClassCastException at Derby EmbeddedDataSource
Hi David, Yes, this actually helped, thank you very much! However, the deployment plan I provided was generated by database pool wizard in the console, as follows: Console Navigation - Services - Database Pools Create a new database pool: Using the Geronimo database pool wizard Database Type: Derby embedded XA Driver JAR: org.apache.derby/derby/10.2.2.0/jar This seems to be a logical and trivial way. And org.apache.geronimo.configs is absent in the Driver JAR list. So, maybe there's a problem with database pool wizard that generates a deployment plan that doesn't work as expected? Vasily -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 10, 2007 4:16 AM To: dev@geronimo.apache.org Subject: Re: ClassCastException at Derby EmbeddedDataSource Hi Vasily, when you use a derby datasource you have to make sure you get the derby classes from the same classloader as the embedded derby database. You normally do this by replacing the derby dependency in your plan with something like dep:dependency dep:groupIdorg.apache.geronimo.configs/dep:groupId dep:artifactIdsystem-database/dep:artifactId dep:typecar/dep:type /dep:dependency Hope this helps david jencks On Oct 9, 2007, at 2:16 PM, Zakharov, Vasily M wrote: Hi, all, I've come into a strange situation, that looks like maybe a bug, while working on SPECjAppServer2004 deployment on G2.0.1. When working with Embedded XA TranQL connector to internal Derby database, class org.apache.geronimo.jdbc.DelegatingDriver (implements java.sql.Driver) comes out in a place where either org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver) or org.apache.derby.jdbc.InternalDriver (implements org.apache.derby.iapi.services.monitor.ModuleControl) is expected, and this causes a ClassCastException on server side: java.lang.ClassCastException: org.apache.geronimo.jdbc.DelegatingDriver at org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter (Unknown Source) at org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown Source) at org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnectio n( AbstractXADataSourceMCF.java:74) at org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection (Embedde dXAMCF.java:52) at org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCon ne ction(MCFConnectionInterceptor.java:48) at org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterce pt or.getConnection(LocalXAResourceInsertionInterceptor.java:41) at org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor .i nternalGetConnection(SinglePoolConnectionInterceptor.java:67) at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInt er ceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78) at org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor .g etConnection(TransactionEnlistingInterceptor.java:46) at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.g et Connection(TransactionCachingInterceptor.java:88) at org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.get Co nnection(ConnectionHandleInterceptor.java:43) at org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection (TCC LInterceptor.java:39) at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.g et Connection(ConnectionTrackingInterceptor.java:66) at org.apache.geronimo.connector.outbound.AbstractConnectionManager.alloc at eConnection(AbstractConnectionManager.java:87) at org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56) ... The deployment plan for the connector can be found here: http://cwiki.apache.org/confluence/download/attachments/64828/sjas- db.xm l This plan is deployed with repository/org/tranql/tranql-connector-derby-embed-xa/1.3/tranql- connect or-derby-embed-xa-1.3.rar Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies
ClassCastException at Derby EmbeddedDataSource
Hi, all, I've come into a strange situation, that looks like maybe a bug, while working on SPECjAppServer2004 deployment on G2.0.1. When working with Embedded XA TranQL connector to internal Derby database, class org.apache.geronimo.jdbc.DelegatingDriver (implements java.sql.Driver) comes out in a place where either org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver) or org.apache.derby.jdbc.InternalDriver (implements org.apache.derby.iapi.services.monitor.ModuleControl) is expected, and this causes a ClassCastException on server side: java.lang.ClassCastException: org.apache.geronimo.jdbc.DelegatingDriver at org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter(Unknown Source) at org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown Source) at org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnection( AbstractXADataSourceMCF.java:74) at org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection(Embedde dXAMCF.java:52) at org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getConne ction(MCFConnectionInterceptor.java:48) at org.apache.geronimo.connector.outbound.LocalXAResourceInsertionIntercept or.getConnection(LocalXAResourceInsertionInterceptor.java:41) at org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor.i nternalGetConnection(SinglePoolConnectionInterceptor.java:67) at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInter ceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78) at org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.g etConnection(TransactionEnlistingInterceptor.java:46) at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.get Connection(TransactionCachingInterceptor.java:88) at org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.getCo nnection(ConnectionHandleInterceptor.java:43) at org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(TCC LInterceptor.java:39) at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.get Connection(ConnectionTrackingInterceptor.java:66) at org.apache.geronimo.connector.outbound.AbstractConnectionManager.allocat eConnection(AbstractConnectionManager.java:87) at org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56) ... The deployment plan for the connector can be found here: http://cwiki.apache.org/confluence/download/attachments/64828/sjas-db.xm l This plan is deployed with repository/org/tranql/tranql-connector-derby-embed-xa/1.3/tranql-connect or-derby-embed-xa-1.3.rar Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
RE: Moving to TranQL 1.4 ?
Yeah, indeed. :) Thank you! Vasily -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 8:48 AM To: dev@geronimo.apache.org Subject: Re: Moving to TranQL 1.4 ? Excellent ... I'm finishing some other performance work. When I get that completed I'd like to get this tested. It will be nice to finally run the monster ;-P On Oct 4, 2007, at 11:29 PM, Zakharov, Vasily M wrote: Hi, Matt, Great to hear from you, and great to hear the news! I've tried to update the deployment plans to G2.0.1 as best as I could, here's what I have now: http://cwiki.apache.org/confluence/download/attachments/64828/sjas- app.x ml http://cwiki.apache.org/confluence/download/attachments/64828/sjas- db.xm l http://cwiki.apache.org/confluence/download/attachments/64828/sjas- jms.x ml http://cwiki.apache.org/confluence/display/GMOxDOC20/ SPECjAppServer2004 It has issues working (e. g. for now I can't lookup the beans through JNDI externally), but at least it deploys with no errors. I assume some things there are anyway obsolete and have to be replaced. Please also note issues OPENEJB-700 and OPENEJB-701 filed while trying to make the things above work, adjustments were made to workaround OPENEJB-701. Thanks alot for your help! Vasily -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 6:56 AM To: dev@geronimo.apache.org Subject: Re: Moving to TranQL 1.4 ? Vasily, We've moved from TranQL for the support of CMP to OpenJPA. Dain provided a neat bridge so we can use the same technology for EJB 3 and EJB 2.x. At this point you can achieve the desired results using the orm.xml and OpenJPA configuration. I'd be interested in helping you out on this. Do you have a current set of DDs your working from or are these the same ones as we had back in http://svn.apache.org/ repos/asf/geronimo/sandbox/specjappserver2004/ On Oct 4, 2007, at 8:57 PM, Zakharov, Vasily M wrote: Hi, Are there any plans of moving to the next version of TranQL, 1.3.1 or maybe 1.4-SNAPSHOT? Both seem to be available at http://dist.codehaus.org/tranql/jars/ When I was working with G1.x last year, it was found that a critical flaw exists in TranQL 1.3, that prevents SPECjAppServer2004 from successfuly running on Geronimo - SjAS requires a support of READ_COMMITTED and REPEATABLE_READ transaction isolation levels in XA mode, and TranQL 1.3 only supports READ_UNCOMMITTED level. Issue GERONIMO-2128 http://issues.apache.org/jira/browse/ GERONIMO-2128 is related to this issue, and it's still open. At that time Matt Hostrom said he has plans to add the necessary support in TranQL 1.3.1 or 1.4, but as I can see, G2.0.1 still uses TranQL 1.3: http://article.gmane.org/gmane.comp.java.geronimo.user/3427 http://thread.gmane.org/gmane.comp.java.openejb.devel/3926 Matt, could you, or anyone else, please shed some light on the current situation with this issue? Thank you very much! Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Moving to TranQL 1.4 ?
Hi, Are there any plans of moving to the next version of TranQL, 1.3.1 or maybe 1.4-SNAPSHOT? Both seem to be available at http://dist.codehaus.org/tranql/jars/ When I was working with G1.x last year, it was found that a critical flaw exists in TranQL 1.3, that prevents SPECjAppServer2004 from successfuly running on Geronimo - SjAS requires a support of READ_COMMITTED and REPEATABLE_READ transaction isolation levels in XA mode, and TranQL 1.3 only supports READ_UNCOMMITTED level. Issue GERONIMO-2128 http://issues.apache.org/jira/browse/GERONIMO-2128 is related to this issue, and it's still open. At that time Matt Hostrom said he has plans to add the necessary support in TranQL 1.3.1 or 1.4, but as I can see, G2.0.1 still uses TranQL 1.3: http://article.gmane.org/gmane.comp.java.geronimo.user/3427 http://thread.gmane.org/gmane.comp.java.openejb.devel/3926 Matt, could you, or anyone else, please shed some light on the current situation with this issue? Thank you very much! Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
RE: Moving to TranQL 1.4 ?
Hi, Matt, Great to hear from you, and great to hear the news! I've tried to update the deployment plans to G2.0.1 as best as I could, here's what I have now: http://cwiki.apache.org/confluence/download/attachments/64828/sjas-app.x ml http://cwiki.apache.org/confluence/download/attachments/64828/sjas-db.xm l http://cwiki.apache.org/confluence/download/attachments/64828/sjas-jms.x ml http://cwiki.apache.org/confluence/display/GMOxDOC20/SPECjAppServer2004 It has issues working (e. g. for now I can't lookup the beans through JNDI externally), but at least it deploys with no errors. I assume some things there are anyway obsolete and have to be replaced. Please also note issues OPENEJB-700 and OPENEJB-701 filed while trying to make the things above work, adjustments were made to workaround OPENEJB-701. Thanks alot for your help! Vasily -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 6:56 AM To: dev@geronimo.apache.org Subject: Re: Moving to TranQL 1.4 ? Vasily, We've moved from TranQL for the support of CMP to OpenJPA. Dain provided a neat bridge so we can use the same technology for EJB 3 and EJB 2.x. At this point you can achieve the desired results using the orm.xml and OpenJPA configuration. I'd be interested in helping you out on this. Do you have a current set of DDs your working from or are these the same ones as we had back in http://svn.apache.org/ repos/asf/geronimo/sandbox/specjappserver2004/ On Oct 4, 2007, at 8:57 PM, Zakharov, Vasily M wrote: Hi, Are there any plans of moving to the next version of TranQL, 1.3.1 or maybe 1.4-SNAPSHOT? Both seem to be available at http://dist.codehaus.org/tranql/jars/ When I was working with G1.x last year, it was found that a critical flaw exists in TranQL 1.3, that prevents SPECjAppServer2004 from successfuly running on Geronimo - SjAS requires a support of READ_COMMITTED and REPEATABLE_READ transaction isolation levels in XA mode, and TranQL 1.3 only supports READ_UNCOMMITTED level. Issue GERONIMO-2128 http://issues.apache.org/jira/browse/GERONIMO-2128 is related to this issue, and it's still open. At that time Matt Hostrom said he has plans to add the necessary support in TranQL 1.3.1 or 1.4, but as I can see, G2.0.1 still uses TranQL 1.3: http://article.gmane.org/gmane.comp.java.geronimo.user/3427 http://thread.gmane.org/gmane.comp.java.openejb.devel/3926 Matt, could you, or anyone else, please shed some light on the current situation with this issue? Thank you very much! Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
SPECjAppServer2004 v1.08 with research mode is released!
Hi, all, I'm happy to announce that the new version of SPECjAppServer2004 (1.08) is released, and includes changes allowing publishing results in open source. SjAS2004 1.08 includes a special research mode workload called EAStress2004 that has a different metric but allows SjAS licensees to publish results for open source products having no J2EE certification and without the results being reviewed by SPEC. This allows for projects like Geronimo to effectively use that workload for testing and discovering performance issues. Here's the press-release: http://www.spec.org/jAppServer2004/jAppServer2004v108.html Vasily Zakharov Intel ESSD
RE: SPECjAppServer2004 v1.08 with research mode is released!
Well, I'm not a SPEC representative, but you could probably ask this question to SPEC itself. Also, existing SPEC licensees may run SjAS on Geronimo and publish results here. Vasily -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 07, 2007 3:56 AM To: dev@geronimo.apache.org Subject: Re: SPECjAppServer2004 v1.08 with research mode is released! Interesting news Vasiliy. According to the press release we need to still buy the benchmark for $250? Does this mean that a one time purchase for Geronimo is possible and that the benchmark would be useable by all Geronimo committers? Thanks for the heads up. On Mar 6, 2007, at 2:44 PM, Zakharov, Vasily M wrote: Hi, all, I'm happy to announce that the new version of SPECjAppServer2004 (1.08) is released, and includes changes allowing publishing results in open source. SjAS2004 1.08 includes a special research mode workload called EAStress2004 that has a different metric but allows SjAS licensees to publish results for open source products having no J2EE certification and without the results being reviewed by SPEC. This allows for projects like Geronimo to effectively use that workload for testing and discovering performance issues. Here's the press-release: http://www.spec.org/jAppServer2004/jAppServer2004v108.html Vasily Zakharov Intel ESSD
RE: Standard for serialVersionUID
Heinz, Adding serialVersionUIDs to Serializable classes is sure a great idea! It's strongly recommended by Sun, and all the way helps when dealing with serialization in large projects. It's not in fact important what particular value you specify for serialVersionUID field, the only thing important is you change the serialVersionUID for a class when its serialized form changes, and ONLY if its serialized form changes. From this perspective, using class version number is not a good idea, as a class may be modified (and thus version number changed), but a serialized form may stay the same, and changing serialVersionUID would introduce an unnecessary serialization incompatibility. The traditional way is to use 'serialver' program from Sun's JDK. If this way is for some reason uncomfortable for you, you may use some other way to calculate serialVersionUIDs, like Eclipse built-in feature or the like. The particular value is not important, only changes to it are. Note however, that small values like 1 or 2 are traditionally used as serialVersionUIDs for synthetic and other system classes, like Enums and RMI Stubs, that are serialized in a special way. So using such values in normal classes may confuse the future readers of the code and make them wonder if that particular class is serialized in a special way. So I'm suggesting using traditional (20-digit or so) values for serialVersionUIDs. Thank you! Vasily Zakharov Intel Middleware Products Division -Original Message- From: Heinz Drews [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 9:46 AM To: geronimo-dev Subject: Standard for serialVersionUID As I have mentioned in another message I have accidently used class files in modules created by Eclipse embeded compiler. This calculates serialVersionUID different way then javac. I think that adding serialVersionUID to all serializable class would address the situation best. There are quite a number of class without the uid. I would volunteer to add them but which standard should be used? Eclipse provides the option set it to 1 or to calculate the uid. But the calculation is different to the one doen by javac. In other projects I have found the convention to use version number to support detection of incompatible modifications. The version number a much nicer to read in the message reporting mismatches than the generated ones. Least impact would be to calculate the value with the serialver tool. This avoids the need for redeploying. Which standard should be chosen? --Heinz
Transaction isolation level in TranQL
Hi, Matt, What are the perspectives of having the capability to specify the transaction isolation level in TranQL? I'm awaiting this feature eagerly, as it looks like a key to a successful SPECjAppServer2004 run... Recently you said (http://www.mail-archive.com/user@geronimo.apache.org/msg03421.html) that this feature may be a part of TranQL 1.3.1, which is gonna be a part of Geronimo 1.1.1, as far as I understand. Am I right? Thank you! Vasily Zakharov Intel Middleware Products Division
RE: [jira] Commented: (GERONIMO-1046) ORA-00920 SQL Exception thrown when testing day trader with Oracle
Matt, What do you mean by plans you corrected? And by select for update we need to be able to specify? Vasily -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Saturday, June 17, 2006 5:48 AM To: dev@geronimo.apache.org Subject: Re: [jira] Commented: (GERONIMO-1046) ORA-00920 SQL Exception thrown when testing day trader with Oracle Thanks Vasily, I have corrected the plans. How are the plans going for Oracle? I think that we need to be able to specify select for update to achieve the right consistency level for SPECj2004. Curious what your feedback is. Vasily Zakharov (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1046?page=comments#action_ 12416551 ] Vasily Zakharov commented on GERONIMO-1046: --- There's a typo in this bug's resolution - the package name for ejb-ql-compiler-factory is org.tranql.ejbQLcompiler. So the right line would be: ejb-ql-compiler-factoryorg.tranql.ejbqlcompiler.OracleEJBQLCompilerFac tory/ejb-ql-compiler-factory ORA-00920 SQL Exception thrown when testing day trader with Oracle -- Key: GERONIMO-1046 URL: http://issues.apache.org/jira/browse/GERONIMO-1046 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.0 Environment: All Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.0 The following exception occurs when running day trader with Oracle: 15:54:36,575 WARN [/trade] /trade/app: java.rmi.RemoteException: Unable to commit container transaction; nested exception is: javax.transaction.SystemException: Unable to commit container transaction at org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.ja va(Compiled Code)) at org.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$c46b8cb8.login(gen erated) at org.apache.geronimo.samples.daytrader.TradeAction.login(TradeAction.java :421) at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doLogin(Tra deServletAction.java:341) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(Tr adeAppServlet.java:124) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doPost(TradeAp pServlet.java:86) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.j ava:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web ApplicationHandler.java:830) at org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(Ord ersAlertFilter.java:84) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web ApplicationHandler.java:821) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:5 68) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplication Context.java:635) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java: 244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: javax.transaction.SystemException: Unable to commit container transac tion at org.apache.geronimo.transaction.context.InheritableTransactionContext .rollbackAndThrow(InheritableTransactionContext.java:327) at org.apache.geronimo.transaction.context.InheritableTransactionContext .complete(InheritableTransactionContext.java(Compiled Code)) at org.apache.geronimo.transaction.context.InheritableTransactionContext .commit(InheritableTransactionContext.java(Compiled Code)) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPo licy.java(Compiled Code)) at org.openejb.transaction.TransactionContextInterceptor.invoke(Transact ionContextInterceptor.java(Compiled Code)) at
RE: cwiki.apache.org [longish]
Hernan, Thank you very much! Now it works fine for me too. Vasily -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 12:05 AM To: dev@geronimo.apache.org Subject: Re: cwiki.apache.org [longish] Hi Vasily, I just copied the page from Atlassian to cwiki and I was able to save it with no problems. It all seems to work just fine now, let me know if you find any issues. Cheers! Hernan Zakharov, Vasily M wrote: Hernan, Thank you very much! Vasily -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 7:56 PM To: dev@geronimo.apache.org Subject: Re: cwiki.apache.org [longish] Hi Vasily, I just reported this issue to Atlassian (https://support.atlassian.com/browse/CSP-4236). Not sure why confluence is complaining, that page is not that big and I was able to migrate it from the other installation. It actually is failing to save any changes, there might be some confluence code in the doc that this new version is not too happy with. I'll review the page markup as soon as I have a min, if I can't find anything suspicious I could re-import it from an XML (a new one from the Atlassian install) while we still look for the final solution. Cheers! Hernan Zakharov, Vasily M wrote: Hernan, Thank you alot for your great work on new G wiki! But oops, I was trying to copy my doc from the old location at: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/SPECjApp Server2004 to the new location at: http://cwiki.apache.org/confluence/display/GMOxDOC10/SPECjAppServer2004 I copied the wiki content and got a successful preview, but when I press Save, I get a System Error: java.lang.IllegalStateException: Form too large at org.mortbay.http.HttpRequest.extractParameters()V(Unknown Source) I see that my doc is rather big, but it worked fine on the old Confluence at opensource.atlassian.com. Is it some new feature of Confluence 2.1.5a? :) Vasily Zakharov Intel Middleware Products Division -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 5:30 PM To: dev@geronimo.apache.org Subject: Re: cwiki.apache.org [longish] All the groups have been updated, you all should have edit permissions. Cheers! Hernan John Sisson wrote: Who has access to fix this? John Jason Dillon wrote: It appears that the other spaces need their permissions updated. --jason On Jun 7, 2006, at 2:39 PM, Erin Mulder wrote: Hernan Cunico wrote: Hi All, I have enabled public signup so now you can register and contribute directly to the documentation. Thanks for setting this up! I just signed up, but once I was logged in, I could no longer see most of the Geronimo spaces. Is it possible that permissions have been set for Anonymous, but not for confluence-users (or whatever the equivalent role is in this installation)? When I'm logged out, I see: Apache Geronimo Documentation (geronimo)Apache Geronimo Project Management (GMOxPMGT)Apache Geronimo SandBox (GMOxSBOX) Apache Geronimo v1.0 (GMOxDOC10)Apache Geronimo v1.1 (GMOxDOC11) When I'm logged in, I see: Apache Geronimo v1.0 (GMOxDOC10)Cayenne Documentation (cayenne)Demonstration Space (ds)Test Space (test) Cheers, Erin
RE: cwiki.apache.org [longish]
Hernan, Thank you alot for your great work on new G wiki! But oops, I was trying to copy my doc from the old location at: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/SPECjApp Server2004 to the new location at: http://cwiki.apache.org/confluence/display/GMOxDOC10/SPECjAppServer2004 I copied the wiki content and got a successful preview, but when I press Save, I get a System Error: java.lang.IllegalStateException: Form too large at org.mortbay.http.HttpRequest.extractParameters()V(Unknown Source) I see that my doc is rather big, but it worked fine on the old Confluence at opensource.atlassian.com. Is it some new feature of Confluence 2.1.5a? :) Vasily Zakharov Intel Middleware Products Division -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 5:30 PM To: dev@geronimo.apache.org Subject: Re: cwiki.apache.org [longish] All the groups have been updated, you all should have edit permissions. Cheers! Hernan John Sisson wrote: Who has access to fix this? John Jason Dillon wrote: It appears that the other spaces need their permissions updated. --jason On Jun 7, 2006, at 2:39 PM, Erin Mulder wrote: Hernan Cunico wrote: Hi All, I have enabled public signup so now you can register and contribute directly to the documentation. Thanks for setting this up! I just signed up, but once I was logged in, I could no longer see most of the Geronimo spaces. Is it possible that permissions have been set for Anonymous, but not for confluence-users (or whatever the equivalent role is in this installation)? When I'm logged out, I see: Apache Geronimo Documentation (geronimo)Apache Geronimo Project Management (GMOxPMGT)Apache Geronimo SandBox (GMOxSBOX) Apache Geronimo v1.0 (GMOxDOC10)Apache Geronimo v1.1 (GMOxDOC11) When I'm logged in, I see: Apache Geronimo v1.0 (GMOxDOC10)Cayenne Documentation (cayenne)Demonstration Space (ds)Test Space (test) Cheers, Erin
RE: cwiki.apache.org [longish]
Hernan, Thank you very much! Vasily -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 7:56 PM To: dev@geronimo.apache.org Subject: Re: cwiki.apache.org [longish] Hi Vasily, I just reported this issue to Atlassian (https://support.atlassian.com/browse/CSP-4236). Not sure why confluence is complaining, that page is not that big and I was able to migrate it from the other installation. It actually is failing to save any changes, there might be some confluence code in the doc that this new version is not too happy with. I'll review the page markup as soon as I have a min, if I can't find anything suspicious I could re-import it from an XML (a new one from the Atlassian install) while we still look for the final solution. Cheers! Hernan Zakharov, Vasily M wrote: Hernan, Thank you alot for your great work on new G wiki! But oops, I was trying to copy my doc from the old location at: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/SPECjApp Server2004 to the new location at: http://cwiki.apache.org/confluence/display/GMOxDOC10/SPECjAppServer2004 I copied the wiki content and got a successful preview, but when I press Save, I get a System Error: java.lang.IllegalStateException: Form too large at org.mortbay.http.HttpRequest.extractParameters()V(Unknown Source) I see that my doc is rather big, but it worked fine on the old Confluence at opensource.atlassian.com. Is it some new feature of Confluence 2.1.5a? :) Vasily Zakharov Intel Middleware Products Division -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 5:30 PM To: dev@geronimo.apache.org Subject: Re: cwiki.apache.org [longish] All the groups have been updated, you all should have edit permissions. Cheers! Hernan John Sisson wrote: Who has access to fix this? John Jason Dillon wrote: It appears that the other spaces need their permissions updated. --jason On Jun 7, 2006, at 2:39 PM, Erin Mulder wrote: Hernan Cunico wrote: Hi All, I have enabled public signup so now you can register and contribute directly to the documentation. Thanks for setting this up! I just signed up, but once I was logged in, I could no longer see most of the Geronimo spaces. Is it possible that permissions have been set for Anonymous, but not for confluence-users (or whatever the equivalent role is in this installation)? When I'm logged out, I see: Apache Geronimo Documentation (geronimo)Apache Geronimo Project Management (GMOxPMGT)Apache Geronimo SandBox (GMOxSBOX) Apache Geronimo v1.0 (GMOxDOC10)Apache Geronimo v1.1 (GMOxDOC11) When I'm logged in, I see: Apache Geronimo v1.0 (GMOxDOC10)Cayenne Documentation (cayenne)Demonstration Space (ds)Test Space (test) Cheers, Erin
TranQL to Geronimo (was: RE: 1.1 Final Items)
Matt, By the way, are there any plans to make TranQL an Apache project, or even a Geronimo component? Vasily Zakharov Intel Middleware Products Division -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Thursday, June 01, 2006 6:54 AM To: dev@geronimo.apache.org Subject: Re: 1.1 Final Items TranQL has three components. The Connectors (1.2-SNAPSHOT), the persistence engine (1.3-SNAPSHOT) and the vendors rars (various versions depending on the rar in question). Does that answer your question ? Matt Jason Dillon wrote: Why 2 versions of TranQL? --jason On 5/31/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Here are the outstanding issues and my proposed plans to finish 1.1. Currently there are 124 JIRAs out there for 1.1. There are also 7 or 8 blockers. I have not seen any activity on these items in the last week so I'm assuming that there is no resource to fix them. I propose that tomorrow I'll move the JIRA's in 1.1 to 1.2 and for those items that are considered hot and people want to work on them they can move them to the 1.1.1 release. I'll do this through a bulk change. The remaining items are: Convert remaining SNAPSHOTs to releases. Here is the remaining list of items: activemq_version=3.2.4-SNAPSHOT geronimo_version=1.1-SNAPSHOT openejb_version=2.1-SNAPSHOT tranql_version=1.2-SNAPSHOT tranql_version=1.3-SNAPSHOT geronimo_spec_corba_version=1.0-SNAPSHOT geronimo_spec_j2ee_version=1.1-SNAPSHOT geronimo_spec_javamail_version=1.1-SNAPSHOT geronimo_spec_jcache_version=1.1-SNAPSHOT daytrader_version=1.1-SNAPSHOT I will convert DayTrader and TranQL after the final set of stress testing. Any volunteers to convert the specs? (Alan :) Kevan, we'll need you to sign off on the activemq versions. When the above is complete I suggest we get a final test from Kevan and cut a proposed 1.1 for Friday. If that's good (or if there are only minor fixes) we'll push 1.1 out next week and then move on to 1.2 and beyond. Thoughts? Matt
RE: cwiki.apache.org and Geronimo web site update
Hernan, Wow, that sounds great! But what, considering this, would happen to http://opensource.atlassian.com/confluence/oss/display/GERONIMO ? Should all the documents be migrated from there? I own a document there, should I move it to the new Confluence immediately? Vasily Zakharov Intel Middleware Products Division -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 8:18 PM To: dev Subject: cwiki.apache.org and Geronimo web site update Hi All, the new cofluence wiki cwiki.apache.org is ready to go live! I have reorganized the documentation, migrated it and updated the new confluence installation, the new structure looks like this: Apache Geronimo v1.0 Apache Geronimo v1.0 - User's Guide Apache Geronimo v1.0 - Developer's Guide Apache Geronimo v1.1 Apache Geronimo v1.1 - User's Guide Apache Geronimo Project Management Apache Geronimo Development Process Apache Geronimo Development Status Apache Geronimo SandBox You can see it LIVE accessing http://geronimo.apache.org/documentation The documents that are still up-to-date from wiki.apache.org/geronimo should be moved over the new confluence wiki, some of those docs should actually go directly into the web site itself. I will work on these changes unless somebody else volunteers :D Part of this update includes reorganizing the web site, the old Libray and Documentation thing. The Documentation link will contain the new structure just decribed (http://geronimo.apache.org/documentation) and the Library link will contain all the available printed and online books, cookbooks, articles, interviews, etc. So, whoever is working on a Geronimo book, articles, etc. and the info is not listed on the web site, pls send the details over so we can update the site. You will have to re-register in the new confluence in order to continue contributing with Geronimo's documentation. Enjoy! Cheers! Hernan
RE: cwiki.apache.org and Geronimo web site update
Haron, One more question, what is the difference between http://geronimo.apache.org/documentation and http://cwiki.apache.org/GERONIMO/home.html ? These locations have similar structure but are clearly different, and the latter has many documents from the old http://opensource.atlassian.com Wiki. Also, I wasn't able to find any way to register on the new site, is registration disabled for now? Thank you! Vasily -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 8:18 PM To: dev Subject: cwiki.apache.org and Geronimo web site update Hi All, the new cofluence wiki cwiki.apache.org is ready to go live! I have reorganized the documentation, migrated it and updated the new confluence installation, the new structure looks like this: Apache Geronimo v1.0 Apache Geronimo v1.0 - User's Guide Apache Geronimo v1.0 - Developer's Guide Apache Geronimo v1.1 Apache Geronimo v1.1 - User's Guide Apache Geronimo Project Management Apache Geronimo Development Process Apache Geronimo Development Status Apache Geronimo SandBox You can see it LIVE accessing http://geronimo.apache.org/documentation The documents that are still up-to-date from wiki.apache.org/geronimo should be moved over the new confluence wiki, some of those docs should actually go directly into the web site itself. I will work on these changes unless somebody else volunteers :D Part of this update includes reorganizing the web site, the old Libray and Documentation thing. The Documentation link will contain the new structure just decribed (http://geronimo.apache.org/documentation) and the Library link will contain all the available printed and online books, cookbooks, articles, interviews, etc. So, whoever is working on a Geronimo book, articles, etc. and the info is not listed on the web site, pls send the details over so we can update the site. You will have to re-register in the new confluence in order to continue contributing with Geronimo's documentation. Enjoy! Cheers! Hernan
RE: [jira] Closed: (GERONIMO-1800) SPECjAppServer2004 Deployment Descriptors
Jacek, I'm now writing the doc and I need to place the stacks somewhere to link to them. Looks like the Jira issue is a good place for that. :) Vasily -Original Message- From: Jacek Laskowski (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 12, 2006 6:31 PM To: dev@geronimo.apache.org Subject: [jira] Closed: (GERONIMO-1800) SPECjAppServer2004 Deployment Descriptors [ http://issues.apache.org/jira/browse/GERONIMO-1800?page=all ] Jacek Laskowski closed GERONIMO-1800: - No need to keep the issue open. Please use the user mailing list. Don't forget to help us with documenting it, Vasily ;) Thanks! SPECjAppServer2004 Deployment Descriptors - Key: GERONIMO-1800 URL: http://issues.apache.org/jira/browse/GERONIMO-1800 Project: Geronimo Type: Task Security: public(Regular issues) Reporter: Vasily Zakharov Fix For: 1.x Attachments: specdb.xml, specj2004-deployment-plan.xml, specjms.xml Here're the deployment descriptors I'm trying to use to deploy the SPECjAppServer2004 benchmark. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [jira] Closed: (GERONIMO-1800) SPECjAppServer2004 Deployment Descriptors
Jacek, Ok, I see. I'll put the links to the posts instead, thank you. Vasily -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski Sent: Wednesday, April 12, 2006 7:15 PM To: dev@geronimo.apache.org Subject: Re: [jira] Closed: (GERONIMO-1800) SPECjAppServer2004 Deployment Descriptors On 4/12/06, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Jacek, I'm now writing the doc and I need to place the stacks somewhere to link to them. Looks like the Jira issue is a good place for that. :) No, it's not. Use the user mailing list (and refer to the post in the archive) or Wiki. JIRA is much more official as their entries constitute a release notes and other things. What's wrong with the mailing lists? That's where people should ask their questions, isn't it? Vasily Jacek -- Jacek Laskowski http://www.laskowski.org.pl
RE: TranQL issue at SPECjAppServer2004 atomicity tests
)
at
org.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$52a1c83e.checkCusto
merCredit(generated)
at
org.spec.jappserver.servlet.helper.SpecAction.atomicityTestTwo(SpecActio
n.java:166)
at
org.spec.jappserver.servlet.helper.SpecServletAction.doAtomicityTests(Sp
ecServletAction.java:1304)
at
org.spec.jappserver.servlet.SpecAppServlet.performTask(SpecAppServlet.ja
va:166)
at
org.spec.jappserver.servlet.SpecAppServlet.doGet(SpecAppServlet.java:96)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.j
ava:99)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web
ApplicationHandler.java:830)
at
org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web
ApplicationHandler.java:821)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationH
andler.java:471)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationCon
text.java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at
org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244
)
at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Any idea what else could I be doing wrong to cause this?
Thank you very much!
Vasily Zakharov
Intel Middleware Product Division
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 09, 2006 9:38 PM
To: dev@geronimo.apache.org
Subject: Re: TranQL issue at SPECjAppServer2004 atomicity tests
On Apr 9, 2006, at 1:27 AM, Zakharov, Vasily M wrote:
David,
The deployment plan is
http://issues.apache.org/jira/secure/attachment/12324904/specdb.xml
and the deployment string is:
java -jar bin/deployer.jar --user system --password manager deploy
repository/tranql/rars/tranql-connector-derby-embed-local-1.1.rar
specdb.xml
(see http://issues.apache.org/jira/browse/GERONIMO-1800 for other
details).
I'm using Geronimo 1.0-Jetty release.
I really really hope this would help. :)
yup :-)
There's supposed to be some checking in there to complain if you try
to do this :-) You need to either change the plan by replacing the
xa-transaction element with local-transaction/ or use the tranql-
connector-derby-embed-xa-1.1.rar connector. I'd hope that this app
would have some 2-participant transactions in it so probably the xa
connector is the better choice.
I've opened GERONIMO-1822 to track this issue.
thanks
david jencks
Thank you very much!
Vasily
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 09, 2006 10:49 AM
To: dev@geronimo.apache.org
Subject: Re: TranQL issue at SPECjAppServer2004 atomicity tests
It looks to me as if a local-tx only connector is being used as if it
supports xa. It shouldn't be possible to deploy a connector with a
correct ra.xml in such a way as to create this problem. Can you
supply the geronimo plan for the connector, and indicate which
connector you deployed, and exactly how you deployed it? With this
information figuring out what is wrong and how to fix it should be
easy (famous last words :-)
Many thanks,
david jencks
On Apr 8, 2006, at 2:10 PM, Zakharov, Vasily M wrote:
Hi, all,
I've successfuly deployed SPECjAppServer2004 benchmark on Geronimo
1.0
(see http://issues.apache.org/jira/browse/GERONIMO-1800), but I have
trouble running the basic atomicity tests
(http://localhost:8080/SPECjAppServer/ page, link Atomicity Tests)
that check the correctness of the benchmark operation - all three
tests
are marked FAILED.
The investigation (see below) showed that the root cause for the
problem
is the following piece of code:
org.tranql.connector.jdbc.ManagedJDBCConnection:
123 public XAResource getXAResource() throws ResourceException {
124 throw new NotSupportedException(XAResource not available
from
a LocalTransaction connection);
125 }
The question is, how critical this situation is? Does it mean
SPECjAppServer2004 uses things it shouldn't use? Or the problem
lies in
TranQL implementation, or maybe Derby database or Derby JDBC
TranQL issue at SPECjAppServer2004 atomicity tests
Hi, all,
I've successfuly deployed SPECjAppServer2004 benchmark on Geronimo 1.0
(see http://issues.apache.org/jira/browse/GERONIMO-1800), but I have
trouble running the basic atomicity tests
(http://localhost:8080/SPECjAppServer/ page, link Atomicity Tests)
that check the correctness of the benchmark operation - all three tests
are marked FAILED.
The investigation (see below) showed that the root cause for the problem
is the following piece of code:
org.tranql.connector.jdbc.ManagedJDBCConnection:
123 public XAResource getXAResource() throws ResourceException {
124 throw new NotSupportedException(XAResource not available from
a LocalTransaction connection);
125 }
The question is, how critical this situation is? Does it mean
SPECjAppServer2004 uses things it shouldn't use? Or the problem lies in
TranQL implementation, or maybe Derby database or Derby JDBC driver? Or
does it mean SPECjAppServer2004 can't run on Geronimo at all?
Any ideas, suggestion and comments are highly welcome!
Thanks!
Here's the original stack displayed in Geronimo console window at each
atomicity tests' run:
javax.transaction.TransactionRolledbackException:
javax.ejb.FinderException: Error executing statement: SELECT C.C_ID FROM
C_CUSTOMER C WHERE C.C_ID = ?
at
org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolic
y.java:126)
at
org.openejb.transaction.TransactionContextInterceptor.invoke(Transaction
ContextInterceptor.java:80)
at
org.openejb.slsb.StatelessInstanceInterceptor.invoke(StatelessInstanceIn
terceptor.java:98)
at
org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolic
y.java:140)
at
org.openejb.transaction.TransactionContextInterceptor.invoke(Transaction
ContextInterceptor.java:80)
at
org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor
.java:82)
at
org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238)
at
org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.ja
va:129)
at
org.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$4084bef.checkCustom
erCredit(generated)
at
org.spec.jappserver.servlet.helper.SpecAction.atomicityTestTwo(SpecActio
n.java:166)
at
org.spec.jappserver.servlet.helper.SpecServletAction.doAtomicityTests(Sp
ecServletAction.java:1304)
at
org.spec.jappserver.servlet.SpecAppServlet.performTask(SpecAppServlet.ja
va:166)
at
org.spec.jappserver.servlet.SpecAppServlet.doGet(SpecAppServlet.java:96)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.j
ava:99)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web
ApplicationHandler.java:830)
at
org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web
ApplicationHandler.java:821)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationH
andler.java:471)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationCon
text.java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at
org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244
)
at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Note that the SQL prepared statement causing the error is correct and
references the table and fields that really exist in the database.
Executing this statement from a separate Java application using JDBC
causes no problem.
The code throwing this exception is:
org.openejb.transaction.ContainerPolicy$TxRequired.invoke():
117try {
118ejbInvocation.setTransactionContext(callerContext);
119return interceptor.invoke(ejbInvocation);
120} catch (Throwable t){
121callerContext.setRollbackOnly();
122if (ejbInvocation.getType().isLocal()) {
123 throw new
TransactionRolledbackLocalException().initCause(t);
124} else {
125// can't set an initCause on a
TransactionRolledbackException
126 - throw new TransactionRolledbackException(t.getMessage());
127}
128} finally {
129
Unintuitive error starting Geronimo with corrupt config.ser
Hello, all.
Recently, I accidentally corrupted the config.ser file in
bin/server.jar. It was my fault in this case, but this can also happen
in the presence of ill-formed scripts that manipulate files in
bin/server.jar or as a result of some bug in building procedures.
Geronimo error handling/diagnostics in that situation were not intuitive
to help me resolve the problem. I believe that an intuitive error
message is possible to help other users that might experience corrupted
config.ser files or other problem at the initial startup phase.
Here's how it looks:
C:\Geronimo java -jar bin\server.jar
Booting Geronimo Kernel (in Java 1.4.2_04)...
java.lang.NullPointerException
at
org.apache.geronimo.system.main.ProgressBarStartupMonitor.repaint()V(Pro
gressBarStartupMonitor.java:362)
at
org.apache.geronimo.system.main.ProgressBarStartupMonitor.serverStartFai
led(Ljava.lang.Exception;)V(ProgressBarStartupMonitor.java:344)
at
org.apache.geronimo.system.main.Daemon.doStartup()V(Daemon.java:277)
at
org.apache.geronimo.system.main.Daemon.init([Ljava.lang.String;)V(Daem
on.java:78)
at
org.apache.geronimo.system.main.Daemon.main([Ljava.lang.String;)V(Daemon
.java:316)
To reproduce it, you can just write some trash to
bin/server.jar/META-INF/config.ser and try to run Geronimo as shown
above.
Note that there's completely no information in the stack about why the
crash really occured. I investigated, and here's what I found.
Looks like the bug is in
org.apache.geronimo.system.main.Daemon.doStartup() method. I here
describe the bug basing on 1.0 M5 version (including source code) I've
downloaded, using the line numbers to reference the code parts.
The doStartup() method is a big try-catch block. The catch block looks
like this:
275} catch (Exception e) {
276if(monitor != null) {
277monitor.serverStartFailed(e);
278}
279e.printStackTrace();
280System.exit(3);
281throw new AssertionError();
282}
As you can see, monitor.serverStartFailed() method is called (277) if
monitor is not null. And monitor is always non-null as it is initialized
in initializeSystem() method (116, 118) that is called from constructor
(73) before doStartup() method is called (78). In other words,
monitor.serverStartFailed() method is always called.
monitor object is really an instance of
org.apache.geronimo.system.main.ProgressBarStartupMonitor class, and its
serverStartFailed() method looks like this:
343currentOperation = Startup failed;
344repaint();
345out.println();
346problem.printStackTrace(out);
It calls repaint() method, which uses the configStatus field (362, 363)
which is initialized by foundConfigurations() method (64).
Now, we get back to Daemon.doStartup() method and see where
monitor.foundConfigurations() method is called. It's line 219.
It means that, if some exception occurs in lines 124 to 219 (in my
example, it's line 149), the exception handler (277) would throw a
NullPointerException (because monitor.configStatus field is not
initialized) and woudn't have a chance to report the real problem (279).
If we, for example, comment out line 277:
275} catch (Exception e) {
276if(monitor != null) {
277//monitor.serverStartFailed(e);
278}
279e.printStackTrace();
280System.exit(3);
281throw new AssertionError();
282}
we immediately get the proper stack:
C:\Geronimo java -jar bin\server.jar
Booting Geronimo Kernel (in Java 1.4.2_04)...
java.io.StreamCorruptedException: invalid stream header
at java.io.ObjectInputStream.readStreamHeader()V(Unknown Source)
at
java.io.ObjectInputStream.init(Ljava.io.InputStream;)V(Unknown Source)
at
org.apache.geronimo.system.main.Daemon.doStartup()V(Daemon.java:147)
at
org.apache.geronimo.system.main.Daemon.init([Ljava.lang.String;)V(Daem
on.java:78)
at
org.apache.geronimo.system.main.Daemon.main([Ljava.lang.String;)V(Daemon
.java:316)
Of course, this situation doesn't normally occur, but in case of some
configuration error or file corruption finding out the problem becomes
impossible without the source code analysis.
I believe that this is a diagnostics bug in the current Geronimo stack.
Perhaps the line 279 should appear before line 276 so that the error
condition stack trace would be reported prior to the
NullPointerException from repaint(). Also the overall structure of error
handling in doStartup() method may be changed to avoid
NullPointerException at all.
Thanks.
Vasily Zakharov, Intel Managed Runtime Division
