[JBoss JIRA] (CDI-114) Allow registration of beans at runtime
by Vincent Massol (JIRA)
[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ]
Vincent Massol commented on CDI-114:
------------------------------------
{quote}So you have multiple 'apps' already running as each of your Wiki-namespace is essentially an own 'app' from a CDI pov, right?{quote}
Not sure. Basically we have a Root Component Manager containing components seen by all namespaces (ie all wikis) and then each subwiki have their own Wiki Component Manager that contain components only seen by those subwikis (so in addition to the components located in the Root Component Manager).
{quote}Would it be possible to bootstrap a new namespace instance and then just swapping out the original one with the freshly booted one? Looks much cleaner to me.{quote}
So you're essentially saying the same thing as what was said earlier but with even most cost in term of performance, no? I.e recreate the classloaders (the root one and the wiki ones affected by the new component/bean being added) + reinitialize CDI (ie scanning and bean resolving), every time a new component is to be added at runtime.
I don't know the performance of such an option but as I mentioned, we do have thousands and thousands of components/beans loaded, with some have initialization steps. IMO that would really be overkill in term of performance. Also in XWiki it's not that unfrequent to add new components at runtime. For example users can creates new macros as script in wiki pages and underneath they get registered as proper components/beans.
Thanks
> Allow registration of beans at runtime
> --------------------------------------
>
> Key: CDI-114
> URL: https://issues.jboss.org/browse/CDI-114
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Vincent Massol
> Fix For: TBD
>
>
> I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (CDI-114) Allow registration of beans at runtime
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-114:
----------------------------------------
I do that in an app (except I have a single plugin but design is reusable for that case) starting N children CDI context inheriting from the parent one (which would be xwiki webapp). Child having access to the parent they can register services etc and still use CDI. Limitation is children are isolated but it can be a nice thing too for plugins. Would it be an option? CDI 2 with its se API should enable that since the managed instance (EE/Servlet) will start several SE contexts.
> Allow registration of beans at runtime
> --------------------------------------
>
> Key: CDI-114
> URL: https://issues.jboss.org/browse/CDI-114
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Vincent Massol
> Fix For: TBD
>
>
> I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (CDI-114) Allow registration of beans at runtime
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-114:
-----------------------------------
I see.
So you have multiple 'apps' already running as each of your Wiki-namespace is essentially an own 'app' from a CDI pov, right?
Would it be possible to bootstrap a new namespace instance and then just swapping out the original one with the freshly booted one? Looks much cleaner to me.
> Allow registration of beans at runtime
> --------------------------------------
>
> Key: CDI-114
> URL: https://issues.jboss.org/browse/CDI-114
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Vincent Massol
> Fix For: TBD
>
>
> I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
Re: [cdi-dev] Extensions and spec-related observer method injection points question
by Matej Novotny
----- Original Message -----
> From: "Mark Struberg" <struberg(a)yahoo.de>
> To: "Matej Novotny" <manovotn(a)redhat.com>
> Sent: Sunday, February 19, 2017 9:05:30 PM
> Subject: Re: [cdi-dev] Extensions and spec-related observer method injection points question
>
> >
> > While you cannot do this, you can still get hold of BeanManager and use it
> > to resolve your bean.
>
> No, you cannot. At least not before AfterBeanValidation.
Obviously, but the question assumes the container is in the state where beans are resolvable.
E.g., the question was meant more like "if I can resolve it with BM, why can't I use plain param. injection".
>
> LieGrue,
> strub
>
>
> > Am 17.02.2017 um 07:08 schrieb Matej Novotny <manovotn(a)redhat.com>:
> >
> > Hi, comment inline.
> >
> > ----- Original Message -----
> >> From: "Laird Nelson" <ljnelson(a)gmail.com>
> >> To: cdi-dev(a)lists.jboss.org
> >> Sent: Thursday, February 16, 2017 11:11:41 PM
> >> Subject: [cdi-dev] Extensions and spec-related observer method injection
> >> points question
> >>
> >> This section (
> >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ) says:
> >> "If
> >> other beans [other than the BeanManager ] are injected into an [portable]
> >> extension’s observer methods, non-portable behavior results."
> >>
> >> Rephrased: a portable extension's observer methods must have a minimum of
> >> one
> >> parameter (the event being observed) and a maximum of two parameters (that
> >> plus the BeanManager ), and none other if you want to stay truly portable.
> >
> > That's correct interpretation.
> >
> >> For true container lifecycle events, I understand this (you don't have
> >> beans
> >> to inject yet). But given that a bean must be provided by the container
> >> for
> >> a portable extension (
> >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ),
> >> wouldn't
> >> it be reasonable to permit extra injection points in a portable
> >> extension's
> >> non -container-lifecycle-event-observing observer methods?
> >>
> >> Concretely, I'd like to do this:
> >>
> >> // In my portable extension
> >> private static final void doSomethingAtStartup(@Observes
> >> @Initialized(ApplicationScoped.class) final Object event, final
> >> Frobnicator
> >> someBean) {
> >> someBean.doSomething();
> >> }
> >
> > While you cannot do this, you can still get hold of BeanManager and use it
> > to resolve your bean.
> >
> >>
> >> ...but that would seem to be in violation of the specification. Could
> >> someone
> >> kindly explain why?
> >
> > Not really sure, perhaps Martin or Antoine can share the details.
> > But I would say this could create quite some confusion if in some observer
> > you could inject certain beans and in others you couldn't.
> > Even in your sample, you can only inject AppScoped beans, so imagine you do
> > such observer for, say, SessionScoped, what can you inject there?
> > SessionScoped for sure, how about Req? Conversation?
> >
> >>
> >> Thanks,
> >> Best,
> >> Laird
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code
> >> under the Apache License, Version 2
> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> provided on this list, the provider waives all patent and other
> >> intellectual
> >> property rights inherent in such information.
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
>
>
7 years, 2 months
[JBoss JIRA] (CDI-114) Allow registration of beans at runtime
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-114:
-----------------------------------
[~atijms] That is totally up to the container. It's simply not defined, so you cannot be sure.
[~vmassol] I see. So you allow that your users upload some jar which you then dynamically add to you Classpath?
Or how does the XWiki container become aware of that new functionality?
Does XWiki use OSGi (which would be suited for such a dynamic reload)?
Or do you roll your own ClassLoader system?
> Allow registration of beans at runtime
> --------------------------------------
>
> Key: CDI-114
> URL: https://issues.jboss.org/browse/CDI-114
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Vincent Massol
> Fix For: TBD
>
>
> I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (CDI-114) Allow registration of beans at runtime
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ]
arjan tijms commented on CDI-114:
---------------------------------
This could also help with the longstanding limitation that web.xml content can not be used for registering beans, since at the time the CDI extension is executed the {{ServletContext}} (and with it, WEB-INF/*) is not yet available.
> Allow registration of beans at runtime
> --------------------------------------
>
> Key: CDI-114
> URL: https://issues.jboss.org/browse/CDI-114
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Vincent Massol
> Fix For: TBD
>
>
> I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (CDI-114) Allow registration of beans at runtime
by Vincent Massol (JIRA)
[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ]
Vincent Massol commented on CDI-114:
------------------------------------
Hi [~struberg]. My exact use case is the following: allowing users of XWiki the ability to install extensions at runtime and without restarting XWiki, and these extensions contain Beans (Components in XWiki terminology) that need to be instantiated/populated and injected in other beans/code requiring them. So this is indeed not for development time but at runtime, when using XWiki in production.
Thanks
> Allow registration of beans at runtime
> --------------------------------------
>
> Key: CDI-114
> URL: https://issues.jboss.org/browse/CDI-114
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Vincent Massol
> Fix For: TBD
>
>
> I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
Extensions and spec-related observer method injection points question
by Laird Nelson
This section (
http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events) says: "If
other beans [other than the BeanManager] are injected into an [portable]
extension’s observer methods, non-portable behavior results."
Rephrased: a portable extension's observer methods must have a minimum of
one parameter (the event being observed) and a maximum of two parameters
(that plus the BeanManager), and none other if you want to stay truly
portable.
For true container lifecycle events, I understand this (you don't have
beans to inject yet). But given that a bean must be provided by the
container for a portable extension (
http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events), wouldn't
it be reasonable to permit extra injection points in a portable extension's
*non*-container-lifecycle-event-observing observer methods?
Concretely, I'd like to do this:
// In my portable extension
private static final void doSomethingAtStartup(@Observes
@Initialized(ApplicationScoped.class) final Object event, final Frobnicator
someBean) {
someBean.doSomething();
}
...but that would seem to be in violation of the specification. Could
someone kindly explain why?
Thanks,
Best,
Laird
7 years, 2 months
Fwd: Extensions and spec-related observer method injection points question
by Mark Struberg
Sorry, should go to reply-all.
LieGrue,
strub
> Anfang der weitergeleiteten Nachricht:
>
> Von: Mark Struberg <struberg(a)yahoo.de>
> Betreff: Aw: [cdi-dev] Extensions and spec-related observer method injection points question
> Datum: 19. Februar 2017 um 21:05:30 MEZ
> An: Matej Novotny <manovotn(a)redhat.com>
>
>>
>> While you cannot do this, you can still get hold of BeanManager and use it to resolve your bean.
>
> No, you cannot. At least not before AfterBeanValidation.
>
> LieGrue,
> strub
>
>
>> Am 17.02.2017 um 07:08 schrieb Matej Novotny <manovotn(a)redhat.com>:
>>
>> Hi, comment inline.
>>
>> ----- Original Message -----
>>> From: "Laird Nelson" <ljnelson(a)gmail.com>
>>> To: cdi-dev(a)lists.jboss.org
>>> Sent: Thursday, February 16, 2017 11:11:41 PM
>>> Subject: [cdi-dev] Extensions and spec-related observer method injection points question
>>>
>>> This section (
>>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ) says: "If
>>> other beans [other than the BeanManager ] are injected into an [portable]
>>> extension’s observer methods, non-portable behavior results."
>>>
>>> Rephrased: a portable extension's observer methods must have a minimum of one
>>> parameter (the event being observed) and a maximum of two parameters (that
>>> plus the BeanManager ), and none other if you want to stay truly portable.
>>
>> That's correct interpretation.
>>
>>> For true container lifecycle events, I understand this (you don't have beans
>>> to inject yet). But given that a bean must be provided by the container for
>>> a portable extension (
>>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ), wouldn't
>>> it be reasonable to permit extra injection points in a portable extension's
>>> non -container-lifecycle-event-observing observer methods?
>>>
>>> Concretely, I'd like to do this:
>>>
>>> // In my portable extension
>>> private static final void doSomethingAtStartup(@Observes
>>> @Initialized(ApplicationScoped.class) final Object event, final Frobnicator
>>> someBean) {
>>> someBean.doSomething();
>>> }
>>
>> While you cannot do this, you can still get hold of BeanManager and use it to resolve your bean.
>>
>>>
>>> ...but that would seem to be in violation of the specification. Could someone
>>> kindly explain why?
>>
>> Not really sure, perhaps Martin or Antoine can share the details.
>> But I would say this could create quite some confusion if in some observer you could inject certain beans and in others you couldn't.
>> Even in your sample, you can only inject AppScoped beans, so imagine you do such observer for, say, SessionScoped, what can you inject there?
>> SessionScoped for sure, how about Req? Conversation?
>>
>>>
>>> Thanks,
>>> Best,
>>> Laird
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the code
>>> under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other intellectual
>>> property rights inherent in such information.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
7 years, 2 months