Build failed in Jenkins: OpenWebBeans_1.0.x #128

[Apache Hudson Server]

See 

--
[...truncated 2051 lines...]
AUwebbeans-jsf/pom.xml
A webbeans-openejb
A webbeans-openejb/src
A webbeans-openejb/src/test
A webbeans-openejb/src/test/java
A webbeans-openejb/src/test/java/org
A webbeans-openejb/src/test/java/org/apache
A webbeans-openejb/src/test/java/org/apache/webbeans
A webbeans-openejb/src/test/java/org/apache/webbeans/ejb
AUwebbeans-openejb/src/test/java/org/apache/webbeans/ejb/MyEntity.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/EjbTestContext.java
A webbeans-openejb/src/test/java/org/apache/webbeans/ejb/bean
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/bean/SimpleBean.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/bean/SimpleBeanTest.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/bean/SimpleBeanLocal.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/OpenEJBIntegrationTest.java
A webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition
A 
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/validator
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/validator/Babos_Broken_Interceptor.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/validator/EjbValidatorTest.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/validator/Babos_Broken_Decorator.java
A 
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/scope
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/scope/Babus_Normal.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/scope/Babus_Broken.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/scope/EjbScopeTypeTest.java
A 
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/Balki_DefaultLocal.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/Balki.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/Balki_ClassLocal.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/Balki_ClassView.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/BalkiLocal_WithoutAnnotation.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/EjbApiTypeTest.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/BalkiLocal.java
A webbeans-openejb/src/test/resources
A webbeans-openejb/src/test/resources/META-INF
AUwebbeans-openejb/src/test/resources/META-INF/persistence.xml
AUwebbeans-openejb/src/test/resources/META-INF/ejb-jar.xml
A webbeans-openejb/src/main
A webbeans-openejb/src/main/java
A webbeans-openejb/src/main/java/org
A webbeans-openejb/src/main/java/org/apache
A webbeans-openejb/src/main/java/org/apache/webbeans
A webbeans-openejb/src/main/java/org/apache/webbeans/ejb
AUwebbeans-openejb/src/main/java/org/apache/webbeans/ejb/EjbPlugin.java
A webbeans-openejb/src/main/java/org/apache/webbeans/ejb/service
AU
webbeans-openejb/src/main/java/org/apache/webbeans/ejb/service/OpenEJBTransactionService.java
AU
webbeans-openejb/src/main/java/org/apache/webbeans/ejb/service/OpenEJBSecurityService.java
A webbeans-openejb/src/main/java/org/apache/webbeans/ejb/component
AU
webbeans-openejb/src/main/java/org/apache/webbeans/ejb/component/OpenEjbBean.java
A webbeans-openejb/src/main/java/org/apache/webbeans/ejb/resource
AU
webbeans-openejb/src/main/java/org/apache/webbeans/ejb/resource/ResourceFactory.java
AU
webbeans-openejb/src/main/java/org/apache/webbeans/ejb/resource/EJBInstanceProxy.java
AU
webbeans-openejb/src/main/java/org/apache/webbeans/ejb/resource/ResourceInjectionProcessor.java
AU
webbeans-openejb/src/main/java/org/apache/webbeans/ejb/resource/OpenEjbResourceInjectionService.java
A webbeans-openejb/src/main/java/org/apache/webbeans/ejb/scanner
AU
webbeans-openejb/src/main/java/org/apache/webbeans/ejb/scanner/EJBMetaDataDiscoveryImpl.java
A webbeans-openejb/src/main/resources
A webbeans-openejb/src/main/resources/META-INF
A webbeans-openejb/src/main/resources/META-INF/services
A 
webbeans-openejb/src/main/resources/META-INF/services/org.apache.webbeans.spi.plugins.OpenWebBeansPlugin
A webbeans-openejb/src/site
A webbeans-openejb/src/site/site.xml
AUwebbeans-openejb/pom.xml
A webbeans-por

Build failed in Jenkins: OpenWebBeans-trunk #415

[Apache Hudson Server]

See 

Changes:

[struberg] OWB-545 OWB-503 further elimination of static calls on SecurityUtil

[struberg] OWB-545 add security handling for SecurityService creation

We only allow creation of the ManagedSecurityService from
within the WebBeansContext!

[struberg] OWB-461 just a bit code cleanup

[struberg] OWB-532 OWB-514 get rid of AbstractOwbJsfPlugin

use BeanManagerImpl#isInUse() instead

[struberg] OWB-532 use BeanManagerImpl#inUse() instead of manual property

[gpetracek] OWB-548 added null check

[struberg] OWB-524 workaround for broken URL which contains %20 for spaces

[struberg] OWB-547 better just force the DefaultContextsService for unit tests

[struberg] OWB-393 finally dropped the rest of the old XML stuff. 

moved additionalInterceptorBindingTypes over to BeanManagerImpl.
Finally we should introduce an own holder for all those 
'additional' stuff which gets registered via Extensions at startup.

[struberg] OWB-547 avoid NPE in WebContextsService

--
[...truncated 2051 lines...]
AUwebbeans-jsf/pom.xml
A webbeans-openejb
A webbeans-openejb/src
A webbeans-openejb/src/test
A webbeans-openejb/src/test/java
A webbeans-openejb/src/test/java/org
A webbeans-openejb/src/test/java/org/apache
A webbeans-openejb/src/test/java/org/apache/webbeans
A webbeans-openejb/src/test/java/org/apache/webbeans/ejb
AUwebbeans-openejb/src/test/java/org/apache/webbeans/ejb/MyEntity.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/EjbTestContext.java
A webbeans-openejb/src/test/java/org/apache/webbeans/ejb/bean
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/bean/SimpleBean.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/bean/SimpleBeanTest.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/bean/SimpleBeanLocal.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/OpenEJBIntegrationTest.java
A webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition
A 
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/validator
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/validator/Babos_Broken_Interceptor.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/validator/EjbValidatorTest.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/validator/Babos_Broken_Decorator.java
A 
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/scope
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/scope/Babus_Normal.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/scope/Babus_Broken.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/scope/EjbScopeTypeTest.java
A 
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/Balki_DefaultLocal.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/Balki.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/Balki_ClassLocal.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/Balki_ClassView.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/BalkiLocal_WithoutAnnotation.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/EjbApiTypeTest.java
AU
webbeans-openejb/src/test/java/org/apache/webbeans/ejb/definition/apitype/BalkiLocal.java
A webbeans-openejb/src/test/resources
A webbeans-openejb/src/test/resources/META-INF
AUwebbeans-openejb/src/test/resources/META-INF/persistence.xml
AUwebbeans-openejb/src/test/resources/META-INF/ejb-jar.xml
A webbeans-openejb/src/main
A webbeans-openejb/src/main/java
A webbeans-openejb/src/main/java/org
A webbeans-openejb/src/main/java/org/apache
A webbeans-openejb/src/main/java/org/apache/webbeans
A webbeans-openejb/src/main/java/org/apache/webbeans/ejb
AUwebbeans-openejb/src/main/java/org/apache/webbeans/ejb/EjbPlugin.java
A webbeans-openejb/src/main/java/org/apache/webbeans/ejb/service
AU
webbeans-openejb/src/main/java/org/apache/webbeans/ejb/service/OpenEJBTransactionService.java
AU
webbeans-openejb/src/main/java/org/apache/webbeans/ejb/service/OpenEJBSecurityService.java
A webbeans-openejb/src/main/java/org/apache/webbeans/ejb/component
AU
webbeans-openejb/src/main/java/org/apache/webbeans/ejb/component/OpenEjbBean.java
A webbeans-openejb/src/main/java/org/apache/webbeans/ejb/resource
AU
webbeans-openejb/sr

[jira] [Updated] (OWB-515) interceptors don't support inheritance without an overridden method annotated with @AroundInvoke

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-515:
--

Fix Version/s: 1.2.0

