[jira] [Created] (DELTASPIKE-426) cdi support for jsf converters and validators

[Gerhard Petracek (JIRA)]

Gerhard Petracek created DELTASPIKE-426:
---

 Summary: cdi support for jsf converters and validators
 Key: DELTASPIKE-426
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-426
 Project: DeltaSpike
  Issue Type: New Feature
  Components: JSF-Module
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 0.6


port MYFACES-3797



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Any plan to adopt Java EE 7

[Gerhard Petracek]

short addition:

some parts were postponed (in the final version of the spec.).
however, at myfaces we are currently working on it.
i'll port whatever is useful, once we are done.

regards,
gerhard



2013/5/1 Gerhard Petracek 

> hi hantsy,
>
> see chapter 5.4.1 of jsr-344 (and the vote you mentioned is fine as well).
>
> regards,
> gerhard
>
>
>
> 2013/5/1 hantsy 
>
>> Hi,
>>
>> I noticed Java EE 7 got approval, is there any plan to support Java EE 7.
>>
>> And for JSF 2.2, the Converter, Validator , UIComponent, all listeners
>> still do not support CDI @Inject. Personally it is a big
>> disappointment.  And other two "big" features introduced in JSF2.2,
>> resource contract and flow, I also have no interest.
>>
>> Especially the flow, the definition is very tedious, I hope Apache
>> Deltaspike can pick up the simple @ConversationScoped and @Begin @End
>> annotations in Seam 2 to implement a simple page flow solution .
>>
>> BTW,  in the vote page, I found the status of  Redhat is "not voted",
>> what this means?
>>
>> Hantsy
>> --
>> Fulltime Java EE Freelancer from China
>>
>
>

Re: git commit: DELTASPIKE-424 taking into account EntityManagerResolver with a normal scope

[Romain Manni-Bucau]

@Mark: if we add the constraint to not use other scoped injections it would
work...but I agree it is maybe a big constraint since the em will often be
@ReqScoped

*Romain Manni-Bucau*
*Twitter: @rmannibucau *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/10/11 Karl Kildén 

