; >
> > +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 schrieb am Do, 18.2.2010:
> >
> > > Von: Paul J. R
eansLogger, since this layer
>>> actually hides the _real_ source of the logging :/
>>>
>>> LieGrue,
>>> strub
>>>
>>> --- Paul J. Reder schrieb am Do, 18.2.2010:
>>>
>>> > Von: Paul J. Reder
>>> > Betreff:
; LieGrue,
>> strub
>>
>> --- Paul J. Reder schrieb am Do, 18.2.2010:
>>
>> > Von: Paul J. Reder
>> > Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError:
>> javax/validation/Validator
>> > An: dev@openwebbeans.apache.org
From: Mark Struberg
To: dev@openwebbeans.apache.org
Sent: Thu, February 18, 2010 8:05:04 PM
Subject: 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
pache.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
, 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 schrieb am Do, 18.2.2010:
> Von: Gurkan Erdogdu
> Betreff: Re: [jira] Commented: (OWB-286) java.lang.
: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 lo
pened (and
if you have multiple occurrences of the same log text)
LieGrue,
strub
--- Joseph Bergmark schrieb am Do, 18.2.2010:
> Von: Joseph Bergmark
> Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError:
> javax/validation/Validator
> An: dev@openwebbeans.a
gt; strub
>
> --- Paul J. Reder schrieb am Do, 18.2.2010:
>
> > Von: Paul J. Reder
> > Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError:
> javax/validation/Validator
> > An: dev@openwebbeans.apache.org
> > Datum: Donnerstag, 18. Febru
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 ;-) )
> >
> >>
>
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 schrieb am Do, 18.2.2010:
Von: Gurkan Erdogdu
Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoC
rub
>
>
> --- Gurkan Erdogdu schrieb am Do, 18.2.2010:
>
>> Von: Gurkan Erdogdu
>> Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError:
>> javax/validation/Validator
>> An: dev@openwebbeans.apache.org
>> Datum: Donnerstag, 18. Februar
ake another really cool OWB feature!
LieGrue,
strub
--- Gurkan Erdogdu schrieb am Do, 18.2.2010:
> Von: Gurkan Erdogdu
> Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError:
> javax/validation/Validator
> An: dev@openwebbeans.apache.org
> Datum:
exactly
On Thu, Feb 18, 2010 at 3:40 PM, Joseph Bergmark 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 excep
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 j
>>>it says true :-)
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.
On Thu, Feb 18, 2010 at 2:24 PM, Gurkan Erdogdu
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
>>>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/j
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
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 crea
[
https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835162#action_12835162
]
Mark Struberg commented on OWB-286:
---
too bad, this slipped into webbeans-core.
We have to m
21 matches
Mail list logo