moved to target 1.2.0

> interceptors don't support inheritance without an overridden method annotated 
> with @AroundInvoke
> 
>
> Key: OWB-515
> URL: https://issues.apache.org/jira/browse/OWB-515
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Interceptor and Decorators
>Affects Versions: 1.1.0
>Reporter: Gerhard Petracek
>Assignee: Gurkan Erdogdu
>Priority: Minor
> Fix For: 1.2.0
>
>
> workaround:
> @Override
> @AroundInvoke
> public Object invoke(InvocationContext context) throws Exception {
> return super.invoke(context);
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-475) support for optional beans

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-475:
--

Affects Version/s: (was: 1.2.0)
   1.0.0
Fix Version/s: 1.2.0

> support for optional beans
> --
>
> Key: OWB-475
> URL: https://issues.apache.org/jira/browse/OWB-475
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core, Injection and Lookup
>Affects Versions: 1.0.0
>Reporter: Gerhard Petracek
>Assignee: Gurkan Erdogdu
> Fix For: 1.2.0
>
>
> extensions might contain optional beans which aren't used if a dependency 
> isn't used by an application.
> ->
> AbstractMetaDataDiscovery#getBeanClasses should catch and log 
> NoClassDefFoundError
> AnnotatedElementFactory#newAnnotatedType should catch and log 
> TypeNotPresentException

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-475) support for optional beans

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-475:
--

Affects Version/s: (was: 1.0.0)
   1.2.0

moved to target 1.2.0

> support for optional beans
> --
>
> Key: OWB-475
> URL: https://issues.apache.org/jira/browse/OWB-475
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core, Injection and Lookup
>Affects Versions: 1.2.0
>Reporter: Gerhard Petracek
>Assignee: Gurkan Erdogdu
>
> extensions might contain optional beans which aren't used if a dependency 
> isn't used by an application.
> ->
> AbstractMetaDataDiscovery#getBeanClasses should catch and log 
> NoClassDefFoundError
> AnnotatedElementFactory#newAnnotatedType should catch and log 
> TypeNotPresentException

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-497) Don't break deployment if java can't read all the annotations

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-497:
--

Fix Version/s: (was: 1.1.0)
   1.2.0

moved to target 1.2.0

> Don't break deployment if java can't read all the annotations
> -
>
> Key: OWB-497
> URL: https://issues.apache.org/jira/browse/OWB-497
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.0
>Reporter: David Jencks
>Assignee: Gurkan Erdogdu
> Fix For: 1.2.0
>
>
> Running the jsr303 tck with OWB installed in geronimo we run into a bunch of 
> exceptions that I think must be a jdk bug: calling a method that causes the 
> annotations on a class to be initialized (clazz.getAnnotations() for 
> instance) throws and exception
> Caused by: java.lang.ArrayStoreException: 
> sun.reflect.annotation.TypeNotPresentExceptionProxy
>   at 
> sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:653)
>   at 
> sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:460)
>   at 
> sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286)
>   at 
> sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222)
>   at 
> sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69)
>   at 
> sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52)
>   at java.lang.Class.initAnnotationsIfNecessary(Class.java:3070)
>   at java.lang.Class.getAnnotation(Class.java:3029)
>   at 
> org.apache.webbeans.util.AnnotationUtil.hasClassAnnotation(AnnotationUtil.java:865)
>   at 
> org.apache.webbeans.config.BeansDeployer.checkSpecializations(BeansDeployer.java:620)
> Googling this is supposedly caused by an annotation (whose class is loadable) 
> having a value whose class is missing.  In my particular case I can't verify 
> this as the cause.
> In any case, OWB seems to have a policy that if a class can't have its 
> annotations read (e.g. ClassNotFoundException or NoClassDefFoundError) we 
> ignore it.  I think this policy should be extended to when this exception 
> occurs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-488) move WebBeansConfigurationException messages to message bundles

[Eric Covener (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Covener updated OWB-488:
-

Fix Version/s: 1.2.0

> move WebBeansConfigurationException messages to message bundles
> ---
>
> Key: OWB-488
> URL: https://issues.apache.org/jira/browse/OWB-488
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.0.0
>Reporter: Eric Covener
>Assignee: Gurkan Erdogdu
> Fix For: 1.2.0
>
>
> lots of grave WebBeansConfigurationException use string literals for stuff 
> that ought to be translatable.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-254) suppress initialising contextual handling for configurable URIs.

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-254.
---

Resolution: Won't Fix

This is not really needed anymore since we moved the most performance intense 
tasks to work via lazy initialisation. Thus when no CDI bean gets accessed in a 
request (e.g. a resource request) this will cause almost no overhead anymore.

> suppress initialising contextual handling for configurable URIs.
> 
>
> Key: OWB-254
> URL: https://issues.apache.org/jira/browse/OWB-254
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Java EE Integration
>Affects Versions: M3
>Reporter: Mark Struberg
>Assignee: Gurkan Erdogdu
>Priority: Minor
> Fix For: 1.1.0
>
>
> In my real world application, I see a lot useless construction and 
> destruction of Contexts since my JSF application also handles resources like 
> small images and CSS.
> We should think about introducing a blacklist of URIs/URI wildcards which do 
> not contain contextual beans to be managed.
> In a typical JSF-2 application this are e.g. all requests handled via the 
> #{resources} handler, thus contextRoot()/javax.faces.resource/*

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-335) implement a sample for @ViewScoped in reservation

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-335.
---

Resolution: Won't Fix

not needed anymore since @ViewScoped support first got moved to webbeans-jsf 
and is now deprecated in favour to using portable extensions like Apache 
MyFaces CODI or JBoss Seam-Faces

> implement a sample for @ViewScoped in reservation
> -
>
> Key: OWB-335
> URL: https://issues.apache.org/jira/browse/OWB-335
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Context and Scopes
>Affects Versions: 1.0.0-alpha-1
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: OWB-329-reservation_viewscoped.diff
>
>
> We should extend our reservation sample to also show the use of the JSF-2 
> @ViewScoped.
> Since this is a custom context implementation which gets serialized regulary, 
> this is a good test for both criterias.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-479) detect loops in producer beans vs. producer method parameters at deployment time

[Eric Covener (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Covener updated OWB-479:
-

Fix Version/s: 1.2.0

> detect loops in producer beans vs. producer method parameters at deployment 
> time
> 
>
> Key: OWB-479
> URL: https://issues.apache.org/jira/browse/OWB-479
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Injection and Lookup
>Affects Versions: 1.0.0
>Reporter: Eric Covener
>Assignee: Gurkan Erdogdu
>Priority: Minor
> Fix For: 1.2.0
>
>
> Currently OWB can cause a stack overflow if a parameter on a producer method 
> is satisfied by the same bean as the producer method itself, it would be nice 
> if we could trap such a thing in producer beans at deployment time and 
> minimally warn about the offending method/parameter.
>   at 
> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:723)
>   at 
> org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:134)
>   at 
> org.apache.webbeans.inject.InjectableMethods.doInjection(InjectableMethods.java:117)
>   at 
> org.apache.webbeans.component.ProducerMethodBean.createDefaultInstance(ProducerMethodBean.java:193)
>   at 
> org.apache.webbeans.component.ProducerMethodBean.createInstance(ProducerMethodBean.java:155)
>   at 
> org.apache.webbeans.component.AbstractOwbBean.createNewInstance(AbstractOwbBean.java:208)
>   at 
> org.apache.webbeans.portable.creation.AbstractProducer.produce(AbstractProducer.java:82)
>   at 
> org.apache.webbeans.component.InjectionTargetWrapper.produce(InjectionTargetWrapper.java:142)
>   at 
> org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:166)
>   at 
> org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:69)
>   at 
> org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:191)
>   at 
> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:839)
>   at 
> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:723)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-444) Using Static Loggers in Shared ClassLoader

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-444.
---

   Resolution: Fixed
