date:20101021

Re: Fail to start geronimo 3.0 snapshot server

2010-10-21 Thread David Jencks

Hi Viola,

Sorry, I forgot how many problems there are without my OWB patches I tried 
to get a committer to look at them today but apparently didn't succeed.

I think you need to apply the patches on 
https://issues.apache.org/jira/browse/OWB-473
https://issues.apache.org/jira/browse/OWB-480

I made some changes in OpenEJB also that are needed but I think david blevins 
pushed a snapshot if there are problems building geronimo-openejb try 
building openejb locally.

thanks
david jencks

On Oct 21, 2010, at 11:31 PM, viola lu wrote:

> HI, i built latest geronimo 3.0 code, but fail to start it, see log, seems 
> errors are from openwebbean integration:
>   2010-10-22 14:29:01,406 INFO  [KernelContextGBean] bound gbean 
> org.apache.geronimo.configs/welcome-tomcat/3.0-SNAPSHOT/car?J2EEApplication=null,WebModule=org.apache.geronimo.configs/welcome-tomcat/3.0-SNAPSHOT/car,j2eeType=ValidatorFactory,name=ValidatorFactory
>  at name 
> org.apache.geronimo.configs/welcome-tomcat/ValidatorFactory/ValidatorFactory
> 2010-10-22 14:29:01,765 INFO  [PropertyLoader] could not find any property 
> files with name META-INF/openwebbeans/openwebbeans.properties
> 2010-10-22 14:29:01,765 ERROR [GBeanInstance] Problem in doFail of 
> org.apache.geronimo.configs/welcome-tomcat/3.0-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.configs/welcome-tomcat/3.0-SNAPSHOT/car
> java.lang.RuntimeException: java.lang.IllegalArgumentException: null source
>   at 
> org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:337)
>   at 
> org.apache.geronimo.tomcat.TomcatWebAppContext.doFail(TomcatWebAppContext.java:582)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1031)
>   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.GBeanInstance.start(GBeanInstance.java:546)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
>   at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175)
>   at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
>   at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:546)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
>   at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175)
>   at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
>   at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
>   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: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.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:199)
>   at 
> org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:91)
>   at 
> org.apache.geronimo.system.osgi.BootActivator$1.execute(BootActivator.java:107)
>   at org.apache.geronimo.main.Bootstrapper.execute(Bootst

Fail to start geronimo 3.0 snapshot server

2010-10-21 Thread viola lu

HI, i built latest geronimo 3.0 code, but fail to start it, see log, seems
errors are from openwebbean integration:
2010-10-22 14:29:01,406 INFO [KernelContextGBean] bound gbean
org.apache.geronimo.configs/welcome-tomcat/3.0-SNAPSHOT/car?J2EEApplication=null,WebModule=org.apache.geronimo.configs/welcome-tomcat/3.0-SNAPSHOT/car,j2eeType=ValidatorFactory,name=ValidatorFactory
at name
org.apache.geronimo.configs/welcome-tomcat/ValidatorFactory/ValidatorFactory
2010-10-22 14:29:01,765 INFO [PropertyLoader] could not find any property
files with name META-INF/openwebbeans/openwebbeans.properties 2010-10-22
14:29:01,765 ERROR [GBeanInstance] Problem in doFail of
org.apache.geronimo.configs/welcome-tomcat/3.0-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.configs/welcome-tomcat/3.0-SNAPSHOT/car
java.lang.RuntimeException: java.lang.IllegalArgumentException: null source
at
org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:337)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.doFail(TomcatWebAppContext.java:582)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1031)
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.GBeanInstance.start(GBeanInstance.java:546)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:546)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
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: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.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:199)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:91)
at
org.apache.geronimo.system.osgi.BootActivator$1.execute(BootActivator.java:107)
at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65) at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) at
org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:32) Caused by:
java.lang.IllegalArgumentException: null source at
java.util.EventObject.(EventObject.java:38) at
javax.management.Notification.(Notification.java:168) at
org.apache.catalina.core.StandardContext.destroyInternal(StandardContext.java:5004)
at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:263) at
org.apache.geronimo.tomcat.GeronimoStandardContext.kill(GeronimoStandardContext.java:423)
at
org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:335)
... 34 more 2010-10-22 14:29:01,765 ERROR [GBeanInstanceState] Error while
starting; GBean is now in the FAILED state:
abstractName="org.apache.geronimo.configs/welcome-tomcat/3.0-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.configs/welcome-tomcat/3.0-

[jira] Commented: (GERONIMO-5610) Problem with install-plugin via the Administration console

2010-10-21 Thread Rex Wang (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923773#action_12923773
 ] 

Rex Wang commented on GERONIMO-5610:


Hi maojia, 
You should not "deploy" a car to geronimo, if you do that, it will go to 
deployer to re-generate the config.ser and the plan.xml in your car won't have 
effect.

you need try the "deploy install-plugin" in cmd line to install a plugin.

> Problem with install-plugin via the Administration console
> --
>
> Key: GERONIMO-5610
> URL: https://issues.apache.org/jira/browse/GERONIMO-5610
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 3.0
> Environment: Windows platform
>Reporter: maojia
>Assignee: Rex Wang
>Priority: Trivial
> Attachments: HelloWorld-1.0.car
>
>
> I deployed a HelloWorld-1.0.car plugin, containing the geronimo-plugin.xml 
> file correctly, on the geronimo-tomcat7-javaee6-3.0-SNAPSHOT server.
> On the Install Geronimo Plugins portlet, I selected 
> "http://localhost:8080/plugin/maven-repo/"; as the chosen repository to show 
> plugins in the selected repository. The HelloWorld-1.0.car file, however, was 
> not in the list of plugins as expected.   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4961) Update Spring version to 3.0.0-RC1

2010-10-21 Thread Ivan (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan updated GERONIMO-4961:
---

Fix Version/s: (was: 3.0)
   Wish List

Currently, no Geronimo plugin requires spring components, we might not ship 
them. Move to the wish list temporarily.

> Update Spring version to 3.0.0-RC1
> --
>
> Key: GERONIMO-4961
> URL: https://issues.apache.org/jira/browse/GERONIMO-4961
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: Plugins
>Affects Versions: 3.0
>Reporter: Ivan
>Assignee: Ivan
> Fix For: Wish List
>
>
> Need to update spring components to latest 3.0.0-RC1, as the spring-web-2.5.6 
> does not accept ervlet spec version 3.0.0

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GERONIMO-4961) Update Spring version to 3.0.0-RC1

2010-10-21 Thread Ivan (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan reassigned GERONIMO-4961:
--

Assignee: Ivan

> Update Spring version to 3.0.0-RC1
> --
>
> Key: GERONIMO-4961
> URL: https://issues.apache.org/jira/browse/GERONIMO-4961
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: Plugins
>Affects Versions: 3.0
>Reporter: Ivan
>Assignee: Ivan
> Fix For: 3.0
>
>
> Need to update spring components to latest 3.0.0-RC1, as the spring-web-2.5.6 
> does not accept ervlet spec version 3.0.0

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GERONIMO-5420) gogo comand deploy:install-plugin not working properly

2010-10-21 Thread Ivan (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan reassigned GERONIMO-5420:
--

Assignee: Ivan

> gogo comand deploy:install-plugin not working properly
> --
>
> Key: GERONIMO-5420
> URL: https://issues.apache.org/jira/browse/GERONIMO-5420
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: commands
>Affects Versions: 3.0-M1
> Environment: Ubtun 9.0.4+JDK 1.6.0
>Reporter: Chi Runhua
>Assignee: Ivan
>Priority: Minor
>
> {code}
> geronimo> install-plugin 
> /home/jeffchi/plugins/hello-tomcat/target/helloworld.car
> Checking for status every 1000ms:
> 2010-07-01 16:13:17,593 ERROR [PluginInstallerGBean] Invalid Configuration 
> Archive /home/jeffchi/Geronimo/geronimo-tomcat7-javaee6-3.0-M1/bin no plugin 
> metadata found
> Installation FAILED: Invalid Configuration Archive 
> /home/jeffchi/Geronimo/geronimo-tomcat7-javaee6-3.0-M1/bin no plugin metadata 
> found
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GERONIMO-5636) Improve the duplicate extract/package operations in the deployment process