> Hello!
>
> I have some trouble understanding why it's bad to destroy the instance with
> that example. What about this example, does it make sense?
>
> DependentProvider ctxControl =
> BeanProvider.getDependent(ContextControl.class);
>
> ctxControl.get().startContext(ApplicationScoped.class);
> // Do something useful in for example a Quartz Job
>
> ctxControl.destroy();
>
> cheers
>
>
>
>
> On 11 October 2013 10:15, Mark Struberg  wrote:
>
> >
> > >If you don't destroy it you'll likely leak.
> > Yes, fully agree. But the way we do it is still wrong. IF it is a
> > @Dependent scoped instance, then we must store the
> > DependentProvider somewhere and only invoke it's destroy()
> > method once we really need.
> >
> > For NormalScoped beans you are relieved of this burden, but for
> @Dependent
> > ones you need to handle it manually. The DependentProvider just helps to
> > easily store the CreationalContext, the Bean and the instance for
> > convenience reasons.
> >
> >
> > LieGrue,
> > strub
> >
> >
> > >
> > > From: Romain Manni-Bucau 
> > >To: "dev@deltaspike.apache.org" ; Mark
> > Struberg 
> > >Sent: Thursday, 10 October 2013, 9:07
> > >Subject: Re: git commit: DELTASPIKE-424 taking into account
> > EntityManagerResolver with a normal scope
> > >
> > >
> > >If you don't destroy it you'll likely leak.
> > >
> > >And once again you are in your case where you handle the emf yourself.
> In
> > >other cases @Dependent should work fine.
> > >
> > >That said nothing again preventing using @Dependent so just do it If it
> > >solves the issue. Normal scopes were the important part for me.
> > >
> > >*Romain Manni-Bucau*
> > >*Twitter: @rmannibucau *
> > >*Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > >*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >*Github: https://github.com/rmannibucau*
> > >
> > >
> > >
> > >
> > >2013/10/10 Mark Struberg 
> > >
> > >>
> > >> >Both works
> > >>
> > >> That's exactly where I disagree. While both 'work' in the sample,
> > >> immediately destroying the instances again after creating them - and
> > only
> > >> later returning the java reference to the now 'dead'
> > EntityManagerResolver
> > >> - is broken if you will use it in productive scenarios.
> > >>
> > >>
> > >> Either we fix this, or we don't need any special handling. In this
> case
> > I
> > >> suggest to just use DependentProvider.get() for all cases. It has no
> > harm
> > >> on NormalScoped instances anyway.
> > >>
> > >> I will guard DependentProvider#destroy to not have any impact on
> > >> @Dependent scoped instances.
> > >>
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >> >
> > >> > From: Romain Manni-Bucau 
> > >> >To: "dev@deltaspike.apache.org" ; Mark
> > >> Struberg 
> > >> >Sent: Thursday, 10 October 2013, 8:33
> > >> >Subject: Re: git commit: DELTASPIKE-424 taking into account
> > >> EntityManagerResolver with a normal scope
> > >> >
> > >> >
> > >> >
> > >> >Both works Mark depending as you said from where you take your em. We
> > >> just need to be explicit on this behavior. BTW I prefer the normal
> scope
> > >> usage too.
> > >> >
> > >> >
> > >> >Romain Manni-Bucau
> > >> >Twitter: @rmannibucau
> > >> >Blog: http://rmannibucau.wordpress.com/
> > >> >LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >> >Github: https://github.com/rmannibucau
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >2013/10/10 Mark Struberg 
> > >> >
> > >> >Not sure if we really need this flag.
> > >> >>The most important question to me is _when_ do we trigger the
> > destroy()
> > >> method.
> > >> >>
> > >> >>The following code doesn't make much sense imo:
> > >> >>
> > >> >>> final DependentProvider resolver
> =
> > >> lookupResolver(emrc);
> > >> >>> result = resolver.get().resolveEntityManager();
> > >> >>> resolver.destroy();
> > >> >>
> > >> >>
> > >> >>The DependentProvider is intended to store it's instances somewhere
> to
> > >> be able to properly destroy the created @Dependent instance once you
> > don't
> > >> need it anymore. Invoking destroy() immediately but returning the
> > created
> > >> contextual instance makes no sense imo. Imagine what happens if you
> > would
> > >> close the EntityManagerFactory in a @PreDestroy method.
> > >> >>
> > >> >>If there is no clean way to clean up the instance again, then we
> > should
> > >> only rely on NormalScoped instances and remove the ha

Re: git commit: DELTASPIKE-424 taking into account EntityManagerResolver with a normal scope

[Karl Kildén]

Hello!

I have some trouble understanding why it's bad to destroy the instance with
that example. What about this example, does it make sense?

DependentProvider ctxControl =
BeanProvider.getDependent(ContextControl.class);

ctxControl.get().startContext(ApplicationScoped.class);
// Do something useful in for example a Quartz Job

ctxControl.destroy();

cheers




On 11 October 2013 10:15, Mark Struberg  wrote:

>
> >If you don't destroy it you'll likely leak.
> Yes, fully agree. But the way we do it is still wrong. IF it is a
> @Dependent scoped instance, then we must store the
> DependentProvider somewhere and only invoke it's destroy()
> method once we really need.
>
> For NormalScoped beans you are relieved of this burden, but for @Dependent
> ones you need to handle it manually. The DependentProvider just helps to
> easily store the CreationalContext, the Bean and the instance for
> convenience reasons.
>
>
> LieGrue,
> strub
>
>
> >
> > From: Romain Manni-Bucau 
> >To: "dev@deltaspike.apache.org" ; Mark
> Struberg 
> >Sent: Thursday, 10 October 2013, 9:07
> >Subject: Re: git commit: DELTASPIKE-424 taking into account
> EntityManagerResolver with a normal scope
> >
> >
> >If you don't destroy it you'll likely leak.
> >
> >And once again you are in your case where you handle the emf yourself. In
> >other cases @Dependent should work fine.
> >
> >That said nothing again preventing using @Dependent so just do it If it
> >solves the issue. Normal scopes were the important part for me.
> >
> >*Romain Manni-Bucau*
> >*Twitter: @rmannibucau *
> >*Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> >*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >*Github: https://github.com/rmannibucau*
> >
> >
> >
> >
> >2013/10/10 Mark Struberg 
> >
> >>
> >> >Both works
> >>
> >> That's exactly where I disagree. While both 'work' in the sample,
> >> immediately destroying the instances again after creating them - and
> only
> >> later returning the java reference to the now 'dead'
> EntityManagerResolver
> >> - is broken if you will use it in productive scenarios.
> >>
> >>
> >> Either we fix this, or we don't need any special handling. In this case
> I
> >> suggest to just use DependentProvider.get() for all cases. It has no
> harm
> >> on NormalScoped instances anyway.
> >>
> >> I will guard DependentProvider#destroy to not have any impact on
> >> @Dependent scoped instances.
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> >
> >> > From: Romain Manni-Bucau 
> >> >To: "dev@deltaspike.apache.org" ; Mark
> >> Struberg 
> >> >Sent: Thursday, 10 October 2013, 8:33
> >> >Subject: Re: git commit: DELTASPIKE-424 taking into account
> >> EntityManagerResolver with a normal scope
> >> >
> >> >
> >> >
> >> >Both works Mark depending as you said from where you take your em. We
> >> just need to be explicit on this behavior. BTW I prefer the normal scope
> >> usage too.
> >> >
> >> >
> >> >Romain Manni-Bucau
> >> >Twitter: @rmannibucau
> >> >Blog: http://rmannibucau.wordpress.com/
> >> >LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> >Github: https://github.com/rmannibucau
> >> >
> >> >
> >> >
> >> >
> >> >2013/10/10 Mark Struberg 
> >> >
> >> >Not sure if we really need this flag.
> >> >>The most important question to me is _when_ do we trigger the
> destroy()
> >> method.
> >> >>
> >> >>The following code doesn't make much sense imo:
> >> >>
> >> >>> final DependentProvider resolver =
> >> lookupResolver(emrc);
> >> >>> result = resolver.get().resolveEntityManager();
> >> >>> resolver.destroy();
> >> >>
> >> >>
> >> >>The DependentProvider is intended to store it's instances somewhere to
> >> be able to properly destroy the created @Dependent instance once you
> don't
> >> need it anymore. Invoking destroy() immediately but returning the
> created
> >> contextual instance makes no sense imo. Imagine what happens if you
> would
> >> close the EntityManagerFactory in a @PreDestroy method.
> >> >>
> >> >>If there is no clean way to clean up the instance again, then we
> should
> >> only rely on NormalScoped instances and remove the handling (and get the
> >> warnings again, because they make sense).
> >> >>
> >> >>LieGrue,
> >> >>strub
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>- Original Message -
> >> >>> From: "rmannibu...@apache.org" 
> >> >>> To: comm...@deltaspike.apache.org
> >> >>> Cc:
> >> >>> Sent: Wednesday, 9 October 2013, 16:46
> >> >>> Subject: git commit: DELTASPIKE-424 taking into account
> >> EntityManagerResolver with a normal scope
> >> >>>
> >> >>> Updated Branches:
> >> >>>   refs/heads/master bdc9cdce6 -> e8148110e
> >> >>>
> >> >>>
> >> >>> DELTASPIKE-424 taking into account EntityManagerResolver with a
> normal
> >> scope
> >> >>>
> >> >>>
> >> >>> Project: http://git-wip-us.apache.org/repos/asf/d

Re: git commit: DELTASPIKE-424 taking into account EntityManagerResolver with a normal scope