Fix Version/s: 1.0.0

actually already fixed in 1.0.0

> Using Static Loggers in Shared ClassLoader
> --
>
> Key: OWB-444
> URL: https://issues.apache.org/jira/browse/OWB-444
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.0-alpha-1
>Reporter: Gurkan Erdogdu
>Assignee: Gurkan Erdogdu
> Fix For: 1.1.0, 1.0.0
>
>
> Errors of using static loggers in shared classloaders environments

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-428) implementation of equals and hashCode for AbstractOwbBean

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-428.
---

Resolution: Won't Fix

I think it's safe to skip this issue.

> implementation of equals and hashCode for AbstractOwbBean
> -
>
> Key: OWB-428
> URL: https://issues.apache.org/jira/browse/OWB-428
> Project: OpenWebBeans
>  Issue Type: Task
>  Components: Core
>Affects Versions: 1.0.0-alpha-1
>Reporter: Gerhard Petracek
>Assignee: Gurkan Erdogdu
> Fix For: 1.1.0
>
> Attachments: OWB-428.patch, OWB-428.patch
>
>
> not sure if we really need it, because there is always only exactly one bean 
> of a given kind. So instance comparison is save and also fast.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-433) add a configuration flag for switching to a lenient lifecycle interceptor checking

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-433.
---

   Resolution: Fixed
Fix Version/s: 1.0.0

actually already fixed in 1.0.0 ;)

> add a configuration flag for switching to a lenient lifecycle interceptor 
> checking
> --
>
> Key: OWB-433
> URL: https://issues.apache.org/jira/browse/OWB-433
> Project: OpenWebBeans
>  Issue Type: New Feature
>Affects Versions: 1.0.0-alpha-1
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.1.0, 1.0.0
>
>
> According to the spec, lifecycle methods like @PreDestroy and @PostConstruct 
> must not throw any checked exceptions. This is the behaviour which is defined 
> in the EE interceptor spec. Since this is sometimes way too restrictive, we 
> shall allow to relax this rule by configuration The default value is 'true' 
> nternally.
> ATTENTION: this property works container wide!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-523) @SessionScoped bean failover does not work

[Joe Bergmark (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joe Bergmark resolved OWB-523.
--

   Resolution: Fixed
Fix Version/s: 1.1.0

Basic failover is working now.

> @SessionScoped bean failover does not work
> --
>
> Key: OWB-523
> URL: https://issues.apache.org/jira/browse/OWB-523
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.0
> Environment: MyFaces 2.0.3, OWB 1.0.0, Tomcat 7.0.8, 
> memcached-session-manager
>Reporter: Thomas Andraschko
>Assignee: Joe Bergmark
>Priority: Minor
> Fix For: 1.1.0
>
>
> OWB failover for @SessionScoped beans does not work.
> A detailed description and a sample project can be found here:
> https://github.com/magro/msm-sample-webapp/tree/openwebbeans

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-151) @Dependent beans not interceptable

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-151:
--

Fix Version/s: (was: 1.1.0)
   1.2.0

This is still not working. 
Comment in the section

Assert.assertTrue(DependentInterceptor.refCount == 1);

in DependentInterceptorTest#testLifecycle() to see what I mean.

> @Dependent beans not interceptable
> --
>
> Key: OWB-151
> URL: https://issues.apache.org/jira/browse/OWB-151
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Interceptor and Decorators
>Affects Versions: 1.0.0
>Reporter: Eric Covener
>Assignee: Joe Bergmark
> Fix For: 1.2.0
>
> Attachments: publicFieldTest.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> @Dependent beans must be interceptable, although implementations are not 
> required to provide a client proxy for them.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OWB-468) Make BeansDeployer.deployFromClassPath(ScannerService) resilient to ClassNotFoundException and NoClassDefFoundError's

[Mark Struberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009310#comment-13009310
 ] 

Mark Struberg commented on OWB-468:
---

Rohit, is this fixed now? - txs!

> Make BeansDeployer.deployFromClassPath(ScannerService) resilient to 
> ClassNotFoundException and NoClassDefFoundError's
> -
>
> Key: OWB-468
> URL: https://issues.apache.org/jira/browse/OWB-468
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core, Java EE Integration, Lifecycle
>Affects Versions: 1.1.0, 1.0.1, 1.0.0, 1.0.0-alpha-2
> Environment: Windows Server 2003
>Reporter: Rohit Dilip Kelapure
>Assignee: Rohit Dilip Kelapure
> Fix For: 1.1.0
>
> Attachments: owb-468.patch
>
>
> In tiered  classloading environments, lifecycle start --> BeansDeployer 
> deploy --> AnnotatedElementFactory.newAnnotatedType(Class) sometimes 
> throws ClassNotFoundException and NoClassDefFoundError's from the following 
> methods 
>   Field[] fields = SecurityUtil.doPrivilegedGetDeclaredFields(annotatedClass);
>   Method[] methods = 
> SecurityUtil.doPrivilegedGetDeclaredMethods(annotatedClass);
>   These exceptions and errors are typically due to incorrect or erroneous 
> application packaging of classes and dependencies. 
> I would like OpenWebBeans to continue loading other classes even if one/few 
> classes cannot be loaded correctly i.e. the assumption is that we don't 
> punish the majority for the crimes of a few. We define Managed Beans ONLY for 
> classes that yield a AnnotatedType. 
> At runtime, if the application exercises any CDI function on the "bad" 
> classes, then the results are indeterminate.
> I will attach a patch that will explain my approach of fixing this. 
> java.lang.NoClassDefFoundError: com.example svt.acme.AnnuityMgmt
>   at java.lang.ClassLoader.defineClassImpl(Native Method)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:260)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:69)
>   at 
> com.ws.classloader.CompoundClassLoader._defineClass(CompoundClassLoader.java:803)
>   at 
> com.ws.classloader.CompoundClassLoader.localFindClass(CompoundClassLoader.java:718)
>   at 
> com.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:541)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:612)
>   at 
> com.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:539)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:612)
>   at java.lang.Class.getDeclaredMethodsImpl(Native Method)
>   at java.lang.Class.getDeclaredMethods(Class.java:674)
>   at 
> org.apache.webbeans.util.SecurityUtil$PrivilegedActionForClass.run(SecurityUtil.java:137)
>   at 
> java.security.AccessController.doPrivileged(AccessController.java:203)
>   at 
> org.apache.webbeans.util.SecurityUtil.doPrivilegedGetDeclaredMethods(SecurityUtil.java:84)
>   at 
> org.apache.webbeans.portable.AnnotatedElementFactory.newAnnotatedType(AnnotatedElementFactory.java:102)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-468) Make BeansDeployer.deployFromClassPath(ScannerService) resilient to ClassNotFoundException and NoClassDefFoundError's

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-468:
--

Fix Version/s: 1.1.0