2010-10-21 Thread Ivan (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan reassigned GERONIMO-5636:
--

Assignee: Ivan

> Improve the duplicate extract/package operations in the deployment process
> --
>
> Key: GERONIMO-5636
> URL: https://issues.apache.org/jira/browse/GERONIMO-5636
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 3.0
>Reporter: Ivan
>Assignee: Ivan
> Fix For: Wish List
>
>
> http://apache-geronimo.328035.n3.nabble.com/Use-Truezip-in-Geronimo-deployment-td1601057.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GERONIMO-5643) fail to edit NIOHTTPConnector directly through console

2010-10-21 Thread Shawn Jiang (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-5643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shawn Jiang reassigned GERONIMO-5643:
-

Assignee: Shawn Jiang

> fail to edit NIOHTTPConnector directly through console
> --
>
> Key: GERONIMO-5643
> URL: https://issues.apache.org/jira/browse/GERONIMO-5643
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 3.0
> Environment: OS:Windows XP SP3
> Java Version: 1.6.0_20
> Server:Geronimo 3.0-SNAPSHOT
>Reporter: Zhen Zhang
>Assignee: Shawn Jiang
>Priority: Minor
> Fix For: 3.0
>
>
> setps to recur:
> 1. start the Geronimo server, and then open the admin console. 
> 2. Open the "web server" portlet , and then click on "edit" link against an 
> existing NIO HTTP Connector in network listener list(like TomcatWebConnector  
> HTTP  8080)
> 3. Modify the port  (Attention:the  port should not be used by others)
> 4. Click on "Save" , to save your change and  then you will find this log 
> info:
> 2010-10-14 13:54:22,843 INFO  [RedirectByHashFilter] Hash value for 
> page:/portal/1-2/Application Server/Web 
> Server/__acconsole-base0x2ConnectorManager!-743665070|1/__pmconsole-base0x2ConnectorManager!-743665070|1_view
>  is:4181896917247261852
> 2010-10-14 13:54:22,843 INFO  [RedirectByHashFilter] no redirect 
> for:http://localhost:8080/console/portal/1-2/Application%20Server/Web%20Server/__acconsole-base0x2ConnectorManager!-743665070%7C1/__pmconsole-base0x2ConnectorManager!-743665070%7C1_view
> 2010-10-14 13:54:22,937 INFO  [RedirectByHashFilter] Hash value for 
> page:/portal/1-2/Application Server/Web 
> Server/__pmconsole-base0x2ConnectorManager!-743665070|1_view/__wsconsole-base0x2ConnectorManager!-743665070|1_normal/__rpconsole-base0x2ConnectorManager!-743665070|1_connectorURI/org0x2apache0x2geronimo0x2configs0xc2Ftomcat70xc2F30x20-SNAPSHOT0xc2Fcar0xc3FServiceModule0xc3Dorg0x2apache0x2geronimo0x2configs0xc2Ftomcat70xc2F30x20-SNAPSHOT0xc2Fcar0xc2Cj2eeType0xc3DGBean0xc2Cname0xc3DTomcatWebConnector/__rpconsole-base0x2ConnectorManager!-743665070|1_mode/edit/__rpconsole-base0x2ConnectorManager!-743665070|1_server/tomcat/__rpconsole-base0x2ConnectorManager!-743665070|1_containerURI/org0x2apache0x2geronimo0x2configs0xc2Ftomcat70xc2F30x20-SNAPSHOT0xc2Fcar0xc3FServiceModule0xc3Dorg0x2apache0x2geronimo0x2configs0xc2Ftomcat70xc2F30x20-SNAPSHOT0xc2Fcar0xc2Cj2eeType0xc3DGBean0xc2Cname0xc3DTomcatWebContainer/__rpconsole-base0x2ConnectorManager!-743665070|1_managerURI/org0x2apache0x2geronimo0x2configs0xc2Ftomcat70xc2F30x20-SNAPSHOT0xc2Fcar0xc3FServiceModule0xc3Dorg0x2apache0x2geronimo0x2configs0xc2Ftomcat70xc2F30x20-SNAPSHOT0xc2Fcar0xc2Cj2eeType0xc3DGBean0xc2Cname0xc3DTomcatWebManager
>  is:-3108636324815761283
> 2010-10-14 13:54:22,937 INFO  [RedirectByHashFilter] no redirect 
> for:http://localhost:8080/console/portal/1-2/Application%20Server/Web%20Server/__pmconsole-base0x2ConnectorManager!-743665070%7C1_view/__wsconsole-base0x2ConnectorManager!-743665070%7C1_normal/__rpconsole-base0x2ConnectorManager!-743665070%7C1_connectorURI/org0x2apache0x2geronimo0x2configs0xc2Ftomcat70xc2F30x20-SNAPSHOT0xc2Fcar0xc3FServiceModule0xc3Dorg0x2apache0x2geronimo0x2configs0xc2Ftomcat70xc2F30x20-SNAPSHOT0xc2Fcar0xc2Cj2eeType0xc3DGBean0xc2Cname0xc3DTomcatWebConnector/__rpconsole-base0x2ConnectorManager!-743665070%7C1_mode/edit/__rpconsole-base0x2ConnectorManager!-743665070%7C1_server/tomcat/__rpconsole-base0x2ConnectorManager!-743665070%7C1_containerURI/org0x2apache0x2geronimo0x2configs0xc2Ftomcat70xc2F30x20-SNAPSHOT0xc2Fcar0xc3FServiceModule0xc3Dorg0x2apache0x2geronimo0x2configs0xc2Ftomcat70xc2F30x20-SNAPSHOT0xc2Fcar0xc2Cj2eeType0xc3DGBean0xc2Cname0xc3DTomcatWebContainer/__rpconsole-base0x2ConnectorManager!-743665070%7C1_managerURI/org0x2apache0x2geronimo0x2configs0xc2Ftomcat70xc2F30x20-SNAPSHOT0xc2Fcar0xc3FServiceModule0xc3Dorg0x2apache0x2geronimo0x2configs0xc2Ftomcat70xc2F30x20-SNAPSHOT0xc2Fcar0xc2Cj2eeType0xc3DGBean0xc2Cname0xc3DTomcatWebManager
> 2010-10-14 13:54:22,968 INFO  [SupportedModesServiceImpl] Portlet mode 'edit' 
> not found for portletId: 'console-base.WebServerManager!-743665070|0'
> 2010-10-14 13:54:23,109 ERROR [ConnectorPortlet] Unable to retrieve value of 
> property asyncTimeout
> java.lang.IllegalArgumentException: No such method found (getAsyncTimeout on 
> org.apache.geronimo.management.StatisticsProvider$$EnhancerByCGLIB$$df99af6f)
>   at 
> org.apache.geronimo.console.BasePortlet.getProperty(BasePortlet.java:121)
>   at 
> org.apache.geronimo.console.webmanager.ConnectorPortlet.doView(ConnectorPortlet.java:346)
>   at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:348)
>   at javax.portlet.GenericPortlet.render(Gen

[jira] Assigned: (GERONIMO-5593) Reenable some missing functions in G 3.0

2010-10-21 Thread Shawn Jiang (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shawn Jiang reassigned GERONIMO-5593:
-

Assignee: Shawn Jiang

> Reenable some missing functions in G 3.0
> 
>
> Key: GERONIMO-5593
> URL: https://issues.apache.org/jira/browse/GERONIMO-5593
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>Affects Versions: 3.0
>Reporter: Forrest Xia
>Assignee: Shawn Jiang
>
> So far, we've made big progress on G 3.0 release target, but still there are 
> some functions in previous release but missing in the current trunk. This 
> task is opened as parent to hold information about missing functions.
> Also we can discuss if the subtask is really required for G 3.0 release.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Pull the latest Tomcat codes to our own repository

2010-10-21 Thread Ivan

I have pulled the latest Tomcat trunk codes to our own repository.  Some
extra changes are included :
a. Comment out the reference of BackupManager in the HTMLManagerServlet due
to the recursive dependency. I have posted an email to Tomcat community,
let's wait to see ...
b. Replace the reference of Globles with static string in the japser module,
as we do not wish it depends on Catalia.
c. Include the extra fix for AsyncLisener.
I will deploy the snapshots to the repository later if everything works
well.

2010/10/20 Ivan 

> Yes, I know it is better to solve this from its root, but from the
> experience in the past ...
> I will try.
>
> 2010/10/20 Kevan Miller 
>
>
>> On Oct 20, 2010, at 2:25 AM, Ivan wrote:
>>
>> > Just find an annoying change in the latest Tomcat codes, a class
>> HTMLManagerServlet in the catalina package refers to a class in the
>> catalina-ha.
>> > I plan to move this class to the catalina-ha package, seems that this
>> class is not refered by any other classes in the Tomcat code base. or anyone
>> has better ideas ?
>>
>> I expect that the following is your intention, but I think it's worth
>> stating -- this should be taken up with the Tomcat community. Our goal
>> should be to not have any long-term changes to Tomcat. We should be working
>> with the Tomcat community to understand our problems and have our updates
>> applied to Tomcat, not in our externals release.
>>
>> In this instance, I don't understand why HTMLManagerServlet needs to be
>> aware of the specific Manager sub-class, at all. Seems like the Manager
>> interface could have provided an appropriate method for retrieving the
>> desired information.
>>
>> --kevan
>
>
>
>
> --
> Ivan
>



-- 
Ivan

Re: Welcome "Janet" Hong Fang Han as a new committer

2010-10-21 Thread viola lu

Congrats!

On Fri, Oct 22, 2010 at 9:37 AM, han hongfang  wrote:

> Thank you all for the congratulations. I'm excited and glad to work with
> all of you~
>
>
> On Thu, Oct 21, 2010 at 8:40 PM, Ted Kirby  wrote:
>
>> Congratulations Janet!  Welcome aboard!
>>
>> Ted
>>
>> On Wed, Oct 20, 2010 at 9:11 PM, Ivan  wrote:
>> > I would like to welcome Janet aboard, as she recently accepted the
>> Geronimo
>> > PMC invitation to become a committer.  Her account was just created this
>> > morning (hanhongfang), so you should start seeing some commits from her
>> > soon.
>> > --
>> > Ivan
>> >
>>
>
>
>
> --
> Best regards,
>
> Han Hong Fang
>



-- 
viola

Re: Is it possible to make those xml digest class serializable ?

2010-10-21 Thread Ivan

Thanks, Leonardo, please help to check my comments below.

2010/10/22 Leonardo Uribe 

> Hi
>
> Here some answers:
>
> 2010/10/20 Ivan 
>
>> Thanks, please help to check my comments below.
>>
>>
>> 2010/10/20 Leonardo Uribe 
>>
>>> Hi
>>>
>>> Some answers to your post below:
>>>
>>> IV>> Just some ideas for the integration improvment, please help to give
>>> some comments.
>>>
>>> IV>> a. Create a new SPI provider and a provider factory, might name
>>> FacesConfigurationProvider/
>>> IV>> FacesConfigurationProviderFactory, which has a method
>>> IV>>  FacesConfig getFacesConfig(ExternalContext context);
>>> IV>>This method is designed to get the final combined the FacesConfig
>>> instance, which including
>>> IV>> application resource configuration + annotation + default web
>>> application resource
>>> IV>>  And move those logic about merge/annotaiton scanning from
>>> FacesConfigurator and
>>> IV>> AnnotationConfigurator to the default implementation provider
>>>
>>> Yes, it could be good to have another SPI provider in this case, but I
>>> don't know how that interface should
>>> looks like. In theory, at some point we have a consolidate FacesConfig,
>>> but without the annotation information.
>>> The reason is not all information provided by annotations is on
>>> faces-config.xml format.
>>>
>>
>> The SPI name might not be proper, I am thinking that, for JSF core, it
>> might not care there is some information in the xml files, and others might
>> be from annotation. Guess she will say to the deployer : hey, just give me
>> the final application configuration files, I have no interest where it is
>> from ;-) So I hope to seperate those sort/combine logic from the
>> FacesConfigurator.
>>
>
> Ok, well, it is true that SPI does not fit well with OSGi after all. We
> have to think about an alternate strategy to provide
> those hooks. I think at this point it is not clear how to put the
> integration points.
>
> JSF 2.0 spec uses SPI interface to configure some artifacts. In section
> 11.2.6.1 FactoryFinder it says the following:
>
> " 4. If a META-INF/services/{factory-class-name} resource is visible to
> the web application class loader for
> the calling application (typically as a result of being present in the
> manifest of a JAR file), its first line is read and
> assumed to be the name of the factory implementation class to use."
>
> Anyway, to ensure proper operation of JSF, SPI interfaces must work because
> by JSF spec, it is expected to use them.
>
> Now, going back to the point, we need to specify this part a little.
>
> What is the intention of such interface?
>

 I might not express the idea clearly. I did not object to use SPI,
actually it is popularly used in the Java EE environment. The idea here is,
just thinking have a provider interface, with it, other containers could
provide the final faces configurations to the JSF core ( including
faces-config.xml and annotations). From my view, the jsf core is just a
consumer for the configurations, she might not require to know where is the
configuration from. For other containers, as you said, they might just
parse, sort, scan and combine the configurations in the deployment time,
then store the result somewhere. While the applications start, those
configurations could be provided to jsf core quickly. In the default impl of
this interface ( or SPI ), think that we could place those existing logic of
parsing, scanning ... there. while those logic currently is in the
FacesConfigurator.


> Is the intention do not parse multiple times faces-config xml files and
> save webapp setup time?
>

Yes.


>
> Is the intention do not parse annotations and save webapp setup time?
>

 Yes.

>
>
>>> IV>> b. Make some classes in the
>>> org.apache.myfaces.config.impl.digester.elements package serializable,
>>> IV>> this might be optional...
>>> IV>> From the integration side, the third-party container could implement
>>> their own
>>> IV>> FacesConfigurationProvider, they might return the FacesConfig object
>>> directly from their own structure.
>>>
>>> Yes, it could be good to provide a way to expose that configuration
>>> information.
>>>
>>> IV>> c. I saw some codes in the ***ProviderFactory is commented out,
>>> IV>>//AnnotationProviderFactory instance =
>>> (AnnotationProviderFactory) ctx.getApplicationMap().get(FACTORY_KEY);
>>> IV>>//if (instance != null)
>>> IV>>//{
>>> IV>>//return instance;
>>> IV>>//}
>>> IV>>   Did it cause any issue ? Or I hope to recover them, as it will be
>>> more easier to set other implemtations
>>> IV>> for other containers. The commons-discovery package might not work
>>> correctly in OSGI environment. as they
>>> IV>> will try to search META-INF/services folder, and this way sometimes
>>> might not work correctly in OSGi environment.
>>> IV>> thanks.
>>>
>>> I commented that code because AnnotationProviderFactory,
>>> FaceletConfigResourceProviderFactory
>>> a

Re: Welcome "Janet" Hong Fang Han as a new committer

2010-10-21 Thread han hongfang

Thank you all for the congratulations. I'm excited and glad to work with all
of you~

On Thu, Oct 21, 2010 at 8:40 PM, Ted Kirby  wrote:

> Congratulations Janet!  Welcome aboard!
>
> Ted
>
> On Wed, Oct 20, 2010 at 9:11 PM, Ivan  wrote:
> > I would like to welcome Janet aboard, as she recently accepted the
> Geronimo
> > PMC invitation to become a committer.  Her account was just created this
> > morning (hanhongfang), so you should start seeing some commits from her
> > soon.
> > --
> > Ivan
> >
>



-- 
Best regards,

Han Hong Fang

[BUILD] trunk: Failed for Revision: 1026188

2010-10-21 Thread gawor

Geronimo Revision: 1026188 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021/build-2100.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021/unit-test-reports
 
43K downloaded  (openejb-loader-3.2-20101020.131205-52.jar)
Downloading: 
http://repository.apache.org/snapshots/org/apache/openejb/openejb-javaagent/3.2-SNAPSHOT/openejb-javaagent-3.2-20101020.131205-52.jar
12K downloaded  (openejb-javaagent-3.2-20101020.131205-52.jar)
Downloading: 
http://repository.apache.org/snapshots/org/apache/openejb/openejb-ejbd/3.2-SNAPSHOT/openejb-ejbd-3.2-20101020.131205-43.jar
59K downloaded  (openejb-ejbd-3.2-20101020.131205-43.jar)
Downloading: 
http://repository.apache.org/snapshots/org/apache/openejb/openejb-server/3.2-SNAPSHOT/openejb-server-3.2-20101020.131205-45.jar
86K downloaded  (openejb-server-3.2-20101020.131205-45.jar)
Downloading: 
http://repository.apache.org/snapshots/org/apache/openejb/openejb-client/3.2-SNAPSHOT/openejb-client-3.2-20101020.131205-45.jar
229K downloaded  (openejb-client-3.2-20101020.131205-45.jar)
Downloading: 
http://repository.apache.org/snapshots/org/apache/openejb/openejb-multicast/3.2-SNAPSHOT/openejb-multicast-3.2-20101020.131205-45.jar
50K downloaded  (openejb-multicast-3.2-20101020.131205-45.jar)
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory 
/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 35 source files to 
/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/target/classes
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[65,29]
 cannot find symbol
symbol  : class OWBContextThreadListener
location: package org.apache.openejb.cdi

/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[66,29]
 cannot find symbol
symbol  : class ThreadSingletonService
location: package org.apache.openejb.cdi

/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/ThreadSingletonServiceAdapter.java:[30,29]
 cannot find symbol
symbol  : class ThreadSingletonService
location: package org.apache.openejb.cdi

/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/ThreadSingletonServiceAdapter.java:[38,87]
 cannot find symbol
symbol: class ThreadSingletonService
public class ThreadSingletonServiceAdapter extends GeronimoSingletonService 
implements ThreadSingletonService {

/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/ThreadSingletonServiceAdapter.java:[44,49]
 cannot find symbol
symbol  : class OWBContext
location: package org.apache.openejb.cdi

/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/ThreadSingletonServiceAdapter.java:[65,55]
 cannot find symbol
symbol  : class OWBContext
location: package org.apache.openejb.cdi

/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/GeronimoSecurityService.java:[53,45]
 [deprecation] 
login(java.lang.String,javax.security.auth.callback.CallbackHandler) in 
org.apache.geronimo.security.ContextManager has been deprecated

/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[169,42]
 cannot find symbol
symbol  : class ThreadSingletonService
location: class org.apache.geronimo.openejb.OpenEjbSystemGBean

/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[171,51]
 cannot find symbol
symbol  : class OWBContextThreadListener
location: class org.apache.geronimo.openejb.OpenEjbSystemGBean

/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/ThreadSingletonServiceAdapter.java:[43,4]
 method does not override or implement a method from a supertype

/home/geronimo/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/ThreadSingletonServiceAdapter.java:[65,18]
 contextEntered(org.apache.openejb.cdi.OWBContext) in 
org.apache.geronimo.openejb.ThreadSingletonServiceAdap

Re: Injection of Bundle/BundleContext into Java EE components

2010-10-21 Thread David Jencks

dunno about the @Inject (seems like a good idea but I don't know enough about 
jcdi)  but the @Resource is a great idea!

david jencks

On Oct 21, 2010, at 2:06 PM, Jarek Gawor wrote:

> Hi all,
> 
> I was thinking about adding support for injection of
> Bundle/BundleContext objects into Java EE components via @Resource
> annotation. Example:
> 
> class MyServlet extends HttpServlet {
>   @Resource
>   Bundle bundle;
>   @Resource
>   BundleContext bundleContext;
>   
> }
> 
> That should make it easier to interact with OSGi within Java EE apps.
> 
> I was also thinking of something similar with @Inject for web beans
> (cdi stuff) but I'm not really sure it's all that useful since it
> should be possible to inject Bundle/BundleContext via @Resource or
> combine it with @Produces.
> 
> What do you think?
> 
> Jarek

[jira] Commented: (GERONIMO-5050) Integrate OpenWebBeans into Geronimo 3.0.

2010-10-21 Thread David Jencks (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923664#action_12923664
 ] 

David Jencks commented on GERONIMO-5050:


rev 1026156 implements a thread/module based SingletonService for OWB in 
cooperation with a recent openejb rev.  I get 46 jcdi tck failures with this.  
Also needs OWB 473 and 480

> Integrate OpenWebBeans into Geronimo 3.0. 
> --
>
> Key: GERONIMO-5050
> URL: https://issues.apache.org/jira/browse/GERONIMO-5050
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: javaee6, OpenWebBeans
>Affects Versions: 3.0
>Reporter: Rick McGuire
> Fix For: 3.0
>
> Attachments: openwebbeans.patch
>
>
> A JSR 299 and 330 implementation is required for Java EE6 and the Java EE 6 
> web profile.  OpenWebBeans is the most feasible candidate for providing these 
> features. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Is it possible to make those xml digest class serializable ?

2010-10-21 Thread Leonardo Uribe

Hi

Here some answers:

2010/10/20 Ivan 

> Thanks, please help to check my comments below.
>
> 2010/10/20 Leonardo Uribe 
>
>> Hi
>>
>> Some answers to your post below:
>>
>> IV>> Just some ideas for the integration improvment, please help to give
>> some comments.
>>
>> IV>> a. Create a new SPI provider and a provider factory, might name
>> FacesConfigurationProvider/
>> IV>> FacesConfigurationProviderFactory, which has a method
>> IV>>  FacesConfig getFacesConfig(ExternalContext context);
>> IV>>This method is designed to get the final combined the FacesConfig
>> instance, which including
>> IV>> application resource configuration + annotation + default web
>> application resource
>> IV>>  And move those logic about merge/annotaiton scanning from
>> FacesConfigurator and
>> IV>> AnnotationConfigurator to the default implementation provider
>>
>> Yes, it could be good to have another SPI provider in this case, but I
>> don't know how that interface should
>> looks like. In theory, at some point we have a consolidate FacesConfig,
>> but without the annotation information.
>> The reason is not all information provided by annotations is on
>> faces-config.xml format.
>>
>
> The SPI name might not be proper, I am thinking that, for JSF core, it
> might not care there is some information in the xml files, and others might
> be from annotation. Guess she will say to the deployer : hey, just give me
> the final application configuration files, I have no interest where it is
> from ;-) So I hope to seperate those sort/combine logic from the
> FacesConfigurator.
>

Ok, well, it is true that SPI does not fit well with OSGi after all. We have
to think about an alternate strategy to provide
those hooks. I think at this point it is not clear how to put the
integration points.

JSF 2.0 spec uses SPI interface to configure some artifacts. In section
11.2.6.1 FactoryFinder it says the following:

" 4. If a META-INF/services/{factory-class-name} resource is visible to
the web application class loader for
the calling application (typically as a result of being present in the
manifest of a JAR file), its first line is read and
assumed to be the name of the factory implementation class to use."

Anyway, to ensure proper operation of JSF, SPI interfaces must work because
by JSF spec, it is expected to use them.

Now, going back to the point, we need to specify this part a little.

What is the intention of such interface?

Is the intention do not parse multiple times faces-config xml files and save
webapp setup time?

Is the intention do not parse annotations and save webapp setup time?


>> IV>> b. Make some classes in the
>> org.apache.myfaces.config.impl.digester.elements package serializable,
>> IV>> this might be optional...
>> IV>> From the integration side, the third-party container could implement
>> their own
>> IV>> FacesConfigurationProvider, they might return the FacesConfig object
>> directly from their own structure.
>>
>> Yes, it could be good to provide a way to expose that configuration
>> information.
>>
>> IV>> c. I saw some codes in the ***ProviderFactory is commented out,
>> IV>>//AnnotationProviderFactory instance = (AnnotationProviderFactory)
>> ctx.getApplicationMap().get(FACTORY_KEY);
>> IV>>//if (instance != null)
>> IV>>//{
>> IV>>//return instance;
>> IV>>//}
>> IV>>   Did it cause any issue ? Or I hope to recover them, as it will be
>> more easier to set other implemtations
>> IV>> for other containers. The commons-discovery package might not work
>> correctly in OSGI environment. as they
>> IV>> will try to search META-INF/services folder, and this way sometimes
>> might not work correctly in OSGi environment.
>> IV>> thanks.
>>
>> I commented that code because AnnotationProviderFactory,
>> FaceletConfigResourceProviderFactory
>> and FacesConfigResourceProviderFactory are only used once in the
>> application lifetime (during initialization)
>> so it does not have sense to put them on application map.
>>
>> In theory, it should work even in OSGi. The reason is to JSF work
>> correctly in OSGi, it should be provided a
>> ThreadContextClassLoader (TCCL) that could find resources all bundles that
>> the web application uses. That's necessary
>> to make javax.faces.FactoryFinder class work correctly, and it is know
>> that libraries like SpringDM, or containers like
>> GlassFish do that to keep code working. Unfortunately, there is no other
>> option because by the spec it is not possible to
>> change the way FactoryFinder works (I can't add a BundleActivator on
>> myfaces-api.jar because this class is public-api).
>>
>
>Yes, I agree that it might work, and just need to place one
> configuration file in a righ place. But I would prefer to set it
> programically, and make sure it could be definitely configured, and no other
> unexpected files would be found, e.g. If the users place some configuration
> files in their own app etc.
>I looked

[BUILD] trunk: Failed for Revision: 1026107

2010-10-21 Thread gawor

Geronimo Revision: 1026107 built with tests included
 
See the full build-1500.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021/build-1500.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 43 minutes 16 seconds
[INFO] Finished at: Thu Oct 21 15:46:51 EDT 2010
[INFO] Final Memory: 455M/997M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021/logs-1500-tomcat/
 
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 19.692 sec <<< 
FAILURE!
 
Assembly: jetty
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021/logs-1500-jetty/
 
Running TestSuite
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.291 sec <<< 
FAILURE!
--
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 19.703 sec <<< 
FAILURE!
 
Samples: trunk
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021/samples-1500.log
 
Build status: OK

Re: Injection of Bundle/BundleContext into Java EE components

2010-10-21 Thread Joe Bohn


Yay!

Joe

On 10/21/10 5:06 PM, Jarek Gawor wrote:

Hi all,

I was thinking about adding support for injection of
Bundle/BundleContext objects into Java EE components via @Resource
annotation. Example:

class MyServlet extends HttpServlet {
@Resource
Bundle bundle;
@Resource
BundleContext bundleContext;

}

That should make it easier to interact with OSGi within Java EE apps.

I was also thinking of something similar with @Inject for web beans
(cdi stuff) but I'm not really sure it's all that useful since it
should be possible to inject Bundle/BundleContext via @Resource or
combine it with @Produces.

What do you think?

Jarek

Injection of Bundle/BundleContext into Java EE components

2010-10-21 Thread Jarek Gawor

Hi all,

I was thinking about adding support for injection of
Bundle/BundleContext objects into Java EE components via @Resource
annotation. Example:

class MyServlet extends HttpServlet {
   @Resource
   Bundle bundle;
   @Resource
   BundleContext bundleContext;
   
}

That should make it easier to interact with OSGi within Java EE apps.

I was also thinking of something similar with @Inject for web beans
(cdi stuff) but I'm not really sure it's all that useful since it
should be possible to inject Bundle/BundleContext via @Resource or
combine it with @Produces.

What do you think?

Jarek

[jira] Commented: (GERONIMO-5551) Failing to start the server with the error "Main not found"

2010-10-21 Thread David Jencks (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923601#action_12923601
 ] 

David Jencks commented on GERONIMO-5551:


I've seen this happen on my mac for app clients while running the tck.  
Possibly my disk free space is too fragmented and its really taking java 1 
minute to find enough disk space.

> Failing to start the server with the error "Main not found" 
> 
>
> Key: GERONIMO-5551
> URL: https://issues.apache.org/jira/browse/GERONIMO-5551
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: startup/shutdown
>Affects Versions: 3.0
> Environment: OS: Windows XP SP3
> JDK： SUN JDK 1.6.0_20
>Reporter: Wang Guang Zhe
> Fix For: 3.0
>
>
> Sometimes the Geronimo 3.0 server fails to start with the only error message 
> "Main not found".

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-5468) Support authenticate/login/logout methods in the HttpServletRequest interface

2010-10-21 Thread David Jencks (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks closed GERONIMO-5468.
--

Resolution: Fixed

tomcat accepted my suggestions and I don't see anything obvious more to do with 
this at the moment.

> Support authenticate/login/logout methods in the HttpServletRequest interface
> -
>
> Key: GERONIMO-5468
> URL: https://issues.apache.org/jira/browse/GERONIMO-5468
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 3.0-M1, 3.0
>Reporter: Ivan
>Assignee: Han Hong Fang
> Fix For: 3.0
>
> Attachments: GERONIMO-5468-geronimo-2.diff, 
> GERONIMO-5468-tomcat-fork.diff, GERONIMO-5468-tomcat-original.diff, 
> GERONIMO-5468.patch
>
>
> In Servlet 3.0, authenticate/login/logout methods are added in the 
> HttpServletRequest interface, we need to support them in Geronimo's way.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-5649) txmanager could try to replace dead XAResources in commit and rollback tasks

2010-10-21 Thread David Jencks (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923595#action_12923595
 ] 

David Jencks commented on GERONIMO-5649:


ported to txmanager trunk in rev 1026099

> txmanager could try to replace dead XAResources in commit and rollback tasks
> 
>
> Key: GERONIMO-5649
> URL: https://issues.apache.org/jira/browse/GERONIMO-5649
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: transaction manager
>Affects Versions: 2.2, 3.0
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.2.1, 3.0
>
> Attachments: GERONIMO-5649-1.patch, GERONIMO-5649-2.patch
>
>
> Generally if a RM crashes, outbound connections to it need to be 
> reestablished.  So if we have a in-doubt tx using an outbound connection, we 
> should try to get a new XAResource to finish up the branch in the CommitTask 
> and proposed RollbackTask.
> AFAIK inbound connections will automatically reestablish connections and use 
> the RETRY error code so we don't need to do this for inbound.  I still need 
> to find out which error codes indicate that we should get a new connection 
> and try again.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

New and pending jetty releases

2010-10-21 Thread David Jencks

Jetty has just released 7.2.0.v20101020.  If we could see if we can get it into 
2.2.1 that would be great.

They are thinking about a jetty 8 milestone soon, perhaps next week.  I'm not 
aware of any problems at the moment but will try to make sure there aren't any 
OWB changes needed... hopefully we can use this in g 3.0-M2.

thanks
david jencks

Re: Bean validation tck failures and JNDI contexts

2010-10-21 Thread Rick McGuire


On 10/21/2010 2:33 PM, David Jencks wrote:

yikes...

I didn't study this in detail recently but I wonder if we should add an xbean 
RuntimeNamingException that wraps the NamingException and have 
ContextFederation.getFederatedBindings() unwrap only this runtime exception?
I'm rebuilding Geronimo now to pick up the changes, but here's what I 
added to getFederatedBindings():


// don't overwrite existing bindings
if  (!bindings.containsKey(bindingName)) {
try  {
bindings.put(bindingName,binding.getObject());
}catch  (RuntimeException  e) {
// if this is a wrapped NamingException, unwrap and 
throw the original
Throwable  cause  =e.getCause();
if  (cause  !=null  &&  cause  instanceof  
NamingException  ) {
throw  (NamingException)cause;
}
// Wrap this into a RuntimeException.
throw  (NamingException)new  NamingException("Could 
retrieve bound instance"  +name).initCause(e);
}
}

This unwraps and rethrows a NamingException if it is there and wraps any 
other RuntimeException inside of a NamingException so that only 
NamingExceptions are seen down stream.  I think this should give the 
behavior we need to fix the TCK problems.


Rick


david jencks

On Oct 21, 2010, at 11:10 AM, Rick McGuire wrote:


On 10/21/2010 12:58 PM, David Jencks wrote:

umm...

doing a naming lookup should only throw NamingExceptions so I think what 
should happen is that the reference should wrap the ValidationException in a 
NamingException.  Will this mess up the tck?

This seems like the correct thing to do, but unfortunately, it didn't work.  
The problem is in the xbean ContextUtil$ReadOnlyBinding.getObject() method:

public  Object  getObject() {
try  {
return  resolve(value,getName(),null,context);
}catch  (NamingException  e) {
throw  new  RuntimeException(e);
}
}

This is catching the NamingException and turning it into a RuntimeException.  
This doesn't seem correct to me, but the Binding interface it implements does 
not throw any checked exceptions, so this is the only way this error can get 
reflected back.

Looking at the call chain, I'm thinking that 
ContextFederation.getFederatedBindings() should catch RuntimeExceptions and and 
either turn them into NamingExceptions or just ignore the exception like it 
does with the NotContextExceptions.

Rick


thanks
david jencks

On Oct 21, 2010, at 9:34 AM, David Jencks wrote:


Hi Rick,

The code that does the lookup is here in the jetty integration code: 
(GeronimoWebAppContext near line 104)

try {
javax.naming.Context ctx = integrationContext.getComponentContext();
Object validatorFactory = ctx.lookup("comp/ValidatorFactory");

setAttribute("javax.faces.validator.beanValidator.ValidatorFactory", 
validatorFactory);
} catch (NamingException e) {
// ignore.  We just don't set the property if it's not available.
}


I suspect it used to pass because we were only using default validatory 
factories so we could always create one.  Either that, or we used to throw a 
NamingException when we failed (the code you quote catches a naming 
exception).

I wonder if a better solution would be to also catch and ignore a 
ValidationException here?

thanks
david jencks

On Oct 21, 2010, at 7:55 AM, Rick McGuire wrote:


I played around with different solutions and finally came up with something 
that fixes the problem.  Unfortunately, I'm not sure what I did is legitimate 
or not.  The root problem here is the naming reference implementations were 
throwing ValidationExceptions for any failures with creating a 
ValidatorFactory.  This probably was the behavior that should be implemented, 
but unfortunately, the getFederatedBindings() processing was triggering the 
resolution of these objects and the resulting exceptions were causing deploy 
failures.  The test cases in question were testing the very conditions that 
triggered the exceptions.  The exception was raised, but at deploy time, 
resulting in a test case failure.

I managed to fix this by having the reference objects we bind into jndi catch 
the exceptions and just return null.  Everything is passing in the TCK now, but 
I'm not sure returning null is the correct thing to do here.

I'm not really sure how we every were passing 100% in the container with the 
original code.  I would have thought that if the same sequence of calls were 
getting made to resolve the provider, then some of the same failures would have 
been seen.  I'm going to hold off on committing my changes until I get some 
feedback on this.

Rick

Re: Bean validation tck failures and JNDI contexts

2010-10-21 Thread David Jencks

yikes...

I didn't study this in detail recently but I wonder if we should add an xbean 
RuntimeNamingException that wraps the NamingException and have 
ContextFederation.getFederatedBindings() unwrap only this runtime exception?

david jencks

On Oct 21, 2010, at 11:10 AM, Rick McGuire wrote:

> On 10/21/2010 12:58 PM, David Jencks wrote:
>> umm...
>> 
>> doing a naming lookup should only throw NamingExceptions so I think what 
>> should happen is that the reference should wrap the ValidationException in a 
>> NamingException.  Will this mess up the tck?
> This seems like the correct thing to do, but unfortunately, it didn't work.  
> The problem is in the xbean ContextUtil$ReadOnlyBinding.getObject() method:
> 
>public  Object  getObject() {
>try  {
>return  resolve(value,getName(),null,context);
>}catch  (NamingException  e) {
>throw  new  RuntimeException(e);
>}
>}
> 
> This is catching the NamingException and turning it into a RuntimeException.  
> This doesn't seem correct to me, but the Binding interface it implements does 
> not throw any checked exceptions, so this is the only way this error can get 
> reflected back.
> 
> Looking at the call chain, I'm thinking that 
> ContextFederation.getFederatedBindings() should catch RuntimeExceptions and 
> and either turn them into NamingExceptions or just ignore the exception like 
> it does with the NotContextExceptions.
> 
> Rick
> 
>> thanks
>> david jencks
>> 
>> On Oct 21, 2010, at 9:34 AM, David Jencks wrote:
>> 
>>> Hi Rick,
>>> 
>>> The code that does the lookup is here in the jetty integration code: 
>>> (GeronimoWebAppContext near line 104)
>>> 
>>>try {
>>>javax.naming.Context ctx = 
>>> integrationContext.getComponentContext();
>>>Object validatorFactory = ctx.lookup("comp/ValidatorFactory");
>>>
>>> setAttribute("javax.faces.validator.beanValidator.ValidatorFactory", 
>>> validatorFactory);
>>>} catch (NamingException e) {
>>>// ignore.  We just don't set the property if it's not available.
>>>}
>>> 
>>> 
>>> I suspect it used to pass because we were only using default validatory 
>>> factories so we could always create one.  Either that, or we used to throw 
>>> a NamingException when we failed (the code you quote catches a naming 
>>> exception).
>>> 
>>> I wonder if a better solution would be to also catch and ignore a 
>>> ValidationException here?
>>> 
>>> thanks
>>> david jencks
>>> 
>>> On Oct 21, 2010, at 7:55 AM, Rick McGuire wrote:
>>> 
 I played around with different solutions and finally came up with 
 something that fixes the problem.  Unfortunately, I'm not sure what I did 
 is legitimate or not.  The root problem here is the naming reference 
 implementations were throwing ValidationExceptions for any failures with 
 creating a ValidatorFactory.  This probably was the behavior that should 
 be implemented, but unfortunately, the getFederatedBindings() processing 
 was triggering the resolution of these objects and the resulting 
 exceptions were causing deploy failures.  The test cases in question were 
 testing the very conditions that triggered the exceptions.  The exception 
 was raised, but at deploy time, resulting in a test case failure.
 
 I managed to fix this by having the reference objects we bind into jndi 
 catch the exceptions and just return null.  Everything is passing in the 
 TCK now, but I'm not sure returning null is the correct thing to do here.
 
 I'm not really sure how we every were passing 100% in the container with 
 the original code.  I would have thought that if the same sequence of 
 calls were getting made to resolve the provider, then some of the same 
 failures would have been seen.  I'm going to hold off on committing my 
 changes until I get some feedback on this.
 
 Rick
 
 On 10/21/2010 7:48 AM, Rick McGuire wrote:
> We're down to 13 bean validation failures in the tck now, but these 
> failures are a little puzzling.   The tests in error are all giving 
> deploy failures, with the root cause being an exception triggered by 
> getFederatedBindings():
> 
> java.lang.RuntimeException: javax.naming.NamingException: Validator [Root 
> exception is javax.validation.ValidationException: Unable to find 
> suitable provider: class 
> org.hibernate.jsr303.tck.common.TCKValidationProvider]
>   at 
> org.apache.xbean.naming.context.ContextUtil$ReadOnlyBinding.getObject(ContextUtil.java:201)
>   at 
> org.apache.xbean.naming.context.ContextFederation.getFederatedBindings(ContextFederation.java:118)
>   at 
> org.apache.xbean.naming.context.AbstractFederatedContext.getBindings(AbstractFederatedContext.java:99)
>   at 
> org.apache.xbean.naming.context.AbstractFederate

Re: Bean validation tck failures and JNDI contexts

2010-10-21 Thread Rick McGuire


On 10/21/2010 12:58 PM, David Jencks wrote:

umm...

doing a naming lookup should only throw NamingExceptions so I think what 
should happen is that the reference should wrap the ValidationException in a 
NamingException.  Will this mess up the tck?
This seems like the correct thing to do, but unfortunately, it didn't 
work.  The problem is in the xbean 
ContextUtil$ReadOnlyBinding.getObject() method:


public  Object  getObject() {
try  {
return  resolve(value,getName(),null,context);
}catch  (NamingException  e) {
throw  new  RuntimeException(e);
}
}

This is catching the NamingException and turning it into a 
RuntimeException.  This doesn't seem correct to me, but the Binding 
interface it implements does not throw any checked exceptions, so this 
is the only way this error can get reflected back.


Looking at the call chain, I'm thinking that 
ContextFederation.getFederatedBindings() should catch RuntimeExceptions 
and and either turn them into NamingExceptions or just ignore the 
exception like it does with the NotContextExceptions.


Rick


thanks
david jencks

On Oct 21, 2010, at 9:34 AM, David Jencks wrote:


Hi Rick,

The code that does the lookup is here in the jetty integration code: 
(GeronimoWebAppContext near line 104)

try {
javax.naming.Context ctx = integrationContext.getComponentContext();
Object validatorFactory = ctx.lookup("comp/ValidatorFactory");

setAttribute("javax.faces.validator.beanValidator.ValidatorFactory", 
validatorFactory);
} catch (NamingException e) {
// ignore.  We just don't set the property if it's not available.
}


I suspect it used to pass because we were only using default validatory 
factories so we could always create one.  Either that, or we used to throw a 
NamingException when we failed (the code you quote catches a naming 
exception).

I wonder if a better solution would be to also catch and ignore a 
ValidationException here?

thanks
david jencks

On Oct 21, 2010, at 7:55 AM, Rick McGuire wrote:


I played around with different solutions and finally came up with something 
that fixes the problem.  Unfortunately, I'm not sure what I did is legitimate 
or not.  The root problem here is the naming reference implementations were 
throwing ValidationExceptions for any failures with creating a 
ValidatorFactory.  This probably was the behavior that should be implemented, 
but unfortunately, the getFederatedBindings() processing was triggering the 
resolution of these objects and the resulting exceptions were causing deploy 
failures.  The test cases in question were testing the very conditions that 
triggered the exceptions.  The exception was raised, but at deploy time, 
resulting in a test case failure.

I managed to fix this by having the reference objects we bind into jndi catch 
the exceptions and just return null.  Everything is passing in the TCK now, but 
I'm not sure returning null is the correct thing to do here.

I'm not really sure how we every were passing 100% in the container with the 
original code.  I would have thought that if the same sequence of calls were 
getting made to resolve the provider, then some of the same failures would have 
been seen.  I'm going to hold off on committing my changes until I get some 
feedback on this.

Rick

On 10/21/2010 7:48 AM, Rick McGuire wrote:

We're down to 13 bean validation failures in the tck now, but these failures 
are a little puzzling.   The tests in error are all giving deploy failures, 
with the root cause being an exception triggered by getFederatedBindings():

java.lang.RuntimeException: javax.naming.NamingException: Validator [Root 
exception is javax.validation.ValidationException: Unable to find suitable 
provider: class org.hibernate.jsr303.tck.common.TCKValidationProvider]
   at 
org.apache.xbean.naming.context.ContextUtil$ReadOnlyBinding.getObject(ContextUtil.java:201)
   at 
org.apache.xbean.naming.context.ContextFederation.getFederatedBindings(ContextFederation.java:118)
   at 
org.apache.xbean.naming.context.AbstractFederatedContext.getBindings(AbstractFederatedContext.java:99)
   at 
org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(AbstractFederatedContext.java:86)
   at 
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:133)
   at 
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:605)
   at 
org.apache.geronimo.jetty8.handler.GeronimoWebAppContext.(GeronimoWebAppContext.java:104)
   at 
org.apache.geronimo.jetty8.WebAppContextWrapper.(WebAppContextWrapper.java:211)
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
   at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Delegati

Re: Bean validation tck failures and JNDI contexts

2010-10-21 Thread Rick McGuire


On 10/21/2010 12:34 PM, David Jencks wrote:

Hi Rick,

The code that does the lookup is here in the jetty integration code: 
(GeronimoWebAppContext near line 104)

 try {
 javax.naming.Context ctx = 
integrationContext.getComponentContext();
 Object validatorFactory = ctx.lookup("comp/ValidatorFactory");
 
setAttribute("javax.faces.validator.beanValidator.ValidatorFactory", 
validatorFactory);
 } catch (NamingException e) {
 // ignore.  We just don't set the property if it's not available.
 }


I suspect it used to pass because we were only using default validatory 
factories so we could always create one.  Either that, or we used to throw a 
NamingException when we failed (the code you quote catches a naming 
exception).
Ah, I hadn't checked to see what was triggering the call.  Yes, that 
could be a simpler solution to this problem.  I'll give that a try.


Rick


I wonder if a better solution would be to also catch and ignore a 
ValidationException here?

thanks
david jencks

On Oct 21, 2010, at 7:55 AM, Rick McGuire wrote:


I played around with different solutions and finally came up with something 
that fixes the problem.  Unfortunately, I'm not sure what I did is legitimate 
or not.  The root problem here is the naming reference implementations were 
throwing ValidationExceptions for any failures with creating a 
ValidatorFactory.  This probably was the behavior that should be implemented, 
but unfortunately, the getFederatedBindings() processing was triggering the 
resolution of these objects and the resulting exceptions were causing deploy 
failures.  The test cases in question were testing the very conditions that 
triggered the exceptions.  The exception was raised, but at deploy time, 
resulting in a test case failure.

I managed to fix this by having the reference objects we bind into jndi catch 
the exceptions and just return null.  Everything is passing in the TCK now, but 
I'm not sure returning null is the correct thing to do here.

I'm not really sure how we every were passing 100% in the container with the 
original code.  I would have thought that if the same sequence of calls were 
getting made to resolve the provider, then some of the same failures would have 
been seen.  I'm going to hold off on committing my changes until I get some 
feedback on this.

Rick

On 10/21/2010 7:48 AM, Rick McGuire wrote:

We're down to 13 bean validation failures in the tck now, but these failures 
are a little puzzling.   The tests in error are all giving deploy failures, 
with the root cause being an exception triggered by getFederatedBindings():

java.lang.RuntimeException: javax.naming.NamingException: Validator [Root 
exception is javax.validation.ValidationException: Unable to find suitable 
provider: class org.hibernate.jsr303.tck.common.TCKValidationProvider]
at 
org.apache.xbean.naming.context.ContextUtil$ReadOnlyBinding.getObject(ContextUtil.java:201)
at 
org.apache.xbean.naming.context.ContextFederation.getFederatedBindings(ContextFederation.java:118)
at 
org.apache.xbean.naming.context.AbstractFederatedContext.getBindings(AbstractFederatedContext.java:99)
at 
org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(AbstractFederatedContext.java:86)
at 
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:133)
at 
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:605)
at 
org.apache.geronimo.jetty8.handler.GeronimoWebAppContext.(GeronimoWebAppContext.java:104)
at 
org.apache.geronimo.jetty8.WebAppContextWrapper.(WebAppContextWrapper.java:211)
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: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:271)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)


