[jira] Closed: (OWB-308) minor clean up on specialization code path
[ https://issues.apache.org/jira/browse/OWB-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gurkan Erdogdu closed OWB-308. -- Resolution: Fixed Fix Version/s: M4 > minor clean up on specialization code path > -- > > Key: OWB-308 > URL: https://issues.apache.org/jira/browse/OWB-308 > Project: OpenWebBeans > Issue Type: Bug > Components: Injection and Lookup >Affects Versions: M3 >Reporter: YING WANG >Assignee: Gurkan Erdogdu >Priority: Minor > Fix For: M4 > > Attachments: 308.patch > > > Ran some tests on recent driver and found a few Exceptions fired due to > multiple invocation of bean.setBeanName( ) when configure specialization. > Changes in this patch include: > 1. For class-based specialization, if bean specialization is already > configured, skip setting bean name and populating qualifiers > 2. For producer-based specialization, comment out 2 blocks of > setBeanName/populating qualifiers in old code path, since that is delayed to > configSpecializedProducerMethodBeans() in checkSpecializations step. > 3. Original test case SpecializesProducer1Test will not work, since there is > no container and checkSpecializations( ) is not invoked. > 4. migrate new SpecializesProducer1Test to use a container in newtest package. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
AW: Java EE Independent Core
big +1 :) LieGrue, strub --- Gurkan Erdogdu schrieb am Fr, 26.2.2010: > Von: Gurkan Erdogdu > Betreff: Java EE Independent Core > An: dev@openwebbeans.apache.org > Datum: Freitag, 26. Februar, 2010 01:03 Uhr > Hi; > > As we have discussed some time ago, Mark and some other > folks would like to use OWB without any dependency on Java > EE. I did more than this, and remove all Java EE and Web > dependency from webbeans-impl. It just depends on EL-API > because of BeanManager API uses it. > > Now, it depends on following jars. I have also created some > other projects related with full Java EE and Java Web > technologies. > > Dependent Jars > - > log4j (think to drop it also) > dom4j > javassist > scannotation > geronimo-interceptor-spec > jcdi-api > atinject-api > > New Projects > --- > webbeans-web --> Supports web > webbeans-ee --> Fully EE Environment > webbeans-ee-common --> Some commons > > I will hold it until releasing M4. In the mean time please > do not commit big changes to trunk. > > Thanks; > > --Gurkan > > > > > ___ > Yahoo! Türkiye açıldı! http://yahoo.com.tr > İnternet üzerindeki en iyi içeriği Yahoo! Türkiye > sizlere sunuyor! __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
Java EE Independent Core
Hi; As we have discussed some time ago, Mark and some other folks would like to use OWB without any dependency on Java EE. I did more than this, and remove all Java EE and Web dependency from webbeans-impl. It just depends on EL-API because of BeanManager API uses it. Now, it depends on following jars. I have also created some other projects related with full Java EE and Java Web technologies. Dependent Jars - log4j (think to drop it also) dom4j javassist scannotation geronimo-interceptor-spec jcdi-api atinject-api New Projects --- webbeans-web --> Supports web webbeans-ee --> Fully EE Environment webbeans-ee-common --> Some commons I will hold it until releasing M4. In the mean time please do not commit big changes to trunk. Thanks; --Gurkan ___ Yahoo! Türkiye açıldı! http://yahoo.com.tr İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
[jira] Commented: (OWB-309) signature check for @Interceptors-enabled interceptors is too strict
[
https://issues.apache.org/jira/browse/OWB-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838590#action_12838590
]
David Blevins commented on OWB-309:
---
And here's how we have that implemented in OpenEJB
Obviously this is for the InvocationContext impl
{code}
public Object proceed() throws Exception {
// The bulk of the logic of this method has intentionally been moved
// out so stepping through a large stack in a debugger can be done
quickly.
// Simply put one break point on 'next.invoke()' or one inside that
method.
try {
Invocation next = next();
return next.invoke();
} catch (InvocationTargetException e) {
throw unwrapInvocationTargetException(e);
}
}
/**
* Business method interceptors can only throw exception allowed by the
target business method.
* Lifecycle interceptors can only throw RuntimeException.
* @param e the invocation target exception of a reflection method invoke
* @return the cause of the exception
* @throws AssertionError if the cause is not an Exception or Error.
*/
private Exception unwrapInvocationTargetException(InvocationTargetException
e) {
Throwable cause = e.getCause();
if (cause == null) {
return e;
} else if (cause instanceof Exception) {
return (Exception) cause;
} else if (cause instanceof Error) {
throw (Error) cause;
} else {
throw new AssertionError(cause);
}
}
{code}
> signature check for @Interceptors-enabled interceptors is too strict
>
>
> Key: OWB-309
> URL: https://issues.apache.org/jira/browse/OWB-309
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Interceptor and Decorators
>Affects Versions: M3
>Reporter: Eric Covener
>Assignee: Eric Covener
>Priority: Minor
> Fix For: M4
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Sometimes having the wrong kind of signature (defined in bean class vs.
> defined in an interceptor) just means the method is n/a to the current bean
> we're looking at. Don't throw an exception for an unexpected
> InvocationContext, just don't enable the method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-307) InvocationContext.setParameters() and primitive vs. wrapped types
[
https://issues.apache.org/jira/browse/OWB-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838586#action_12838586
]
David Blevins commented on OWB-307:
---
Here's the code we have in OpenEJB for setParameters, The boxing/uboxing
should happen automatically at the vm level, but we do check types are
respected.
public void setParameters(Object[] parameters) {
if (operation.isCallback()) {
throw new IllegalStateException(getIllegalParameterAccessMessage());
}
if (parameters == null) throw new NullPointerException("parameters is
null");
if (parameters.length != this.parameters.length) {
throw new IllegalArgumentException("Expected " +
this.parameters.length + " parameters, but only got " + parameters.length + "
parameters");
}
for (int i = 0; i < parameters.length; i++) {
Object parameter = parameters[i];
Class parameterType = parameterTypes[i];
if (parameter == null) {
if (parameterType.isPrimitive()) {
throw new IllegalArgumentException("Expected parameter " +
i + " to be primitive type " + parameterType.getName() +
", but got a parameter that is null");
}
} else if (!parameterType.isInstance(parameter)) {
throw new IllegalArgumentException("Expected parameter " + i +
" to be of type " + parameterType.getName() +
", but got a parameter of type " +
parameter.getClass().getName());
}
}
System.arraycopy(parameters, 0, this.parameters, 0, parameters.length);
}
> InvocationContext.setParameters() and primitive vs. wrapped types
> -
>
> Key: OWB-307
> URL: https://issues.apache.org/jira/browse/OWB-307
> Project: OpenWebBeans
> Issue Type: Bug
>Affects Versions: M3
>Reporter: Eric Covener
>Assignee: Gurkan Erdogdu
> Fix For: 1.0.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> right now setParameters() on a method with primtiive types does not permit
> the wrapped types to be set.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-309) signature check for @Interceptors-enabled interceptors is too strict
signature check for @Interceptors-enabled interceptors is too strict Key: OWB-309 URL: https://issues.apache.org/jira/browse/OWB-309 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M3 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: M4 Sometimes having the wrong kind of signature (defined in bean class vs. defined in an interceptor) just means the method is n/a to the current bean we're looking at. Don't throw an exception for an unexpected InvocationContext, just don't enable the method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-306) overrridden @AroundInvoke and lifecycle interceptors are still run
[
https://issues.apache.org/jira/browse/OWB-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838579#action_12838579
]
David Blevins commented on OWB-306:
---
Here is the basic code we use in OpenEJB for this. Essentially all annotated
methods we find are collected as CallbackInfo objects (that part is not
important) then we go back and find the first method of that name+params by
starting at the top of the inheritance and going backwards till we hit
something (important) then we check to see if the declaring classes are the
same, if they are not we throw the entry away as that means the method was
overridden in a subclass. We don't need to check if that method itself is
annotated with the callback annotation because if it was there will be another
CallbackInfo in the list for it, so we can just ignore that aspect and let it
be found when it comes up in the list.
{code}
public static class CallbackInfo extends InfoObject {
public String className;
public String method;
}
/**
* Used for getting the java.lang.reflect.Method objects for the following
callbacks:
*
* - @PostConstruct void (InvocationContext)
* - @PreDestroy void (InvocationContext)
* - @PrePassivate void (InvocationContext)
* - @PostActivate void (InvocationContext)
* - @AroundInvoke Object (InvocationContext)
throws Exception
*
* @param clazz
* @param callbackInfos the raw CallbackInfo objects
* @param methods the collection where the created methods will be placed
*/
private void toMethods(Class clazz, List callbackInfos,
List methods) {
for (CallbackInfo callbackInfo : callbackInfos) {
try {
Method method = getMethod(clazz, callbackInfo.method,
InvocationContext.class);
if (callbackInfo.className == null &&
method.getDeclaringClass().equals(clazz)){
methods.add(method);
}
if
(method.getDeclaringClass().getName().equals(callbackInfo.className)){
methods.add(method);
}
} catch (NoSuchMethodException e) {
logger.warning("Interceptor method not found (skipping): public
Object " + callbackInfo.method + "(InvocationContext); in class " +
clazz.getName());
}
}
// I can't remember why we sort them, think it's just for easy debugging
Collections.sort(methods, new MethodCallbackComparator());
}
/**
* Used by toMethods and toCallbacks to find the nearest
java.lang.reflect.Method with the given
* name and parameters. Callbacks can be private so class.getMethod()
cannot be used. Searching
* starts by looking in the specified class, if the method is not found
searching continues with
* the immediate parent and continues recurssively until the method is
found or java.lang.Object
* is reached. If the method is not found a NoSuchMethodException is
thrown.
*
* @param clazz
* @param methodName
* @param parameterTypes
* @return
* @throws NoSuchMethodException if the method is not found in this class
or any of its parent classes
*/
private Method getMethod(Class clazz, String methodName, Class...
parameterTypes) throws NoSuchMethodException {
NoSuchMethodException original = null;
while (clazz != null){
try {
Method method = clazz.getDeclaredMethod(methodName,
parameterTypes);
return SetAccessible.on(method);
} catch (NoSuchMethodException e) {
if (original == null) original = e;
}
clazz = clazz.getSuperclass();
}
throw original;
}
{code}
> overrridden @AroundInvoke and lifecycle interceptors are still run
> --
>
> Key: OWB-306
> URL: https://issues.apache.org/jira/browse/OWB-306
> Project: OpenWebBeans
> Issue Type: Bug
>Affects Versions: M3
>Reporter: Eric Covener
>Assignee: Eric Covener
> Fix For: 1.0.0
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> Interceptor spec says:
> ---
> If an around-invoke method is overridden by another method (regardless of
> whether that method is itself an around-invoke method), it will not be
> invoked.
> If a lifecycle callback interceptor method is overridden by another method
> (regardless of whether that
> method is itself a lifecycle callback interceptor method (of the same or
> different type)), it will not be
> invoked.
> ---
> I don't have a fix for this issue, but it is at least conceptually pretty
> easy to grok.
> It seems that we can't just check the stack or even all enabled interceptors
--
This message is automatically gene
[jira] Updated: (OWB-308) minor clean up on specialization code path
[ https://issues.apache.org/jira/browse/OWB-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YING WANG updated OWB-308: -- Attachment: 308.patch upload patch. > minor clean up on specialization code path > -- > > Key: OWB-308 > URL: https://issues.apache.org/jira/browse/OWB-308 > Project: OpenWebBeans > Issue Type: Bug > Components: Injection and Lookup >Affects Versions: M3 >Reporter: YING WANG >Assignee: Gurkan Erdogdu >Priority: Minor > Attachments: 308.patch > > > Ran some tests on recent driver and found a few Exceptions fired due to > multiple invocation of bean.setBeanName( ) when configure specialization. > Changes in this patch include: > 1. For class-based specialization, if bean specialization is already > configured, skip setting bean name and populating qualifiers > 2. For producer-based specialization, comment out 2 blocks of > setBeanName/populating qualifiers in old code path, since that is delayed to > configSpecializedProducerMethodBeans() in checkSpecializations step. > 3. Original test case SpecializesProducer1Test will not work, since there is > no container and checkSpecializations( ) is not invoked. > 4. migrate new SpecializesProducer1Test to use a container in newtest package. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-308) minor clean up on specialization code path
minor clean up on specialization code path -- Key: OWB-308 URL: https://issues.apache.org/jira/browse/OWB-308 Project: OpenWebBeans Issue Type: Bug Components: Injection and Lookup Affects Versions: M3 Reporter: YING WANG Assignee: Gurkan Erdogdu Priority: Minor Ran some tests on recent driver and found a few Exceptions fired due to multiple invocation of bean.setBeanName( ) when configure specialization. Changes in this patch include: 1. For class-based specialization, if bean specialization is already configured, skip setting bean name and populating qualifiers 2. For producer-based specialization, comment out 2 blocks of setBeanName/populating qualifiers in old code path, since that is delayed to configSpecializedProducerMethodBeans() in checkSpecializations step. 3. Original test case SpecializesProducer1Test will not work, since there is no container and checkSpecializations( ) is not invoked. 4. migrate new SpecializesProducer1Test to use a container in newtest package. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-307) InvocationContext.setParameters() and primitive vs. wrapped types
InvocationContext.setParameters() and primitive vs. wrapped types - Key: OWB-307 URL: https://issues.apache.org/jira/browse/OWB-307 Project: OpenWebBeans Issue Type: Bug Affects Versions: M3 Reporter: Eric Covener Assignee: Gurkan Erdogdu Fix For: 1.0.0 right now setParameters() on a method with primtiive types does not permit the wrapped types to be set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-306) overrridden @AroundInvoke and lifecycle interceptors are still run
overrridden @AroundInvoke and lifecycle interceptors are still run -- Key: OWB-306 URL: https://issues.apache.org/jira/browse/OWB-306 Project: OpenWebBeans Issue Type: Bug Affects Versions: M3 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0 Interceptor spec says: --- If an around-invoke method is overridden by another method (regardless of whether that method is itself an around-invoke method), it will not be invoked. If a lifecycle callback interceptor method is overridden by another method (regardless of whether that method is itself a lifecycle callback interceptor method (of the same or different type)), it will not be invoked. --- I don't have a fix for this issue, but it is at least conceptually pretty easy to grok. It seems that we can't just check the stack or even all enabled interceptors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: AW: svn commit: r916274 - in /openwebbeans/trunk/webbeans-impl/src: main/java/org/apache/webbeans/annotation/ main/java/org/apache/webbeans/decorator/ main/java/org/apache/webbeans/inject/instance
Thanks, will check it out!
The problem did occur in my real world application so I should try translate
this scenario into a test.
LieGrue,
strub
--- Gurkan Erdogdu schrieb am Do, 25.2.2010:
> Von: Gurkan Erdogdu
> Betreff: Re: AW: svn commit: r916274 - in
> /openwebbeans/trunk/webbeans-impl/src:
> main/java/org/apache/webbeans/annotation/
> main/java/org/apache/webbeans/decorator/
> main/java/org/apache/webbeans/inject/instance/
> main/java/org/apache/webbeans/util/ test/java/org/apache/w...
> An: dev@openwebbeans.apache.org
> Datum: Donnerstag, 25. Februar, 2010 18:54 Uhr
> Mark;
>
> Seems that your test case is implemented wrongly! I have
> committed changes and test run succesfully.
>
> Please check it!
>
> --Gurkan
>
>
>
>
>
> From: Mark Struberg
> To: dev@openwebbeans.apache.org
> Sent: Thu, February 25, 2010 3:08:13 PM
> Subject: AW: svn commit: r916274 - in
> /openwebbeans/trunk/webbeans-impl/src:
> main/java/org/apache/webbeans/annotation/
> main/java/org/apache/webbeans/decorator/
> main/java/org/apache/webbeans/inject/instance/
> main/java/org/apache/webbeans/util/
> test/java/org/apache/w...
>
> Hi!
>
> usually I don't commits which break the tests, but this is
> really an outstanding blocker. Basically all ProducerMethods
> are not working anymore as far as I saw.
>
> Looks like it has something to do with the
> ParameterizedType.
>
> Gurkan, can we look at this together in the evening
> please?
>
> LieGrue,
> strub
>
> --- strub...@apache.org
>
> schrieb am Do, 25.2.2010:
>
> > Von: strub...@apache.org
>
> > Betreff: svn commit: r916274 - in
> /openwebbeans/trunk/webbeans-impl/src:
> main/java/org/apache/webbeans/annotation/
> main/java/org/apache/webbeans/decorator/
> main/java/org/apache/webbeans/inject/instance/
> main/java/org/apache/webbeans/util/
> test/java/org/apache/w...
> > An: comm...@openwebbeans.apache.org
> > Datum: Donnerstag, 25. Februar, 2010 14:00 Uhr
> > Author: struberg
> > Date: Thu Feb 25 13:00:29 2010
> > New Revision: 916274
> >
> > URL: http://svn.apache.org/viewvc?rev=916274&view=rev
> > Log:
> > OWB-304 add test for broken behaviour
> >
> > + a few cleanup tasks
> >
> > Added:
> >
> >
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/profields/beans/InformationConsumerBean.java
> > Modified:
> >
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> >
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> >
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
> >
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/util/WebBeansAnnotatedTypeUtil.java
> >
> >
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/AbstractUnitTest.java
> >
> >
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/injection/typeliteral/TypeLiteralTest.java
> >
> >
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/profields/GetterStringInjectorTest.java
> >
> > Modified:
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> > URL:
> > http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java?rev=916274&r1=916273&r2=916274&view=diff
> >
> ==
> > ---
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> > (original)
> > +++
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> > Thu Feb 25 13:00:29 2010
> > @@ -25,6 +25,16 @@
> > public class NamedLiteral extends
> > AnnotationLiteral implements Named
> > {
> > private String value;
> > +
> > + public NamedLiteral()
> > + {
> > +
> > + }
> > +
> > + public NamedLiteral(String value)
> > + {
> > + this.value = value;
> > + }
> >
> > @Override
> > public String value()
> >
> > Modified:
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> > URL:
> > http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java?rev=916274&r1=916273&r2=916274&view=diff
> >
> ==
> > ---
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> > (original)
> > +++
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> > Thu Feb 25 13:00:29 2010
> > @@ -26,7 +26,6 @@
> > import javax.enterprise.inject.spi.Decorator;
> >
> > import
> >
> org.apache.webbeans.component
Re: AW: svn commit: r916274 - in /openwebbeans/trunk/webbeans-impl/src: main/java/org/apache/webbeans/annotation/ main/java/org/apache/webbeans/decorator/ main/java/org/apache/webbeans/inject/instance
Mark;
Seems that your test case is implemented wrongly! I have committed changes and
test run succesfully.
Please check it!
--Gurkan
From: Mark Struberg
To: dev@openwebbeans.apache.org
Sent: Thu, February 25, 2010 3:08:13 PM
Subject: AW: svn commit: r916274 - in /openwebbeans/trunk/webbeans-impl/src:
main/java/org/apache/webbeans/annotation/
main/java/org/apache/webbeans/decorator/
main/java/org/apache/webbeans/inject/instance/
main/java/org/apache/webbeans/util/ test/java/org/apache/w...
Hi!
usually I don't commits which break the tests, but this is really an
outstanding blocker. Basically all ProducerMethods are not working anymore as
far as I saw.
Looks like it has something to do with the ParameterizedType.
Gurkan, can we look at this together in the evening please?
LieGrue,
strub
--- strub...@apache.org schrieb am Do, 25.2.2010:
> Von: strub...@apache.org
> Betreff: svn commit: r916274 - in /openwebbeans/trunk/webbeans-impl/src:
> main/java/org/apache/webbeans/annotation/
> main/java/org/apache/webbeans/decorator/
> main/java/org/apache/webbeans/inject/instance/
> main/java/org/apache/webbeans/util/ test/java/org/apache/w...
> An: comm...@openwebbeans.apache.org
> Datum: Donnerstag, 25. Februar, 2010 14:00 Uhr
> Author: struberg
> Date: Thu Feb 25 13:00:29 2010
> New Revision: 916274
>
> URL: http://svn.apache.org/viewvc?rev=916274&view=rev
> Log:
> OWB-304 add test for broken behaviour
>
> + a few cleanup tasks
>
> Added:
>
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/profields/beans/InformationConsumerBean.java
> Modified:
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/util/WebBeansAnnotatedTypeUtil.java
>
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/AbstractUnitTest.java
>
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/injection/typeliteral/TypeLiteralTest.java
>
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/profields/GetterStringInjectorTest.java
>
> Modified:
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java?rev=916274&r1=916273&r2=916274&view=diff
> ==
> ---
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> (original)
> +++
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> Thu Feb 25 13:00:29 2010
> @@ -25,6 +25,16 @@
> public class NamedLiteral extends
> AnnotationLiteral implements Named
> {
> private String value;
> +
> +public NamedLiteral()
> +{
> +
> +}
> +
> +public NamedLiteral(String value)
> +{
> +this.value = value;
> +}
>
> @Override
> public String value()
>
> Modified:
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java?rev=916274&r1=916273&r2=916274&view=diff
> ==
> ---
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> (original)
> +++
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> Thu Feb 25 13:00:29 2010
> @@ -26,7 +26,6 @@
> import javax.enterprise.inject.spi.Decorator;
>
> import
> org.apache.webbeans.component.AbstractInjectionTargetBean;
> -import org.apache.webbeans.component.ManagedBean;
> import org.apache.webbeans.config.OWBLogConst;
> import org.apache.webbeans.container.BeanManagerImpl;
> import
> org.apache.webbeans.exception.WebBeansConfigurationException;
>
> Modified:
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
> URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java?rev=916274&r1=916273&r2=916274&view=diff
> ==
> ---
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
> (original)
> +++
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceIm
Re: TCK Report Before M4
I have confirmed that these are bug in TCK. org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingBeanConstructor.DecoratorWithNonPassivatingBeanConstructorTest --> Seems a bug in TCK org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInitializerMethod.DecoratorWithNonPassivatingInitializerMethodTest --> Seems a bug in TCK org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInjectedField.DecoratorWithNonPassivatingInjectedFieldTest--> Seems a bug in TCK --Gurkan From: Gurkan Erdogdu To: dev@openwebbeans.apache.org Sent: Wed, February 24, 2010 9:39:08 PM Subject: TCK Report Before M4 Hello folks; I have been working on standalone TCK (standalone means that not running in container but includes EJB tests using OpenEJB) for a long time and decreased the number of failed tests considerably. Some of those failed tests are related with CDI-TCK bug and reported to CDI-TCK team. Some of them are not correctlyy implemented in OWB. I give the failed tests and their reasons why they have failed: I have so tired and I invite all of you to help me to pass it :) Working on TCK likes walking on spiny road. Please create a JIRA for any test you want to work on to pass it :) I have tested with the CDI-TCK 1.0.1-Final, and I have used TestNG plugin for Eclipse. Please do not commit big changes to current code base. I will start to release procedure by tomorrow evening maybe Saturday. Total Test: 582 Failed Test: 28 Thanks; --Gurkan org.jboss.jsr299.tck.tests.lookup.byname.duplicatePrefixResolution.DuplicateNamePrefixResolutionTest --> NOT IMPLEMENTED (EL Names) org.jboss.jsr299.tck.tests.lookup.typesafe.resolution.ResolutionByTypeTest --> I really do not understand. Sometimes work, sometimes not org.jboss.jsr299.tck.tests.lookup.byname.duplicateNameResolution.DuplicateNameResolutionTest -->NOT IMPLMENTED (EL Names) org.jboss.jsr299.tck.tests.lookup.circular.CircularDependencyTest org.jboss.jsr299.tck.tests.lookup.injectionpoint.InjectionPointTest --> InjectionPoint with Decorators delegate problem! <--OpenEJB Does not support beans without definining interface> org.jboss.jsr299.tck.tests.implementation.enterprise.broken.singletonWithSessionScope.SingletonWithSessionScopeTest -->NOT CLient Interface org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest -->NOT ClientInterface -->NOT CLient Interface org.jboss.jsr299.tck.tests.implementation.enterprise.broken.singletonWithRequestScope.SingletonWithRequestScopeTest -->NOT CLient Interface org.jboss.jsr299.tck.tests.context.dependent.DependentContextTest org.jboss.jsr299.tck.tests.context.passivating.broken.enterpriseBeanWithNonPassivatingInjectedFieldInInterceptor.EnterpriseBeanWithNonPassivatingInjectedFieldInInterceptorTest --> EJB Interceptor Injections Not Supported org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingBeanConstructor.DecoratorWithNonPassivatingBeanConstructorTest --> Seems a bug in TCK org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInitializerMethod.DecoratorWithNonPassivatingInitializerMethodTest --> Seems a bug in TCK org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInjectedField.DecoratorWithNonPassivatingInjectedFieldTest--> Seems a bug in TCK org.jboss.jsr299.tck.tests.context.passivating.broken.passivatingProducerMethodWithNonPassivatingParameter.PassivatingProducerMethodWithNonPassivatingParameterTest org.jboss.jsr299.tck.tests.event.observer.wildcardAndTypeVariable.ObserverMethodWithParametertizedTypeTest org.jboss.jsr299.tck.tests.extensions.beanManager.BeanManagerTest --> CDITCK-121 org.jboss.jsr299.tck.tests.decorators.invocation.DecoratorInvocationTest org.jboss.jsr299.tck.tests.decorators.resolution.DecoratorResolutionTest org.jboss.jsr299.tck.tests.inheritance.specialization.simple.broken.extendejb.testSpecializingClassDirectlyExtendsEnterpriseBean org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsSimpleBean.DirectlyExtendsSimpleBeanTest org.jboss.jsr299.tck.tests.inheritance.specialization.producer.method.ProducerMethodSpecializationTest org.jboss.jsr299.tck.tests.inheritance.specialization.simple.broken.extendejb.SpecializingBeanExtendsEnterpriseBeanTest ___ Yahoo! Türkiye açıldı! http://yahoo.com.tr İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor! ___ Yahoo! Türkiye açıldı! http://yahoo.com.tr İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
[jira] Closed: (OWB-302) InjectionPoint injections (both method and field based) in Decorators result in null
[ https://issues.apache.org/jira/browse/OWB-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bergmark closed OWB-302. Resolution: Not A Problem This appears to be the correct behavior based on the way we have Decorators implemented. To summarize, Decorators are not directly injected into the InjectionPoint that resolves to the Bean they decorate. As they are not injected, then @Inject InjectionPoint should be null inside a Decorator. Similarly the second Decorator in the chain is not directly injected into the first, so @Inject InjectionPont should also be null inside subsequent Decorators. Instead we have a MethodHandler that gets called when the decorated bean is invoked that handles the call stack for the Decorator chain. This approach seems to break the way the TCK is trying to verify the Decorator call stack. > InjectionPoint injections (both method and field based) in Decorators result > in null > > > Key: OWB-302 > URL: https://issues.apache.org/jira/browse/OWB-302 > Project: OpenWebBeans > Issue Type: Bug > Components: Interceptor and Decorators >Affects Versions: M3 >Reporter: Joe Bergmark >Assignee: Joe Bergmark > Fix For: 1.0.0 > > > InjectionPoint injections in Decorators result in null. This appears to be a > recent behavior change, previously the > javax.enterprise.inject.spi.InjectionPoint would be injected but would > reference the Decorator itself rather than the bean it was decorating. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSSION] Using of Logginf in OWB
Actually yes but it also adds extra jars. Instead of adding extra jars could we use it with reflection mechanism? WDYT? If it really needs a jar on classpath, then I think we can live with it. I am also +1 on using slf4j after reading some documents :) Thanks; --Gurkan 2010/2/25 James Carman > -1 to #3, why re-invent the wheel? It's more code that you have to > implement, test, maintain, and enhance. > > +1 to #2 and SLF4J > > On Thu, Feb 25, 2010 at 2:11 AM, Gurkan Erdogdu > wrote: > > Hi; > > > > Last couple of days there were some good discussion on how to proceed > with > > logging in OWB. There are some approaches: > > > > 1* Remove any hard log dependency library from classpath(For example : > > removing log4.jar from classpath) and use java logging. > > 2* Use some third-party facades, for example using commons-logging and > slf4j > > etc. I read many complaints about using commons-logging in projects > because > > of classloading issues and memory leaks etc. But no knowledge on using > > slf4j. > > 3* Define our own interface and implement it with other logger > frameworks. > > At runtime, OWB selects which one to use. > > > > Related issue is : http://issues.apache.org/jira/browse/OWB-300 > > > > My Comment: > > -- > > I do not think that using only standard java logging is good. Clients > want > > to use other logging frameworks with OWB replacing standard java logging. > > But also, I do not want that logging will be the most complex part of the > > OWB. Logging must be simple. > > > > Instead of using third party libraries and their jars (managing their > jars, > > adding extra classpath jars etc.), I just want to create a our own simple > > facade(interface),and implement it with "log4j" and "java logging". But > > log4j.jar will be optional in "pom.xml" therefore there is no hard > > dependency to log4j.jar. After that we can provide configuration options > to > > clients which logging framework they use. (Using system properties, owb > > configuration file etc.).Standard logging will be Java Logging. If anyone > > really wants to use another logging framework, it must implement and > > contribute :) > > > > +1 for the item (3) > > > > > > WDYT? > > > > --Gurkan > > > -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
Re: svn commit: r916274 - in /openwebbeans/trunk/webbeans-impl/src: main/java/org/apache/webbeans/annotation/ main/java/org/apache/webbeans/decorator/ main/java/org/apache/webbeans/inject/instance/
Hello Mark;
This can be resulted from updated NamedLiteral. Please try with inverting
change?
Sure, we can look at the evening!
thanks;
--Gurkan
2010/2/25 Mark Struberg
> Hi!
>
> usually I don't commits which break the tests, but this is really an
> outstanding blocker. Basically all ProducerMethods are not working anymore
> as far as I saw.
>
> Looks like it has something to do with the ParameterizedType.
>
> Gurkan, can we look at this together in the evening please?
>
> LieGrue,
> strub
>
> --- strub...@apache.org schrieb am Do, 25.2.2010:
>
> > Von: strub...@apache.org
> > Betreff: svn commit: r916274 - in /openwebbeans/trunk/webbeans-impl/src:
> main/java/org/apache/webbeans/annotation/
> main/java/org/apache/webbeans/decorator/
> main/java/org/apache/webbeans/inject/instance/
> main/java/org/apache/webbeans/util/ test/java/org/apache/w...
> > An: comm...@openwebbeans.apache.org
> > Datum: Donnerstag, 25. Februar, 2010 14:00 Uhr
> > Author: struberg
> > Date: Thu Feb 25 13:00:29 2010
> > New Revision: 916274
> >
> > URL: http://svn.apache.org/viewvc?rev=916274&view=rev
> > Log:
> > OWB-304 add test for broken behaviour
> >
> > + a few cleanup tasks
> >
> > Added:
> >
> >
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/profields/beans/InformationConsumerBean.java
> > Modified:
> >
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> >
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> >
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
> >
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/util/WebBeansAnnotatedTypeUtil.java
> >
> >
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/AbstractUnitTest.java
> >
> >
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/injection/typeliteral/TypeLiteralTest.java
> >
> >
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/profields/GetterStringInjectorTest.java
> >
> > Modified:
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> > URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java?rev=916274&r1=916273&r2=916274&view=diff
> >
> ==
> > ---
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> > (original)
> > +++
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> > Thu Feb 25 13:00:29 2010
> > @@ -25,6 +25,16 @@
> > public class NamedLiteral extends
> > AnnotationLiteral implements Named
> > {
> > private String value;
> > +
> > +public NamedLiteral()
> > +{
> > +
> > +}
> > +
> > +public NamedLiteral(String value)
> > +{
> > +this.value = value;
> > +}
> >
> > @Override
> > public String value()
> >
> > Modified:
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> > URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java?rev=916274&r1=916273&r2=916274&view=diff
> >
> ==
> > ---
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> > (original)
> > +++
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> > Thu Feb 25 13:00:29 2010
> > @@ -26,7 +26,6 @@
> > import javax.enterprise.inject.spi.Decorator;
> >
> > import
> > org.apache.webbeans.component.AbstractInjectionTargetBean;
> > -import org.apache.webbeans.component.ManagedBean;
> > import org.apache.webbeans.config.OWBLogConst;
> > import org.apache.webbeans.container.BeanManagerImpl;
> > import
> > org.apache.webbeans.exception.WebBeansConfigurationException;
> >
> > Modified:
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
> > URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java?rev=916274&r1=916273&r2=916274&view=diff
> >
> ==
> > ---
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
> > (original)
> > +++
> >
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
> > Thu Feb 25 13:00:29 2010
> > @@ -38,6 +38,8 @@
> > */
> > class InstanceImpl implements Instance,
> > Serializable
> > {
> > +private static final long serialVe
AW: svn commit: r916274 - in /openwebbeans/trunk/webbeans-impl/src: main/java/org/apache/webbeans/annotation/ main/java/org/apache/webbeans/decorator/ main/java/org/apache/webbeans/inject/instance/ ma
Hi!
usually I don't commits which break the tests, but this is really an
outstanding blocker. Basically all ProducerMethods are not working anymore as
far as I saw.
Looks like it has something to do with the ParameterizedType.
Gurkan, can we look at this together in the evening please?
LieGrue,
strub
--- strub...@apache.org schrieb am Do, 25.2.2010:
> Von: strub...@apache.org
> Betreff: svn commit: r916274 - in /openwebbeans/trunk/webbeans-impl/src:
> main/java/org/apache/webbeans/annotation/
> main/java/org/apache/webbeans/decorator/
> main/java/org/apache/webbeans/inject/instance/
> main/java/org/apache/webbeans/util/ test/java/org/apache/w...
> An: comm...@openwebbeans.apache.org
> Datum: Donnerstag, 25. Februar, 2010 14:00 Uhr
> Author: struberg
> Date: Thu Feb 25 13:00:29 2010
> New Revision: 916274
>
> URL: http://svn.apache.org/viewvc?rev=916274&view=rev
> Log:
> OWB-304 add test for broken behaviour
>
> + a few cleanup tasks
>
> Added:
>
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/profields/beans/InformationConsumerBean.java
> Modified:
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/util/WebBeansAnnotatedTypeUtil.java
>
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/AbstractUnitTest.java
>
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/injection/typeliteral/TypeLiteralTest.java
>
> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/profields/GetterStringInjectorTest.java
>
> Modified:
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java?rev=916274&r1=916273&r2=916274&view=diff
> ==
> ---
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> (original)
> +++
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/NamedLiteral.java
> Thu Feb 25 13:00:29 2010
> @@ -25,6 +25,16 @@
> public class NamedLiteral extends
> AnnotationLiteral implements Named
> {
> private String value;
> +
> + public NamedLiteral()
> + {
> +
> + }
> +
> + public NamedLiteral(String value)
> + {
> + this.value = value;
> + }
>
> �...@override
> public String value()
>
> Modified:
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java?rev=916274&r1=916273&r2=916274&view=diff
> ==
> ---
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> (original)
> +++
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DecoratorUtil.java
> Thu Feb 25 13:00:29 2010
> @@ -26,7 +26,6 @@
> import javax.enterprise.inject.spi.Decorator;
>
> import
> org.apache.webbeans.component.AbstractInjectionTargetBean;
> -import org.apache.webbeans.component.ManagedBean;
> import org.apache.webbeans.config.OWBLogConst;
> import org.apache.webbeans.container.BeanManagerImpl;
> import
> org.apache.webbeans.exception.WebBeansConfigurationException;
>
> Modified:
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
> URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java?rev=916274&r1=916273&r2=916274&view=diff
> ==
> ---
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
> (original)
> +++
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
> Thu Feb 25 13:00:29 2010
> @@ -38,6 +38,8 @@
> */
> class InstanceImpl implements Instance,
> Serializable
> {
> + private static final long serialVersionUID =
> -8401944412490389024L;
> +
> /** Injected class type */
> private Type injectionClazz;
>
>
> Modified:
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/util/WebBeansAnnotatedTypeUtil.java
> URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/util/WebBeansAnnotatedTypeUtil.ja
[jira] Created: (OWB-304) Beans from a ProducerMethods don't get injected anymore
Beans from a ProducerMethods don't get injected anymore
---
Key: OWB-304
URL: https://issues.apache.org/jira/browse/OWB-304
Project: OpenWebBeans
Issue Type: Bug
Components: Injection and Lookup
Affects Versions: M3
Reporter: Mark Struberg
Assignee: Mark Struberg
Priority: Blocker
Fix For: M4
Beans from a ProducerMethods don't get injected anymore
a method
@Produces TypeA makeTypeA() { return new TypeA(); }
don't get injected into
@Inject TypeA tA;
currently.
This used to work until recently
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Producer Method problem
Folks, it seems we introduced a problem with our handling of ProducerMethods recently. A few Beans in my productional setup don't get created anymore. I'm trying to pin this down in a unit test this afternoon. LieGrue, strub __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
[jira] Commented: (OWB-300) Currently OWB requires log4j for logging. This patch provides a means of choosing other loggers.
[ https://issues.apache.org/jira/browse/OWB-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838322#action_12838322 ] Ceki Gulcu commented on OWB-300: If every framework had its own logging abstraction, the user would need to deal with each separately wasting time and energy. > Currently OWB requires log4j for logging. This patch provides a means of > choosing other loggers. > > > Key: OWB-300 > URL: https://issues.apache.org/jira/browse/OWB-300 > Project: OpenWebBeans > Issue Type: Improvement > Components: Core >Affects Versions: M4 > Environment: All >Reporter: Paul J. Reder >Assignee: Gurkan Erdogdu >Priority: Minor > Fix For: M4 > > Attachments: OWBLoggerOnly.patch > > > Currently OWB requires (is dependent on) log4j for logging. This patch > provides a means of choosing other loggers (thus reducing the number of > dependencies but allowing flexibility). Notably, the patch switches the > logging code to using the JDK java util logging (which is already available > for other reasons). The patch includes comments to show how to maintain log4j > use or use it as a model to enable other logging libs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSSION] Using of Logginf in OWB
-1 to #3, why re-invent the wheel? It's more code that you have to implement, test, maintain, and enhance. +1 to #2 and SLF4J On Thu, Feb 25, 2010 at 2:11 AM, Gurkan Erdogdu wrote: > Hi; > > Last couple of days there were some good discussion on how to proceed with > logging in OWB. There are some approaches: > > 1* Remove any hard log dependency library from classpath(For example : > removing log4.jar from classpath) and use java logging. > 2* Use some third-party facades, for example using commons-logging and slf4j > etc. I read many complaints about using commons-logging in projects because > of classloading issues and memory leaks etc. But no knowledge on using > slf4j. > 3* Define our own interface and implement it with other logger frameworks. > At runtime, OWB selects which one to use. > > Related issue is : http://issues.apache.org/jira/browse/OWB-300 > > My Comment: > -- > I do not think that using only standard java logging is good. Clients want > to use other logging frameworks with OWB replacing standard java logging. > But also, I do not want that logging will be the most complex part of the > OWB. Logging must be simple. > > Instead of using third party libraries and their jars (managing their jars, > adding extra classpath jars etc.), I just want to create a our own simple > facade(interface),and implement it with "log4j" and "java logging". But > log4j.jar will be optional in "pom.xml" therefore there is no hard > dependency to log4j.jar. After that we can provide configuration options to > clients which logging framework they use. (Using system properties, owb > configuration file etc.).Standard logging will be Java Logging. If anyone > really wants to use another logging framework, it must implement and > contribute :) > > +1 for the item (3) > > > WDYT? > > --Gurkan >
[jira] Created: (OWB-303) upgrade Javassist to a newer version
upgrade Javassist to a newer version Key: OWB-303 URL: https://issues.apache.org/jira/browse/OWB-303 Project: OpenWebBeans Issue Type: Bug Components: Lifecycle Affects Versions: M3 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.0.0 The javassist version we currently use (3.11.0.GA) creates permgenspace leaks and looses the configured MethodHandler on de-serialization. We should upgrade to a new version if available. The library currently has 2 problems 1.) serialization doesn't work (looses the MethodHandler) 2.) the internal cache is broken, so we should disable it. This has no impact on OWB, since we already cache generated proxy classes ourselfs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
AW: [DISCUSSION] Performance of OWB
+1 on collecting ideas after M4. Had a few interesting discussions on performance issues in this area yesterday with a few pretty smart guys while being on the JSFdays. more things to come... LieGrue, strub --- Gurkan Erdogdu schrieb am Do, 25.2.2010: > Von: Gurkan Erdogdu > Betreff: [DISCUSSION] Performance of OWB > An: dev@openwebbeans.apache.org > Datum: Donnerstag, 25. Februar, 2010 08:19 Uhr > Hi; > > In fact, I have not done any performance related work on > OWB so far. I just > want to kick start a discussion on Performance > Problems/Solutions of OWB. I > will also create an JIRA issue. > > Mainly, performance problems occur resulting from; > > 1* Lots of proxy usage > 2* Bean resolution algorithms used in > InjectionResolver#implResolveByType > and implResolveByName > 3* Observer resolution in NotificationManager > 4* Decorator and interceptor resolution > 5* Others > > WDYT? > > --Gurkan > __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