> Make BeansDeployer.deployFromClassPath(ScannerService) resilient to 
> ClassNotFoundException and NoClassDefFoundError's
> -
>
> Key: OWB-468
> URL: https://issues.apache.org/jira/browse/OWB-468
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core, Java EE Integration, Lifecycle
>Affects Versions: 1.1.0, 1.0.1, 1.0.0, 1.0.0-alpha-2
> Environment: Windows Server 2003
>Reporter: Rohit Dilip Kelapure
>Assignee: Rohit Dilip Kelapure
> Fix For: 1.1.0
>
> Attachments: owb-468.patch
>
>
> In tiered  classloading environments, lifecycle start --> BeansDeployer 
> deploy --> AnnotatedElementFactory.newAnnotatedType(Class) sometimes 
> throws ClassNotFoundException and NoClassDefFoundError's from the following 
> methods 
>   Field[] fields = SecurityUtil.doPrivilegedGetDeclaredFields(annotatedClass);
>   Method[] methods = 
> SecurityUtil.doPrivilegedGetDeclaredMethods(annotatedClass);
>   These exceptions and errors are typically due to incorrect or erroneous 
> application packaging of classes and dependencies. 
> I would like OpenWebBeans to continue loading other classes even if one/few 
> classes cannot be loaded correctly i.e. the assumption is that we don't 
> punish the majority for the crimes of a few. We define Managed Beans ONLY for 
> classes that yield a AnnotatedType. 
> At runtime, if the application exercises any CDI function on the "bad" 
> classes, then the results are indeterminate.
> I will attach a patch that will explain my approach of fixing this. 
> java.lang.NoClassDefFoundError: com.example svt.acme.AnnuityMgmt
>   at java.lang.ClassLoader.defineClassImpl(Native Method)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:260)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:69)
>   at 
> com.ws.classloader.CompoundClassLoader._defineClass(CompoundClassLoader.java:803)
>   at 
> com.ws.classloader.CompoundClassLoader.localFindClass(CompoundClassLoader.java:718)
>   at 
> com.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:541)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:612)
>   at 
> com.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:539)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:612)
>   at java.lang.Class.getDeclaredMethodsImpl(Native Method)
>   at java.lang.Class.getDeclaredMethods(Class.java:674)
>   at 
> org.apache.webbeans.util.SecurityUtil$PrivilegedActionForClass.run(SecurityUtil.java:137)
>   at 
> java.security.AccessController.doPrivileged(AccessController.java:203)
>   at 
> org.apache.webbeans.util.SecurityUtil.doPrivilegedGetDeclaredMethods(SecurityUtil.java:84)
>   at 
> org.apache.webbeans.portable.AnnotatedElementFactory.newAnnotatedType(AnnotatedElementFactory.java:102)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OWB-453) add a flag to disable context activation in EJB interceptor

[Mark Struberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009308#comment-13009308
 ] 

Mark Struberg commented on OWB-453:
---

Rohit, Eric what's the status? Is this now resolved? - txs!

> add a flag to disable context activation in EJB interceptor
> ---
>
> Key: OWB-453
> URL: https://issues.apache.org/jira/browse/OWB-453
> Project: OpenWebBeans
>  Issue Type: Task
>Affects Versions: 1.0.0-alpha-2
>Reporter: Eric Covener
>Assignee: Rohit Dilip Kelapure
> Fix For: 1.1.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Some containers might activate contexts in some other way (another dedicated 
> interceptor, or even something else), 
> so make the OpenWebBeansEJBInterceptor conditionally look at the requests 
> context.
> org.apache.webbeans.application.useEJBInterceptorActivation (true by default)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-495) create a jetty integration plugin

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-495:
--

Fix Version/s: (was: 1.1.0)
   1.2.0

moved target to 1.2.0

> create a jetty integration plugin 
> --
>
> Key: OWB-495
> URL: https://issues.apache.org/jira/browse/OWB-495
> Project: OpenWebBeans
>  Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.2.0
>
>
> for jetty you currently need to add the
> 
> 
> org.apache.webbeans.servlet.WebBeansConfigurationListener
> 
> in your web.xml manually. 
> This is ofc not a good thing if we like to integrate into geronimo using 
> jetty.
> We should create a jetty plugin similar as we have with webbeans-tomcat6 & 7

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-519) broken wls support

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-519:
--

Fix Version/s: 1.1.0
 Assignee: Gerhard Petracek  (was: Gurkan Erdogdu)

Gerhard, could you please retest this if possible? We'd like to ship it with 
1.1.0 - txs!

> broken wls support
> --
>
> Key: OWB-519
> URL: https://issues.apache.org/jira/browse/OWB-519
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core, Injection and Lookup
>Affects Versions: 1.0.1
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
>Priority: Critical
> Fix For: 1.1.0
>
>
> owb doesn't work in weblogic 10.3 since r1036194 (OWB-472)
> [update]:
> the original issue is fixed
> 2nd issue:
> random classloading issue (for now: the implementation of r1028218 works) - 
> see the comments for further details

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-472) archive centric beans.xml enabling

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-472:
--

Fix Version/s: 1.1.0

set to fixed in 1.1.0.

Jacquelle, Joe, could you please be so kind and retest the current snapshot? 
I've cleaned up/fixed a lot of things - especially in those core parts - so I 
hope I didn't break this feature.
Can you please ping me if it works or if its broken? Txs a bunch!


> archive centric beans.xml enabling 
> ---
>
> Key: OWB-472
> URL: https://issues.apache.org/jira/browse/OWB-472
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Injection and Lookup
>Reporter: Jacquelle Leggett
>Assignee: Mark Struberg
> Fix For: 1.1.0
>
> Attachments: patch.txt
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> This issue was discussed in great detail in June 
> (http://mail-archives.apache.org/mod_mbox/openwebbeans-dev/201006.mbox/browser)
>  on the developers forum.  The title of the thread is "problems with lack of 
> archive-centric BeanManager".  
> The main problem is described below (snippet from discussion):
> "...Our current design does not permit either of the following scenarions, 
> AFAICT:
>   b.jar and c.jar both enable the interceptor defined in a.jar
> (treated as a duplicate)
>   Exactly one of b.jar and c.jar enables the interceptor defined in
> a.jar (ends up enabled for beans from either archive if enabled in one
> -- this is in the more troubling neighborhood)..."

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-469) JSR299TCK: Security Error / Passivation errors during readObject

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-469:
--

Fix Version/s: 1.1.0

this should get into 1.1.0

> JSR299TCK: Security Error / Passivation errors during readObject
> 
>
> Key: OWB-469
> URL: https://issues.apache.org/jira/browse/OWB-469
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Events
>Affects Versions: 1.1.0, 1.0.1, 1.0.0-alpha-2
> Environment: win server 2003
>Reporter: Rohit Dilip Kelapure
>Assignee: Rohit Dilip Kelapure
> Fix For: 1.1.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> JIRA opened on behalf of Paul Reder. 
> Problem Observed: 
> Snippet for failure:
>@SpecAssertions({
>   @SpecAssertion(section = "10.3.2", id = "g"),
>   @SpecAssertion(section = "6.6.2", id = "e")
>})
>public void testImplicitEventIsPassivationCapable() throws IOException, 
> ClassNotFoundException
>{
>   StudentDirectory directory = getInstanceByType(StudentDirectory.class);
>   directory.reset();
>   Registration registration = getInstanceByType(Registration.class);
>   Event event = 
> registration.getInjectedStudentRegisteredEvent();
>   assert Serializable.class.isAssignableFrom(event.getClass());
>   byte[] serializedEvent = serialize(event);
>   ...
>   Event eventCopy = 
> (Event) deserialize(serializedEvent); // <--- error 
> here
>   ...
> Error:
> java.security.AccessControlException: Access denied 
> (java.lang.RuntimePermission accessClassInPackage.com.xxx.oti.reflect)
>at 
> java.security.AccessController.checkPermission(AccessController.java:108)
>at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:533)
>at 
> com.xxx.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:212)
>at 
> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1528)
>at 
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:343)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:619)
>at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:438)
>at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
>at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
>at 
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:103)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:619)
>at java.lang.Class.forNameImpl(Native Method)
>at java.lang.Class.forName(Class.java:169)
>at 
> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:605)
>at 
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1559)
>at 
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1500)
>at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1736)
>at 
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
>at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1951)
>at 
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1875)
>at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1757)
>at 
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
>at 
> java.io.ObjectInputStream.readArray(ObjectInputStream.java:1671)
>at 
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1327)
>at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1951)
>at 
> java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:481)
>at 
> org.apache.webbeans.event.EventImpl.readObject(EventImpl.java:153)
>at 
> java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1033)
>at 
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1853)
>at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1757)
>at 
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
>at 
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:352)
>at 
> org.jboss.jsr299.tck.AbstractJSR299Test.deserialize(AbstractJSR299Test.java:63)
>at 
> org.jboss.jsr299.tck.tests.event.implicit.ImplicitEventTest.testImplicitEventIsPassivationCapable(ImplicitEventTest.java:118)