The root cause of this failure is an exception in 
DefaultValidatorReference.getContent():

@Override
public  Object  getContent()throws  NamingException  {
ValidatorFactory  factory  =null;
try  {

Re: Bean validation tck failures and JNDI contexts

2010-10-21 Thread David Jencks

umm...

doing a naming lookup should only throw NamingExceptions so I think what 
should happen is that the reference should wrap the ValidationException in a 
NamingException.  Will this mess up the tck?

thanks
david jencks

On Oct 21, 2010, at 9:34 AM, David Jencks wrote:

> Hi Rick,
> 
> The code that does the lookup is here in the jetty integration code: 
> (GeronimoWebAppContext near line 104)
> 
>try {
>javax.naming.Context ctx = 
> integrationContext.getComponentContext();
>Object validatorFactory = ctx.lookup("comp/ValidatorFactory");
>
> setAttribute("javax.faces.validator.beanValidator.ValidatorFactory", 
> validatorFactory);
>} catch (NamingException e) {
>// ignore.  We just don't set the property if it's not available.
>}
> 
> 
> I suspect it used to pass because we were only using default validatory 
> factories so we could always create one.  Either that, or we used to throw a 
> NamingException when we failed (the code you quote catches a naming 
> exception).
> 
> I wonder if a better solution would be to also catch and ignore a 
> ValidationException here?
> 
> thanks
> david jencks
> 
> On Oct 21, 2010, at 7:55 AM, Rick McGuire wrote:
> 
>> I played around with different solutions and finally came up with something 
>> that fixes the problem.  Unfortunately, I'm not sure what I did is 
>> legitimate or not.  The root problem here is the naming reference 
>> implementations were throwing ValidationExceptions for any failures with 
>> creating a ValidatorFactory.  This probably was the behavior that should be 
>> implemented, but unfortunately, the getFederatedBindings() processing was 
>> triggering the resolution of these objects and the resulting exceptions were 
>> causing deploy failures.  The test cases in question were testing the very 
>> conditions that triggered the exceptions.  The exception was raised, but at 
>> deploy time, resulting in a test case failure.
>> 
>> I managed to fix this by having the reference objects we bind into jndi 
>> catch the exceptions and just return null.  Everything is passing in the TCK 
>> now, but I'm not sure returning null is the correct thing to do here.
>> 
>> I'm not really sure how we every were passing 100% in the container with the 
>> original code.  I would have thought that if the same sequence of calls were 
>> getting made to resolve the provider, then some of the same failures would 
>> have been seen.  I'm going to hold off on committing my changes until I get 
>> some feedback on this.
>> 
>> Rick
>> 
>> On 10/21/2010 7:48 AM, Rick McGuire wrote:
>>> We're down to 13 bean validation failures in the tck now, but these 
>>> failures are a little puzzling.   The tests in error are all giving deploy 
>>> failures, with the root cause being an exception triggered by 
>>> getFederatedBindings():
>>> 
>>> java.lang.RuntimeException: javax.naming.NamingException: Validator [Root 
>>> exception is javax.validation.ValidationException: Unable to find suitable 
>>> provider: class org.hibernate.jsr303.tck.common.TCKValidationProvider]
>>>   at 
>>> org.apache.xbean.naming.context.ContextUtil$ReadOnlyBinding.getObject(ContextUtil.java:201)
>>>   at 
>>> org.apache.xbean.naming.context.ContextFederation.getFederatedBindings(ContextFederation.java:118)
>>>   at 
>>> org.apache.xbean.naming.context.AbstractFederatedContext.getBindings(AbstractFederatedContext.java:99)
>>>   at 
>>> org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(AbstractFederatedContext.java:86)
>>>   at 
>>> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:133)
>>>   at 
>>> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:605)
>>>   at 
>>> org.apache.geronimo.jetty8.handler.GeronimoWebAppContext.(GeronimoWebAppContext.java:104)
>>>   at 
>>> org.apache.geronimo.jetty8.WebAppContextWrapper.(WebAppContextWrapper.java:211)
>>>   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: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:27

