[
https://issues.apache.org/jira/browse/OWB-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835518#action_12835518
]
Sven Linstaedt commented on OWB-288:
Sure, there might more than one proxy instance per cl
[
https://issues.apache.org/jira/browse/OWB-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gurkan Erdogdu closed OWB-279.
--
Resolution: Fixed
> Indirect specialization (4.3.1) throws InconsistentSpecializationException
> -
[
https://issues.apache.org/jira/browse/OWB-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gurkan Erdogdu closed OWB-289.
--
Resolution: Fixed
Fix Version/s: M4
> Owb return 2 beans for Indirect specialized producer beans
>
[
https://issues.apache.org/jira/browse/OWB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gurkan Erdogdu updated OWB-285:
---
Fix Version/s: M4
> Interceptor and Decorator instances must be @Dependent scoped
>
provide SPI for Servlet ContainerLifecycle for better testing support
-
Key: OWB-290
URL: https://issues.apache.org/jira/browse/OWB-290
Project: OpenWebBeans
Issue Type: Imp
[
https://issues.apache.org/jira/browse/OWB-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835437#action_12835437
]
Joe Bergmark commented on OWB-288:
--
We definitely need to do this, but I think we need to be
Owb return 2 beans for Indirect specialized producer beans
--
Key: OWB-289
URL: https://issues.apache.org/jira/browse/OWB-289
Project: OpenWebBeans
Issue Type: Bug
Components:
cache generated Proxiy classes
--
Key: OWB-288
URL: https://issues.apache.org/jira/browse/OWB-288
Project: OpenWebBeans
Issue Type: Improvement
Components: Core
Affects Versions: M3
Repor
[
https://issues.apache.org/jira/browse/OWB-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OWB-287.
---
Resolution: Fixed
> DefaultScannerService should skip WAR checks if no context is given
> --
DefaultScannerService should skip WAR checks if no context is given
---
Key: OWB-287
URL: https://issues.apache.org/jira/browse/OWB-287
Project: OpenWebBeans
Issue Type: Improve
This sounds good to me. No reason not to allow people to use log4j if they
prefer it.
The major thing that jumped out at me as differences in log levels between
Log4j and the JDK logging is that Log4j has both a FATAL and a ERROR, and
JDK logging only really has an SEVERE level that feels equival
what's up with the ArrayList? I'd prefer List..
On Thu, Feb 18, 2010 at 7:36 PM, wrote:
> Author: gerdogdu
> Date: Thu Feb 18 18:36:19 2010
> New Revision: 911515
>
> URL: http://svn.apache.org/viewvc?rev=911515&view=rev
> Log:
> [OWB-284] thanks to YING WANG
>
> Modified:
>
> openwebbeans/
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 w
+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 wrote:
> +1, but I'm not sure I see the need to remove WebbeansLogger. Tha
[
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 be
.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
Nope. For example
private static final WebBeansLogger logger =
WebBeansLogger.getLogger(Boot.class);
public static void main(String[] args)
>>>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
To: dev@openwebbeans.apache.org
>>>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
To: dev@openwebbeans.apache.org
Sent: Thu, February 18, 2010 5:52:01 PM
Subject: Re: [jira] Commented: (
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
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
+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 t
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 schrieb am Do, 18.2.2010:
> Von: Paul J. Reder
> Betreff: Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError:
> java
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 m
[
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 Erdog
On Thu, Feb 18, 2010 at 4:52 PM, Mark Struberg 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 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 wel
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
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 wrote:
> hi,
>
> deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the
> following exception.
>
> I understand that JavaEE has some requirement on
java.lang.NoClassDefFoundError: javax/validation/Validator
--
Key: OWB-286
URL: https://issues.apache.org/jira/browse/OWB-286
Project: OpenWebBeans
Issue Type: Bug
Reporter:
True, we should create an own plugin for Validator injection.
LieGrue,
strub
--- Matthias Wessendorf schrieb am Do, 18.2.2010:
> Von: Matthias Wessendorf
> Betreff: Dependency on javax.validation*
> An: dev@openwebbeans.apache.org
> Datum: Donnerstag, 18. Februar, 2010 11:29 Uhr
> hi,
>
> dep
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 w
I will write a unit test for that. I created this bug mainly do not forget to
check it;)
I debugged through my project and found the same non-injected non-static values
from my TransactionalInterceptor in multiple beans. Actually I was really
surprised that Interceptor worked and my private Thr
39 matches
Mail list logo