--
This mes

[jira] [Updated] (OWB-513) proxies should be inactive after a container shutdown

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-513:
--

Fix Version/s: 1.2.0

> proxies should be inactive after a container shutdown
> -
>
> Key: OWB-513
> URL: https://issues.apache.org/jira/browse/OWB-513
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: 1.0.0
>Reporter: Gerhard Petracek
>Assignee: Gurkan Erdogdu
> Fix For: 1.2.0
>
>
> something like the exception below might happen if 
> WebBeansConfigurationListener#contextDestroyed gets called before other 
> listeners.
> SEVERE: Error while loading the propertyFile 
> META-INF/openwebbeans/openwebbeans.properties
> java.util.zip.ZipException: error in opening zip file
>   at java.util.zip.ZipFile.open(Native Method)
>   at java.util.zip.ZipFile.(ZipFile.java:114)
>   at java.util.jar.JarFile.(JarFile.java:135)
>   at java.util.jar.JarFile.(JarFile.java:72)
>   at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:72)
>   at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:48)
>   at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:70)
>   at 
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
>   at 
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:132)
>   at java.net.URL.openStream(URL.java:1010)
>   at 
> org.apache.webbeans.config.PropertyLoader.loadAllProperties(PropertyLoader.java:115)
>   at 
> org.apache.webbeans.config.PropertyLoader.getProperties(PropertyLoader.java:75)
>   at 
> org.apache.webbeans.config.OpenWebBeansConfiguration.parseConfiguration(OpenWebBeansConfiguration.java:216)
>   at 
> org.apache.webbeans.config.OpenWebBeansConfiguration.(OpenWebBeansConfiguration.java:128)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>   at java.lang.Class.newInstance0(Class.java:355)
>   at java.lang.Class.newInstance(Class.java:308)
>   at 
> org.apache.webbeans.corespi.DefaultSingletonService.getSingletonInstance(DefaultSingletonService.java:89)
>   at 
> org.apache.webbeans.corespi.DefaultSingletonService.get(DefaultSingletonService.java:201)
>   at 
> org.apache.webbeans.config.WebBeansFinder.getSingletonInstance(WebBeansFinder.java:57)
>   at 
> org.apache.webbeans.config.WebBeansFinder.getSingletonInstance(WebBeansFinder.java:52)
>   at 
> org.apache.webbeans.config.OpenWebBeansConfiguration.getInstance(OpenWebBeansConfiguration.java:120)
>   at 
> org.apache.webbeans.corespi.ServiceLoader.getService(ServiceLoader.java:54)
>   at 
> org.apache.webbeans.context.ContextFactory.getContextsService(ContextFactory.java:81)
>   at 
> org.apache.webbeans.context.ContextFactory.getStandardContext(ContextFactory.java:261)
>   at 
> org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:281)
>   at 
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:124)
>   at 
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:95)
>   at 
> org.javassist.tmp.java.lang.Object_$$_javassist_23.toString(Object_$$_javassist_23.java)
>   at 
> org.apache.catalina.loader.WebappClassLoader.clearThreadLocalMap(WebappClassLoader.java:2193)
>   at 
> org.apache.catalina.loader.WebappClassLoader.clearReferencesThreadLocals(WebappClassLoader.java:2126)
>   at 
> org.apache.catalina.loader.WebappClassLoader.clearReferences(WebappClassLoader.java:1746)
>   at 
> org.apache.catalina.loader.WebappClassLoader.stop(WebappClassLoader.java:1658)
>   at org.apache.catalina.loader.WebappLoader.stop(WebappLoader.java:710)
>   at 
> org.apache.catalina.core.StandardContext.stop(StandardContext.java:4649)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-505) OwbApplicationFactory should not be installed by default

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-505.
---

Resolution: Fixed
  Assignee: Mark Struberg  (was: Gurkan Erdogdu)

fixed by using BeanManagerImpl#isInUse() to detect if OwbApplicationFactory 
should be doing something.

> OwbApplicationFactory should not be installed by default
> 
>
> Key: OWB-505
> URL: https://issues.apache.org/jira/browse/OWB-505
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.0
>Reporter: David Jencks
>Assignee: Mark Struberg
> Fix For: 1.1.0
>
>
> Although OwbApplicationFactory is convenient, there's nothing in the spec 
> that indicates that something like it should be installed by default.  
> Currently geronimo is treating all jsf apps as web beans apps and automatic 
> installation of OwbApplicationFactory is interfering with some jsf tck tests 
> that check that getApplication returns the same as setApplication and all 
> ways of getting an EL ExpressionFactory return the same object.  I think that 
> if users want the functionality of the OwbApplicationFactory they can install 
> it themselves.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-532) create a new BeanManager#isInUse()

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-532.
---

Resolution: Fixed

finished in r1083887

> create a new BeanManager#isInUse()
> --
>
> Key: OWB-532
> URL: https://issues.apache.org/jira/browse/OWB-532
> Project: OpenWebBeans
>  Issue Type: New Feature
>  Components: Lifecycle
>Affects Versions: 1.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.1.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Sometimes it's useful to know if OWB really got used from an application. 
> Depending on this we could implement performance tweaks, like e.g. disabling 
> the WebBeansELResolver for non-CDI apps.
> This would be very usefull in EE scenarios if the OWB jars are available in 
> the classpath but CDI doesn't get used by a WebApp.
> I'll just separate BeanManagerImpl#addBean() into a 'public' version for 
> standard beans and a #addInternalBean for adding BeanManagerBean and stuff.
> #addBean() will set a isInUse = true; whereas addInternalBean will not touch 
> this flag.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Classpath Scanner proposal

[Mark Struberg]

Hi Sven!

Yea, I'm aiming for something like that. The major benefit would be that we do 
not trash our ClassLoader with all the reflection stuff only needed for the 
initial class scanning. This is currently eating up lots of PermGenSpace. 

Btw, the reflections project is based on the original scannotation code from 
Bill Burke, so we aint that far away ;)
We are also looking for probably moving it over to xbean-finder which David 
wrote for OpenEJB and is now also being used in geronimo and a few other apache 
projects. But we'll do that after 1.1.0 ;)

txs and LieGrue,
strub

--- On Mon, 3/21/11, Sven Linstaedt  wrote:

> From: Sven Linstaedt 
> Subject: Re: Classpath Scanner proposal
> To: dev@openwebbeans.apache.org
> Date: Monday, March 21, 2011, 5:35 PM
> Another interesting use case would
> look like using some kind of
> pre-generated scanning information created during
> build-time.
> 
> Artifacts are in general considered final after creation,
> so scans done at
> runtime will return the same result. This result could be
> generated during
> build-time and inlined into the artifact in a serialized
> form, which in turn
> in used during runtime to further speed up scan jobs. [1]
> is doing something
> similar by providing a maven plugin.
> 
> br, Sven
> 
> 
> [1] http://code.google.com/p/reflections/
> 
> 
> 2011/2/27 Mark Struberg 
> 
> > I think it should be enough if the classscanner
> implementation itself
> > shades any such 3rd party jar into a inner
> dependency.
> > My main focus currently is to design the API flexible
> enough to allow all
> > necessary use cases to work.
> >
> > LieGrue,
> > strub
> >
> > --- On Sun, 2/27/11, Jan-Kees van Andel 
> wrote:
> >
> > > From: Jan-Kees van Andel 
> > > Subject: Re: Classpath Scanner proposal
> > > To: dev@openwebbeans.apache.org,
> d...@geronimo.apache.org
> > > Date: Sunday, February 27, 2011, 1:35 PM
> > > +1, although I think Jar hell is a
> > > real issue. Think about libraries like
> > > cglib, asm or commons-*** and the pain they
> sometimes
> > > cause.
> > >
> > > But we can easily work around it, for example by
> packaging
> > > all
> > > using-frameworks as uber-jars and renaming
> > > the "org.apache.commons.classscan" packages to
> something
> > > like
> "org.apache.myfaces.org.apache.commons.classscan"
> > > and
> "org.apache.webbeans.org.apache.commons.classscan".
> > > This way we prevent
> > > any future versioning issues that libraries like
> cglib and
> > > asm currently
> > > have.
> > >
> > > Regards,
> > > Jan-Kees
> > >
> > >
> > > 2011/2/27 Mark Struberg 
> > >
> > > > Hi Jan-Kees!
> > > >
> > > > Txs for this info!
> > > >
> > > > Of course, I think the downside of getting
> another
> > > dependency to myfaces
> > > > would highly be outvalued by the benefit
> we'd gain
> > > from it :)
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > > --- On Sun, 2/27/11, Jan-Kees van Andel
> 
> > > wrote:
> > > >
> > > > > From: Jan-Kees van Andel 
> > > > > Subject: Re: Classpath Scanner
> proposal
> > > > > To: dev@openwebbeans.apache.org,
> > > d...@geronimo.apache.org,
> > > "Mark
> > > > Struberg" 
> > > > > Date: Sunday, February 27, 2011, 12:58
> PM
> > > > > Hey Mark,
> > > > >
> > > > > About the JSR proposal. I've actually
> been
> > > talking to some
> > > > > Oracle folks
> > > > > about this idea some (like 3?) years
> ago. They
> > > didn't
> > > > > really like it, since
> > > > > the classpath is only a VM
> implementation
> > > detail.
> > > > > I proposed it, because back then there
> were
> > > already rumours
> > > > > about module
> > > > > systems and writing a mechanism that
> relies on
> > > the
> > > > > classpath seemed like a
> > > > > bad idea at that time. A JSR (like 277
> back then)
> > > could
> > > > > keep annotation
> > > > > scanning in mind while writing the
> spec.
> > > > > I pinged them again (I think it was
> last year)
> > > and they
> > > > > responded that they
> > > > > would think about adding an annotation
> scanner to
> > > Jigsaw,
> > > > > but a JSR was out
> > > > > of the question.
> > > > >
> > > > > I think mentioning their names here is
> > > inappropriate, but
> > > > > they're influential people in the
> Java/JCP
> > > world...
> > > > >
> > > > > This is not a reason to not write a
> framework or
> > > to not
> > > > > submit a JSR, but I
> > > > > thought I'd mention it...
> > > > >
> > > > > Ps. Maybe it's a good idea to "promote"
> XBean
> > > Finder and
> > > > > use it in
> > > > > MyFaces/OWB/etc...?
> > > > > Ps2. IIRC, we implemented our own
> scanner for
> > > MyFaces, for
> > > > > the simple reason
> > > > > that it removes an additional
> dependency. But,
> > > OTOH, using
> > > > > XBean Finder with
> > > > > the Maven Shade Plugin would also
> work...
> > > > >
> > > > > Regards,
> > > > > Jan-Kees
> > > > >
> > > > >
> > > > > 2011/2/27 Mark Struberg 
> > > > >
> > > > > > Hi Ivan!
> > > > > >
> > > > > > Yes, I already prepared for the
> addition of
> > > a

Re: Classpath Scanner proposal

[Sven Linstaedt]

Another interesting use case would look like using some kind of
pre-generated scanning information created during build-time.

Artifacts are in general considered final after creation, so scans done at
runtime will return the same result. This result could be generated during
build-time and inlined into the artifact in a serialized form, which in turn
in used during runtime to further speed up scan jobs. [1] is doing something
similar by providing a maven plugin.

br, Sven


[1] http://code.google.com/p/reflections/


2011/2/27 Mark Struberg 

> I think it should be enough if the classscanner implementation itself
> shades any such 3rd party jar into a inner dependency.
> My main focus currently is to design the API flexible enough to allow all
> necessary use cases to work.
>
> LieGrue,
> strub
>
> --- On Sun, 2/27/11, Jan-Kees van Andel  wrote:
>
> > From: Jan-Kees van Andel 
> > Subject: Re: Classpath Scanner proposal
> > To: dev@openwebbeans.apache.org, d...@geronimo.apache.org
> > Date: Sunday, February 27, 2011, 1:35 PM
> > +1, although I think Jar hell is a
> > real issue. Think about libraries like
> > cglib, asm or commons-*** and the pain they sometimes
> > cause.
> >
> > But we can easily work around it, for example by packaging
> > all
> > using-frameworks as uber-jars and renaming
> > the "org.apache.commons.classscan" packages to something
> > like "org.apache.myfaces.org.apache.commons.classscan"
> > and "org.apache.webbeans.org.apache.commons.classscan".
> > This way we prevent
> > any future versioning issues that libraries like cglib and
> > asm currently
> > have.
> >
> > Regards,
> > Jan-Kees
> >
> >
> > 2011/2/27 Mark Struberg 
> >
> > > Hi Jan-Kees!
> > >
> > > Txs for this info!
> > >
> > > Of course, I think the downside of getting another
> > dependency to myfaces
> > > would highly be outvalued by the benefit we'd gain
> > from it :)
> > >
> > > LieGrue,
> > > strub
> > >
> > > --- On Sun, 2/27/11, Jan-Kees van Andel 
> > wrote:
> > >
> > > > From: Jan-Kees van Andel 
> > > > Subject: Re: Classpath Scanner proposal
> > > > To: dev@openwebbeans.apache.org,
> > d...@geronimo.apache.org,
> > "Mark
> > > Struberg" 
> > > > Date: Sunday, February 27, 2011, 12:58 PM
> > > > Hey Mark,
> > > >
> > > > About the JSR proposal. I've actually been
> > talking to some
> > > > Oracle folks
> > > > about this idea some (like 3?) years ago. They
> > didn't
> > > > really like it, since
> > > > the classpath is only a VM implementation
> > detail.
> > > > I proposed it, because back then there were
> > already rumours
> > > > about module
> > > > systems and writing a mechanism that relies on
> > the
> > > > classpath seemed like a
> > > > bad idea at that time. A JSR (like 277 back then)
> > could
> > > > keep annotation
> > > > scanning in mind while writing the spec.
> > > > I pinged them again (I think it was last year)
> > and they
> > > > responded that they
> > > > would think about adding an annotation scanner to
> > Jigsaw,
> > > > but a JSR was out
> > > > of the question.
> > > >
> > > > I think mentioning their names here is
> > inappropriate, but
> > > > they're influential people in the Java/JCP
> > world...
> > > >
> > > > This is not a reason to not write a framework or
> > to not
> > > > submit a JSR, but I
> > > > thought I'd mention it...
> > > >
> > > > Ps. Maybe it's a good idea to "promote" XBean
> > Finder and
> > > > use it in
> > > > MyFaces/OWB/etc...?
> > > > Ps2. IIRC, we implemented our own scanner for
> > MyFaces, for
> > > > the simple reason
> > > > that it removes an additional dependency. But,
> > OTOH, using
> > > > XBean Finder with
> > > > the Maven Shade Plugin would also work...
> > > >
> > > > Regards,
> > > > Jan-Kees
> > > >
> > > >
> > > > 2011/2/27 Mark Struberg 
> > > >
> > > > > Hi Ivan!
> > > > >
> > > > > Yes, I already prepared for the addition of
> > a
> > > > xbean-finder based
> > > > > ClassScanner implementation. But since I
> > didn't reach
> > > > David yesterday and I
> > > > > personally don't know xbean-finder well
> > enough, I just
> > > > started hacking on a
> > > > > scannotation based one (similar to the one
> > we use in
> > > > OpenWebBeans).
> > > > >
> > > > >
> > > > > LieGrue,
> > > > > strub
> > > > >
> > > > > --- On Sun, 2/27/11, Ivan 
> > > > wrote:
> > > > >
> > > > > > From: Ivan 
> > > > > > Subject: Re: Classpath Scanner
> > proposal
> > > > > > To: dev@openwebbeans.apache.org,
> > > > d...@geronimo.apache.org
> > > > > > Date: Sunday, February 27, 2011, 12:01
> > PM
> > > > > > Totally agree the idea, in Geronimo,
> > > > > > it is definitely an issue, as many
> > > > > > components need to scan the target
> > application,
> > > > and we are
> > > > > > trying to improve
> > > > > > this, e,g. In the xbean-finder, we use
> > some
> > > > filter to limit
> > > > > > the scanning
> > > > > > scope. Also, we hope to have a
> > sharable
> > > > annotation scanning
> > > > > > tool, and open a
> > > > > > JIRA to track this