Re: Bean validation tck failures and JNDI contexts

2010-10-21 Thread David Jencks

Hi Rick,

The code that does the lookup is here in the jetty integration code: 
(GeronimoWebAppContext near line 104)

try {
javax.naming.Context ctx = integrationContext.getComponentContext();
Object validatorFactory = ctx.lookup("comp/ValidatorFactory");

setAttribute("javax.faces.validator.beanValidator.ValidatorFactory", 
validatorFactory);
} catch (NamingException e) {
// ignore.  We just don't set the property if it's not available.
}


I suspect it used to pass because we were only using default validatory 
factories so we could always create one.  Either that, or we used to throw a 
NamingException when we failed (the code you quote catches a naming 
exception).

I wonder if a better solution would be to also catch and ignore a 
ValidationException here?

thanks
david jencks

On Oct 21, 2010, at 7:55 AM, Rick McGuire wrote:

> I played around with different solutions and finally came up with something 
> that fixes the problem.  Unfortunately, I'm not sure what I did is legitimate 
> or not.  The root problem here is the naming reference implementations were 
> throwing ValidationExceptions for any failures with creating a 
> ValidatorFactory.  This probably was the behavior that should be implemented, 
> but unfortunately, the getFederatedBindings() processing was triggering the 
> resolution of these objects and the resulting exceptions were causing deploy 
> failures.  The test cases in question were testing the very conditions that 
> triggered the exceptions.  The exception was raised, but at deploy time, 
> resulting in a test case failure.
> 
> I managed to fix this by having the reference objects we bind into jndi catch 
> the exceptions and just return null.  Everything is passing in the TCK now, 
> but I'm not sure returning null is the correct thing to do here.
> 
> I'm not really sure how we every were passing 100% in the container with the 
> original code.  I would have thought that if the same sequence of calls were 
> getting made to resolve the provider, then some of the same failures would 
> have been seen.  I'm going to hold off on committing my changes until I get 
> some feedback on this.
> 
> Rick
> 
> On 10/21/2010 7:48 AM, Rick McGuire wrote:
>> We're down to 13 bean validation failures in the tck now, but these failures 
>> are a little puzzling.   The tests in error are all giving deploy failures, 
>> with the root cause being an exception triggered by getFederatedBindings():
>> 
>> java.lang.RuntimeException: javax.naming.NamingException: Validator [Root 
>> exception is javax.validation.ValidationException: Unable to find suitable 
>> provider: class org.hibernate.jsr303.tck.common.TCKValidationProvider]
>>at 
>> org.apache.xbean.naming.context.ContextUtil$ReadOnlyBinding.getObject(ContextUtil.java:201)
>>at 
>> org.apache.xbean.naming.context.ContextFederation.getFederatedBindings(ContextFederation.java:118)
>>at 
>> org.apache.xbean.naming.context.AbstractFederatedContext.getBindings(AbstractFederatedContext.java:99)
>>at 
>> org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(AbstractFederatedContext.java:86)
>>at 
>> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:133)
>>at 
>> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:605)
>>at 
>> org.apache.geronimo.jetty8.handler.GeronimoWebAppContext.(GeronimoWebAppContext.java:104)
>>at 
>> org.apache.geronimo.jetty8.WebAppContextWrapper.(WebAppContextWrapper.java:211)
>>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: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:271)
>>at 
>> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
>> 
>> 
>> The root cause of this failure is an exception in 
>> DefaultValidatorReference.getContent():
>> 
>>@Override
>>public  Object  getContent()throws  NamingException  {
>>ValidatorFactory  factory  =null;
>>try  {
>>factory  =

Re: Bean validation tck failures and JNDI contexts

2010-10-21 Thread Rick McGuire

I played around with different solutions and finally came up with 
something that fixes the problem.  Unfortunately, I'm not sure what I 
did is legitimate or not.  The root problem here is the naming reference 
implementations were throwing ValidationExceptions for any failures with 
creating a ValidatorFactory.  This probably was the behavior that should 
be implemented, but unfortunately, the getFederatedBindings() processing 
was triggering the resolution of these objects and the resulting 
exceptions were causing deploy failures.  The test cases in question 
were testing the very conditions that triggered the exceptions.  The 
exception was raised, but at deploy time, resulting in a test case failure.


I managed to fix this by having the reference objects we bind into jndi 
catch the exceptions and just return null.  Everything is passing in the 
TCK now, but I'm not sure returning null is the correct thing to do here.


I'm not really sure how we every were passing 100% in the container with 
the original code.  I would have thought that if the same sequence of 
calls were getting made to resolve the provider, then some of the same 
failures would have been seen.  I'm going to hold off on committing my 
changes until I get some feedback on this.


Rick

On 10/21/2010 7:48 AM, Rick McGuire wrote:
We're down to 13 bean validation failures in the tck now, but these 
failures are a little puzzling.   The tests in error are all giving 
deploy failures, with the root cause being an exception triggered by 
getFederatedBindings():


java.lang.RuntimeException: javax.naming.NamingException: Validator 
[Root exception is javax.validation.ValidationException: Unable to 
find suitable provider: class 
org.hibernate.jsr303.tck.common.TCKValidationProvider]
at 
org.apache.xbean.naming.context.ContextUtil$ReadOnlyBinding.getObject(ContextUtil.java:201)
at 
org.apache.xbean.naming.context.ContextFederation.getFederatedBindings(ContextFederation.java:118)
at 
org.apache.xbean.naming.context.AbstractFederatedContext.getBindings(AbstractFederatedContext.java:99)
at 
org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(AbstractFederatedContext.java:86)
at 
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:133)
at 
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:605)
at 
org.apache.geronimo.jetty8.handler.GeronimoWebAppContext.(GeronimoWebAppContext.java:104)
at 
org.apache.geronimo.jetty8.WebAppContextWrapper.(WebAppContextWrapper.java:211)
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: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:271)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)



