[jira] [Commented] (GERONIMO-5521) NoClassDefFoundError when deploying a datasource with non-OSGi jdbc lib dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065733#comment-13065733 ] Rex Wang commented on GERONIMO-5521: modified the install-library cmd so that it can automatically convert the non-OSGi jars -Rex NoClassDefFoundError when deploying a datasource with non-OSGi jdbc lib dependencies Key: GERONIMO-5521 URL: https://issues.apache.org/jira/browse/GERONIMO-5521 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 3.0 Environment: ubuntu 8.04 x86-32 sun java 1.6.0_20 Reporter: Forrest Xia Assignee: Rex Wang Steps: 1. start geronimo tomcat we profile assembly 2. install jdbc library via deploy install-library command. The jdbc libraries are not bundlized yet 3. define a datasource deployment plan with dependencies on the jdbc libraries 4. deploy the datasource via proper tranql adapter An exception throws like this: 2010-08-11 09:02:59,585 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.samples.daytrader.plugins/daytrader-db2-datasource/3.0-M1/car?J2EEApplication=null,JCAConnectionFactory=jdbc/TradeDataSource,JCAResource=tranql-connector-db2-xa-1.5,ResourceAdapter=tranql-connector-db2-xa-1.5,ResourceAdapterModule=org.apache.geronimo.samples.daytrader.plugins/daytrader-db2-datasource/3.0-M1/car,j2eeType=JCAManagedConnectionFactory,name=jdbc/TradeDataSource java.lang.NoClassDefFoundError: com.ibm.db2.jcc.DB2XADataSource at org.tranql.connector.db2.XAMCF.init(XAMCF.java:51) at java.lang.J9VMInternals.newInstanceImpl(Native Method) at java.lang.Class.newInstance(Class.java:1325) at org.apache.geronimo.connector.wrapper.outbound.ManagedConnectionFactoryWrapper.init(ManagedConnectionFactoryWrapper.java:115) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:44) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39) at java.lang.reflect.Constructor.newInstance(Constructor.java:516) at org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952) at org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:460) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:224) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:698) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:677) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:344) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at
[jira] [Issue Comment Edited] (GERONIMO-5521) NoClassDefFoundError when deploying a datasource with non-OSGi jdbc lib dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065733#comment-13065733 ] Rex Wang edited comment on GERONIMO-5521 at 7/15/11 6:04 AM: - modified the install-library cmd so that it can automatically convert the non-OSGi jars in GERONIMO-5586. So closed this. -Rex was (Author: rwonly): modified the install-library cmd so that it can automatically convert the non-OSGi jars -Rex NoClassDefFoundError when deploying a datasource with non-OSGi jdbc lib dependencies Key: GERONIMO-5521 URL: https://issues.apache.org/jira/browse/GERONIMO-5521 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 3.0 Environment: ubuntu 8.04 x86-32 sun java 1.6.0_20 Reporter: Forrest Xia Assignee: Rex Wang Steps: 1. start geronimo tomcat we profile assembly 2. install jdbc library via deploy install-library command. The jdbc libraries are not bundlized yet 3. define a datasource deployment plan with dependencies on the jdbc libraries 4. deploy the datasource via proper tranql adapter An exception throws like this: 2010-08-11 09:02:59,585 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.samples.daytrader.plugins/daytrader-db2-datasource/3.0-M1/car?J2EEApplication=null,JCAConnectionFactory=jdbc/TradeDataSource,JCAResource=tranql-connector-db2-xa-1.5,ResourceAdapter=tranql-connector-db2-xa-1.5,ResourceAdapterModule=org.apache.geronimo.samples.daytrader.plugins/daytrader-db2-datasource/3.0-M1/car,j2eeType=JCAManagedConnectionFactory,name=jdbc/TradeDataSource java.lang.NoClassDefFoundError: com.ibm.db2.jcc.DB2XADataSource at org.tranql.connector.db2.XAMCF.init(XAMCF.java:51) at java.lang.J9VMInternals.newInstanceImpl(Native Method) at java.lang.Class.newInstance(Class.java:1325) at org.apache.geronimo.connector.wrapper.outbound.ManagedConnectionFactoryWrapper.init(ManagedConnectionFactoryWrapper.java:115) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:44) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39) at java.lang.reflect.Constructor.newInstance(Constructor.java:516) at org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952) at org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:460) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:224) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:698) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:677) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:344) at
[jira] [Assigned] (GERONIMO-5734) Enable sharelib in osgi based geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang reassigned GERONIMO-5734: -- Assignee: Rex Wang (was: Ashish Jain) Enable sharelib in osgi based geronimo --- Key: GERONIMO-5734 URL: https://issues.apache.org/jira/browse/GERONIMO-5734 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 3.0 Environment: geronimo 3.0 Reporter: Ashish Jain Assignee: Rex Wang -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-5521) NoClassDefFoundError when deploying a datasource with non-OSGi jdbc lib dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang resolved GERONIMO-5521. Resolution: Fixed Fix Version/s: 3.0 NoClassDefFoundError when deploying a datasource with non-OSGi jdbc lib dependencies Key: GERONIMO-5521 URL: https://issues.apache.org/jira/browse/GERONIMO-5521 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 3.0 Environment: ubuntu 8.04 x86-32 sun java 1.6.0_20 Reporter: Forrest Xia Assignee: Rex Wang Fix For: 3.0 Steps: 1. start geronimo tomcat we profile assembly 2. install jdbc library via deploy install-library command. The jdbc libraries are not bundlized yet 3. define a datasource deployment plan with dependencies on the jdbc libraries 4. deploy the datasource via proper tranql adapter An exception throws like this: 2010-08-11 09:02:59,585 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.samples.daytrader.plugins/daytrader-db2-datasource/3.0-M1/car?J2EEApplication=null,JCAConnectionFactory=jdbc/TradeDataSource,JCAResource=tranql-connector-db2-xa-1.5,ResourceAdapter=tranql-connector-db2-xa-1.5,ResourceAdapterModule=org.apache.geronimo.samples.daytrader.plugins/daytrader-db2-datasource/3.0-M1/car,j2eeType=JCAManagedConnectionFactory,name=jdbc/TradeDataSource java.lang.NoClassDefFoundError: com.ibm.db2.jcc.DB2XADataSource at org.tranql.connector.db2.XAMCF.init(XAMCF.java:51) at java.lang.J9VMInternals.newInstanceImpl(Native Method) at java.lang.Class.newInstance(Class.java:1325) at org.apache.geronimo.connector.wrapper.outbound.ManagedConnectionFactoryWrapper.init(ManagedConnectionFactoryWrapper.java:115) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:44) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39) at java.lang.reflect.Constructor.newInstance(Constructor.java:516) at org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952) at org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:460) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:224) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:698) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:677) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:344) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600)
[jira] [Resolved] (GERONIMO-5734) Enable sharelib in osgi based geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang resolved GERONIMO-5734. Resolution: Won't Fix Fix Version/s: 3.0 Enable sharelib in osgi based geronimo --- Key: GERONIMO-5734 URL: https://issues.apache.org/jira/browse/GERONIMO-5734 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 3.0 Environment: geronimo 3.0 Reporter: Ashish Jain Assignee: Rex Wang Fix For: 3.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5734) Enable sharelib in osgi based geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065735#comment-13065735 ] Rex Wang commented on GERONIMO-5734: We really should follow the OSGi way to do things, so we won't need this function. In GERONIMO-5586, we can automatically convert a non-OSGi jar. And user can write a plan to import packages required. Enable sharelib in osgi based geronimo --- Key: GERONIMO-5734 URL: https://issues.apache.org/jira/browse/GERONIMO-5734 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 3.0 Environment: geronimo 3.0 Reporter: Ashish Jain Assignee: Rex Wang Fix For: 3.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSSION]Some artifacts to release for geornimo 3.0.
Is the JIRA Release Date: 30/Nov/11 for geronimo 3.0.1 still valid? Thanks Frank -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/DISCUSSION-Some-artifacts-to-release-for-geornimo-3-0-tp3147174p3171248.html Sent from the Development mailing list archive at Nabble.com.
Re: Release Connector/Transaction components
On Tue, Jul 12, 2011 at 8:11 AM, Jean-Louis MONTEIRO jeano...@gmail.com wrote: any news on the availability? Expect the binaries later today. Jacek -- Jacek Laskowski Java EE, functional languages and IBM WebSphere - http://blog.japila.pl Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl
[jira] [Updated] (GERONIMODEVTOOLS-764) Control the OSGI bundle's start level in GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Xiao updated GERONIMODEVTOOLS-764: - Attachment: controlBundleStartLevel_764.patch Control the OSGI bundle's start level in GEP Key: GERONIMODEVTOOLS-764 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-764 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 3.0 Environment: WinXP sp3 32bit Win7 64bit, Oracle JDK 1.6, Eclipse3.6SR1SR2 Reporter: Yi Xiao Assignee: Yi Xiao Labels: OSGI, startLevel Fix For: 3.0 Attachments: controlBundleStartLevel_764.patch 1 Provide a UI interface to control all the bundles' start level 2 Control the specific bundle's start level easily -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMODEVTOOLS-764) Control the OSGI bundle's start level in GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065765#comment-13065765 ] Yi Xiao commented on GERONIMODEVTOOLS-764: -- The patch add a section named Default OSGI Bundle Start Level in server page to control all the user bundle's start level, and also, add a menu item when right click the module in servers view named Change Start Level to control a single bundle's start level. I will attach pics to show them. Control the OSGI bundle's start level in GEP Key: GERONIMODEVTOOLS-764 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-764 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 3.0 Environment: WinXP sp3 32bit Win7 64bit, Oracle JDK 1.6, Eclipse3.6SR1SR2 Reporter: Yi Xiao Assignee: Yi Xiao Labels: OSGI, startLevel Fix For: 3.0 Attachments: controlBundleStartLevel_764.patch 1 Provide a UI interface to control all the bundles' start level 2 Control the specific bundle's start level easily -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMODEVTOOLS-764) Control the OSGI bundle's start level in GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Xiao updated GERONIMODEVTOOLS-764: - Attachment: singleStartLevel.jpg defaultStartLevel.jpg Control the OSGI bundle's start level in GEP Key: GERONIMODEVTOOLS-764 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-764 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 3.0 Environment: WinXP sp3 32bit Win7 64bit, Oracle JDK 1.6, Eclipse3.6SR1SR2 Reporter: Yi Xiao Assignee: Yi Xiao Labels: OSGI, startLevel Fix For: 3.0 Attachments: controlBundleStartLevel_764.patch, defaultStartLevel.jpg, singleStartLevel.jpg 1 Provide a UI interface to control all the bundles' start level 2 Control the specific bundle's start level easily -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
NPE in MyFacesWebAppContext.doStart() if jsf web application is packaged into an EAR
Hi, Dev:
I packaged a web app with jsf features into an EAR, and deployed it, but
got an NPE when starting MyFacesWebAppContext gbean. This is related with
code line in MyFacesModuleBuilderExtension
*AbstractName myFacesWebAppContextName =
moduleContext.getNaming().createChildName(moduleName,
myFacesWebAppContext, MyFacesWebAppContext);*
*
*
In an EAR, ModuleContext abstract name is like:
org.apache.geronimo.daytrader/daytrader/
3.0.0.0/car?j2eeType=J2EEApplication,name=org.apache.geronimo.daytrader/daytrader/3.0.0.0/car
The result won't contain WebModule
But in an WAR is like
com.apache.geronimo.samples/jsf/3.0.0.0/car?J2EEApplication=null,*
WebModule=com.apache.geronimo.samples/jsf/3.0.0.0/car # **contaning
WebModule*
The result contains WebModule
After constructing MyFacesWebAppContext GBean, and start it as below,
*public String getWebModuleName(){*
*return abName.getNameProperty(NameFactory.WEB_MODULE); **#
**NameFactory.WEB_MODULE
value is WebModule*
*}*
*
*
*@Override*
*public void doStart() throws Exception {*
*MYFACES_WEBAPP_CONTEXTS.put(getWebModuleName(), this);*
*}*
trying to find a *WebModule* string in its abstract name, but if jsf web
app is in an ear, its abstractname doesn't contain *WebModule*, coz of its
parent is an EAR, whose abstract name doesn't include WebModule. This code
only work when jsf web app is standalone.
What i think is change MyFacesWebAppContext mapping way or change
myfaceswebappcontext abstractname generation way,not sure which is better.
Appreciate if somebody can shadow some lights on it.
--
viola
Apache Geronimo
[VOTE] release YOKO 1.2 - 2nd attempt.
[VOTE] release YOKO 1.2 - 2nd attempt. This is a bug fixes release for Java EE 6 compliance: The fixes in this release are: YOKO-431 Classloader issue when initializing a corba skeleton for EJB object YOKO-433 YOKO chunking logic does not set the the chunk flag to false when the valuetype tag is false on the chunking bit The artifacts up for vote are: 1. https://repository.apache.org/content/repositories/orgapachegeronimo-020/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz 2. https://repository.apache.org/content/repositories/orgapachegeronimo-020/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-016 https://repository.apache.org/content/repositories/orgapachegeronimo-020 The source tag is: https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Forrest
Re: [VOTE] release YOKO 1.2 - 2nd attempt.
Copyright info update, unit test and build is OK, so myself +1 Forrest On Fri, Jul 15, 2011 at 9:16 PM, Forrest Xia forres...@gmail.com wrote: [VOTE] release YOKO 1.2 - 2nd attempt. This is a bug fixes release for Java EE 6 compliance: The fixes in this release are: YOKO-431 Classloader issue when initializing a corba skeleton for EJB object YOKO-433 YOKO chunking logic does not set the the chunk flag to false when the valuetype tag is false on the chunking bit The artifacts up for vote are: 1. https://repository.apache.org/content/repositories/orgapachegeronimo-020/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz 2. https://repository.apache.org/content/repositories/orgapachegeronimo-020/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-016 https://repository.apache.org/content/repositories/orgapachegeronimo-020 The source tag is: https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Forrest
Re: [DISCUSSION]Some artifacts to release for geornimo 3.0.
+1 I'm doing YOKO release, pls vote. Forrest On Thu, Jul 7, 2011 at 12:53 PM, Shawn Jiang genspr...@gmail.com wrote: I think it's time to release some dependencies of geronimo 3.0. Following is the list I can think of for now. 1, Some updated geronimo bundles 2, Some updated geornimo specs 3, xbean 4, yoko 5, txmanager/connector We might also want to ask for other projects to consider to do releases for components that have stable geronimo tck results.Thoughts ? -- Shawn
Re: low entropy on linux systems
On 15.07.2011 04:19, Kevan Miller wrote: From time to time I encounter a problem starting a Geronimo server on a Linux system (I've always seen it on Ubuntu -- but the problem could exist on other distributions). The server start seems to hang. However, if you're patient, which I rarely am, the server will eventually start. If you're inquisitive, and dump the stack traces of the java process, you'll see something like: main prio=10 tid=0x40c0d800 nid=0xa79 runnable [0x7f57a04fb000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:220) at sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:185) at sun.security.provider.NativePRNG$RandomIO.implGenerateSeed(NativePRNG.java:202) - locked 0xdaad63e0 (a java.lang.Object) at sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:108) at sun.security.provider.NativePRNG.engineGenerateSeed(NativePRNG.java:102) at java.security.SecureRandom.generateSeed(SecureRandom.java:495) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.getSalt(PKCS12KeyStore.java:477) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.calculateMac(PKCS12KeyStore.java:834) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.engineStore(PKCS12KeyStore.java:788) - locked 0xd3b5a768 (a com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore) at java.security.KeyStore.store(KeyStore.java:1117) ... This problem isn't Geronimo specific. But since I see it from time to time, thought it would be worth passing along to the community... The Sun/Oracle-based JVM is attempting to generate a pseudo-random number to be used as a seed for an SSL server socket. To generate the pseudo-random number, the JVM is reading from the /dev/random device to obtain some random information for the seed. The problem is that reads from the /dev/random device will block if the system does not have a good source of random events. So, the Geronimo server startup is blocked waiting for enough random information to be returned from /dev/random. This article may be help understand the basic issue -- http://en.wikipedia.org/wiki//dev/random#Linux I'm no security expert. And I don't know the potential implications, but the simplest way that I've found to avoid the problem is to use the /dev/urandom device, instead of /dev/random. Do this by specifying the following java property '-Djava.security.egd=file:/dev/./urandom'. So, the following should work well: $ GERONIMO_OPTS=-Djava.security.egd=file:/dev/./urandom ./geronimo run --long Note to self -- would be nice to record this on our Wiki somewhere. Anyway, hope this is useful... And note that due to a bug in the JDK you really need to use /dev/./urandom or /dev//urandom and not /dev/urandom. Oracle themselves already internally use dev/urandom, but later they switch from /dev/urandom to /dev/random if the setting is trsingwise identical to /dev/random. That's why you need to use some different string that's equivalent to /dev/urandom after path normalization. We had the same problem for Tomcat, mostly when starting two instances in parallel. Regards, Rainer
[jira] [Updated] (GERONIMO-5729) Access the wrong web console page should get appropriate error message
[ https://issues.apache.org/jira/browse/GERONIMO-5729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-5729: --- Fix Version/s: (was: 3.0.1) 3.0 Access the wrong web console page should get appropriate error message -- Key: GERONIMO-5729 URL: https://issues.apache.org/jira/browse/GERONIMO-5729 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.2.2, 3.0-M2, 3.0 Reporter: Shawn Jiang Assignee: Shenghao Fang Priority: Minor Fix For: 3.0 Attachments: GERONIMO-5729-updated-1.patch, GERONIMO-5729-updated.patch, GERONIMO-5729.patch I have also found the reason why I sometimes did not see the menu at the left hand: When you log in to /console/portal/welcome (which was the default location in previeous versions) then you do _not_ see the menu. When you log in to /console/ the you'll be forwarded to /console/portal/0/Welcome, and you see everything correctly. It seems, that the content I've seen is the default page that will be displayed for users when they've called illegal page names. It also shows up for /console/portal/Testpage . Unfortunately the message displayed says Welcome to the Apache Geronimo™ Administration Console! etc. instead of a error message... As I think it's not critical enough to delay release, I gave +1. Thank you all for all the development works! Johannes -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5729) Access the wrong web console page should get appropriate error message
[ https://issues.apache.org/jira/browse/GERONIMO-5729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-5729: --- Fix Version/s: (was: 3.0) 3.0.1 Access the wrong web console page should get appropriate error message -- Key: GERONIMO-5729 URL: https://issues.apache.org/jira/browse/GERONIMO-5729 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.2.2, 3.0-M2, 3.0 Reporter: Shawn Jiang Assignee: Shenghao Fang Priority: Minor Fix For: 3.0.1 Attachments: GERONIMO-5729-updated-1.patch, GERONIMO-5729-updated.patch, GERONIMO-5729.patch I have also found the reason why I sometimes did not see the menu at the left hand: When you log in to /console/portal/welcome (which was the default location in previeous versions) then you do _not_ see the menu. When you log in to /console/ the you'll be forwarded to /console/portal/0/Welcome, and you see everything correctly. It seems, that the content I've seen is the default page that will be displayed for users when they've called illegal page names. It also shows up for /console/portal/Testpage . Unfortunately the message displayed says Welcome to the Apache Geronimo™ Administration Console! etc. instead of a error message... As I think it's not critical enough to delay release, I gave +1. Thank you all for all the development works! Johannes -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: low entropy on linux systems
On 15.07.2011 15:56, Rainer Jung wrote: On 15.07.2011 04:19, Kevan Miller wrote: From time to time I encounter a problem starting a Geronimo server on a Linux system (I've always seen it on Ubuntu -- but the problem could exist on other distributions). The server start seems to hang. However, if you're patient, which I rarely am, the server will eventually start. If you're inquisitive, and dump the stack traces of the java process, you'll see something like: main prio=10 tid=0x40c0d800 nid=0xa79 runnable [0x7f57a04fb000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:220) at sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:185) at sun.security.provider.NativePRNG$RandomIO.implGenerateSeed(NativePRNG.java:202) - locked 0xdaad63e0 (a java.lang.Object) at sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:108) at sun.security.provider.NativePRNG.engineGenerateSeed(NativePRNG.java:102) at java.security.SecureRandom.generateSeed(SecureRandom.java:495) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.getSalt(PKCS12KeyStore.java:477) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.calculateMac(PKCS12KeyStore.java:834) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.engineStore(PKCS12KeyStore.java:788) - locked 0xd3b5a768 (a com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore) at java.security.KeyStore.store(KeyStore.java:1117) ... This problem isn't Geronimo specific. But since I see it from time to time, thought it would be worth passing along to the community... The Sun/Oracle-based JVM is attempting to generate a pseudo-random number to be used as a seed for an SSL server socket. To generate the pseudo-random number, the JVM is reading from the /dev/random device to obtain some random information for the seed. The problem is that reads from the /dev/random device will block if the system does not have a good source of random events. So, the Geronimo server startup is blocked waiting for enough random information to be returned from /dev/random. This article may be help understand the basic issue -- http://en.wikipedia.org/wiki//dev/random#Linux I'm no security expert. And I don't know the potential implications, but the simplest way that I've found to avoid the problem is to use the /dev/urandom device, instead of /dev/random. Do this by specifying the following java property '-Djava.security.egd=file:/dev/./urandom'. So, the following should work well: $ GERONIMO_OPTS=-Djava.security.egd=file:/dev/./urandom ./geronimo run --long Note to self -- would be nice to record this on our Wiki somewhere. Anyway, hope this is useful... And note that due to a bug in the JDK you really need to use /dev/./urandom or /dev//urandom and not /dev/urandom. Oracle themselves already internally use dev/urandom, but later they switch from /dev/urandom to /dev/random if the setting is trsingwise identical to /dev/random. That's why you need to use some different string that's equivalent to /dev/urandom after path normalization. We had the same problem for Tomcat, mostly when starting two instances in parallel. ... and a bit more detail available at: http://marc.info/?l=tomcat-devm=130182757504685w=2 Regards, Rainer
Re: [DISCUSSION]Some artifacts to release for geornimo 3.0.
On Jul 15, 2011, at 2:48 AM, pif wrote: Is the JIRA Release Date: 30/Nov/11 for geronimo 3.0.1 still valid? Hi Frank, I'm not sure where that date came from/who set it. We traditionally don't target dates for a release. We're still finalizing a 3.0 release... So, that may be a reasonable date for a 3.0.1, but don't hold us to it... --kevan
Re: low entropy on linux systems
On Jul 15, 2011, at 10:03 AM, Rainer Jung wrote: snip And note that due to a bug in the JDK you really need to use /dev/./urandom or /dev//urandom and not /dev/urandom. Oracle themselves already internally use dev/urandom, but later they switch from /dev/urandom to /dev/random if the setting is trsingwise identical to /dev/random. That's why you need to use some different string that's equivalent to /dev/urandom after path normalization. We had the same problem for Tomcat, mostly when starting two instances in parallel. ... and a bit more detail available at: http://marc.info/?l=tomcat-devm=130182757504685w=2 Cool. Thanks for the additional information, Rainer. --kevan
board report
Our board report is due next week. I've added a template to our Wiki -- https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2011-07+-+July Will plan on updating during the next few days. Contributions welcome! --kevan
Re: board report
If we value documentation as much as we value code, then how about this modification? -RG - current - Community There are x subscribers to the user@ mailing list and y subscribers to the dev@ mailing list. Although the makeup of the project is diverse, most of the current development activities are coming from IBM employees. - - change - Community There are x subscribers to the user@ mailing list and y subscribers to the dev@ mailing list. Although the makeup of the project is diverse, most of the current development activities are coming from IBM employees. Yet, during this past period, there have been several non-IBM employees working as contributors to provide documentation through the project's Wiki. - On 07/15/2011 10:11 AM, Kevan Miller wrote: Our board report is due next week. I've added a template to our Wiki -- https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2011-07+-+July Will plan on updating during the next few days. Contributions welcome! --kevan
[jira] [Commented] (GERONIMODEVTOOLS-764) Control the OSGI bundle's start level in GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13066029#comment-13066029 ] Jarek Gawor commented on GERONIMODEVTOOLS-764: -- A few comments: 1) Make sure you configure your editor to use spaces instead of tabs (per our coding standards). 2) I'm confused about setting the default start level. It looks like the user can set the default start level in the server configuration in Eclipse but the code also looks up the default start level from the server. And changing the level in Eclipse won't be saved in the server configuration. So I think we have a few options: 1) Eclipse shouldn't be allowed the change the default start level at all or 2) If the default start level is changed in Eclipse it should save the server configuration as well, or 3) make the default start level in Eclipse completely separate from the server's (and be persistent between Eclipse restarts). Right now I think my preference would be for option #3. 3) Don't modify the AriesHelper.BundleInfo. BundleInfo was supposed to be somewhat private to AriesHelper class. Instead maybe rename AriesHelper.BundleInfo to AriesHelper.ProjectInfo (or something like that) and create your own BundleInfo for the OSGiModuleHadler purposes. 4) Don't forget about the Apache headers for the new files. Control the OSGI bundle's start level in GEP Key: GERONIMODEVTOOLS-764 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-764 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 3.0 Environment: WinXP sp3 32bit Win7 64bit, Oracle JDK 1.6, Eclipse3.6SR1SR2 Reporter: Yi Xiao Assignee: Yi Xiao Labels: OSGI, startLevel Fix For: 3.0 Attachments: controlBundleStartLevel_764.patch, defaultStartLevel.jpg, singleStartLevel.jpg 1 Provide a UI interface to control all the bundles' start level 2 Control the specific bundle's start level easily -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: board report
Background information on our branding requirements: http://www.apache.org/foundation/marks/responsibility.html --kevan
Re: board report
On Jul 15, 2011, at 11:45 AM, Russell E Glaue wrote: If we value documentation as much as we value code, then how about this modification? Great. Thanks! It wasn't actually my intent to include that diversity statement. That was a one time statement from a past report, motivated by external events. Inclusion in the draft was a copy-paste carryover and poor editing on my part. The documentation contributions are definitely worth noting (and well desired, too!) I've updated the wiki. I've also added the project branding checklist that is required for our board report. --kevan
Re: board report
And probably most relevant to the task at hand: http://www.apache.org/foundation/marks/pmcs --kevan
Re: board report
On Jul 15, 2011, at 12:25 PM, Kevan Miller wrote: And probably most relevant to the task at hand: http://www.apache.org/foundation/marks/pmcs We have some low-hanging fruit, here. Can definitely have some of these requirements resolved for our report. It's ok to have some items pending. However, we need to be making forward progress. As always, help welcome... --kevan
Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
On Jul 13, 2011, at 12:29 AM, Shawn Jiang wrote: On Wed, Jul 13, 2011 at 12:01 PM, Kevan Miller kevan.mil...@gmail.com wrote: Looks good with one exception. geronimo-stax-api_1.2_spec-1.1/NOTICE.txt contains: Copyright 2003-2006 The Apache Software Foundation Not a hard requirement, but by our convention the latter date should be 2011. Just updated latter date to 2011 for all notice files in geronimo bundles. Also, most of our LICENSE/NOTICE files no longer have the .txt suffix. Do you mean we need to rename LICENSE/NOTICE to LICENSE.txt/NOTICE.txt ? Oops. So, I misread your question and now I've messed this all up. Let me try again. Most of our LICENSE/NOTICE files no longer have a .txt suffix. LICENSE/NOTICE should be our desired names for license/notice files. LICENSE.txt/NOTICE.txt files are acceptable, but LICENSE/NOTICE are the preferred names for the ASF. Where possible we should use the file names without a .txt suffix. No nead to -1 or cancel any votes, just for this. So, current votes are fine, IMO. --kevan
Re: [VOTE] release YOKO 1.2 - 2nd attempt.
Here's my +1. Thanks Forrest! Signature/checksums looked good. Source, license/notice, and build all looked good. --kevan On Jul 15, 2011, at 9:16 AM, Forrest Xia wrote: [VOTE] release YOKO 1.2 - 2nd attempt. This is a bug fixes release for Java EE 6 compliance: The fixes in this release are: YOKO-431 Classloader issue when initializing a corba skeleton for EJB object YOKO-433 YOKO chunking logic does not set the the chunk flag to false when the valuetype tag is false on the chunking bit The artifacts up for vote are: 1. https://repository.apache.org/content/repositories/orgapachegeronimo-020/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz 2. https://repository.apache.org/content/repositories/orgapachegeronimo-020/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-020 The source tag is: https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Forrest
Re: less-osgi-friendly code drop
On Jul 13, 2011, at 10:10 PM, David Jencks wrote: On Jul 13, 2011, at 9:46 PM, David Blevins wrote: On Jul 11, 2011, at 12:54 AM, David Jencks wrote: testSpecializedBeanNotInstantiated(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationIntegrationTest) testSpecializingBeanHasBindingsOfSpecializedAndSpecializingBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationTest) testSpecializingBeanHasNameOfSpecializedBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationTest) testSpecializingClassDirectlyExtendsNothing(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsNothing.DirectlyExtendsNothingTest) testSpecializingClassDirectlyExtendsSimpleBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsSimpleBean.DirectlyExtendsSimpleBeanTest) testSpecializingClassImplementsInterfaceAndExtendsNothing(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.implementInterfaceAndExtendsNothing.ImplementsInterfaceAndExtendsNothingTest) testSpecializingAndSpecializedBeanHasName(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.sameName.SameNameTest) Have all but 3 of these passing in the embedded container in my local copy. The 3 that fail are broken ones. Simply need to add validation for those. My impl code is a bit hacked -- currently only works for @Stateful and not exactly implemented in the right spot -- but otherwise looks like a good approach. Will clean it up and check it in tomorrow. Excellent! On the geronimo side I've changed things around so that we have one openejb appInfo tree for the entire application and use it to set up the owb context. This _ought_ to fix the problem in g. that I was seeing that the owb context didn't include any of the specialized classes (since it was looking at only one of the modules in the ear). However I'm still cleaning up loose ends so apps will deploy ok :-) Checked in my specialization code to OWB and OpenEJB. It fixes things in the embedded container (sans the three 'broken' tests). Still seeing them fail in G though. Hacking up the validation logic for the 'broken' tests now. -David
Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
, OK, then I'll rename all LICENSE.txt, NOTICE.txt back for all remaining specs/bundles. On Sat, Jul 16, 2011 at 1:56 AM, Kevan Miller kevan.mil...@gmail.comwrote: On Jul 13, 2011, at 12:29 AM, Shawn Jiang wrote: On Wed, Jul 13, 2011 at 12:01 PM, Kevan Miller kevan.mil...@gmail.com wrote: Looks good with one exception. geronimo-stax-api_1.2_spec-1.1/NOTICE.txt contains: Copyright 2003-2006 The Apache Software Foundation Not a hard requirement, but by our convention the latter date should be 2011. Just updated latter date to 2011 for all notice files in geronimo bundles. Also, most of our LICENSE/NOTICE files no longer have the .txt suffix. Do you mean we need to rename LICENSE/NOTICE to LICENSE.txt/NOTICE.txt ? Oops. So, I misread your question and now I've messed this all up. Let me try again. Most of our LICENSE/NOTICE files no longer have a .txt suffix. LICENSE/NOTICE should be our desired names for license/notice files. LICENSE.txt/NOTICE.txt files are acceptable, but LICENSE/NOTICE are the preferred names for the ASF. Where possible we should use the file names without a .txt suffix. No nead to -1 or cancel any votes, just for this. So, current votes are fine, IMO. --kevan -- Shawn
Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
On Jul 15, 2011, at 9:15 PM, Shawn Jiang wrote: , OK, then I'll rename all LICENSE.txt, NOTICE.txt back for all remaining specs/bundles. I think I got them all... --kevan
Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
Just saw the commit history, thanks ! : ) Will close this vote soon. On Sat, Jul 16, 2011 at 9:29 AM, Kevan Miller kevan.mil...@gmail.comwrote: On Jul 15, 2011, at 9:15 PM, Shawn Jiang wrote: , OK, then I'll rename all LICENSE.txt, NOTICE.txt back for all remaining specs/bundles. I think I got them all... --kevan -- Shawn
