[jira] Closed: (OWB-464) InjectionPointImpl using wrong class loader during serialize/deserialize, dropping qualifiers, and omiting qualifier values.
[ https://issues.apache.org/jira/browse/OWB-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gurkan Erdogdu closed OWB-464. -- Fix Version/s: 1.0.0-GA (was: 1.0.0-alpha-2) Resolution: Fixed Cool patch, thanks Paul! committed in r1002951 InjectionPointImpl using wrong class loader during serialize/deserialize, dropping qualifiers, and omiting qualifier values. Key: OWB-464 URL: https://issues.apache.org/jira/browse/OWB-464 Project: OpenWebBeans Issue Type: Bug Components: Injection and Lookup Affects Versions: 1.0.0-alpha-2 Environment: All Reporter: Paul J. Reder Assignee: Gurkan Erdogdu Fix For: 1.0.0-GA Attachments: InjectionPoint_fix.patch Original Estimate: 1h Remaining Estimate: 1h InjectionPointImpl was using the default class loader instead of the thread class loader during serialize/deserialize which was resulting in class not found exceptions. It was also dropping every other qualifier due to the way readObject was double-reading the qualifiers while looking for the '~' delimeter. And finally, the writeObject code was writing the type of the qualifiers rather than writing the whole object, thus omiting qualifier values (i.e. @Named(org.apache.webbeans.foo) resulted in @Named(value=)). Attached patch resolves these issues when applied on top of OWB-462. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ambiguous dependencies when using multiple qualifiers
OK, thanks for the clarification!
Regards,
Jakob
2010/9/29 Joseph Bergmark bergm...@apache.org:
I think you hit the nail on the head with your last paragraph.
Basically it only matters that the bean (or producer in this case)
matches all of the qualifiers on the injection point. From the
perspective of the specification it doesn't matter if the bean has
extra qualifiers beyond those on the injection point. Section 5.3 is
another key section here.
Sincerely,
Joe
On Wed, Sep 29, 2010 at 12:30 PM, Jakob Korherr jakob.korh...@gmail.com
wrote:
Hi,
I tested some scenarios when using multiple qualifiers for test-cases
in MyFaces CODI and stumbled upon the following scenario, which is not
totally clear to me.
Image you have the following producer methods:
�...@produces
�...@qualifier2
�...@applicationscoped
public ProducerBean createWithQualifier2()
{
return new ProducerBean();
}
�...@produces
�...@qualifier1
�...@qualifier2
�...@applicationscoped
public ProducerBean createWithQualifier1And2()
{
return new ProducerBean();
}
and you want to inject the instances produced by these producers. Now
you can use @Inject @Qualifier1 or @Inject @Qualifier1 @Qualifier2,
but when using @Inject @Qualifier2 you will get an exception, because
the injection point is ambiguous (both producers provide @Qualifier2).
However I was wondering if this is really unresolvable ambiguous,
because if you think about it, it would make sence to take the
producer createWithQualifier2() in this scenario (because the other
one provides additional qualifiers).
I also took a look in the CDI spec about this, but could only find the
following from section 2.3.4: A bean may only be injected to an
injection point if it has all the qualifiers of the injection point.
Of course this applies to both producers and thus, yes, it's kinda
ambiguous.
WDYT?
Regards,
Jakob
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: last TCK run
On Thu, Sep 30, 2010 at 8:57 AM, Mark Struberg strub...@yahoo.de wrote: Hi! Before doing a release this afternoon, I'm currently running the TCK again. For standalone, I have one test which fails: DestroyedInstanceReturnedByGetTest Anyone knows anything about it? That's one of three I am used to seeing in my sandbox.
Re: last TCK run
and the others? LieGrue, strub --- On Thu, 9/30/10, Eric Covener cove...@gmail.com wrote: From: Eric Covener cove...@gmail.com Subject: Re: last TCK run To: dev@openwebbeans.apache.org Date: Thursday, September 30, 2010, 1:12 PM On Thu, Sep 30, 2010 at 8:57 AM, Mark Struberg strub...@yahoo.de wrote: Hi! Before doing a release this afternoon, I'm currently running the TCK again. For standalone, I have one test which fails: DestroyedInstanceReturnedByGetTest Anyone knows anything about it? That's one of three I am used to seeing in my sandbox.
Re: last TCK run
On Thu, Sep 30, 2010 at 9:20 AM, Mark Struberg strub...@yahoo.de wrote: and the others? Failed tests: testDestroyedInstanceMustNotBeReturnedByGet(org.jboss.jsr299.tck.tests.context.DestroyedInstanceReturnedByGetTest) testBindingTypesAppliedToDisposalMethodParameters(org.jboss.jsr299.tck.tests.implementation.disposal.method.definition.DisposalMethodDefinitionTest) testContextCreatesNewInstanceForInjection(org.jboss.jsr299.tck.tests.implementation.simple.lifecycle.SimpleBeanLifecycleTest) Tests run: 574, Failures: 3, Errors: 0, Skipped: 0
[jira] Resolved: (OWB-465) enhance EJB common code for crude @LocalBean support
[ https://issues.apache.org/jira/browse/OWB-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-465. -- Resolution: Fixed enhance EJB common code for crude @LocalBean support Key: OWB-465 URL: https://issues.apache.org/jira/browse/OWB-465 Project: OpenWebBeans Issue Type: Improvement Components: Java EE Integration Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: 1.0.0-GA Original Estimate: 1h Remaining Estimate: 1h I need a small enhancement to expose no-interface local views for EJB to the 299 Api Types. I am not sure if this is necessary for openejb, but in my containr the bean-class is not returned among the local business itnterfaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-466) Ensure removal of all ThreadLocal values
[ https://issues.apache.org/jira/browse/OWB-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated OWB-466: -- Attachment: OWB-466.patch Ensure removal of all ThreadLocal values Key: OWB-466 URL: https://issues.apache.org/jira/browse/OWB-466 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.0.0-alpha-2 Reporter: Jakob Korherr Assignee: Gurkan Erdogdu Attachments: OWB-466.patch While running our automated webapp tests with MyFaces CODI and OWB, I always got the following log entries: 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@543c944f]) and a value of type [org.apache.webbeans.inject.impl.InjectionPointImpl] (value [Field Injection Point, field name : postConstructApplicationEvent, Bean Owner : [Name:systemEventBroadcaster,WebBeans Type:MANAGED,API Types:[java.lang.Object,org.apache.myfaces.extensions.cdi.jsf2.impl.listener.system.SystemEventBroadcaster],Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default,javax.inject.Named]]]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@552cf9bd]) and a value of type [org.apache.webbeans.context.SessionContext] (value [org.apache.webbeans.context.sessioncont...@7bc012fa]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@552cf9bd]) and a value of type [org.apache.webbeans.context.SessionContext] (value [org.apache.webbeans.context.sessioncont...@7f1e1a8e]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. 30.09.2010 16:14:14 org.apache.coyote.http11.Http11Protocol destroy ..saying that Tomcat's webappclassloader had to remove some ThreadLocal values from the ThreadMap. I was able to track the affected ThreadLocal instances down: InstanceBean.local and WebContextsService.sessionContext. After digging into the code, I found out that there are many remove() operations on various ThreadLocal instances, but it was not thought that remove() only works for the current Thread. Thus when a ThreadLocal is set during a request it won't be removed when the container stops, because the shutdown-thread is clearly not the same as the request-thread. This means the request-ThreadLocal instances have to be removed after every request has ended - in requestDestroyed(ServletRequestEvent event). The provided patch adds some remove() calls in requestDestroyed() and also in afterStopApplication(). With this patch none of the above error-logs are shown in any of my test cases. However there might be some other ThreadLocals which should be cleaned up at every request, but this solution currently works for me! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r1003072 - in /openwebbeans/trunk/webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component: BaseEjbBean.java EjbBeanCreatorImpl.java
no problem, just trying to fix this one broken TCK test yet. I'll call another round for TCK checks in 3 hours or so and if all runs well I'll call for a checkin freeze. LieGrue, strub --- On Thu, 9/30/10, Eric Covener cove...@apache.org wrote: From: Eric Covener cove...@apache.org Subject: Re: svn commit: r1003072 - in /openwebbeans/trunk/webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component: BaseEjbBean.java EjbBeanCreatorImpl.java To: dev@openwebbeans.apache.org Date: Thursday, September 30, 2010, 2:20 PM On Thu, Sep 30, 2010 at 10:18 AM, cove...@apache.org wrote: Author: covener Date: Thu Sep 30 14:18:17 2010 New Revision: 1003072 sorry Mark -- I know we are pseudo-frozen but need this [safe] hook for container integration.
[jira] Assigned: (OWB-466) Ensure removal of all ThreadLocal values
[ https://issues.apache.org/jira/browse/OWB-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned OWB-466: - Assignee: Mark Struberg (was: Gurkan Erdogdu) Ensure removal of all ThreadLocal values Key: OWB-466 URL: https://issues.apache.org/jira/browse/OWB-466 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.0.0-alpha-2 Reporter: Jakob Korherr Assignee: Mark Struberg Attachments: OWB-466.patch While running our automated webapp tests with MyFaces CODI and OWB, I always got the following log entries: 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@543c944f]) and a value of type [org.apache.webbeans.inject.impl.InjectionPointImpl] (value [Field Injection Point, field name : postConstructApplicationEvent, Bean Owner : [Name:systemEventBroadcaster,WebBeans Type:MANAGED,API Types:[java.lang.Object,org.apache.myfaces.extensions.cdi.jsf2.impl.listener.system.SystemEventBroadcaster],Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default,javax.inject.Named]]]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@552cf9bd]) and a value of type [org.apache.webbeans.context.SessionContext] (value [org.apache.webbeans.context.sessioncont...@7bc012fa]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@552cf9bd]) and a value of type [org.apache.webbeans.context.SessionContext] (value [org.apache.webbeans.context.sessioncont...@7f1e1a8e]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. 30.09.2010 16:14:14 org.apache.coyote.http11.Http11Protocol destroy ..saying that Tomcat's webappclassloader had to remove some ThreadLocal values from the ThreadMap. I was able to track the affected ThreadLocal instances down: InstanceBean.local and WebContextsService.sessionContext. After digging into the code, I found out that there are many remove() operations on various ThreadLocal instances, but it was not thought that remove() only works for the current Thread. Thus when a ThreadLocal is set during a request it won't be removed when the container stops, because the shutdown-thread is clearly not the same as the request-thread. This means the request-ThreadLocal instances have to be removed after every request has ended - in requestDestroyed(ServletRequestEvent event). The provided patch adds some remove() calls in requestDestroyed() and also in afterStopApplication(). With this patch none of the above error-logs are shown in any of my test cases. However there might be some other ThreadLocals which should be cleaned up at every request, but this solution currently works for me! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: last TCK run
I've added a CDI-TCK [1] since pete also confirmed that this seems broken. LieGrue, strub [1] https://jira.jboss.org/browse/CDITCK-183 --- On Thu, 9/30/10, Eric Covener cove...@gmail.com wrote: From: Eric Covener cove...@gmail.com Subject: Re: last TCK run To: dev@openwebbeans.apache.org Date: Thursday, September 30, 2010, 1:50 PM On Thu, Sep 30, 2010 at 9:20 AM, Mark Struberg strub...@yahoo.de wrote: and the others? Failed tests: testDestroyedInstanceMustNotBeReturnedByGet(org.jboss.jsr299.tck.tests.context.DestroyedInstanceReturnedByGetTest) testBindingTypesAppliedToDisposalMethodParameters(org.jboss.jsr299.tck.tests.implementation.disposal.method.definition.DisposalMethodDefinitionTest) testContextCreatesNewInstanceForInjection(org.jboss.jsr299.tck.tests.implementation.simple.lifecycle.SimpleBeanLifecycleTest) Tests run: 574, Failures: 3, Errors: 0, Skipped: 0
[jira] Resolved: (OWB-466) Ensure removal of all ThreadLocal values
[ https://issues.apache.org/jira/browse/OWB-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OWB-466. --- Fix Version/s: 1.0.0-GA Resolution: Fixed patch applied, thanks Jakob! Ensure removal of all ThreadLocal values Key: OWB-466 URL: https://issues.apache.org/jira/browse/OWB-466 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.0.0-alpha-2 Reporter: Jakob Korherr Assignee: Mark Struberg Fix For: 1.0.0-GA Attachments: OWB-466.patch While running our automated webapp tests with MyFaces CODI and OWB, I always got the following log entries: 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@543c944f]) and a value of type [org.apache.webbeans.inject.impl.InjectionPointImpl] (value [Field Injection Point, field name : postConstructApplicationEvent, Bean Owner : [Name:systemEventBroadcaster,WebBeans Type:MANAGED,API Types:[java.lang.Object,org.apache.myfaces.extensions.cdi.jsf2.impl.listener.system.SystemEventBroadcaster],Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default,javax.inject.Named]]]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@552cf9bd]) and a value of type [org.apache.webbeans.context.SessionContext] (value [org.apache.webbeans.context.sessioncont...@7bc012fa]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@552cf9bd]) and a value of type [org.apache.webbeans.context.SessionContext] (value [org.apache.webbeans.context.sessioncont...@7f1e1a8e]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. 30.09.2010 16:14:14 org.apache.coyote.http11.Http11Protocol destroy ..saying that Tomcat's webappclassloader had to remove some ThreadLocal values from the ThreadMap. I was able to track the affected ThreadLocal instances down: InstanceBean.local and WebContextsService.sessionContext. After digging into the code, I found out that there are many remove() operations on various ThreadLocal instances, but it was not thought that remove() only works for the current Thread. Thus when a ThreadLocal is set during a request it won't be removed when the container stops, because the shutdown-thread is clearly not the same as the request-thread. This means the request-ThreadLocal instances have to be removed after every request has ended - in requestDestroyed(ServletRequestEvent event). The provided patch adds some remove() calls in requestDestroyed() and also in afterStopApplication(). With this patch none of the above error-logs are shown in any of my test cases. However there might be some other ThreadLocals which should be cleaned up at every request, but this solution currently works for me! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: I'm now starting of release process
Can we update our log file after the first release ? --Thanks, Rohit On Thu, Sep 30, 2010 at 2:57 PM, Mark Struberg strub...@yahoo.de wrote: Hi folks! I'm starting the preparation for the 1.0.0 release in about 15 minutes. So please abstain from checking in until I'll ping you again. Txs and LieGrue, strub
Re: I'm now starting of release process
sorry meant logo file . On Thu, Sep 30, 2010 at 3:01 PM, Rohit Kelapure kelap...@gmail.com wrote: Can we update our log file after the first release ? --Thanks, Rohit On Thu, Sep 30, 2010 at 2:57 PM, Mark Struberg strub...@yahoo.de wrote: Hi folks! I'm starting the preparation for the 1.0.0 release in about 15 minutes. So please abstain from checking in until I'll ping you again. Txs and LieGrue, strub
Re: I'm now starting of release process
reply heh yes, we can We just need to copy it onto our web server LieGrue, strub --- On Thu, 9/30/10, Rohit Kelapure kelap...@gmail.com wrote: From: Rohit Kelapure kelap...@gmail.com Subject: Re: I'm now starting of release process To: dev@openwebbeans.apache.org Date: Thursday, September 30, 2010, 7:01 PM sorry meant logo file . On Thu, Sep 30, 2010 at 3:01 PM, Rohit Kelapure kelap...@gmail.com wrote: Can we update our log file after the first release ? --Thanks, Rohit On Thu, Sep 30, 2010 at 2:57 PM, Mark Struberg strub...@yahoo.de wrote: Hi folks! I'm starting the preparation for the 1.0.0 release in about 15 minutes. So please abstain from checking in until I'll ping you again. Txs and LieGrue, strub
[jira] Updated: (OWB-448) More changes for decorator and interceptor passivation support
[ https://issues.apache.org/jira/browse/OWB-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OWB-448: -- Fix Version/s: 1.1.0 (was: 1.0.0-alpha-3) More changes for decorator and interceptor passivation support -- Key: OWB-448 URL: https://issues.apache.org/jira/browse/OWB-448 Project: OpenWebBeans Issue Type: Improvement Components: Interceptor and Decorators Affects Versions: 1.0.0-alpha-2 Reporter: YING WANG Assignee: YING WANG Priority: Minor Fix For: 1.1.0 add some serialization/deserialization code for interceptor, decorator, and @EJB and some of their handlers. Note: due to the nature of abstract decorator and javassist (we use a proxy object to instanciate the abstract decorator class. ), passivation of abstract decorator is not working right now since the fields in the decorator((proxy object) could not be serialzed by javassist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-445) we must not use javassist ProxyFactory#setHandler(MethodHandler)
[ https://issues.apache.org/jira/browse/OWB-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OWB-445. --- Fix Version/s: 1.0.0-GA (was: 1.0.0-alpha-3) Resolution: Fixed we must not use javassist ProxyFactory#setHandler(MethodHandler) Key: OWB-445 URL: https://issues.apache.org/jira/browse/OWB-445 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.0.0-alpha-2 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.0.0-GA ProxyFactory.setHandler is deprecated and if used creates memory leaks! We must create the ProxyClass without a default method handler and set it after we create a proxy instance of that very class: Object proxyInstance = proxyClass.newInstance(); ((ProxyObject) proxyInstance ).setHandler( ... ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-428) implementation of equals and hashCode for AbstractOwbBean
[ https://issues.apache.org/jira/browse/OWB-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OWB-428: -- Fix Version/s: 1.1.0 (was: 1.0.0-GA) Description: 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. 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. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-384) OWB needs to call 299-defined PrePassivate, PostActivate, and AroundTimeout interceptors for EJBs
[ https://issues.apache.org/jira/browse/OWB-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OWB-384. --- Resolution: Fixed fixed. see OWB-422 OWB needs to call 299-defined PrePassivate, PostActivate, and AroundTimeout interceptors for EJBs - Key: OWB-384 URL: https://issues.apache.org/jira/browse/OWB-384 Project: OpenWebBeans Issue Type: Bug Components: Java EE Integration Affects Versions: 1.0.0-alpha-1 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-GA Original Estimate: 16h Remaining Estimate: 16h ignoring OWB's internal passivation needs, 299 interceptors might hook into these lifecycle events. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-177) Handling of InterceptionType#POST_ACTIVATE, PRE_PASSIVATE and AROUND_TIMEOUT is missing
[ https://issues.apache.org/jira/browse/OWB-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OWB-177. --- Resolution: Fixed fixed. see OWB-422 Handling of InterceptionType#POST_ACTIVATE, PRE_PASSIVATE and AROUND_TIMEOUT is missing --- Key: OWB-177 URL: https://issues.apache.org/jira/browse/OWB-177 Project: OpenWebBeans Issue Type: Improvement Components: Interceptor and Decorators Affects Versions: 1.0.0-alpha-1 Reporter: Mark Struberg Assignee: Gurkan Erdogdu Fix For: 1.0.0-GA those interceptor types allow handling of the new ones defined in EJB-3.1. Where do we handle them? This turns out to be a very basic decision whether to pull in the EE api or not. If we handle them in the in openwebbeans-geronimo or openwebbeans-ejb only, then we'd loose this functionality if we are running in e.g. a pure ServletContainer. But although it's defined in the EJB spec, I personally think this functionality might be interesting for SE applications too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] release Apache OpenWebBeans 1.0.0
Hi! I'd like to call a VOTE on releasing Apache OpenWebBeans-1.0.0 . Maven staging repo: https://repository.apache.org/content/repositories/orgapacheopenwebbeans-001/ SVN source tag (1003328): https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.0.0/ Source release: https://repository.apache.org/content/repositories/orgapacheopenwebbeans-001/org/apache/openwebbeans/openwebbeans/1.0.0/openwebbeans-1.0.0-source-release.zip Binary release: https://repository.apache.org/content/repositories/orgapacheopenwebbeans-001/org/apache/openwebbeans/openwebbeans-distribution/1.0.0/openwebbeans-distribution-1.0.0-binary.tar.gz PGP release key 2FDB81B1 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 veto (and reason why) A small note: I've created a owb_1.0.x branch which will contain the maintenance work on OWB-1.0.x. Feature development will be performed in trunk which now has a version of 1.1.0-SNAPSHOT txs and LieGrue, strub