The root cause of this failure is an exception in 
DefaultValidatorReference.getContent():


@Override
public  Object  getContent()throws  NamingException  {
ValidatorFactory  factory  =null;
try  {
factory  = (ValidatorFactory)new  
InitialContext().lookup("java:comp/ValidatorFactory");

}catch(NamingException  e) {
factory  =Validation.buildDefaultValidatorFactory();
}
return  factory.getValidator();
}

The root cause of this failure is the NamingException on the .lookup() 
call.  Since this occurs during the building of the federated context, 
I suspect the initial context is not initialized correctly at this 
phase.  There's a bit of a chicken-and-egg problem here.  The 
buildDefaultValidatorFactory() call is failing because the incorrect 
thread context classloader is getting used to resolve the provider.


The puzzling piece to me is why this process is making the 
getContent() calls in the first place.  Since this binding will create 
a new instance each time it is requested, either A) an instance is 
getting created needlessly and thrown away or B) this instance is 
ending up bound to the JNDI context as a one-off, which would be an 
incorrect result.


I think I can fix this by making the DefaultValidatorReference look up 
the Vali

[BUILD] trunk: Failed for Revision: 1025987

2010-10-21 Thread gawor

Geronimo Revision: 1025987 built with tests included
 
See the full build-0900.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021/build-0900.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 38 minutes 22 seconds
[INFO] Finished at: Thu Oct 21 09:41:54 EDT 2010
[INFO] Final Memory: 456M/1007M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021/logs-0900-tomcat/
 
 
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar: 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/corba-marshal-client-3.0-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[WARNING] Skipping verification of legal files in artifacts:
[WARNING] 
org.apache.geronimo.testsuite:corba-marshal-client:jar:3.0-SNAPSHOT
[INFO] [install:install {execution: default-install}]
[INFO] Installing 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/corba-marshal-client-3.0-SNAPSHOT.jar
 to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/corba-marshal-client/3.0-SNAPSHOT/corba-marshal-client-3.0-SNAPSHOT.jar