[Gerhard Petracek]

@mark: +1

regards,
gerhard



2013/10/11 Mark Struberg 

>
> >If you don't destroy it you'll likely leak.
> Yes, fully agree. But the way we do it is still wrong. IF it is a
> @Dependent scoped instance, then we must store the
> DependentProvider somewhere and only invoke it's destroy()
> method once we really need.
>
> For NormalScoped beans you are relieved of this burden, but for @Dependent
> ones you need to handle it manually. The DependentProvider just helps to
> easily store the CreationalContext, the Bean and the instance for
> convenience reasons.
>
>
> LieGrue,
> strub
>
>
> >
> > From: Romain Manni-Bucau 
> >To: "dev@deltaspike.apache.org" ; Mark
> Struberg 
> >Sent: Thursday, 10 October 2013, 9:07
> >Subject: Re: git commit: DELTASPIKE-424 taking into account
> EntityManagerResolver with a normal scope
> >
> >
> >If you don't destroy it you'll likely leak.
> >
> >And once again you are in your case where you handle the emf yourself. In
> >other cases @Dependent should work fine.
> >
> >That said nothing again preventing using @Dependent so just do it If it
> >solves the issue. Normal scopes were the important part for me.
> >
> >*Romain Manni-Bucau*
> >*Twitter: @rmannibucau *
> >*Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> >*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >*Github: https://github.com/rmannibucau*
> >
> >
> >
> >
> >2013/10/10 Mark Struberg 
> >
> >>
> >> >Both works
> >>
> >> That's exactly where I disagree. While both 'work' in the sample,
> >> immediately destroying the instances again after creating them - and
> only
> >> later returning the java reference to the now 'dead'
> EntityManagerResolver
> >> - is broken if you will use it in productive scenarios.
> >>
> >>
> >> Either we fix this, or we don't need any special handling. In this case
> I
> >> suggest to just use DependentProvider.get() for all cases. It has no
> harm
> >> on NormalScoped instances anyway.
> >>
> >> I will guard DependentProvider#destroy to not have any impact on
> >> @Dependent scoped instances.
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> >
> >> > From: Romain Manni-Bucau 
> >> >To: "dev@deltaspike.apache.org" ; Mark
> >> Struberg 
> >> >Sent: Thursday, 10 October 2013, 8:33
> >> >Subject: Re: git commit: DELTASPIKE-424 taking into account
> >> EntityManagerResolver with a normal scope
> >> >
> >> >
> >> >
> >> >Both works Mark depending as you said from where you take your em. We
> >> just need to be explicit on this behavior. BTW I prefer the normal scope
> >> usage too.
> >> >
> >> >
> >> >Romain Manni-Bucau
> >> >Twitter: @rmannibucau
> >> >Blog: http://rmannibucau.wordpress.com/
> >> >LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> >Github: https://github.com/rmannibucau
> >> >
> >> >
> >> >
> >> >
> >> >2013/10/10 Mark Struberg 
> >> >
> >> >Not sure if we really need this flag.
> >> >>The most important question to me is _when_ do we trigger the
> destroy()
> >> method.
> >> >>
> >> >>The following code doesn't make much sense imo:
> >> >>
> >> >>> final DependentProvider resolver =
> >> lookupResolver(emrc);
> >> >>> result = resolver.get().resolveEntityManager();
> >> >>> resolver.destroy();
> >> >>
> >> >>
> >> >>The DependentProvider is intended to store it's instances somewhere to
> >> be able to properly destroy the created @Dependent instance once you
> don't
> >> need it anymore. Invoking destroy() immediately but returning the
> created
> >> contextual instance makes no sense imo. Imagine what happens if you
> would
> >> close the EntityManagerFactory in a @PreDestroy method.
> >> >>
> >> >>If there is no clean way to clean up the instance again, then we
> should
> >> only rely on NormalScoped instances and remove the handling (and get the
> >> warnings again, because they make sense).
> >> >>
> >> >>LieGrue,
> >> >>strub
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>- Original Message -
> >> >>> From: "rmannibu...@apache.org" 
> >> >>> To: comm...@deltaspike.apache.org
> >> >>> Cc:
> >> >>> Sent: Wednesday, 9 October 2013, 16:46
> >> >>> Subject: git commit: DELTASPIKE-424 taking into account
> >> EntityManagerResolver with a normal scope
> >> >>>
> >> >>> Updated Branches:
> >> >>>   refs/heads/master bdc9cdce6 -> e8148110e
> >> >>>
> >> >>>
> >> >>> DELTASPIKE-424 taking into account EntityManagerResolver with a
> normal
> >> scope
> >> >>>
> >> >>>
> >> >>> Project: http://git-wip-us.apache.org/repos/asf/deltaspike/repo
> >> >>> Commit:
> >> http://git-wip-us.apache.org/repos/asf/deltaspike/commit/e8148110
> >> >>> Tree:
> http://git-wip-us.apache.org/repos/asf/deltaspike/tree/e8148110
> >> >>> Diff:
> http://git-wip-us.apache.org/repos/asf/deltaspike/diff/e8148110
> >> >>>
> >> >>> Branch: refs/heads/master
> >> >>> Commit: e8148110ea2458fa2244a439583da0f2adddb482
> >> >>> Parents: bdc9cdc
> >> >>> Auth

