[jira] [Closed] (GERONIMO-5472) Java EE 6 sample: fileupload run incorrectly on tomcat-assembly.
[ https://issues.apache.org/jira/browse/GERONIMO-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia closed GERONIMO-5472. - Resolution: Fixed Verified the latest sample with the latest build, this sample is OK now, so close this jira. Java EE 6 sample: fileupload run incorrectly on tomcat-assembly. Key: GERONIMO-5472 URL: https://issues.apache.org/jira/browse/GERONIMO-5472 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 3.0 Reporter: Wang Guang Zhe Assignee: Ivan Fix For: 3.0 1. The fileupload sample is under samples/javaee6, first checkout it from samples trunk and build it. 2. Deploy the war package on tomcat-assembly server after it is started. 3. After the sample is deployed and started successfully, visit http://localhost:8080/fileupload-javaee6/, you will be asked to select file to upload. Select a text file which is not larger than 10kb, and click submit. 4. The right response page will show the content of the file you submitted. But on tomcat-assembly,it responses with HttpServletRequest.getParts() returns an empty collection! HttpServletRequest.getPart(String name) returns null! The error stack is: java.lang.NullPointerException at org.apache.geronimo.samples.javaee6.fileupload.MessageFilter.doFilter (MessageFilter.java:48) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:242) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:243) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:201) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve. invoke(GeronimoStandardContext.java:675) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero nimoBeforeAfterValve.java:47) at org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(Protecte dTargetValve.java:53) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:146) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:108) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:402) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :254) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce ss(Http11Protocol.java:267) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce ss(Http11Protocol.java:245) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoin t.java:260) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(Th readPool.java:344) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source ) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (GERONIMO-5302) A successfully deployed war package(contained in a ear package) is not listed on admin console.
[ https://issues.apache.org/jira/browse/GERONIMO-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia closed GERONIMO-5302. - Verified with daytrader sample of 20110714, the web context root appears in the EAR list page, so close this jira. A successfully deployed war package(contained in a ear package) is not listed on admin console. --- Key: GERONIMO-5302 URL: https://issues.apache.org/jira/browse/GERONIMO-5302 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 3.0 Environment: OS:WIN XP GERONIMO Build:3.0 SNAPSHOT 2010.5.6 build JDK:1.6 Reporter: Lu Jiang Assignee: Ivan Fix For: 3.0 Attachments: sendmail-ear-2.1.1.4.ear Sendmail-ear.ear can be successfully deployed on geronimo 3.0 snapshot. Open http://localhost:8080/sendmail/ in a web browser ,this application works fine. But As far as I can remember if the ear contains a war package and this war package is specifiled in application .xml like: module web web-urisendmail-war-2.1.1.4.war/web-uri context-root/sendmail/context-root /web /module Then on admin console,under Console Navigation/Applicatios,click web App Wars,it/s expected to see an item like this: org.apache.geronimo.samples/sendmail-ear_sendmail-war-2.1.1.4.war/2.1.1/car /sendmail running StopRestart Uninstall then we can get access to the application via the link /sendmail. But currently on 3.0 snapshot console,the deployed war will not be listed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[BUILD] branches/2.2: Failed for Revision: 1146510
Geronimo Revision: 1146510 built with tests included See the full build-2000.log file at http://people.apache.org/builds/geronimo/server/binaries/2.2/20110714/build-2000.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.2/20110714 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 430 minutes 7 seconds [INFO] Finished at: Thu Jul 14 03:13:57 EDT 2011 [INFO] Final Memory: 315M/770M [INFO] TESTSUITE RESULTS (Failures only) = Assembly: tomcat = See full test results and logs at http://people.apache.org/builds/geronimo/server/binaries/2.2/20110714/logs-2000-tomcat/ Booting Geronimo Kernel (in Java 1.5.0_22)... Module 1/75 org.apache.geronimo.framework/j2ee-system/2.2.2-SNAPSHOT/car started in .001s Module 2/75 org.apache.geronimo.framework/jee-specs/2.2.2-SNAPSHOT/car started in .000s Module 3/75 org.apache.geronimo.plugins.classloaders/xbean-finder/2.2.2-SNAPSHOT/car started in .000s Module 4/75 org.apache.geronimo.framework/xmlbeans/2.2.2-SNAPSHOT/car started in .000s Module 5/75 org.apache.geronimo.framework/rmi-naming/2.2.2-SNAPSHOT/car 2011-07-14 03:18:53,417 WARN [RMIRegistryService] RMI Registry failed 2011-07-14 03:18:53,418 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.framework/rmi-naming/2.2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/rmi-naming/2.2.2-SNAPSHOT/car,j2eeType=GBean,name=RMIRegistry java.rmi.server.ExportException: Port already in use: 1099; nested exception is: java.net.BindException: Address already in use at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:249) at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:184) at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:382) at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:116) at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:180) at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92) at sun.rmi.registry.RegistryImpl.init(RegistryImpl.java:68) at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222) at org.apache.geronimo.kernel.rmi.RMIRegistryService.doStart(RMIRegistryService.java:72) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:953) 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:539) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:377) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:465) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:190) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:546) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$bf303f44.startConfiguration(generated) at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:204) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:87
Re: less-osgi-friendly code drop
Hi David Jencks,
Many cases in interop and webservices failed with following similar
exception at deployment phase after your owb/openejb refactor. Seems
deploymentinfo does not get initialized correclty in
org.apache.geronimo.openejb.EjbDeployment.initialize(BeanContext) {
...
}
at all.could you please take a look ?
Caused by: org.apache.geronimo.gbean.InvalidConfigurationException:
Configuration xxx failed to start due
following reasons:
The service
EJBModule=.jar,J2EEApplication=default//1-default/car,SingletonBean=,j
WSLink,name= did not start because null
java.lang.NullPointerException
at
org.apache.geronimo.openejb.EjbDeployment.getBeanClass(EjbDeployment.java:239)
at
org.apache.geronimo.axis2.ejb.EJBWebServiceGBean.init(EJBWebServiceGBean.java:76)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:958)
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:940)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:567)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:462)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:226)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:702)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:681)
at
org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:67)
at java.lang.Thread.run(Thread.java:619)
On Thu, Jul 14, 2011 at 1:10 PM, David Jencks david_jen...@yahoo.comwrote:
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 :-)
thanks
david jencks
-David
--
Shawn
[jira] [Updated] (GERONIMO-5981) Some objects to be injected were not found in jndi: could not look up something
[ https://issues.apache.org/jira/browse/GERONIMO-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shenghao Fang updated GERONIMO-5981: Attachment: GERONIMO-5981.patch OpenEJB requires the type (.jar or .war) for jndi binding. Add a hard coded '.jar' to artifactId for temporary fixing. A more robust solution is needed. Some objects to be injected were not found in jndi: could not look up something --- Key: GERONIMO-5981 URL: https://issues.apache.org/jira/browse/GERONIMO-5981 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: PlanCreator Affects Versions: 3.0 Environment: Windows XP SP3 x86 IBM jdk Java60 Geronimo build on 20110525 Reporter: Jacky Liu Assignee: Shenghao Fang Priority: Minor Attachments: CurrencyConverterEJB.jar, GERONIMO-5981.patch, WebAppEjbAccessAnnotations.war 1. start Geronimo 2. deploy CurrencyConverterEJB.jar 3. deploy WebAppEjbAccessAnnotations.war through PlanCreator portlet 4. go to http://localhost:8080/WebAppEjbAccessAnnotations/ to check the Convertor function -- ERROR OCCURS!! When WebAppEjbAccessAnnotations.war is deployed through Plan Creator portlet, Convertor will get a RUNNING failure. 2011-05-26 09:42:53,677 ERROR [[ConverterHandler]] Allocate exception for servlet ConverterHandler java.lang.InstantiationException: Some objects to be injected were not found in jndi: [javax.naming.NamingException: could not look up openejb/Deployment/CurrencyConverterEJB/ConverterBean/myPackage.Converter!Remote [Root exception is javax.naming.NotContextException: openejb/Deployment/CurrencyConverterEJB/ConverterBean/myPackage.Converter!Remote]] at org.apache.geronimo.j2ee.annotation.Holder.newInstance(Holder.java:174) at org.apache.geronimo.tomcat.TomcatInstanceManager.newInstance(TomcatInstanceManager.java:74) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1048) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:799) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:645) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:581) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:518) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:927) at org.apache.jsp.index_jsp._jspService(index_jsp.java:69) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:417) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:391) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:306) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:696) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:48) at org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(ProtectedTargetValve.java:53) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:550) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:380) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:243) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:188) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:288) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:243) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:373) at
[jira] [Commented] (GERONIMO-5764) Support Bundles Deployment in deployment command line
[ https://issues.apache.org/jira/browse/GERONIMO-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065200#comment-13065200 ] Yi Xiao commented on GERONIMO-5764: --- As the life cycle of Geronimo's modules is not under the control of OSGI framework, only +10 in GEP side still can not work successfully. It will be a heavy work to make all the Geronimo's modules' under the control of OSGI framework, I think an optional way is that try to start the resolved bundles after all the Geronimo's modules have been started. Anyway, I will still add the OSGI start level code in GEP side. Support Bundles Deployment in deployment command line - Key: GERONIMO-5764 URL: https://issues.apache.org/jira/browse/GERONIMO-5764 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: commands, console, deployment Affects Versions: 3.0 Reporter: viola.lu Assignee: Rex Wang Priority: Critical Fix For: 3.0 Attachments: GERONIMO-5764-install-bundle.patch, GERONIMO-5764-install-uninstall-bundle.patch, GERONIMO-5764-record-bundle.patch, GERONIMO-5764.patch Now we have to deploy a regular bundle via karaf shell: osgi:install file:/[bunlde_path], not deployer command line, so open this jira to track this feature enablement. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5764) Support Bundles Deployment in deployment command line
[ https://issues.apache.org/jira/browse/GERONIMO-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065243#comment-13065243 ] Rex Wang commented on GERONIMO-5764: Yes, Geronimo modules is installed and started after the framework launch, which means it is out of the control from the start level service :-( Commit the workaround At revision: 1146683 Support Bundles Deployment in deployment command line - Key: GERONIMO-5764 URL: https://issues.apache.org/jira/browse/GERONIMO-5764 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: commands, console, deployment Affects Versions: 3.0 Reporter: viola.lu Assignee: Rex Wang Priority: Critical Fix For: 3.0 Attachments: GERONIMO-5764-install-bundle.patch, GERONIMO-5764-install-uninstall-bundle.patch, GERONIMO-5764-record-bundle.patch, GERONIMO-5764.patch Now we have to deploy a regular bundle via karaf shell: osgi:install file:/[bunlde_path], not deployer command line, so open this jira to track this feature enablement. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5764) Support Bundles Deployment in deployment command line
[ https://issues.apache.org/jira/browse/GERONIMO-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065277#comment-13065277 ] Yi Xiao commented on GERONIMO-5764: --- Thank you, Rex, it works! I will create a sub jira under GERONIMODEVTOOLS-759 in GEP to adapt the new feature. Support Bundles Deployment in deployment command line - Key: GERONIMO-5764 URL: https://issues.apache.org/jira/browse/GERONIMO-5764 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: commands, console, deployment Affects Versions: 3.0 Reporter: viola.lu Assignee: Rex Wang Priority: Critical Fix For: 3.0 Attachments: GERONIMO-5764-install-bundle.patch, GERONIMO-5764-install-uninstall-bundle.patch, GERONIMO-5764-record-bundle.patch, GERONIMO-5764.patch Now we have to deploy a regular bundle via karaf shell: osgi:install file:/[bunlde_path], not deployer command line, so open this jira to track this feature enablement. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMODEVTOOLS-764) Control the OSGI bundle's start level in GEP
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 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] [Created] (GERONIMO-6077) Display usage information after server startup?
Display usage information after server startup?
---
Key: GERONIMO-6077
URL: https://issues.apache.org/jira/browse/GERONIMO-6077
Project: Geronimo
Issue Type: Improvement
Security Level: public (Regular issues)
Reporter: Kevan Miller
The usage information:
{code}
Hit 'tab' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit 'ctrl-d' or 'osgi:shutdown' to shutdown Geronimo.
{code}
Would be better displayed after a server startup is complete. Also, the command
prompt (i.e. 'geronimo') is not visible after the server has been started.
So, it's not apparent to new users that they can enter a command.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: less-osgi-friendly code drop
I just committed something that along with fixing some owb integration problems
seems to fix this specific error. I think that in the code below some gbean
dependencies got mixed up and the web service gbean was starting before the ejb
module actually started. I moved the start code back into EjbModuleImpl and
don't see this NPE.
thanks
david jencks
On Jul 14, 2011, at 4:38 AM, Shawn Jiang wrote:
Hi David Jencks,
Many cases in interop and webservices failed with following similar exception
at deployment phase after your owb/openejb refactor. Seems deploymentinfo
does not get initialized correclty in
org.apache.geronimo.openejb.EjbDeployment.initialize(BeanContext) {
...
}
at all.could you please take a look ?
Caused by: org.apache.geronimo.gbean.InvalidConfigurationException:
Configuration xxx failed to start due
following reasons:
The service
EJBModule=.jar,J2EEApplication=default//1-default/car,SingletonBean=,j
WSLink,name= did not start because null
java.lang.NullPointerException
at
org.apache.geronimo.openejb.EjbDeployment.getBeanClass(EjbDeployment.java:239)
at
org.apache.geronimo.axis2.ejb.EJBWebServiceGBean.init(EJBWebServiceGBean.java:76)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:958)
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:940)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:567)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:462)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:226)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:702)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:681)
at
org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:67)
at java.lang.Thread.run(Thread.java:619)
On Thu, Jul 14, 2011 at 1:10 PM, David Jencks david_jen...@yahoo.com 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.
[jira] [Commented] (GERONIMO-6077) Display usage information after server startup?
[
https://issues.apache.org/jira/browse/GERONIMO-6077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065653#comment-13065653
]
Yi Xiao commented on GERONIMO-6077:
---
Hi, Kevan, the command prompt 'geronimo' is visible, but after show it, the
geronimo modules' start infos are outputted, so it seems like no 'geronimo' is
visible~
Display usage information after server startup?
---
Key: GERONIMO-6077
URL: https://issues.apache.org/jira/browse/GERONIMO-6077
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Reporter: Kevan Miller
The usage information:
{code}
Hit 'tab' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit 'ctrl-d' or 'osgi:shutdown' to shutdown Geronimo.
{code}
Would be better displayed after a server startup is complete. Also, the
command prompt (i.e. 'geronimo') is not visible after the server has been
started. So, it's not apparent to new users that they can enter a command.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6038) testNonContextualSessionBeanReferenceIsIntercepted(org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonCo
[
https://issues.apache.org/jira/browse/GERONIMO-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065672#comment-13065672
]
David Blevins commented on GERONIMO-6038:
-
public class Cruiser implements Ship
{
@EJB
MissileLocal missile; never injected
public void defend()
{
missile.fire();
}
}
testNonContextualSessionBeanReferenceIsIntercepted(org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonContextualEjbReferenceTest)
--
Key: GERONIMO-6038
URL: https://issues.apache.org/jira/browse/GERONIMO-6038
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Reporter: David Blevins
Assignee: David Blevins
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
low entropy on linux systems
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... --kevan
[jira] [Commented] (GERONIMO-6077) Display usage information after server startup?
[
https://issues.apache.org/jira/browse/GERONIMO-6077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065683#comment-13065683
]
Kevan Miller commented on GERONIMO-6077:
Right. Which is really what I meant. The 'geronimo' prompt (and the usage
information) has typically scrolled off the screen and is probably 'no longer
visible' to the user.
Display usage information after server startup?
---
Key: GERONIMO-6077
URL: https://issues.apache.org/jira/browse/GERONIMO-6077
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Reporter: Kevan Miller
The usage information:
{code}
Hit 'tab' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit 'ctrl-d' or 'osgi:shutdown' to shutdown Geronimo.
{code}
Would be better displayed after a server startup is complete. Also, the
command prompt (i.e. 'geronimo') is not visible after the server has been
started. So, it's not apparent to new users that they can enter a command.
--
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
Kevan, thanks for letting us know. I've collected your description into G3.0 doc. https://cwiki.apache.org/GMOxDOC30/runtime-issues.html Jeff On Fri, Jul 15, 2011 at 10:19 AM, Kevan Miller kevan.mil...@gmail.comwrote: 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... --kevan
[jira] [Created] (GERONIMO-6078) Navigation tree displays wrong links for different roles
Navigation tree displays wrong links for different roles Key: GERONIMO-6078 URL: https://issues.apache.org/jira/browse/GERONIMO-6078 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 3.0 Reporter: Shenghao Fang Assignee: Shenghao Fang 1. Login Admin Console with 'system'. The navigation tree displays all links. 2. Logout Admin Console. 3. Login Admin Console with 'monitor'. The navigation tree still displays all links. -- 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
Installing rngd/rng-tools also can help fix these sorts of problems. --jason On Jul 14, 2011, at 7:19 PM, 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... --kevan
[jira] [Resolved] (GERONIMODEVTOOLS-760) Two GeronimoServerBehaviourDelegates created for one IServer
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMODEVTOOLS-760. -- Resolution: Fixed Fix Version/s: 3.0 I have not seen this issue error again so I'm assuming it is fixed. Two GeronimoServerBehaviourDelegates created for one IServer Key: GERONIMODEVTOOLS-760 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-760 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 3.0 Reporter: Jarek Gawor Assignee: Jarek Gawor Fix For: 3.0 Once in a while two GeronimoServerBehaviourDelegates are created for the same IServer and GeronimoServerBehaviourDelegates.initialize() is called twice. Here's a call stack from the two calls to .initialize(): java.lang.Exception at org.apache.geronimo.st.v30.core.GeronimoServerBehaviourDelegate.initialize(GeronimoServerBehaviourDelegate.java:686) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.initialize(ServerBehaviourDelegate.java:102) at org.eclipse.wst.server.core.model.InternalInitializer.initializeServerBehaviourDelegate(InternalInitializer.java:41) at org.eclipse.wst.server.core.internal.Server.getBehaviourDelegate(Server.java:510) at org.eclipse.wst.server.core.internal.Server.loadAdapter(Server.java:1493) at org.apache.geronimo.st.v30.core.Activator.getGeronimoServerBehaviourDelegate(Activator.java:154) at org.apache.geronimo.st.v30.core.Activator.triggerStartUpdateServerTask(Activator.java:169) at org.apache.geronimo.st.v30.core.Activator.start(Activator.java:117) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:417) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:469) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:338) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:232) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1197) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:174) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:904) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55) at org.eclipse.wst.server.core.internal.ServerType.createServerBehaviourDelegate(ServerType.java:91) at org.eclipse.wst.server.core.internal.Server.getBehaviourDelegate(Server.java:508) at org.eclipse.wst.server.core.internal.Server.canPublish(Server.java:1095) at org.eclipse.wst.server.core.internal.Server.shouldPublish(Server.java:1109) at org.eclipse.wst.server.ui.internal.cnf.ServerDecorator.getServerStatusLabel(ServerDecorator.java:139) at org.eclipse.wst.server.ui.internal.cnf.ServerDecorator.decorate(ServerDecorator.java:73) at
[jira] [Updated] (GERONIMO-6076) Graphics cannot be displayed on monitoring porlet
[ https://issues.apache.org/jira/browse/GERONIMO-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Xiao updated GERONIMO-6076: -- Attachment: ShowDojoCharting_6076.patch Graphics cannot be displayed on monitoring porlet - Key: GERONIMO-6076 URL: https://issues.apache.org/jira/browse/GERONIMO-6076 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 3.0 Reporter: Shenghao Fang Attachments: ShowDojoCharting_6076.patch Graphics cannot be displayed on monitoring porlet. This is a regression by GERONIMO-5674. Monitoring portlet requires chart related dojo library which was removed by GERONIMO-5674. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-5586) Provide a way to transform traditional jar to OSGi bundle when user install the jar into G repository.
[ https://issues.apache.org/jira/browse/GERONIMO-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang reassigned GERONIMO-5586: -- Assignee: Rex Wang (was: David Jencks) Provide a way to transform traditional jar to OSGi bundle when user install the jar into G repository. -- Key: GERONIMO-5586 URL: https://issues.apache.org/jira/browse/GERONIMO-5586 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 3.0 Reporter: Forrest Xia Assignee: Rex Wang As G server fundamentally turn into an OSGi based java ee application server, all libraries are required to be a OSGi bundle. But this may not work friendly to popular Java EE user. Let's say a simple scenario that deploys a data source to G server: 1. User uses install-library command or admin console to install the jdbc driver into G repository 2. User prepare a datasource deployment plan that depends on the installed jdbc driver 3. User uses deploy command or admin console to deploy the datasource The deployer will report a ClassNotFound exception saying jdbc driver class is not found. Java EE user may confuse around here, since they know they've installed the jdbc libraries into the repository, but why encounter the CNF exception? From user-friendly aspect, G server is better to provide a way to transform traditional jar into a OSGi bundle transparently. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6076) Graphics cannot be displayed on monitoring porlet
[ https://issues.apache.org/jira/browse/GERONIMO-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065730#comment-13065730 ] Yi Xiao commented on GERONIMO-6076: --- The root cause is the compressed dojox.js file is not imported into some of the monitoring jsp files. Also add some js code to readjust the position of dojo chart's coordinated numbers. Graphics cannot be displayed on monitoring porlet - Key: GERONIMO-6076 URL: https://issues.apache.org/jira/browse/GERONIMO-6076 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 3.0 Reporter: Shenghao Fang Attachments: ShowDojoCharting_6076.patch Graphics cannot be displayed on monitoring porlet. This is a regression by GERONIMO-5674. Monitoring portlet requires chart related dojo library which was removed by GERONIMO-5674. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5586) Provide a way to transform traditional jar to OSGi bundle when user install the jar into G repository.
[ https://issues.apache.org/jira/browse/GERONIMO-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065731#comment-13065731 ] Rex Wang commented on GERONIMO-5586: At revision: 1146965 I modified the code logic (the previous one has the wrong if condition), and also add the ability to install-library cli. I re-write the repository jsp to make it more usable. -Rex Provide a way to transform traditional jar to OSGi bundle when user install the jar into G repository. -- Key: GERONIMO-5586 URL: https://issues.apache.org/jira/browse/GERONIMO-5586 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 3.0 Reporter: Forrest Xia Assignee: Rex Wang Fix For: 3.0 As G server fundamentally turn into an OSGi based java ee application server, all libraries are required to be a OSGi bundle. But this may not work friendly to popular Java EE user. Let's say a simple scenario that deploys a data source to G server: 1. User uses install-library command or admin console to install the jdbc driver into G repository 2. User prepare a datasource deployment plan that depends on the installed jdbc driver 3. User uses deploy command or admin console to deploy the datasource The deployer will report a ClassNotFound exception saying jdbc driver class is not found. Java EE user may confuse around here, since they know they've installed the jdbc libraries into the repository, but why encounter the CNF exception? From user-friendly aspect, G server is better to provide a way to transform traditional jar into a OSGi bundle transparently. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-5586) Provide a way to transform traditional jar to OSGi bundle when user install the jar into G repository.
[ https://issues.apache.org/jira/browse/GERONIMO-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang resolved GERONIMO-5586. Resolution: Fixed Fix Version/s: 3.0 Provide a way to transform traditional jar to OSGi bundle when user install the jar into G repository. -- Key: GERONIMO-5586 URL: https://issues.apache.org/jira/browse/GERONIMO-5586 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 3.0 Reporter: Forrest Xia Assignee: Rex Wang Fix For: 3.0 As G server fundamentally turn into an OSGi based java ee application server, all libraries are required to be a OSGi bundle. But this may not work friendly to popular Java EE user. Let's say a simple scenario that deploys a data source to G server: 1. User uses install-library command or admin console to install the jdbc driver into G repository 2. User prepare a datasource deployment plan that depends on the installed jdbc driver 3. User uses deploy command or admin console to deploy the datasource The deployer will report a ClassNotFound exception saying jdbc driver class is not found. Java EE user may confuse around here, since they know they've installed the jdbc libraries into the repository, but why encounter the CNF exception? From user-friendly aspect, G server is better to provide a way to transform traditional jar into a OSGi bundle transparently. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