[INFO] 
[INFO] Building Geronimo TestSuite :: CORBA TestSuite :: Marshal EAR
[INFO]task-segment: [install]
[INFO] 
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [geronimo-property:set-property {execution: set-property}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [ear:generate-application-xml {execution: 
default-generate-application-xml}]
[INFO] Generating application.xml
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/src/main/resources
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] [ear:ear {execution: default-ear}]
[INFO] Copying 
artifact[ejb:org.apache.geronimo.testsuite:corba-marshal-ejb:3.0-SNAPSHOT] 
to[corba-marshal-ejb-3.0-SNAPSHOT.jar]
[INFO] Copying 
artifact[jar:org.apache.geronimo.testsuite:corba-marshal-client:3.0-SNAPSHOT] 
to[corba-marshal-client-3.0-SNAPSHOT.jar]
[INFO] Copy ear resources to 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/target/corba-marshal-ear-3.0-SNAPSHOT
[INFO] Could not find manifest file: 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/src/main/application/META-INF/MANIFEST.MF
 - Generating one
[INFO] Building jar: 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/target/corba-marshal-ear-3.0-SNAPSHOT.ear
[INFO] [geronimo:start-server {execution: start-geronimo}]
[INFO] Using assembly configuration: tomcat
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-tomcat7-javaee6:zip:bin:3.0-SNAPSHOT:provided
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/target/geronimo-tomcat7-javaee6-3.0-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6/3.0-SNAPSHOT/geronimo-tomcat7-javaee6-3.0-SNAPSHOT-bin.zip
 into 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Initialized with URL: 
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector, 
environment: {jmx.remote.credentials=[Ljava.lang.String;@1f35aaa}
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: 
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; 
ignoring: java.io.IOException: Failed to retrieve RMIServer stub: 
javax.naming.ServiceUnavailableException [Root ex

Re: Welcome "Janet" Hong Fang Han as a new committer

2010-10-21 Thread Ted Kirby

Congratulations Janet!  Welcome aboard!

Ted

On Wed, Oct 20, 2010 at 9:11 PM, Ivan  wrote:
> I would like to welcome Janet aboard, as she recently accepted the Geronimo
> PMC invitation to become a committer.  Her account was just created this
> morning (hanhongfang), so you should start seeing some commits from her
> soon.
> --
> Ivan
>

Re: Is it possible to make those xml digest class serializable ?

2010-10-21 Thread Jakob Korherr

Hi Ivan,

Actually the ApplicationMap is only a "wrapper" of the ServletContext
attributes, thus you get the same Map from any Faces-/ExternalContext
(regardless if startup, shutdown or request).

Thus if you put your SPI instance(s) on the ServletContext attributes
Map, we can pick them up via the Application Map.

Regards,
Jakob

2010/10/21 Ivan :
> Forgot to use reply all :-)
>
> Thanks, please help to check my comments below.
>
> 2010/10/20 Leonardo Uribe 
>>
>> Hi
>>
>> Some answers to your post below:
>>
>> IV>> Just some ideas for the integration improvment, please help to give
>> some comments.
>>
>> IV>> a. Create a new SPI provider and a provider factory, might name
>> FacesConfigurationProvider/
>> IV>> FacesConfigurationProviderFactory, which has a method
>> IV>>  FacesConfig getFacesConfig(ExternalContext context);
>> IV>>    This method is designed to get the final combined the FacesConfig
>> instance, which including
>> IV>> application resource configuration + annotation + default web
>> application resource
>> IV>>  And move those logic about merge/annotaiton scanning from
>> FacesConfigurator and
>> IV>> AnnotationConfigurator to the default implementation provider
>>
>> Yes, it could be good to have another SPI provider in this case, but I
>> don't know how that interface should
>> looks like. In theory, at some point we have a consolidate FacesConfig,
>> but without the annotation information.
>> The reason is not all information provided by annotations is on
>> faces-config.xml format.
>
>     The SPI name might not be proper, I am thinking that, for JSF core, it
> might not care there is some information in the xml files, and others might
> be from annotation. Guess she will say to the deployer : hey, just give me
> the final application configuration files, I have no interest where it is
> from ;-) So I hope to seperate those sort/combine logic from the
> FacesConfigurator.
>>
>> IV>> b. Make some classes in the
>> org.apache.myfaces.config.impl.digester.elements package serializable,
>> IV>> this might be optional...
>> IV>> From the integration side, the third-party container could implement
>> their own
>> IV>> FacesConfigurationProvider, they might return the FacesConfig object
>> directly from their own structure.
>>
>> Yes, it could be good to provide a way to expose that configuration
>> information.
>>
>> IV>> c. I saw some codes in the ***ProviderFactory is commented out,
>> IV>>    //AnnotationProviderFactory instance = (AnnotationProviderFactory)
>> ctx.getApplicationMap().get(FACTORY_KEY);
>> IV>>        //if (instance != null)
>> IV>>        //{
>> IV>>        //    return instance;
>> IV>>        //}
>> IV>>   Did it cause any issue ? Or I hope to recover them, as it will be
>> more easier to set other implemtations
>> IV>> for other containers. The commons-discovery package might not work
>> correctly in OSGI environment. as they
>> IV>> will try to search META-INF/services folder, and this way sometimes
>> might not work correctly in OSGi environment.
>> IV>> thanks.
>> I commented that code because AnnotationProviderFactory,
>> FaceletConfigResourceProviderFactory
>> and FacesConfigResourceProviderFactory are only used once in the
>> application lifetime (during initialization)
>> so it does not have sense to put them on application map.
>>
>> In theory, it should work even in OSGi. The reason is to JSF work
>> correctly in OSGi, it should be provided a
>> ThreadContextClassLoader (TCCL) that could find resources all bundles that
>> the web application uses. That's necessary
>> to make javax.faces.FactoryFinder class work correctly, and it is know
>> that libraries like SpringDM, or containers like
>> GlassFish do that to keep code working. Unfortunately, there is no other
>> option because by the spec it is not possible to
>> change the way FactoryFinder works (I can't add a BundleActivator on
>> myfaces-api.jar because this class is public-api).
>
>
>    Yes, I agree that it might work, and just need to place one configuration
> file in a righ place. But I would prefer to set it programically, and make
> sure it could be definitely configured, and no other unexpected files would
> be found, e.g. If the users place some configuration files in their own app
> etc.
>    I looked at the codes in the AbstractFacesInitializer, some methods like
>
>    private FacesContext _createFacesContext(ServletContext
> servletContext, boolean startup)
>    public void destroyStartupFacesContext(FacesContext facesContext)
>   Also in the StartupServletContextListener, I found the FacesContext for
> startup is released. So seems that MyFaces will create FacesContext for
> startup use only. Guess that it might be OK to put in the applicationMap of
> startup externalContext ?
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>> 2010/10/20 Ivan 
>>>
>>> Hi, devs, I posted some initial ideas to MYFACES-2945, and very
>>> appriciated with any comment :-) Once we have final result, I will