Re: OpenWebBeans-1.1.0 release planing

[Mark Struberg]

nah, that's really welcome, Kevan!

I'd like to close a few major cleanups today and tomorrow and then call a 
feature stop. After that we should focus on bugfixing/stabilising for 3 days 
and then I'd like to release.

LieGrue,
strub

PS: sorry for the cross post ;)

--- On Mon, 3/21/11, Kevan Miller  wrote:

> From: Kevan Miller 
> Subject: Re: release planing
> To: dev@openwebbeans.apache.org
> Date: Monday, March 21, 2011, 5:01 PM
> 
> On Mar 16, 2011, at 6:39 AM, Mark Struberg wrote:
> 
> > Hi folks!
> > 
> > I'd like to fix/finish a few of my open tasks and then
> trigger the tasks for an openwebbeans-1.1.0 release.
> > 
> > Any objections?
> > 
> > Please give me a list of issues which should get done
> until then.
> > 
> > Please note that this will not be the final 1.1
> release but I like to release a 1.1.1 ~1 month later with
> all the further bugfixes and improvements missing.
> > 
> > WDYT?
> 
> Sounds good. It would be great if Geronimo would get
> through a clean TCK. They never got through a clean JCDI
> run. Looks like some of the recent OpenWebBeans/OpenEJB
> changes have introduced some additional problems. I'll try
> and stir up some interest/urgency, but I wouldn't hold up
> the release for that...
> 
> --kevan
> 
> 


  

Re: release planing

[Kevan Miller]

On Mar 16, 2011, at 6:39 AM, Mark Struberg wrote:

> Hi folks!
> 
> I'd like to fix/finish a few of my open tasks and then trigger the tasks for 
> an openwebbeans-1.1.0 release.
> 
> Any objections?
> 
> Please give me a list of issues which should get done until then.
> 
> Please note that this will not be the final 1.1 release but I like to release 
> a 1.1.1 ~1 month later with all the further bugfixes and improvements missing.
> 
> WDYT?

Sounds good. It would be great if Geronimo would get through a clean TCK. They 
never got through a clean JCDI run. Looks like some of the recent 
OpenWebBeans/OpenEJB changes have introduced some additional problems. I'll try 
and stir up some interest/urgency, but I wouldn't hold up the release for 
that...

--kevan

[jira] [Created] (OWB-548) missing null check in DefaultContextsService#stopApplicationContext

[Gerhard Petracek (JIRA)]

missing null check in DefaultContextsService#stopApplicationContext
---

 Key: OWB-548
 URL: https://issues.apache.org/jira/browse/OWB-548
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Gerhard Petracek
Assignee: Gurkan Erdogdu
 Fix For: 1.1.0


CdiTestOpenWebBeansContainer#stopContexts as well as 
CdiTestOpenWebBeansContainer#shutdownContainer try to stop the 
application-context - the 2nd try causes a NPE in 
DefaultContextsService#stopApplicationContext

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (OWB-532) create a new BeanManager#isInUse()

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg reopened OWB-532:
---


we can imo effectively kill JSFUtil#isOwbApplication() and all other usages of 
OpenWebBeansConfiguration#PROPERTY_OWB_APPLICATION now, isn't?

> create a new BeanManager#isInUse()
> --
>
> Key: OWB-532
> URL: https://issues.apache.org/jira/browse/OWB-532
> Project: OpenWebBeans
>  Issue Type: New Feature
>  Components: Lifecycle
>Affects Versions: 1.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.1.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Sometimes it's useful to know if OWB really got used from an application. 
> Depending on this we could implement performance tweaks, like e.g. disabling 
> the WebBeansELResolver for non-CDI apps.
> This would be very usefull in EE scenarios if the OWB jars are available in 
> the classpath but CDI doesn't get used by a WebApp.
> I'll just separate BeanManagerImpl#addBean() into a 'public' version for 
> standard beans and a #addInternalBean for adding BeanManagerBean and stuff.
> #addBean() will set a isInUse = true; whereas addInternalBean will not touch 
> this flag.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-383) static fields in CreationalContext

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-383.
---

Resolution: Fixed
  Assignee: Mark Struberg  (was: Gurkan Erdogdu)

CreationalContextImpl#currentRemoveObject got dropped. Of course there are 
still a few other public static ThreadLocals which need to get cleaned up. But 
they deserve their own Jiras...

> static fields in CreationalContext
> --
>
> Key: OWB-383
> URL: https://issues.apache.org/jira/browse/OWB-383
> Project: OpenWebBeans
>  Issue Type: Question
>Affects Versions: 1.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.1.0
>
>
> CreationalContextImpl#currentRemoveObject is currently defined as static 
> ThreadLocal.
> This will most probably make problems with geronimo or other 
> multi-classloader environments

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OWB-469) JSR299TCK: Security Error / Passivation errors during readObject

[Mark Struberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009174#comment-13009174
 ] 

Mark Struberg commented on OWB-469:
---

Rohit, this is fixed now, isn't?

Can you please close resolve it - txs!

> JSR299TCK: Security Error / Passivation errors during readObject
> 
>
> Key: OWB-469
> URL: https://issues.apache.org/jira/browse/OWB-469
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Events
>Affects Versions: 1.1.0, 1.0.1, 1.0.0-alpha-2
> Environment: win server 2003
>Reporter: Rohit Dilip Kelapure
>Assignee: Rohit Dilip Kelapure
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> JIRA opened on behalf of Paul Reder. 
> Problem Observed: 
> Snippet for failure:
>@SpecAssertions({
>   @SpecAssertion(section = "10.3.2", id = "g"),
>   @SpecAssertion(section = "6.6.2", id = "e")
>})
>public void testImplicitEventIsPassivationCapable() throws IOException, 
> ClassNotFoundException
>{
>   StudentDirectory directory = getInstanceByType(StudentDirectory.class);
>   directory.reset();
>   Registration registration = getInstanceByType(Registration.class);
>   Event event = 
> registration.getInjectedStudentRegisteredEvent();
>   assert Serializable.class.isAssignableFrom(event.getClass());
>   byte[] serializedEvent = serialize(event);
>   ...
>   Event eventCopy = 
> (Event) deserialize(serializedEvent); // <--- error 
> here
>   ...
> Error:
> java.security.AccessControlException: Access denied 
> (java.lang.RuntimePermission accessClassInPackage.com.xxx.oti.reflect)
>at 
> java.security.AccessController.checkPermission(AccessController.java:108)
>at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:533)
>at 
> com.xxx.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:212)
>at 
> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1528)
>at 
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:343)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:619)
>at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:438)
>at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
>at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
>at 
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:103)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:619)
>at java.lang.Class.forNameImpl(Native Method)
>at java.lang.Class.forName(Class.java:169)
>at 
> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:605)
>at 
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1559)
>at 
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1500)
>at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1736)
>at 
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
>at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1951)
>at 
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1875)
>at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1757)
>at 
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
>at 
> java.io.ObjectInputStream.readArray(ObjectInputStream.java:1671)
>at 
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1327)
>at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1951)
>at 
> java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:481)
>at 
> org.apache.webbeans.event.EventImpl.readObject(EventImpl.java:153)
>at 
> java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1033)
>at 
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1853)
>at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1757)
>at 
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
>at 
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:352)
>at 
> org.jboss.jsr299.tck.AbstractJSR299Test.deserialize(AbstractJSR299Test.java:63)
>at 
> org.jboss.jsr299.tck.tests.event.implicit.ImplicitEventTest.testImplicitEventIsPassivationCa