Re: git commit: DELTASPIKE-424 taking into account EntityManagerResolver with a normal scope

[Mark Struberg]

>If you don't destroy it you'll likely leak.
Yes, fully agree. But the way we do it is still wrong. IF it is a @Dependent 
scoped instance, then we must store the DependentProvider 
somewhere and only invoke it's destroy() method once we really need.

For NormalScoped beans you are relieved of this burden, but for @Dependent ones 
you need to handle it manually. The DependentProvider just helps to easily 
store the CreationalContext, the Bean and the instance for convenience 
reasons.


LieGrue,
strub


>
> From: Romain Manni-Bucau 
>To: "dev@deltaspike.apache.org" ; Mark Struberg 
> 
>Sent: Thursday, 10 October 2013, 9:07
>Subject: Re: git commit: DELTASPIKE-424 taking into account 
>EntityManagerResolver with a normal scope
> 
>
>If you don't destroy it you'll likely leak.
>
>And once again you are in your case where you handle the emf yourself. In
>other cases @Dependent should work fine.
>
>That said nothing again preventing using @Dependent so just do it If it
>solves the issue. Normal scopes were the important part for me.
>
>*Romain Manni-Bucau*
>*Twitter: @rmannibucau *
>*Blog: **http://rmannibucau.wordpress.com/*
>*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>*Github: https://github.com/rmannibucau*
>
>
>
>
>2013/10/10 Mark Struberg 
>
>>
>> >Both works
>>
>> That's exactly where I disagree. While both 'work' in the sample,
>> immediately destroying the instances again after creating them - and only
>> later returning the java reference to the now 'dead' EntityManagerResolver
>> - is broken if you will use it in productive scenarios.
>>
>>
>> Either we fix this, or we don't need any special handling. In this case I
>> suggest to just use DependentProvider.get() for all cases. It has no harm
>> on NormalScoped instances anyway.
>>
>> I will guard DependentProvider#destroy to not have any impact on
>> @Dependent scoped instances.
>>
>>
>> LieGrue,
>> strub
>>
>>
>> >
>> > From: Romain Manni-Bucau 
>> >To: "dev@deltaspike.apache.org" ; Mark
>> Struberg 
>> >Sent: Thursday, 10 October 2013, 8:33
>> >Subject: Re: git commit: DELTASPIKE-424 taking into account
>> EntityManagerResolver with a normal scope
>> >
>> >
>> >
>> >Both works Mark depending as you said from where you take your em. We
>> just need to be explicit on this behavior. BTW I prefer the normal scope
>> usage too.
>> >
>> >
>> >Romain Manni-Bucau
>> >Twitter: @rmannibucau
>> >Blog: http://rmannibucau.wordpress.com/
>> >LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >Github: https://github.com/rmannibucau
>> >
>> >
>> >
>> >
>> >2013/10/10 Mark Struberg 
>> >
>> >Not sure if we really need this flag.
>> >>The most important question to me is _when_ do we trigger the destroy()
>> method.
>> >>
>> >>The following code doesn't make much sense imo:
>> >>
>> >>> final DependentProvider resolver =
>> lookupResolver(emrc);
>> >>> result = resolver.get().resolveEntityManager();
>> >>> resolver.destroy();
>> >>
>> >>
>> >>The DependentProvider is intended to store it's instances somewhere to
>> be able to properly destroy the created @Dependent instance once you don't
>> need it anymore. Invoking destroy() immediately but returning the created
>> contextual instance makes no sense imo. Imagine what happens if you would
>> close the EntityManagerFactory in a @PreDestroy method.
>> >>
>> >>If there is no clean way to clean up the instance again, then we should
>> only rely on NormalScoped instances and remove the handling (and get the
>> warnings again, because they make sense).
>> >>
>> >>LieGrue,
>> >>strub
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>- Original Message -
>> >>> From: "rmannibu...@apache.org" 
>> >>> To: comm...@deltaspike.apache.org
>> >>> Cc:
>> >>> Sent: Wednesday, 9 October 2013, 16:46
>> >>> Subject: git commit: DELTASPIKE-424 taking into account
>> EntityManagerResolver with a normal scope
>> >>>
>> >>> Updated Branches:
>> >>>   refs/heads/master bdc9cdce6 -> e8148110e
>> >>>
>> >>>
>> >>> DELTASPIKE-424 taking into account EntityManagerResolver with a normal
>> scope
>> >>>
>> >>>
>> >>> Project: http://git-wip-us.apache.org/repos/asf/deltaspike/repo
>> >>> Commit:
>> http://git-wip-us.apache.org/repos/asf/deltaspike/commit/e8148110
>> >>> Tree: http://git-wip-us.apache.org/repos/asf/deltaspike/tree/e8148110
>> >>> Diff: http://git-wip-us.apache.org/repos/asf/deltaspike/diff/e8148110
>> >>>
>> >>> Branch: refs/heads/master
>> >>> Commit: e8148110ea2458fa2244a439583da0f2adddb482
>> >>> Parents: bdc9cdc
>> >>> Author: Romain Manni-Bucau 
>> >>> Authored: Wed Oct 9 16:46:06 2013 +0200
>> >>> Committer: Romain Manni-Bucau 
>> >>> Committed: Wed Oct 9 16:46:06 2013 +0200
>> >>>
>> >>> --
>> >>> .../data/impl/RepositoryExtension.java          |  2 +-
>> >>> .../data/impl/handler/EntityManagerLookup.java  | 20 +

[jira] [Resolved] (DELTASPIKE-425) DependentProvider#destroy() must not destroy NormalScoped instances

[Mark Struberg (JIRA)]

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

Mark Struberg resolved DELTASPIKE-425.
--

Resolution: Fixed

> DependentProvider#destroy() must not destroy NormalScoped instances
> ---
>
> Key: DELTASPIKE-425
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-425
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 0.5
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 0.6
>
>
> Our DependentProvider is intended to hold information (the Bean, the 
> contextual instance and the CreationalContext) of @Dependent scoped 
> instances. This allows us to later invoke #destroy() which will properly 
> cleanup this instance (mainly calling @PreDestroy if available).
> For NormalScoped instances we must not perform any action in destroy as 
> NormalScoped beans always have their own lifecycle which we must not disrupt. 
> Which means the DependentProvider#destroy() method must detect whether the 
> provided instance is NormalScoped and skip any action in this case.



--
This message was sent by Atlassian JIRA
(v6.1#6144)