Bean validation tck failures and JNDI contexts

2010-10-21 Thread Rick McGuire

We're down to 13 bean validation failures in the tck now, but these 
failures are a little puzzling.   The tests in error are all giving 
deploy failures, with the root cause being an exception triggered by 
getFederatedBindings():


java.lang.RuntimeException: javax.naming.NamingException: Validator [Root 
exception is javax.validation.ValidationException: Unable to find suitable 
provider: class org.hibernate.jsr303.tck.common.TCKValidationProvider]
at 
org.apache.xbean.naming.context.ContextUtil$ReadOnlyBinding.getObject(ContextUtil.java:201)
at 
org.apache.xbean.naming.context.ContextFederation.getFederatedBindings(ContextFederation.java:118)
at 
org.apache.xbean.naming.context.AbstractFederatedContext.getBindings(AbstractFederatedContext.java:99)
at 
org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(AbstractFederatedContext.java:86)
at 
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:133)
at 
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:605)
at 
org.apache.geronimo.jetty8.handler.GeronimoWebAppContext.(GeronimoWebAppContext.java:104)
at 
org.apache.geronimo.jetty8.WebAppContextWrapper.(WebAppContextWrapper.java:211)
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: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:271)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)


The root cause of this failure is an exception in 
DefaultValidatorReference.getContent():


@Override
public  Object  getContent()throws  NamingException  {
ValidatorFactory  factory  =null;

try  {

factory  = (ValidatorFactory)new  
InitialContext().lookup("java:comp/ValidatorFactory");
}catch(NamingException  e) {
factory  =Validation.buildDefaultValidatorFactory();
}

return  factory.getValidator();

}

The root cause of this failure is the NamingException on the .lookup() 
call.  Since this occurs during the building of the federated context, I 
suspect the initial context is not initialized correctly at this phase.  
There's a bit of a chicken-and-egg problem here.  The 
buildDefaultValidatorFactory() call is failing because the incorrect 
thread context classloader is getting used to resolve the provider.


The puzzling piece to me is why this process is making the getContent() 
calls in the first place.  Since this binding will create a new instance 
each time it is requested, either A) an instance is getting created 
needlessly and thrown away or B) this instance is ending up bound to the 
JNDI context as a one-off, which would be an incorrect result.


I think I can fix this by making the DefaultValidatorReference look up 
the ValidatorFactoryGBean to obtain the factory used to create the 
ValidatorInstance rather than doing a jndi lookup, but I want to verify 
that the lookup occurring at this point is the correct behavior and 
there's not a better solution available.


Rick

[jira] Assigned: (GERONIMO-5284) Redeploy of Blog sample fails

2010-10-21 Thread Shawn Jiang (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shawn Jiang reassigned GERONIMO-5284:
-

Assignee: Shawn Jiang

> Redeploy of Blog sample fails
> -
>
> Key: GERONIMO-5284
> URL: https://issues.apache.org/jira/browse/GERONIMO-5284
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 3.0
>Reporter: Kevan Miller
>Assignee: Shawn Jiang
> Fix For: 3.0
>
>
> running redeploy of the blog sample fails as follows:
> $ ./deploy redeploy 
> ../../samples/org.apache.aries.samples.blog.jpa.eba-0.1-incubating.eba 
> Using GERONIMO_HOME:   /Users/kevan/Demo/geronimo-tomcat7-javaee6-3.0-SNAPSHOT
> Using GERONIMO_TMPDIR: var/temp
> Using JRE_HOME:
> /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
> No ModuleID or TargetModuleID provided.  Attempting to guess based
> on the content of the archive.
> Unable to locate Geronimo deployment plan in archive.  Calculating
> default ModuleID from archive name.
> Attempting to use ModuleID
> 'default/org.apache.aries.samples.blog.jpa.eba-0.1-incubating//'
> 2010-05-04 11:28:56,187 ERROR [DeployTool] Error: 
> org.apache.geronimo.common.DeploymentException: 
> default/org.apache.aries.samples.blog.jpa.eba-0.1-incubating// does not 
> appear to be a the name of a module available on the selected server. Perhaps 
> it has already been stopped or undeployed?  If you're trying to specify a 
> TargetModuleID, use the syntax TargetName|ModuleName instead. If you're not 
> sure what's running, try the list-modules command.
> at 
> org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:207)
> at 
> org.apache.geronimo.deployment.cli.CommandRedeploy.execute(CommandRedeploy.java:353)
> at 
> org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:173)
> at 
> org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64)
> at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65)
> at 
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
> at 
> org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-5488) inPlace deployment fails