[jira] [Updated] (OWB-492) events don't get sent to private @Observes methods

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-492:
--

Fix Version/s: (was: 1.0.1)

only fixed in 1.1.0-SNAPSHOT

> events don't get sent to private @Observes methods
> --
>
> Key: OWB-492
> URL: https://issues.apache.org/jira/browse/OWB-492
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Events
>Affects Versions: 1.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.1.0
>
>
> We currently do not notify private observer methods correctly. This is caused 
> by resolving a contextual reference is currently always performed to fulfil 
> section 7.2 of the spec:
> "Invocations of producer, disposer and observer methods by the container are 
> business method invocations and are in- tercepted by method interceptors and 
> decorators."
> But since private methods are no business methods anyway, we can just resolve 
> the contextual instance instead of the contextual reference in this case

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-492) events don't get sent to private @Observes methods

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-492.
---

Resolution: Fixed

> events don't get sent to private @Observes methods
> --
>
> Key: OWB-492
> URL: https://issues.apache.org/jira/browse/OWB-492
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Events
>Affects Versions: 1.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.1.0, 1.0.1
>
>
> We currently do not notify private observer methods correctly. This is caused 
> by resolving a contextual reference is currently always performed to fulfil 
> section 7.2 of the spec:
> "Invocations of producer, disposer and observer methods by the container are 
> business method invocations and are in- tercepted by method interceptors and 
> decorators."
> But since private methods are no business methods anyway, we can just resolve 
> the contextual instance instead of the contextual reference in this case

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-512) ApplicationContext and SingletonContext in WebContextsService

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-512.
---

Resolution: Not A Problem
  Assignee: Mark Struberg  (was: Gurkan Erdogdu)

imo this is spec conform. 

Where we do store the info doesn't make a difference. The important fact is 
that the Context got closed and is not active anymore. This might only affect 
an Extension which also accesses this context in a servlet listener. Applying a 
different order in your web.xml should work - and don't ask me how to do this 
with the broken servlet-3 spec ;)

> ApplicationContext and SingletonContext in WebContextsService
> -
>
> Key: OWB-512
> URL: https://issues.apache.org/jira/browse/OWB-512
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Java EE Integration
>Affects Versions: 1.1.0
>Reporter: Gerhard Petracek
>Assignee: Mark Struberg
>
> WebContextsService shouldn't cache ApplicationContext and SingletonContext in 
> thread-locals (without a fallback) because WebBeansConfigurationListener 
> might call WebContextsService#endContext too early.
> if e.g. a portable extension gets invoked afterwards it can't access those 
> contexts. since both contexts have to exist all the time a different approach 
> (or a fallback) is needed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-526) remove usage of java.net.URLs from ScannerService and drop scannotation

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-526.
---

Resolution: Fixed

all URL parameters and ret vals got replaced by their toExternalForm() 
representation.

Buggy Scannotation parts got internalized, but a few classes from the jar are 
still needed. We will probably switch to XBeanFinder, but that should get an 
own Jira.

> remove usage of java.net.URLs from ScannerService and drop scannotation
> ---
>
> Key: OWB-526
> URL: https://issues.apache.org/jira/browse/OWB-526
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.1.0
>
> Attachments: OsgiMetaDataScannerService.java.mine
>
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> Our ScannerService currently returns Set sometimes caused by the 
> underlying use of scannotation.
> Since scannotation is broken anyway (see OWB-524) we should drop scannotation 
> and switch to url - Strings in the ScannerService SPI interface.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-490) ProcessObserverMethod Type parameters are inverted (CDITCK-174)

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-490.
---

Resolution: Fixed

should be fixed now. latest TCK is working well

> ProcessObserverMethod Type parameters are inverted (CDITCK-174)
> ---
>
> Key: OWB-490
> URL: https://issues.apache.org/jira/browse/OWB-490
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Events
>Affects Versions: 1.1.0
>Reporter: David Jencks
>Assignee: Gurkan Erdogdu
> Fix For: 1.1.0
>
>
> cf CDITCK-174.  There's some code in NotificationManager that swaps the 
> arguments if it's an observer.  I think this was because the tck was wrong.  
> Now that its fixed this swapping causes a tck failure.  The order is checked 
> in the PortableAddObserverMethodTest and AddObserverMethodExtension which has 
> the opposite order as the tck ProcessObserverMethodObserver.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-543) get rid of checked Exceptions in our SPI

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-543.
---

Resolution: Fixed

checked Exceptions got removed from our SPI if possible.

> get rid of checked Exceptions in our SPI
> 
>
> Key: OWB-543
> URL: https://issues.apache.org/jira/browse/OWB-543
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.1.0
>
>
> We currently have lots of 'throws Exception' in our SPI. We should drop those 
> because all our internal Exceptions are RuntimeExceptions anyway.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-524) OWB classpath scanning of non-jars doesn't work if the classpath contains spaces

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-524.
---

Resolution: Fixed

fixed in AnnotationDB, r1083814

> OWB classpath scanning of non-jars doesn't work if the classpath contains 
> spaces
> 
>
> Key: OWB-524
> URL: https://issues.apache.org/jira/browse/OWB-524
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.1.0
>
>
> If a CDI application gets hosted in a directory which contains spaces, our 
> ScannerService will not find any classes.
> This is caused by a subsequent bug in scannotation.
> new File("/home/msx/tmp/CODI test/trunk/core/impl/target/classes/").exists() 
> returns true but the url.getPath() used in 
> org.scannotation.archiveiterator.FileProtocolIteratorFactory returns
> /home/msx/tmp/CODI%20test/trunk/core/impl/target/classes/
> and uses this value to create a new File to check for f.isDirectory()

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-393) remove old XML configuration code

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-393.
---

Resolution: Fixed

> remove old XML configuration code
> -
>
> Key: OWB-393
> URL: https://issues.apache.org/jira/browse/OWB-393
> Project: OpenWebBeans
>  Issue Type: Improvement
>Affects Versions: M4
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.1.0
>
>
> we should finally remove the legacy XML configuration code from our codebase. 
> This code is pretty much dead because it's not defined in the spec anymore. 
> Plus it doesn't reflect all the new features which got introduced in the 
> meantime. All the configuration can be performed via extensions in a portable 
> way anyway, so there is no more need to do this in the core.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-547) WebContextsService throws NPE on asynchronous app startup

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-547.
---

Resolution: Fixed

fixed in r1083717

> WebContextsService throws NPE on asynchronous app startup
> -
>
> Key: OWB-547
> URL: https://issues.apache.org/jira/browse/OWB-547
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Lifecycle
>Affects Versions: 1.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.1.0
>
>
> If our webbeans-web plugin is present when starting our test lifecycle, we 
> get a NPE because our WebContextsService always expects a Session. But in 
> case of unit tests on the frontend the session is actually null. Same is true 
> for asynchronous operations inside a web server and e.g. for MessageDriven 
> Beans.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OWB-547) WebContextsService throws NPE on asynchronous app startup

[Mark Struberg (JIRA)]

WebContextsService throws NPE on asynchronous app startup
-

 Key: OWB-547
 URL: https://issues.apache.org/jira/browse/OWB-547
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Lifecycle
Affects Versions: 1.0.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 1.1.0


If our webbeans-web plugin is present when starting our test lifecycle, we get 
a NPE because our WebContextsService always expects a Session. But in case of 
unit tests on the frontend the session is actually null. Same is true for 
asynchronous operations inside a web server and e.g. for MessageDriven Beans.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira