java.lang.NoClassDefFoundError: javax/validation/Validator
--
Key: OWB-286
URL: https://issues.apache.org/jira/browse/OWB-286
Project: OpenWebBeans
Issue Type: Bug
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
[
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
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
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
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*
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
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
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
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
[
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
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
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
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
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]
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:
[
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
+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
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
19 matches
Mail list logo