2010-10-21 Thread Shawn Jiang (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shawn Jiang closed GERONIMO-5488.
-

Resolution: Duplicate

duplicated with following jira.

https://issues.apache.org/jira/browse/GERONIMO-5658

> inPlace deployment fails
> 
>
> Key: GERONIMO-5488
> URL: https://issues.apache.org/jira/browse/GERONIMO-5488
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 3.0-M1
> Environment: Windows 7
>Reporter: Gursel Koca
>
> https://cwiki.apache.org/GMOxDOC22/quick-start-apache-geronimo-for-the-impatient.html#Quickstart-ApacheGeronimofortheimpatient-Creatinganddeployingasampleapplication
>   , while trying to deploy this sample application with inPlace option, I 
> have got below exception ;
> 2010-07-30 15:34:17,318 ERROR [DeployTool] Error:
> org.apache.geronimo.common.DeploymentException: Unable to deploy 
> simplewebapp: U
> nable to create configuration for deployment: dependencies: null
> Unable to cache bundle: 
> reference:file:/C:/Users/GURSEL~1/AppData/Local/
> Temp/geronimo-fileutils3898612084313656863.tmpfile
> error in opening zip file
> at 
> org.apache.geronimo.deployment.cli.CommandDeploy.runCommand(CommandDe
> ploy.java:43)
> at 
> org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(Co
> mmandDistribute.java:148)
> at 
> org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandD
> istribute.java:124)
> at 
> org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java
> :173)
> at 
> org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64
> )
> at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65)
> at 
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
> at 
> org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31
> )

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [BUILD] trunk: Failed for Revision: 1025806

2010-10-21 Thread Rick McGuire


On 10/20/2010 10:07 PM, Shawn Jiang wrote:

Just deployed geronimo-jaspi:jar and geronimo-jaspi:jar:tests to fix this.
Sorry, I thought I had already deployed the new snapshot.  Thanks for 
handling that.


Rick


On Thu, Oct 21, 2010 at 9:47 AM, > wrote:


Geronimo Revision: 1025806 built with tests included

See the full build-2100.log file at

http://people.apache.org/builds/geronimo/server/binaries/trunk/20101020/build-2100.log


See the unit test reports at

http://people.apache.org/builds/geronimo/server/binaries/trunk/20101020/unit-test-reports

   1)
org.apache.geronimo.modules:geronimo-jetty8-builder:bundle:3.0-SNAPSHOT
   2)
org.apache.geronimo.components:geronimo-jaspi:jar:tests:1.2-SNAPSHOT



[INFO]

[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error
transferring file: Server returned HTTP response code: 502 for
URL:

http://repository.apache.org/snapshots/org/apache/geronimo/components/geronimo-jaspi/1.2-SNAPSHOT/geronimo-jaspi-1.2-20101020.151015-1-tests.jar
 org.apache.geronimo.components:geronimo-jaspi:jar:1.2-20101020.151015-1

from the specified remote repositories:
 apache.snapshots (http://repository.apache.org/snapshots),
 codehaus.snapshots (http://snapshots.repository.codehaus.org),
 openqa-snapshots
(http://nexus.openqa.org/content/repositories/snapshots),
 local (file:///home/geronimo/.m2/jtidy.repository),
ibiblio.org 
(http://maven.rtp.raleigh.ibm.com/nexus-proxy/),
 java.net.2 (http://download.java.net/maven/1/),
jetty.oss.sonatype.org 
(http://oss.sonatype.org/content/repositories/jetty/),
 openqa-releases
(http://nexus.openqa.org/content/repositories/releases),
 smx.svn (http://svn.apache.org/repos/asf/servicemix/m2-repo/)

Path to dependency:
   1)
org.apache.geronimo.modules:geronimo-jetty8-builder:bundle:3.0-SNAPSHOT
   2)
org.apache.geronimo.components:geronimo-jaspi:jar:tests:1.2-SNAPSHOT


   at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711)
   at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
   at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
   at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
   at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
   at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
   at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
   at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
   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:597)
   at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by:
org.apache.maven.artifact.resolver.ArtifactResolutionException:
Error transferring file: Server returned HTTP response code: 502
for URL:

http://repository.apache.org/snapshots/org/apache/geronimo/components/geronimo-jaspi/1.2-SNAPSHOT/geronimo-jaspi-1.2-20101020.151015-1-tests.jar
 org.apache.geronimo.components:geronimo-jaspi:jar:1.2-20101020.151015-1

from the specified remote repositories:
 apache.snapshots (http://repository.apache.org/snapshots),
 codehaus.snapshots (http://snapshots.repository.codehaus.org),
 openqa-snapshots
(http://nexus.openqa.org/content/repositories/snapshots),
 local (file:///home/geronimo/.m2/jtidy.repository),
ibiblio.org 
(http://maven.rtp.raleigh.ibm.com/nexus-proxy/),
 java.net.2 (http://download.java.net/maven/1/),
jetty.oss.sonatype.org 
(http://oss.sonatype.org/content/repositories/jetty/),
 openqa-releases
(http://nexus.openqa.org/content/repositories/releases),
 smx.svn (http://svn.apache.org/rep

[jira] Commented: (GERONIMO-5089) Reorganize the Geronimo console and rebase on Pluto 2.

2010-10-21 Thread Shawn Jiang (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-5089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923378#action_12923378
 ] 

Shawn Jiang commented on GERONIMO-5089:
---

"Reorganize the Geronimo console" have been completed with GERONIMO-4950 .   I 
believe the two sub-task could also be closed ?

> Reorganize the Geronimo console and rebase on Pluto 2. 
> ---
>
> Key: GERONIMO-5089
> URL: https://issues.apache.org/jira/browse/GERONIMO-5089
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console, javaee6
>Affects Versions: 3.0
>Reporter: Rick McGuire
> Fix For: 3.0
>
>
> This new release is a good opportunity to redo the console and convert to a 
> Pluto 2 portal version. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-5631) Can NOT find meta class & can NOT insert record in the table

2010-10-21 Thread Shawn Jiang (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923375#action_12923375
 ] 

Shawn Jiang commented on GERONIMO-5631:
---

Please add following in your root pom build section.  This will generate the 
metamodel for you at the build time.

   
org.apache.maven.plugins
maven-compiler-plugin
2.3.2

  -Aopenjpa.metamodel=true

  


> Can NOT find meta class & can NOT insert record in the table
> 
>
> Key: GERONIMO-5631
> URL: https://issues.apache.org/jira/browse/GERONIMO-5631
> Project: Geronimo
>  Issue Type: Test
>  Security Level: public(Regular issues) 
>  Components: persistence
>Affects Versions: 3.0
>Reporter: LiWenQin
>Assignee: Shawn Jiang
> Attachments: jpa2.0-test.7z
>
>
> Hi,
> I wrote a jpa 2.0 test case.
> In the entity class Course.java:
> @ElementCollection
> @CollectionTable(name="COURSE_COMMENTS")
> private List evaluation;
> Here member "evaluation" contains comments of the course in another 
> Table:COURSE_COMMENT
> I run it on Geronimo 3.0 , howver, inserting record into the Table 
> "COURSE" is NOT sucessful.
>  
> The server gives warning such like this:
>   WARN [DefaultThreadPool 198] openjpa.MetaData - Meta class
>   "org.apache.geronimo.javaee6.jpa20.entities.Course_" for entity class 
> org.apach
>  e.geronimo.javaee6.jpa20.entities.Course can not be registered with 
> following ex
>  ception "java.security.PrivilegedActionException: 
> java.lang.ClassNotFoundExcepti
>   on: org.apache.geronimo.javaee6.jpa20.entities.Course_"
>Also can Not find meta class Evaluation_
>I'm not sure whether I should create meta class(Course_,  Evaluation_ and 
> so on ) befroe deploy the app on the server?
> Need I do manual operation such like below:
> Eg:  javac -classpath path/to/openjpa-all.jar -Aopenjpa.metamodel=true 
> packageName/Course.java
> Or the Geronimo will create meta class automatically?
> Could anyone help to have a look at it?
> Thanks in advance!
> PS: I attached the code in the attachment.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[BUILD] trunk: Failed for Revision: 1025858

2010-10-21 Thread gawor

Geronimo Revision: 1025858 built with tests included
 
See the full build-0300.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021/build-0300.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 41 minutes 29 seconds
[INFO] Finished at: Thu Oct 21 03:44:21 EDT 2010
[INFO] Final Memory: 455M/997M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101021/logs-0300-tomcat/
 
 
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar: 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/corba-marshal-client-3.0-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[WARNING] Skipping verification of legal files in artifacts:
[WARNING] 
org.apache.geronimo.testsuite:corba-marshal-client:jar:3.0-SNAPSHOT
[INFO] [install:install {execution: default-install}]
[INFO] Installing 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/corba-marshal-client-3.0-SNAPSHOT.jar
 to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/corba-marshal-client/3.0-SNAPSHOT/corba-marshal-client-3.0-SNAPSHOT.jar
[INFO] 
[INFO] Building Geronimo TestSuite :: CORBA TestSuite :: Marshal EAR
[INFO]task-segment: [install]
[INFO] 
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [geronimo-property:set-property {execution: set-property}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [ear:generate-application-xml {execution: 
default-generate-application-xml}]
[INFO] Generating application.xml
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/src/main/resources
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] [ear:ear {execution: default-ear}]
[INFO] Copying 
artifact[ejb:org.apache.geronimo.testsuite:corba-marshal-ejb:3.0-SNAPSHOT] 
to[corba-marshal-ejb-3.0-SNAPSHOT.jar]
[INFO] Copying 
artifact[jar:org.apache.geronimo.testsuite:corba-marshal-client:3.0-SNAPSHOT] 
to[corba-marshal-client-3.0-SNAPSHOT.jar]
[INFO] Copy ear resources to 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/target/corba-marshal-ear-3.0-SNAPSHOT
[INFO] Could not find manifest file: 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/src/main/application/META-INF/MANIFEST.MF
 - Generating one
[INFO] Building jar: 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/target/corba-marshal-ear-3.0-SNAPSHOT.ear
[INFO] [geronimo:start-server {execution: start-geronimo}]
[INFO] Using assembly configuration: tomcat
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-tomcat7-javaee6:zip:bin:3.0-SNAPSHOT:provided
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/target/geronimo-tomcat7-javaee6-3.0-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6/3.0-SNAPSHOT/geronimo-tomcat7-javaee6-3.0-SNAPSHOT-bin.zip
 into 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ear/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Initialized with URL: 
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector, 
environment: {jmx.remote.credentials=[Ljava.lang.String;@1c1ca8e}
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: 
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; 
ignoring: java.io.IOException: Failed to retrieve RMIServer stub: 
javax.naming.ServiceUnavailableException [Root ex

41 matches

Mail list logo