[jira] Created: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
java.lang.NoClassDefFoundError: javax/validation/Validator -- Key: OWB-286 URL: https://issues.apache.org/jira/browse/OWB-286 Project: OpenWebBeans Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Gurkan Erdogdu deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the following exception. I understand that JavaEE has some requirement on this, but I actually don't care about JSR 303 (in this scenario). Should there be a more lenient way? E.g. logging a WARNING ? IMO this also cause trouble when one want's to use OWB on older app-servers. My (little) project is here: https://facesgoodies.googlecode.com/svn/MS/trunk run = mvn -Pmyfaces java.lang.NoClassDefFoundError: javax/validation/Validator at org.apache.webbeans.component.javaee.ValidatorBean.init(ValidatorBean.java:36) at org.apache.webbeans.config.BeansDeployer.configureDefaultBeans(BeansDeployer.java:196) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:137) at org.apache.webbeans.lifecycle.DefaultLifecycle.applicationStarted(DefaultLifecycle.java:202) at org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) 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: java.lang.ClassNotFoundException: javax.validation.Validator at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native
Re: Dependency on javax.validation*
and here the ticket goes: https://issues.apache.org/jira/browse/OWB-286 -Matthias On Thu, Feb 18, 2010 at 11:29 AM, Matthias Wessendorf mat...@apache.org wrote: hi, deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the following exception. I understand that JavaEE has some requirement on this, but I actually don't care about JSR 303 (in this scenario). Should there be a more lenient way? E.g. logging a WARNING ? IMO this also cause trouble when one want's to use OWB on older app-servers. My (little) project is here: https://facesgoodies.googlecode.com/svn/MS/trunk run = mvn -Pmyfaces java.lang.NoClassDefFoundError: javax/validation/Validator at org.apache.webbeans.component.javaee.ValidatorBean.init(ValidatorBean.java:36) at org.apache.webbeans.config.BeansDeployer.configureDefaultBeans(BeansDeployer.java:196) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:137) at org.apache.webbeans.lifecycle.DefaultLifecycle.applicationStarted(DefaultLifecycle.java:202) at org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) 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: java.lang.ClassNotFoundException: javax.validation.Validator at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at
[jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
[ https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162 ] Mark Struberg commented on OWB-286: --- too bad, this slipped into webbeans-core. We have to move all this stuff into an own plugin. java.lang.NoClassDefFoundError: javax/validation/Validator -- Key: OWB-286 URL: https://issues.apache.org/jira/browse/OWB-286 Project: OpenWebBeans Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Gurkan Erdogdu deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the following exception. I understand that JavaEE has some requirement on this, but I actually don't care about JSR 303 (in this scenario). Should there be a more lenient way? E.g. logging a WARNING ? IMO this also cause trouble when one want's to use OWB on older app-servers. My (little) project is here: https://facesgoodies.googlecode.com/svn/MS/trunk run = mvn -Pmyfaces java.lang.NoClassDefFoundError: javax/validation/Validator at org.apache.webbeans.component.javaee.ValidatorBean.init(ValidatorBean.java:36) at org.apache.webbeans.config.BeansDeployer.configureDefaultBeans(BeansDeployer.java:196) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:137) at org.apache.webbeans.lifecycle.DefaultLifecycle.applicationStarted(DefaultLifecycle.java:202) at org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) 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
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
I have remarked several times about issues related with Java EE 6 dependencies. I emphasize the fact that JSR-299 is a Java EE 6 specification not for Jetty, Tomcat or any other containers that is not Java EE 6. But we are doing the best to run it possible on those containers. But we must not create plugins for every Java EE service dependency because of this does not work in some containers that are not Java EE 6 compatible. Therefore, if you would like to use it you have to add validation-api or any dependent api to your container. In our samples we add those dependent Java EE dependencies to our WEB-INF/lib. Therefore this is not a bug, I will close this issue. 2010/2/18 Mark Struberg (JIRA) j...@apache.org [ https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162] Mark Struberg commented on OWB-286: --- too bad, this slipped into webbeans-core. We have to move all this stuff into an own plugin. java.lang.NoClassDefFoundError: javax/validation/Validator -- Key: OWB-286 URL: https://issues.apache.org/jira/browse/OWB-286 Project: OpenWebBeans Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Gurkan Erdogdu deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the following exception. I understand that JavaEE has some requirement on this, but I actually don't care about JSR 303 (in this scenario). Should there be a more lenient way? E.g. logging a WARNING ? IMO this also cause trouble when one want's to use OWB on older app-servers. My (little) project is here: https://facesgoodies.googlecode.com/svn/MS/trunk run = mvn -Pmyfaces java.lang.NoClassDefFoundError: javax/validation/Validator at org.apache.webbeans.component.javaee.ValidatorBean.init(ValidatorBean.java:36) at org.apache.webbeans.config.BeansDeployer.configureDefaultBeans(BeansDeployer.java:196) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:137) at org.apache.webbeans.lifecycle.DefaultLifecycle.applicationStarted(DefaultLifecycle.java:202) at org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
Pretty harsh :-) Not intended :) he 299 spec _require_ validator API Yes. Look at specification 3.6 Additional Beans does weld (candi) also have this *hard* dependency on the javax.validation API ? For weld -- yes http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml Thanks; --Gurkan 2010/2/18 Matthias Wessendorf mat...@apache.org Pretty harsh :-) IMO JSF2 is doing better here. It just checks if the dependency in question (yeah, javax.validation) is present if not = don't bother... But... I have to say that JSF 2.0 was released _before_ the JAvaEE6 was available. I understand your motivation for closing the ticket, but I wonder if there actual interest in solving this in a more convenient way. Regarding JSF2 and Validation API: Not only JSF2 was there _before_ JavaEE6. Playing nice here is a gained experience when targeting a JAva EE platform (kinda) independent release; Interesting q: -the 299 spec _require_ validator API if yes = OK :) If no = -does weld (candi) also have this *hard* dependency on the javax.validation API ? -Matthias On Thu, Feb 18, 2010 at 2:00 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: I have remarked several times about issues related with Java EE 6 dependencies. I emphasize the fact that JSR-299 is a Java EE 6 specification not for Jetty, Tomcat or any other containers that is not Java EE 6. But we are doing the best to run it possible on those containers. But we must not create plugins for every Java EE service dependency because of this does not work in some containers that are not Java EE 6 compatible. Therefore, if you would like to use it you have to add validation-api or any dependent api to your container. In our samples we add those dependent Java EE dependencies to our WEB-INF/lib. Therefore this is not a bug, I will close this issue. 2010/2/18 Mark Struberg (JIRA) j...@apache.org [ https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162 ] Mark Struberg commented on OWB-286: --- too bad, this slipped into webbeans-core. We have to move all this stuff into an own plugin. java.lang.NoClassDefFoundError: javax/validation/Validator -- Key: OWB-286 URL: https://issues.apache.org/jira/browse/OWB-286 Project: OpenWebBeans Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Gurkan Erdogdu deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the following exception. I understand that JavaEE has some requirement on this, but I actually don't care about JSR 303 (in this scenario). Should there be a more lenient way? E.g. logging a WARNING ? IMO this also cause trouble when one want's to use OWB on older app-servers. My (little) project is here: https://facesgoodies.googlecode.com/svn/MS/trunk run = mvn -Pmyfaces java.lang.NoClassDefFoundError: javax/validation/Validator at org.apache.webbeans.component.javaee.ValidatorBean.init(ValidatorBean.java:36) at org.apache.webbeans.config.BeansDeployer.configureDefaultBeans(BeansDeployer.java:196) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:137) at org.apache.webbeans.lifecycle.DefaultLifecycle.applicationStarted(DefaultLifecycle.java:202) at org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
On Thu, Feb 18, 2010 at 2:24 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: Pretty harsh :-) Not intended :) I know; it wasn't you that wrote the spec :-) he 299 spec _require_ validator API Yes. Look at specification 3.6 Additional Beans does weld (candi) also have this *hard* dependency on the javax.validation API ? For weld -- yes http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml it says optionaltrue/optional :-) -Matthias Thanks; --Gurkan 2010/2/18 Matthias Wessendorf mat...@apache.org Pretty harsh :-) IMO JSF2 is doing better here. It just checks if the dependency in question (yeah, javax.validation) is present if not = don't bother... But... I have to say that JSF 2.0 was released _before_ the JAvaEE6 was available. I understand your motivation for closing the ticket, but I wonder if there actual interest in solving this in a more convenient way. Regarding JSF2 and Validation API: Not only JSF2 was there _before_ JavaEE6. Playing nice here is a gained experience when targeting a JAva EE platform (kinda) independent release; Interesting q: -the 299 spec _require_ validator API if yes = OK :) If no = -does weld (candi) also have this *hard* dependency on the javax.validation API ? -Matthias On Thu, Feb 18, 2010 at 2:00 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: I have remarked several times about issues related with Java EE 6 dependencies. I emphasize the fact that JSR-299 is a Java EE 6 specification not for Jetty, Tomcat or any other containers that is not Java EE 6. But we are doing the best to run it possible on those containers. But we must not create plugins for every Java EE service dependency because of this does not work in some containers that are not Java EE 6 compatible. Therefore, if you would like to use it you have to add validation-api or any dependent api to your container. In our samples we add those dependent Java EE dependencies to our WEB-INF/lib. Therefore this is not a bug, I will close this issue. 2010/2/18 Mark Struberg (JIRA) j...@apache.org [ https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162 ] Mark Struberg commented on OWB-286: --- too bad, this slipped into webbeans-core. We have to move all this stuff into an own plugin. java.lang.NoClassDefFoundError: javax/validation/Validator -- Key: OWB-286 URL: https://issues.apache.org/jira/browse/OWB-286 Project: OpenWebBeans Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Gurkan Erdogdu deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the following exception. I understand that JavaEE has some requirement on this, but I actually don't care about JSR 303 (in this scenario). Should there be a more lenient way? E.g. logging a WARNING ? IMO this also cause trouble when one want's to use OWB on older app-servers. My (little) project is here: https://facesgoodies.googlecode.com/svn/MS/trunk run = mvn -Pmyfaces java.lang.NoClassDefFoundError: javax/validation/Validator at org.apache.webbeans.component.javaee.ValidatorBean.init(ValidatorBean.java:36) at org.apache.webbeans.config.BeansDeployer.configureDefaultBeans(BeansDeployer.java:196) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:137) at org.apache.webbeans.lifecycle.DefaultLifecycle.applicationStarted(DefaultLifecycle.java:202) at org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
it says optionaltrue/optional :-) Optional because runtime environment provides this :) IF there is no validation-api it throws ClassNFException as you have got. It means that, if you provide scope as optional and your maven project use it, its optional dependency does not transitively passed to using project. You have to provide explicitly this dependency. 2010/2/18 Matthias Wessendorf mat...@apache.org On Thu, Feb 18, 2010 at 2:24 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: Pretty harsh :-) Not intended :) I know; it wasn't you that wrote the spec :-) he 299 spec _require_ validator API Yes. Look at specification 3.6 Additional Beans does weld (candi) also have this *hard* dependency on the javax.validation API ? For weld -- yes http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml it says optionaltrue/optional :-) -Matthias Thanks; --Gurkan 2010/2/18 Matthias Wessendorf mat...@apache.org Pretty harsh :-) IMO JSF2 is doing better here. It just checks if the dependency in question (yeah, javax.validation) is present if not = don't bother... But... I have to say that JSF 2.0 was released _before_ the JAvaEE6 was available. I understand your motivation for closing the ticket, but I wonder if there actual interest in solving this in a more convenient way. Regarding JSF2 and Validation API: Not only JSF2 was there _before_ JavaEE6. Playing nice here is a gained experience when targeting a JAva EE platform (kinda) independent release; Interesting q: -the 299 spec _require_ validator API if yes = OK :) If no = -does weld (candi) also have this *hard* dependency on the javax.validation API ? -Matthias On Thu, Feb 18, 2010 at 2:00 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: I have remarked several times about issues related with Java EE 6 dependencies. I emphasize the fact that JSR-299 is a Java EE 6 specification not for Jetty, Tomcat or any other containers that is not Java EE 6. But we are doing the best to run it possible on those containers. But we must not create plugins for every Java EE service dependency because of this does not work in some containers that are not Java EE 6 compatible. Therefore, if you would like to use it you have to add validation-api or any dependent api to your container. In our samples we add those dependent Java EE dependencies to our WEB-INF/lib. Therefore this is not a bug, I will close this issue. 2010/2/18 Mark Struberg (JIRA) j...@apache.org [ https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162 ] Mark Struberg commented on OWB-286: --- too bad, this slipped into webbeans-core. We have to move all this stuff into an own plugin. java.lang.NoClassDefFoundError: javax/validation/Validator -- Key: OWB-286 URL: https://issues.apache.org/jira/browse/OWB-286 Project: OpenWebBeans Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Gurkan Erdogdu deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the following exception. I understand that JavaEE has some requirement on this, but I actually don't care about JSR 303 (in this scenario). Should there be a more lenient way? E.g. logging a WARNING ? IMO this also cause trouble when one want's to use OWB on older app-servers. My (little) project is here: https://facesgoodies.googlecode.com/svn/MS/trunk run = mvn -Pmyfaces java.lang.NoClassDefFoundError: javax/validation/Validator at org.apache.webbeans.component.javaee.ValidatorBean.init(ValidatorBean.java:36) at org.apache.webbeans.config.BeansDeployer.configureDefaultBeans(BeansDeployer.java:196) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:137) at org.apache.webbeans.lifecycle.DefaultLifecycle.applicationStarted(DefaultLifecycle.java:202) at org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
I agree that the 3rd and 4th bullets in 3.6 make this a hard requirement. It seems the tradeoff to me is: 1) Additional complexity of another plugin based approach to avoid this scenario. or 2) Handling of the CNF exception inside OWB with a warning message vs. The user having to bundle an API jar they don't necessarily care about inside their application when running in a not full JEE environment. While the latter doesn't seem like a huge burden, I've seen cases where users have dozens on API jars inside their application and sometimes they don't even know why or what side affects that may cause when they later run inside a JEE environment and start changing classloader settings. Sincerely, Joe On Thu, Feb 18, 2010 at 8:24 AM, Gurkan Erdogdu cgurkanerdo...@gmail.comwrote: Pretty harsh :-) Not intended :) he 299 spec _require_ validator API Yes. Look at specification 3.6 Additional Beans does weld (candi) also have this *hard* dependency on the javax.validation API ? For weld -- yes http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml Thanks; --Gurkan 2010/2/18 Matthias Wessendorf mat...@apache.org Pretty harsh :-) IMO JSF2 is doing better here. It just checks if the dependency in question (yeah, javax.validation) is present if not = don't bother... But... I have to say that JSF 2.0 was released _before_ the JAvaEE6 was available. I understand your motivation for closing the ticket, but I wonder if there actual interest in solving this in a more convenient way. Regarding JSF2 and Validation API: Not only JSF2 was there _before_ JavaEE6. Playing nice here is a gained experience when targeting a JAva EE platform (kinda) independent release; Interesting q: -the 299 spec _require_ validator API if yes = OK :) If no = -does weld (candi) also have this *hard* dependency on the javax.validation API ? -Matthias On Thu, Feb 18, 2010 at 2:00 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: I have remarked several times about issues related with Java EE 6 dependencies. I emphasize the fact that JSR-299 is a Java EE 6 specification not for Jetty, Tomcat or any other containers that is not Java EE 6. But we are doing the best to run it possible on those containers. But we must not create plugins for every Java EE service dependency because of this does not work in some containers that are not Java EE 6 compatible. Therefore, if you would like to use it you have to add validation-api or any dependent api to your container. In our samples we add those dependent Java EE dependencies to our WEB-INF/lib. Therefore this is not a bug, I will close this issue. 2010/2/18 Mark Struberg (JIRA) j...@apache.org [ https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162 ] Mark Struberg commented on OWB-286: --- too bad, this slipped into webbeans-core. We have to move all this stuff into an own plugin. java.lang.NoClassDefFoundError: javax/validation/Validator -- Key: OWB-286 URL: https://issues.apache.org/jira/browse/OWB-286 Project: OpenWebBeans Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Gurkan Erdogdu deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the following exception. I understand that JavaEE has some requirement on this, but I actually don't care about JSR 303 (in this scenario). Should there be a more lenient way? E.g. logging a WARNING ? IMO this also cause trouble when one want's to use OWB on older app-servers. My (little) project is here: https://facesgoodies.googlecode.com/svn/MS/trunk run = mvn -Pmyfaces java.lang.NoClassDefFoundError: javax/validation/Validator at org.apache.webbeans.component.javaee.ValidatorBean.init(ValidatorBean.java:36) at org.apache.webbeans.config.BeansDeployer.configureDefaultBeans(BeansDeployer.java:196) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:137) at org.apache.webbeans.lifecycle.DefaultLifecycle.applicationStarted(DefaultLifecycle.java:202) at org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
exactly On Thu, Feb 18, 2010 at 3:40 PM, Joseph Bergmark bergm...@apache.org wrote: I agree that the 3rd and 4th bullets in 3.6 make this a hard requirement. It seems the tradeoff to me is: 1) Additional complexity of another plugin based approach to avoid this scenario. or 2) Handling of the CNF exception inside OWB with a warning message vs. The user having to bundle an API jar they don't necessarily care about inside their application when running in a not full JEE environment. While the latter doesn't seem like a huge burden, I've seen cases where users have dozens on API jars inside their application and sometimes they don't even know why or what side affects that may cause when they later run inside a JEE environment and start changing classloader settings. one benefit of ranting in comments :-) users better get that, but I agree with a ton of (lame) dependencies it can be come quite un-handy. http://facesgoodies.googlecode.com/svn/MS/trunk/pom.xml == !-- This is a lame dependency, required by the JSR 299 specification. Not the fault of Apache OWB, but we have to have this here in order to be able to use Apache OWB outside of the typical EE realm. (Yes here in Jetty). -- dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-validation_1.0_spec/artifactId version1.0/version scoperuntime/scope /dependency == Sincerely, Joe On Thu, Feb 18, 2010 at 8:24 AM, Gurkan Erdogdu cgurkanerdo...@gmail.comwrote: Pretty harsh :-) Not intended :) he 299 spec _require_ validator API Yes. Look at specification 3.6 Additional Beans does weld (candi) also have this *hard* dependency on the javax.validation API ? For weld -- yes http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml Thanks; --Gurkan 2010/2/18 Matthias Wessendorf mat...@apache.org Pretty harsh :-) IMO JSF2 is doing better here. It just checks if the dependency in question (yeah, javax.validation) is present if not = don't bother... But... I have to say that JSF 2.0 was released _before_ the JAvaEE6 was available. I understand your motivation for closing the ticket, but I wonder if there actual interest in solving this in a more convenient way. Regarding JSF2 and Validation API: Not only JSF2 was there _before_ JavaEE6. Playing nice here is a gained experience when targeting a JAva EE platform (kinda) independent release; Interesting q: -the 299 spec _require_ validator API if yes = OK :) If no = -does weld (candi) also have this *hard* dependency on the javax.validation API ? -Matthias On Thu, Feb 18, 2010 at 2:00 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: I have remarked several times about issues related with Java EE 6 dependencies. I emphasize the fact that JSR-299 is a Java EE 6 specification not for Jetty, Tomcat or any other containers that is not Java EE 6. But we are doing the best to run it possible on those containers. But we must not create plugins for every Java EE service dependency because of this does not work in some containers that are not Java EE 6 compatible. Therefore, if you would like to use it you have to add validation-api or any dependent api to your container. In our samples we add those dependent Java EE dependencies to our WEB-INF/lib. Therefore this is not a bug, I will close this issue. 2010/2/18 Mark Struberg (JIRA) j...@apache.org [ https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162 ] Mark Struberg commented on OWB-286: --- too bad, this slipped into webbeans-core. We have to move all this stuff into an own plugin. java.lang.NoClassDefFoundError: javax/validation/Validator -- Key: OWB-286 URL: https://issues.apache.org/jira/browse/OWB-286 Project: OpenWebBeans Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Gurkan Erdogdu deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the following exception. I understand that JavaEE has some requirement on this, but I actually don't care about JSR 303 (in this scenario). Should there be a more lenient way? E.g. logging a WARNING ? IMO this also cause trouble when one want's to use OWB on older app-servers. My (little) project is here: https://facesgoodies.googlecode.com/svn/MS/trunk run = mvn -Pmyfaces java.lang.NoClassDefFoundError: javax/validation/Validator at
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
On Thu, Feb 18, 2010 at 4:52 PM, Mark Struberg strub...@yahoo.de wrote: I don't buy this. The only Validator imports in weld are under the main/java/org/jboss/weld/bean/builtin/ee/ and this whole package imo only get's used (and classloaded) if you are running in an EE container. At least that's how I remember that it used to be half a year ago when I looked at weld sources the last time. Also, I don't really care what weld is doing! If we have a way to do this better, then we should do it! So please don't close it, but I agree that this is not a 'bug' and we should change this to 'feature', ok? It would make another really cool OWB feature! +1 not only a cool feature. Actually playing nice with customers (the guys that are supposed to use OWB ;-) ) LieGrue, strub --- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Do, 18.2.2010: Von: Gurkan Erdogdu cgurkanerdo...@gmail.com Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator An: dev@openwebbeans.apache.org Datum: Donnerstag, 18. Februar, 2010 14:33 Uhr it says optionaltrue/optional :-) Optional because runtime environment provides this :) IF there is no validation-api it throws ClassNFException as you have got. It means that, if you provide scope as optional and your maven project use it, its optional dependency does not transitively passed to using project. You have to provide explicitly this dependency. 2010/2/18 Matthias Wessendorf mat...@apache.org On Thu, Feb 18, 2010 at 2:24 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: Pretty harsh :-) Not intended :) I know; it wasn't you that wrote the spec :-) he 299 spec _require_ validator API Yes. Look at specification 3.6 Additional Beans does weld (candi) also have this *hard* dependency on the javax.validation API ? For weld -- yes http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml it says optionaltrue/optional :-) -Matthias Thanks; --Gurkan 2010/2/18 Matthias Wessendorf mat...@apache.org Pretty harsh :-) IMO JSF2 is doing better here. It just checks if the dependency in question (yeah, javax.validation) is present if not = don't bother... But... I have to say that JSF 2.0 was released _before_ the JAvaEE6 was available. I understand your motivation for closing the ticket, but I wonder if there actual interest in solving this in a more convenient way. Regarding JSF2 and Validation API: Not only JSF2 was there _before_ JavaEE6. Playing nice here is a gained experience when targeting a JAva EE platform (kinda) independent release; Interesting q: -the 299 spec _require_ validator API if yes = OK :) If no = -does weld (candi) also have this *hard* dependency on the javax.validation API ? -Matthias On Thu, Feb 18, 2010 at 2:00 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: I have remarked several times about issues related with Java EE 6 dependencies. I emphasize the fact that JSR-299 is a Java EE 6 specification not for Jetty, Tomcat or any other containers that is not Java EE 6. But we are doing the best to run it possible on those containers. But we must not create plugins for every Java EE service dependency because of this does not work in some containers that are not Java EE 6 compatible. Therefore, if you would like to use it you have to add validation-api or any dependent api to your container. In our samples we add those dependent Java EE dependencies to our WEB-INF/lib. Therefore this is not a bug, I will close this issue. 2010/2/18 Mark Struberg (JIRA) j...@apache.org [ https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162 ] Mark Struberg commented on OWB-286: --- too bad, this slipped into webbeans-core. We have to move all this stuff into an own plugin. java.lang.NoClassDefFoundError: javax/validation/Validator -- Key: OWB-286 URL: https://issues.apache.org/jira/browse/OWB-286 Project: OpenWebBeans Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Gurkan Erdogdu deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the following exception. I understand that JavaEE has some requirement on this, but I actually don't care about JSR 303 (in this scenario). Should there be a more lenient way? E.g. logging a WARNING ?
[jira] Updated: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
[ https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OWB-286: -- Affects Version/s: M3 Fix Version/s: 1.0.0 Assignee: Mark Struberg (was: Gurkan Erdogdu) Issue Type: Improvement (was: Bug) Chaged to 'Improvement' We should move ValidatorBean and stuff into an own plugin so webbeans-core has no dependencies on it anymore. java.lang.NoClassDefFoundError: javax/validation/Validator -- Key: OWB-286 URL: https://issues.apache.org/jira/browse/OWB-286 Project: OpenWebBeans Issue Type: Improvement Affects Versions: M3 Reporter: Matthias Weßendorf Assignee: Mark Struberg Fix For: 1.0.0 deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the following exception. I understand that JavaEE has some requirement on this, but I actually don't care about JSR 303 (in this scenario). Should there be a more lenient way? E.g. logging a WARNING ? IMO this also cause trouble when one want's to use OWB on older app-servers. My (little) project is here: https://facesgoodies.googlecode.com/svn/MS/trunk run = mvn -Pmyfaces java.lang.NoClassDefFoundError: javax/validation/Validator at org.apache.webbeans.component.javaee.ValidatorBean.init(ValidatorBean.java:36) at org.apache.webbeans.config.BeansDeployer.configureDefaultBeans(BeansDeployer.java:196) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:137) at org.apache.webbeans.lifecycle.DefaultLifecycle.applicationStarted(DefaultLifecycle.java:202) at org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) 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
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
Slightly off-topic, but along these same lines... While working on the logging patches I've submitted, I noticed that OWB uses log4j instead of JDK logging (thus requiring log4j to be pulled in - the link to current topic). Is there a specific reason we're using log4j? Could I submit a patch to migrate to using the JDK logger that is already present? If that is acceptable then I will open a separate JIRA issue and continue discussion there. Thanks, Paul J. Reder On 02/18/2010 11:07 AM, Matthias Wessendorf wrote: On Thu, Feb 18, 2010 at 4:52 PM, Mark Strubergstrub...@yahoo.de wrote: I don't buy this. The only Validator imports in weld are under the main/java/org/jboss/weld/bean/builtin/ee/ and this whole package imo only get's used (and classloaded) if you are running in an EE container. At least that's how I remember that it used to be half a year ago when I looked at weld sources the last time. Also, I don't really care what weld is doing! If we have a way to do this better, then we should do it! So please don't close it, but I agree that this is not a 'bug' and we should change this to 'feature', ok? It would make another really cool OWB feature! +1 not only a cool feature. Actually playing nice with customers (the guys that are supposed to use OWB ;-) ) LieGrue, strub --- Gurkan Erdogducgurkanerdo...@gmail.com schrieb am Do, 18.2.2010: Von: Gurkan Erdogducgurkanerdo...@gmail.com Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator An: dev@openwebbeans.apache.org Datum: Donnerstag, 18. Februar, 2010 14:33 Uhr it says optionaltrue/optional :-) Optional because runtime environment provides this :) IF there is no validation-api it throws ClassNFException as you have got. It means that, if you provide scope as optional and your maven project use it, its optional dependency does not transitively passed to using project. You have to provide explicitly this dependency. 2010/2/18 Matthias Wessendorfmat...@apache.org On Thu, Feb 18, 2010 at 2:24 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: Pretty harsh :-) Not intended :) I know; it wasn't you that wrote the spec :-) he 299 spec _require_ validator API Yes. Look at specification 3.6 Additional Beans does weld (candi) also have this *hard* dependency on the javax.validation API ? For weld -- yes http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml it saysoptionaltrue/optional :-) -Matthias Thanks; --Gurkan 2010/2/18 Matthias Wessendorfmat...@apache.org Pretty harsh :-) IMO JSF2 is doing better here. It just checks if the dependency in question (yeah, javax.validation) is present if not = don't bother... But... I have to say that JSF 2.0 was released _before_ the JAvaEE6 was available. I understand your motivation for closing the ticket, but I wonder if there actual interest in solving this in a more convenient way. Regarding JSF2 and Validation API: Not only JSF2 was there _before_ JavaEE6. Playing nice here is a gained experience when targeting a JAva EE platform (kinda) independent release; Interesting q: -the 299 spec _require_ validator API if yes = OK :) If no = -does weld (candi) also have this *hard* dependency on the javax.validation API ? -Matthias On Thu, Feb 18, 2010 at 2:00 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: I have remarked several times about issues related with Java EE 6 dependencies. I emphasize the fact that JSR-299 is a Java EE 6 specification not for Jetty, Tomcat or any other containers that is not Java EE 6. But we are doing the best to run it possible on those containers. But we must not create plugins for every Java EE service dependency because of this does not work in some containers that are not Java EE 6 compatible. Therefore, if you would like to use it you have to add validation-api or any dependent api to your container. In our samples we add those dependent Java EE dependencies to our WEB-INF/lib. Therefore this is not a bug, I will close this issue. 2010/2/18 Mark Struberg (JIRA)j...@apache.org [ https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162 ] Mark Struberg commented on OWB-286: --- too bad, this slipped into webbeans-core. We have to move all this stuff into an own plugin. java.lang.NoClassDefFoundError: javax/validation/Validator -- Key: OWB-286 URL: https://issues.apache.org/jira/browse/OWB-286 Project: OpenWebBeans Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Gurkan Erdogdu deploying OWB (trunk) on Jetty (w/ myfaces2
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
abstraction is a good point, but it currently always reports the wrong location. Thus in the log, you don't see the line and the class where the logging really was done but only the the location somewhere in WebbeansLogger :( This is a bad if you need to know where the logging actually happened (and if you have multiple occurrences of the same log text) LieGrue, strub --- Joseph Bergmark bergm...@apache.org schrieb am Do, 18.2.2010: Von: Joseph Bergmark bergm...@apache.org Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator An: dev@openwebbeans.apache.org Datum: Donnerstag, 18. Februar, 2010 18:58 Uhr +1, but I'm not sure I see the need to remove WebbeansLogger. That provides an abstraction layer on top of whatever logging technology you want to use, which may make switching loggers easier if we needed to in the future. The only down side to the current WebBeansLogger is that the methods are tied pretty closely to log4j logging levels. Sincerely, Joe On Thu, Feb 18, 2010 at 12:37 PM, Mark Struberg strub...@yahoo.de wrote: Hi Paul! +1 and please let's get rid of our WebbeansLogger, since this layer actually hides the _real_ source of the logging :/ LieGrue, strub --- Paul J. Reder rede...@remulak.net schrieb am Do, 18.2.2010: Von: Paul J. Reder rede...@remulak.net Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator An: dev@openwebbeans.apache.org Datum: Donnerstag, 18. Februar, 2010 18:11 Uhr Slightly off-topic, but along these same lines... While working on the logging patches I've submitted, I noticed that OWB uses log4j instead of JDK logging (thus requiring log4j to be pulled in - the link to current topic). Is there a specific reason we're using log4j? Could I submit a patch to migrate to using the JDK logger that is already present? If that is acceptable then I will open a separate JIRA issue and continue discussion there. Thanks, Paul J. Reder On 02/18/2010 11:07 AM, Matthias Wessendorf wrote: On Thu, Feb 18, 2010 at 4:52 PM, Mark Strubergstrub...@yahoo.de wrote: I don't buy this. The only Validator imports in weld are under the main/java/org/jboss/weld/bean/builtin/ee/ and this whole package imo only get's used (and classloaded) if you are running in an EE container. At least that's how I remember that it used to be half a year ago when I looked at weld sources the last time. Also, I don't really care what weld is doing! If we have a way to do this better, then we should do it! So please don't close it, but I agree that this is not a 'bug' and we should change this to 'feature', ok? It would make another really cool OWB feature! +1 not only a cool feature. Actually playing nice with customers (the guys that are supposed to use OWB ;-) ) LieGrue, strub --- Gurkan Erdogducgurkanerdo...@gmail.com schrieb am Do, 18.2.2010: Von: Gurkan Erdogducgurkanerdo...@gmail.com Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator An: dev@openwebbeans.apache.org Datum: Donnerstag, 18. Februar, 2010 14:33 Uhr it says optionaltrue/optional :-) Optional because runtime environment provides this :) IF there is no validation-api it throws ClassNFException as you have got. It means that, if you provide scope as optional and your maven project use it, its optional dependency does not transitively passed to using project. You have to provide explicitly this dependency. 2010/2/18 Matthias Wessendorfmat...@apache.org On Thu, Feb 18, 2010 at 2:24 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: Pretty harsh :-) Not intended :) I know; it wasn't you that wrote the spec :-) he 299 spec _require_ validator API Yes. Look at specification 3.6 Additional Beans does weld (candi) also have this *hard* dependency on the javax.validation API ? For weld -- yes http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml it saysoptionaltrue/optional :-) -Matthias Thanks; --Gurkan 2010/2/18 Matthias Wessendorfmat...@apache.org Pretty harsh :-) IMO JSF2 is doing better here. It just checks if the dependency in question (yeah, javax.validation) is present if not = don't bother... But... I have to say that JSF 2.0 was released _before_ the JAvaEE6 was available. I understand your motivation
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
Hi; It is not reasonable to remove WebBeansLogger. Hımm, I think that we can implement a new interface called OwbLogger and add WebBeansLogger methods into it. After that rename WebBeansLogger to OwbLog4jLogger that implement OwbLogger. As Joe remarked, I was thinking about some wrappers when I was writing this logger implementation at the start of the project. If we write like this, we can define configuration options for which one we use. WDYT? Thanks; --Gurkan From: Joseph Bergmark bergm...@apache.org To: dev@openwebbeans.apache.org Sent: Thu, February 18, 2010 7:58:23 PM Subject: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator +1, but I'm not sure I see the need to remove WebbeansLogger. That provides an abstraction layer on top of whatever logging technology you want to use, which may make switching loggers easier if we needed to in the future. The only down side to the current WebBeansLogger is that the methods are tied pretty closely to log4j logging levels. Sincerely, Joe On Thu, Feb 18, 2010 at 12:37 PM, Mark Struberg strub...@yahoo.de wrote: Hi Paul! +1 and please let's get rid of our WebbeansLogger, since this layer actually hides the _real_ source of the logging :/ LieGrue, strub --- Paul J. Reder rede...@remulak.net schrieb am Do, 18.2.2010: Von: Paul J. Reder rede...@remulak.net Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator An: dev@openwebbeans.apache.org Datum: Donnerstag, 18. Februar, 2010 18:11 Uhr Slightly off-topic, but along these same lines... While working on the logging patches I've submitted, I noticed that OWB uses log4j instead of JDK logging (thus requiring log4j to be pulled in - the link to current topic). Is there a specific reason we're using log4j? Could I submit a patch to migrate to using the JDK logger that is already present? If that is acceptable then I will open a separate JIRA issue and continue discussion there. Thanks, Paul J. Reder On 02/18/2010 11:07 AM, Matthias Wessendorf wrote: On Thu, Feb 18, 2010 at 4:52 PM, Mark Strubergstrub...@yahoo.de wrote: I don't buy this. The only Validator imports in weld are under the main/java/org/jboss/weld/bean/builtin/ee/ and this whole package imo only get's used (and classloaded) if you are running in an EE container. At least that's how I remember that it used to be half a year ago when I looked at weld sources the last time. Also, I don't really care what weld is doing! If we have a way to do this better, then we should do it! So please don't close it, but I agree that this is not a 'bug' and we should change this to 'feature', ok? It would make another really cool OWB feature! +1 not only a cool feature. Actually playing nice with customers (the guys that are supposed to use OWB ;-) ) LieGrue, strub --- Gurkan Erdogducgurkanerdo...@gmail.com schrieb am Do, 18.2.2010: Von: Gurkan Erdogducgurkanerdo...@gmail.com Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator An: dev@openwebbeans.apache.org Datum: Donnerstag, 18. Februar, 2010 14:33 Uhr it says optionaltrue/optional :-) Optional because runtime environment provides this :) IF there is no validation-api it throws ClassNFException as you have got. It means that, if you provide scope as optional and your maven project use it, its optional dependency does not transitively passed to using project. You have to provide explicitly this dependency. 2010/2/18 Matthias Wessendorfmat...@apache.org On Thu, Feb 18, 2010 at 2:24 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: Pretty harsh :-) Not intended :) I know; it wasn't you that wrote the spec :-) he 299 spec _require_ validator API Yes. Look at specification 3.6 Additional Beans does weld (candi) also have this *hard* dependency on the javax.validation API ? For weld -- yes http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml it saysoptionaltrue/optional :-) -Matthias Thanks; --Gurkan 2010/2/18 Matthias Wessendorfmat...@apache.org Pretty harsh :-) IMO JSF2 is doing better here. It just checks if the dependency in question (yeah, javax.validation) is present if not = don't bother... But... I have to say that JSF 2.0 was released _before_ the JAvaEE6 was available. I understand your motivation for closing the ticket, but I wonder if there actual interest in solving this in a more convenient way. Regarding JSF2 and
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
So please don't close it, but I agree that this is not a 'bug' and we should change this to 'feature', ok? Sure. Thanks; --Gurkan From: Mark Struberg strub...@yahoo.de To: dev@openwebbeans.apache.org Sent: Thu, February 18, 2010 5:52:01 PM Subject: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator I don't buy this. The only Validator imports in weld are under the main/java/org/jboss/weld/bean/builtin/ee/ and this whole package imo only get's used (and classloaded) if you are running in an EE container. At least that's how I remember that it used to be half a year ago when I looked at weld sources the last time. Also, I don't really care what weld is doing! If we have a way to do this better, then we should do it! So please don't close it, but I agree that this is not a 'bug' and we should change this to 'feature', ok? It would make another really cool OWB feature! LieGrue, strub --- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Do, 18.2.2010: Von: Gurkan Erdogdu cgurkanerdo...@gmail.com Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator An: dev@openwebbeans.apache.org Datum: Donnerstag, 18. Februar, 2010 14:33 Uhr it says optionaltrue/optional :-) Optional because runtime environment provides this :) IF there is no validation-api it throws ClassNFException as you have got. It means that, if you provide scope as optional and your maven project use it, its optional dependency does not transitively passed to using project. You have to provide explicitly this dependency. 2010/2/18 Matthias Wessendorf mat...@apache.org On Thu, Feb 18, 2010 at 2:24 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: Pretty harsh :-) Not intended :) I know; it wasn't you that wrote the spec :-) he 299 spec _require_ validator API Yes. Look at specification 3.6 Additional Beans does weld (candi) also have this *hard* dependency on the javax.validation API ? For weld -- yes http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml it says optionaltrue/optional :-) -Matthias Thanks; --Gurkan 2010/2/18 Matthias Wessendorf mat...@apache.org Pretty harsh :-) IMO JSF2 is doing better here. It just checks if the dependency in question (yeah, javax.validation) is present if not = don't bother... But... I have to say that JSF 2.0 was released _before_ the JAvaEE6 was available. I understand your motivation for closing the ticket, but I wonder if there actual interest in solving this in a more convenient way. Regarding JSF2 and Validation API: Not only JSF2 was there _before_ JavaEE6. Playing nice here is a gained experience when targeting a JAva EE platform (kinda) independent release; Interesting q: -the 299 spec _require_ validator API if yes = OK :) If no = -does weld (candi) also have this *hard* dependency on the javax.validation API ? -Matthias On Thu, Feb 18, 2010 at 2:00 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: I have remarked several times about issues related with Java EE 6 dependencies. I emphasize the fact that JSR-299 is a Java EE 6 specification not for Jetty, Tomcat or any other containers that is not Java EE 6. But we are doing the best to run it possible on those containers. But we must not create plugins for every Java EE service dependency because of this does not work in some containers that are not Java EE 6 compatible. Therefore, if you would like to use it you have to add validation-api or any dependent api to your container. In our samples we add those dependent Java EE dependencies to our WEB-INF/lib. Therefore this is not a bug, I will close this issue. 2010/2/18 Mark Struberg (JIRA) j...@apache.org [ https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162 ] Mark Struberg commented on OWB-286: --- too bad, this slipped into webbeans-core. We have to move all this stuff into an own plugin. java.lang.NoClassDefFoundError: javax/validation/Validator -- Key: OWB-286 URL: https://issues.apache.org/jira/browse/OWB-286 Project: OpenWebBeans Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Gurkan Erdogdu deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
The question is whether we need to wrap a wrapper of a wrapper of ... ;)
This is a common design pattern that is used in real world frameworks/servers
etc.. Not everyone like default JDK Logger like me :)
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Thu, February 18, 2010 8:21:22 PM
Subject: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError:
javax/validation/Validator
The question is whether we need to wrap a wrapper of a wrapper of ... ;)
The java.util.logging.Logger has a few downsides, but along the line it now
gets common adopted, and it's extendable, thus it's good enough for real worlds
need.
The other strong point of java.util Logger is that he defers String
construction by allowing to log via a message key with variable arguments.
There is no need to do something like
if (log.isLogDebug()) {
log.debug(lalala + idX + 2ndparam= + idY);
}
This increases the speed up to 20 times and/or makes the code more readable.
But I really don't care much what we use to do our logging.
LieGrue,
strub
--- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Do, 18.2.2010:
Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError:
javax/validation/Validator
An: dev@openwebbeans.apache.org
Datum: Donnerstag, 18. Februar, 2010 19:12 Uhr
Hi;
It is not reasonable to remove WebBeansLogger. Hımm, I
think that we can implement a new interface called OwbLogger
and add WebBeansLogger methods into it. After that rename
WebBeansLogger to OwbLog4jLogger that implement OwbLogger.
As Joe remarked, I was thinking about some wrappers when I
was writing this logger implementation at the start of the
project.
If we write like this, we can define configuration options
for which one we use.
WDYT?
Thanks;
--Gurkan
From: Joseph Bergmark bergm...@apache.org
To: dev@openwebbeans.apache.org
Sent: Thu, February 18, 2010 7:58:23 PM
Subject: Re: [jira] Commented: (OWB-286)
java.lang.NoClassDefFoundError:
javax/validation/Validator
+1, but I'm not sure I see the need to remove
WebbeansLogger. That provides
an abstraction layer on top of whatever logging technology
you want to use,
which may make switching loggers easier if we needed to in
the future. The
only down side to the current WebBeansLogger is that the
methods are tied
pretty closely to log4j logging levels.
Sincerely,
Joe
On Thu, Feb 18, 2010 at 12:37 PM, Mark Struberg strub...@yahoo.de
wrote:
Hi Paul!
+1 and please let's get rid of our
WebbeansLogger, since this layer
actually hides the _real_ source of the logging :/
LieGrue,
strub
--- Paul J. Reder rede...@remulak.net
schrieb am Do, 18.2.2010:
Von: Paul J. Reder rede...@remulak.net
Betreff: Re: [jira] Commented: (OWB-286)
java.lang.NoClassDefFoundError:
javax/validation/Validator
An: dev@openwebbeans.apache.org
Datum: Donnerstag, 18. Februar, 2010 18:11 Uhr
Slightly off-topic, but along these
same lines...
While working on the logging patches I've
submitted, I
noticed that OWB uses
log4j instead of JDK logging (thus requiring
log4j to be
pulled in - the link
to current topic). Is there a specific reason
we're using
log4j? Could
I submit a patch to migrate to using the JDK
logger that is
already present?
If that is acceptable then I will open a separate
JIRA
issue and continue
discussion there.
Thanks,
Paul J. Reder
On 02/18/2010 11:07 AM, Matthias Wessendorf
wrote:
On Thu, Feb 18, 2010 at 4:52 PM, Mark
Strubergstrub...@yahoo.de
wrote:
I don't buy this.
The only Validator imports in weld are
under the
main/java/org/jboss/weld/bean/builtin/ee/ and
this whole
package imo only get's used (and classloaded) if
you are
running in an EE container. At least that's how I
remember
that it used to be half a year ago when I looked
at weld
sources the last time.
Also, I don't really care what weld is
doing! If
we have a way to do this better, then we should
do it!
So please don't close it, but I agree
that this is
not a 'bug' and we should change this to
'feature', ok?
It would make another really cool OWB
feature!
+1
not only a cool feature. Actually playing
nice with
customers (the
guys that are supposed to use OWB ;-) )
LieGrue,
strub
--- Gurkan Erdogducgurkanerdo...@gmail.com
schrieb am Do, 18.2.2010:
Von: Gurkan Erdogducgurkanerdo...@gmail.com
Betreff: Re: [jira] Commented:
(OWB-286)
java.lang.NoClassDefFoundError:
javax/validation/Validator
An: dev@openwebbeans.apache.org
Datum: Donnerstag, 18. Februar, 2010
14:33
Uhr
it says
optionaltrue/optional
:-)
Optional because runtime environment
provides
this :) IF
[jira] Closed: (OWB-284) OWB could not find default bean if alternative specialized bean is not enabled.
[ https://issues.apache.org/jira/browse/OWB-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gurkan Erdogdu closed OWB-284. -- Resolution: Fixed Fix Version/s: M4 OWB could not find default bean if alternative specialized bean is not enabled. --- Key: OWB-284 URL: https://issues.apache.org/jira/browse/OWB-284 Project: OpenWebBeans Issue Type: Bug Components: Injection and Lookup Affects Versions: M3 Reporter: YING WANG Assignee: Gurkan Erdogdu Fix For: M4 Attachments: owb284.patch, owb284testcase.jar I have 2 managed beans: @QualifierSpecialized Bus @Alternative @Specializes public class SchoolBus extends Bus owb works fine when SchoolBus is enabled in bean.xml. However, if SchoolBus is not enabled in bean.xml, owb could NOT locate Bus either. (test case will be uploaded later). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
+1 on Log4j Not sure on the WebbeansLogger (would need to see the code, before rating in here) I usually tend to add some more convenient methods on-top of jul. -Matthias On Thu, Feb 18, 2010 at 6:58 PM, Joseph Bergmark bergm...@apache.org wrote: +1, but I'm not sure I see the need to remove WebbeansLogger. That provides an abstraction layer on top of whatever logging technology you want to use, which may make switching loggers easier if we needed to in the future. The only down side to the current WebBeansLogger is that the methods are tied pretty closely to log4j logging levels. Sincerely, Joe On Thu, Feb 18, 2010 at 12:37 PM, Mark Struberg strub...@yahoo.de wrote: Hi Paul! +1 and please let's get rid of our WebbeansLogger, since this layer actually hides the _real_ source of the logging :/ LieGrue, strub --- Paul J. Reder rede...@remulak.net schrieb am Do, 18.2.2010: Von: Paul J. Reder rede...@remulak.net Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator An: dev@openwebbeans.apache.org Datum: Donnerstag, 18. Februar, 2010 18:11 Uhr Slightly off-topic, but along these same lines... While working on the logging patches I've submitted, I noticed that OWB uses log4j instead of JDK logging (thus requiring log4j to be pulled in - the link to current topic). Is there a specific reason we're using log4j? Could I submit a patch to migrate to using the JDK logger that is already present? If that is acceptable then I will open a separate JIRA issue and continue discussion there. Thanks, Paul J. Reder On 02/18/2010 11:07 AM, Matthias Wessendorf wrote: On Thu, Feb 18, 2010 at 4:52 PM, Mark Strubergstrub...@yahoo.de wrote: I don't buy this. The only Validator imports in weld are under the main/java/org/jboss/weld/bean/builtin/ee/ and this whole package imo only get's used (and classloaded) if you are running in an EE container. At least that's how I remember that it used to be half a year ago when I looked at weld sources the last time. Also, I don't really care what weld is doing! If we have a way to do this better, then we should do it! So please don't close it, but I agree that this is not a 'bug' and we should change this to 'feature', ok? It would make another really cool OWB feature! +1 not only a cool feature. Actually playing nice with customers (the guys that are supposed to use OWB ;-) ) LieGrue, strub --- Gurkan Erdogducgurkanerdo...@gmail.com schrieb am Do, 18.2.2010: Von: Gurkan Erdogducgurkanerdo...@gmail.com Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator An: dev@openwebbeans.apache.org Datum: Donnerstag, 18. Februar, 2010 14:33 Uhr it says optionaltrue/optional :-) Optional because runtime environment provides this :) IF there is no validation-api it throws ClassNFException as you have got. It means that, if you provide scope as optional and your maven project use it, its optional dependency does not transitively passed to using project. You have to provide explicitly this dependency. 2010/2/18 Matthias Wessendorfmat...@apache.org On Thu, Feb 18, 2010 at 2:24 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: Pretty harsh :-) Not intended :) I know; it wasn't you that wrote the spec :-) he 299 spec _require_ validator API Yes. Look at specification 3.6 Additional Beans does weld (candi) also have this *hard* dependency on the javax.validation API ? For weld -- yes http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml it saysoptionaltrue/optional :-) -Matthias Thanks; --Gurkan 2010/2/18 Matthias Wessendorfmat...@apache.org Pretty harsh :-) IMO JSF2 is doing better here. It just checks if the dependency in question (yeah, javax.validation) is present if not = don't bother... But... I have to say that JSF 2.0 was released _before_ the JAvaEE6 was available. I understand your motivation for closing the ticket, but I wonder if there actual interest in solving this in a more convenient way. Regarding JSF2 and Validation API: Not only JSF2 was there _before_ JavaEE6. Playing nice here is a gained experience when targeting a JAva EE platform (kinda) independent release; Interesting q: -the 299 spec _require_ validator API if yes = OK :) If no = -does weld (candi) also have this *hard* dependency on the javax.validation API ? -Matthias On Thu, Feb 18, 2010 at 2:00 PM, Gurkan Erdogdu
Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator
eh... I mean, I am always in fav of using jul (java.util.logging). In myfaces we also try to get rid of log4j :-) As Mark said jul is OK, but has some downsides, therefore I usually create a tiny logger abstraction on-top of it... -Matthias On Thu, Feb 18, 2010 at 8:31 PM, Matthias Wessendorf mat...@apache.org wrote: +1 on Log4j Not sure on the WebbeansLogger (would need to see the code, before rating in here) I usually tend to add some more convenient methods on-top of jul. -Matthias On Thu, Feb 18, 2010 at 6:58 PM, Joseph Bergmark bergm...@apache.org wrote: +1, but I'm not sure I see the need to remove WebbeansLogger. That provides an abstraction layer on top of whatever logging technology you want to use, which may make switching loggers easier if we needed to in the future. The only down side to the current WebBeansLogger is that the methods are tied pretty closely to log4j logging levels. Sincerely, Joe On Thu, Feb 18, 2010 at 12:37 PM, Mark Struberg strub...@yahoo.de wrote: Hi Paul! +1 and please let's get rid of our WebbeansLogger, since this layer actually hides the _real_ source of the logging :/ LieGrue, strub --- Paul J. Reder rede...@remulak.net schrieb am Do, 18.2.2010: Von: Paul J. Reder rede...@remulak.net Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator An: dev@openwebbeans.apache.org Datum: Donnerstag, 18. Februar, 2010 18:11 Uhr Slightly off-topic, but along these same lines... While working on the logging patches I've submitted, I noticed that OWB uses log4j instead of JDK logging (thus requiring log4j to be pulled in - the link to current topic). Is there a specific reason we're using log4j? Could I submit a patch to migrate to using the JDK logger that is already present? If that is acceptable then I will open a separate JIRA issue and continue discussion there. Thanks, Paul J. Reder On 02/18/2010 11:07 AM, Matthias Wessendorf wrote: On Thu, Feb 18, 2010 at 4:52 PM, Mark Strubergstrub...@yahoo.de wrote: I don't buy this. The only Validator imports in weld are under the main/java/org/jboss/weld/bean/builtin/ee/ and this whole package imo only get's used (and classloaded) if you are running in an EE container. At least that's how I remember that it used to be half a year ago when I looked at weld sources the last time. Also, I don't really care what weld is doing! If we have a way to do this better, then we should do it! So please don't close it, but I agree that this is not a 'bug' and we should change this to 'feature', ok? It would make another really cool OWB feature! +1 not only a cool feature. Actually playing nice with customers (the guys that are supposed to use OWB ;-) ) LieGrue, strub --- Gurkan Erdogducgurkanerdo...@gmail.com schrieb am Do, 18.2.2010: Von: Gurkan Erdogducgurkanerdo...@gmail.com Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator An: dev@openwebbeans.apache.org Datum: Donnerstag, 18. Februar, 2010 14:33 Uhr it says optionaltrue/optional :-) Optional because runtime environment provides this :) IF there is no validation-api it throws ClassNFException as you have got. It means that, if you provide scope as optional and your maven project use it, its optional dependency does not transitively passed to using project. You have to provide explicitly this dependency. 2010/2/18 Matthias Wessendorfmat...@apache.org On Thu, Feb 18, 2010 at 2:24 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: Pretty harsh :-) Not intended :) I know; it wasn't you that wrote the spec :-) he 299 spec _require_ validator API Yes. Look at specification 3.6 Additional Beans does weld (candi) also have this *hard* dependency on the javax.validation API ? For weld -- yes http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml it saysoptionaltrue/optional :-) -Matthias Thanks; --Gurkan 2010/2/18 Matthias Wessendorfmat...@apache.org Pretty harsh :-) IMO JSF2 is doing better here. It just checks if the dependency in question (yeah, javax.validation) is present if not = don't bother... But... I have to say that JSF 2.0 was released _before_ the JAvaEE6 was available. I understand your motivation for closing the ticket, but I wonder if there actual interest in solving this in a more convenient way. Regarding JSF2 and Validation API: Not only JSF2 was there _before_ JavaEE6. Playing nice here is a gained experience when targeting a JAva EE
