Re: are @PostConstruct and @PreDestroy really interceptor functions?
I agree it may not be necessary, but Gavin has strongly hinted that he expected Decorators (and maybe even Interceptors) to be implemented using subclassing. Seems our current solution works in a spec compliant way for normal scoped beans though. Not sure if any MRs to the spec will change that. Sincerely, Joe On Wed, Apr 7, 2010 at 3:48 PM, Gurkan Erdogdu wrote: > Actually, for normal scoped beans it is not necessary to add byte code > injection altough it can be done. Because running code is there, you could > concentrate on some other stuff. But it is handy way to use it on > DependentScoped beans interceptors, because spec. talks about subclassing > for dependent scoped beans. > > Thanks; > > --Gurkan > > > > > > From: Mark Struberg > To: dev@openwebbeans.apache.org > Sent: Wed, April 7, 2010 10:21:32 PM > Subject: Re: are @PostConstruct and @PreDestroy really interceptor > functions? > > Thanks Gurkan! > > I now also found the utility method who filters out the AROUND_INVOKE > interceptors we need. > > Did you look at the test code which shows the principal way to create > subclasses which I committed? > wdyt? > > LieGrue, > strub > > --- Gurkan Erdogdu schrieb am Mi, 7.4.2010: > > > Von: Gurkan Erdogdu > > Betreff: Re: are @PostConstruct and @PreDestroy really interceptor > functions? > > An: dev@openwebbeans.apache.org > > Datum: Mittwoch, 7. April, 2010 21:19 Uhr > > Those are not handled by > > InterceptorHandler. These are defined in > > AbstractInjectionTargetBean#postConstruct or preDestroy > > > > > > > > > > > > From: Mark Struberg > > To: dev@openwebbeans.apache.org > > Sent: Wed, April 7, 2010 7:56:37 PM > > Subject: are @PostConstruct and @PreDestroy really > > interceptor functions? > > > > Hi! > > > > Currently we handle @PostConstruct and @PreDestroy methods > > via the InterceptorHandler. > > > > Is this really necessary? > > > > Those functions are directly called by the container in > > very clear defined situations in the lifecycle. And they > > always get called from _inside_ the container and not > > triggered by any client code. > > > > So can we move those 2 out of the interceptor stack? > > > > wdyt? > > > > LieGrue, > > strub > > > > __ > > Do You Yahoo!? > > Sie sind Spam leid? Yahoo! Mail verfügt über einen > > herausragenden Schutz gegen Massenmails. > > http://mail.yahoo.com > > > > > > > > > > ___ > > Yahoo! Türkiye açıldı! http://yahoo.com.tr > > İnternet üzerindeki en iyi içeriği Yahoo! Türkiye > > sizlere sunuyor! > > __ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz > gegen Massenmails. > http://mail.yahoo.com > > > > ___ > Yahoo! Türkiye açıldı! http://yahoo.com.tr > İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor! >
Re: are @PostConstruct and @PreDestroy really interceptor functions?
Actually, for normal scoped beans it is not necessary to add byte code injection altough it can be done. Because running code is there, you could concentrate on some other stuff. But it is handy way to use it on DependentScoped beans interceptors, because spec. talks about subclassing for dependent scoped beans. Thanks; --Gurkan From: Mark Struberg To: dev@openwebbeans.apache.org Sent: Wed, April 7, 2010 10:21:32 PM Subject: Re: are @PostConstruct and @PreDestroy really interceptor functions? Thanks Gurkan! I now also found the utility method who filters out the AROUND_INVOKE interceptors we need. Did you look at the test code which shows the principal way to create subclasses which I committed? wdyt? LieGrue, strub --- Gurkan Erdogdu schrieb am Mi, 7.4.2010: > Von: Gurkan Erdogdu > Betreff: Re: are @PostConstruct and @PreDestroy really interceptor functions? > An: dev@openwebbeans.apache.org > Datum: Mittwoch, 7. April, 2010 21:19 Uhr > Those are not handled by > InterceptorHandler. These are defined in > AbstractInjectionTargetBean#postConstruct or preDestroy > > > > > > From: Mark Struberg > To: dev@openwebbeans.apache.org > Sent: Wed, April 7, 2010 7:56:37 PM > Subject: are @PostConstruct and @PreDestroy really > interceptor functions? > > Hi! > > Currently we handle @PostConstruct and @PreDestroy methods > via the InterceptorHandler. > > Is this really necessary? > > Those functions are directly called by the container in > very clear defined situations in the lifecycle. And they > always get called from _inside_ the container and not > triggered by any client code. > > So can we move those 2 out of the interceptor stack? > > wdyt? > > LieGrue, > strub > > __ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen > herausragenden Schutz gegen Massenmails. > http://mail.yahoo.com > > > > > ___ > Yahoo! Türkiye açıldı! http://yahoo.com.tr > İnternet üzerindeki en iyi içeriği Yahoo! Türkiye > sizlere sunuyor! __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ Yahoo! Türkiye açıldı! http://yahoo.com.tr İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
Re: are @PostConstruct and @PreDestroy really interceptor functions?
Thanks Gurkan! I now also found the utility method who filters out the AROUND_INVOKE interceptors we need. Did you look at the test code which shows the principal way to create subclasses which I committed? wdyt? LieGrue, strub --- Gurkan Erdogdu schrieb am Mi, 7.4.2010: > Von: Gurkan Erdogdu > Betreff: Re: are @PostConstruct and @PreDestroy really interceptor functions? > An: dev@openwebbeans.apache.org > Datum: Mittwoch, 7. April, 2010 21:19 Uhr > Those are not handled by > InterceptorHandler. These are defined in > AbstractInjectionTargetBean#postConstruct or preDestroy > > > > > > From: Mark Struberg > To: dev@openwebbeans.apache.org > Sent: Wed, April 7, 2010 7:56:37 PM > Subject: are @PostConstruct and @PreDestroy really > interceptor functions? > > Hi! > > Currently we handle @PostConstruct and @PreDestroy methods > via the InterceptorHandler. > > Is this really necessary? > > Those functions are directly called by the container in > very clear defined situations in the lifecycle. And they > always get called from _inside_ the container and not > triggered by any client code. > > So can we move those 2 out of the interceptor stack? > > wdyt? > > LieGrue, > strub > > __ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen > herausragenden Schutz gegen Massenmails. > http://mail.yahoo.com > > > > > ___ > Yahoo! Türkiye açıldı! http://yahoo.com.tr > İnternet üzerindeki en iyi içeriği Yahoo! Türkiye > sizlere sunuyor! __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
Re: are @PostConstruct and @PreDestroy really interceptor functions?
Those are not handled by InterceptorHandler. These are defined in AbstractInjectionTargetBean#postConstruct or preDestroy From: Mark Struberg To: dev@openwebbeans.apache.org Sent: Wed, April 7, 2010 7:56:37 PM Subject: are @PostConstruct and @PreDestroy really interceptor functions? Hi! Currently we handle @PostConstruct and @PreDestroy methods via the InterceptorHandler. Is this really necessary? Those functions are directly called by the container in very clear defined situations in the lifecycle. And they always get called from _inside_ the container and not triggered by any client code. So can we move those 2 out of the interceptor stack? wdyt? LieGrue, strub __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ Yahoo! Türkiye açıldı! http://yahoo.com.tr İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
are @PostConstruct and @PreDestroy really interceptor functions?
Hi! Currently we handle @PostConstruct and @PreDestroy methods via the InterceptorHandler. Is this really necessary? Those functions are directly called by the container in very clear defined situations in the lifecycle. And they always get called from _inside_ the container and not triggered by any client code. So can we move those 2 out of the interceptor stack? wdyt? LieGrue, strub __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
[jira] Resolved: (OWB-345) Remove duplicate dependencies
[ https://issues.apache.org/jira/browse/OWB-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OWB-345. --- Resolution: Fixed Fix Version/s: 1.0.0 patch applied, txs 2 jlmonteiro! > Remove duplicate dependencies > - > > Key: OWB-345 > URL: https://issues.apache.org/jira/browse/OWB-345 > Project: OpenWebBeans > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: WinXP >Reporter: Jean-Louis MONTEIRO >Assignee: Mark Struberg > Fix For: 1.0.0 > > Attachments: patch-OWB-345.txt > > > Maven 3 does not allow duplicate dependencies. So in order to use Maven 3, > can you remove duplicate entries ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OWB-345) Remove duplicate dependencies
[ https://issues.apache.org/jira/browse/OWB-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned OWB-345: - Assignee: Mark Struberg (was: Gurkan Erdogdu) > Remove duplicate dependencies > - > > Key: OWB-345 > URL: https://issues.apache.org/jira/browse/OWB-345 > Project: OpenWebBeans > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: WinXP >Reporter: Jean-Louis MONTEIRO >Assignee: Mark Struberg > Attachments: patch-OWB-345.txt > > > Maven 3 does not allow duplicate dependencies. So in order to use Maven 3, > can you remove duplicate entries ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-345) Remove duplicate dependencies
[ https://issues.apache.org/jira/browse/OWB-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-345: Attachment: patch-OWB-345.txt > Remove duplicate dependencies > - > > Key: OWB-345 > URL: https://issues.apache.org/jira/browse/OWB-345 > Project: OpenWebBeans > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: WinXP >Reporter: Jean-Louis MONTEIRO >Assignee: Gurkan Erdogdu > Attachments: patch-OWB-345.txt > > > Maven 3 does not allow duplicate dependencies. So in order to use Maven 3, > can you remove duplicate entries ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-345) Remove duplicate dependencies
Remove duplicate dependencies - Key: OWB-345 URL: https://issues.apache.org/jira/browse/OWB-345 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.0.0 Environment: WinXP Reporter: Jean-Louis MONTEIRO Assignee: Gurkan Erdogdu Maven 3 does not allow duplicate dependencies. So in order to use Maven 3, can you remove duplicate entries ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-344) implement Decorators and Interceptors as subclassing
implement Decorators and Interceptors as subclassing Key: OWB-344 URL: https://issues.apache.org/jira/browse/OWB-344 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.0.0 This will allow us to further speed up interceptor and decorator handling and to store interceptor instances directly with the contextual instances. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-317) creationalContext in InvocationContextImpl is always null
[ https://issues.apache.org/jira/browse/OWB-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OWB-317. --- Resolution: Fixed > creationalContext in InvocationContextImpl is always null > - > > Key: OWB-317 > URL: https://issues.apache.org/jira/browse/OWB-317 > Project: OpenWebBeans > Issue Type: Bug > Components: Interceptor and Decorators >Affects Versions: M4 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.0.0 > > > the creationalContext in InvocationContextImpl never gets set. So any > situation where the contextual instance is not set (e.g. in > InterceptorHandler#invoke) may not create a fresh contextual instance. > This situation should occur rarely if we fix the code in > NormalScopedBeanInterceptorHandler though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
