Re: Programmatic instance look up

[John D. Ament]

Its a single classloader.  Programmatic lookup is just

CDI.current().select(SomeClass.class).select(someAnnotationLiteral).get();

This fails, I would imagine, at least last time I did this on OWB, because
there's no injection point defined

@Inject
@SomeAnnotation
private SomeClass sc;

and the bean has scope dependent.

John

On Tue, Dec 27, 2016 at 6:29 PM Romain Manni-Bucau 
wrote:

> Hi John
>
> What does the lookup look like? Using the related bean manager un several
> apps with success.
>
> Side note: is your classloader well setup?
>
>
> Le 27 déc. 2016 23:29, "John D. Ament"  a écrit :
>
> > Hi,
> >
> > So I'm starting to run into my old friend, where instance doesn't work
> the
> > same in OWB and Weld.  Basically anytime I use CDI.current() to resolve a
> > bean, it fails.  The same lookup works when using
> BeanManager.getReference,
> > or even the DeltaSpike utilities.
> >
> > My understanding is that I should be able to look up any bean via
> > CDI.current() not just beans that have injection targets.  So I was
> > wondering, would it make sense to relax the requirement on injection
> > points?
> >
> > John
> >
>

Re: Programmatic instance look up

[Romain Manni-Bucau]

Hi John

What does the lookup look like? Using the related bean manager un several
apps with success.

Side note: is your classloader well setup?


Le 27 déc. 2016 23:29, "John D. Ament"  a écrit :

> Hi,
>
> So I'm starting to run into my old friend, where instance doesn't work the
> same in OWB and Weld.  Basically anytime I use CDI.current() to resolve a
> bean, it fails.  The same lookup works when using BeanManager.getReference,
> or even the DeltaSpike utilities.
>
> My understanding is that I should be able to look up any bean via
> CDI.current() not just beans that have injection targets.  So I was
> wondering, would it make sense to relax the requirement on injection
> points?
>
> John
>

Programmatic instance look up

[John D. Ament]

Hi,

So I'm starting to run into my old friend, where instance doesn't work the
same in OWB and Weld.  Basically anytime I use CDI.current() to resolve a
bean, it fails.  The same lookup works when using BeanManager.getReference,
or even the DeltaSpike utilities.

My understanding is that I should be able to look up any bean via
CDI.current() not just beans that have injection targets.  So I was
wondering, would it make sense to relax the requirement on injection points?

John

Re: Handling bootstrap for mixed SE/Servlet scenario

[Romain Manni-Bucau]

we do something equivalent in meecrowave since we start cdi before servlets
to support listener injections so we extend the listener and impl
contextInitialized
as a noop

think it is quite specific to vendors and if you think a bit more you just
need a start/stop abstraction which is already the ContainerLifecycle


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2016-12-27 16:52 GMT+01:00 John D. Ament :

> Ok, so in the end I did have to sublcass WebBeansConfigurationListener.
> The issue I ran into was that in contextInitialized you're attempting to
> start the application.  Since I do my servlet initialization in a @Observes
> @Initialized(ApplicationScoped.class) callback, OWB was firing the event
> that was already in progress.  This causes a stackoverflow.  My overridden
> version doesn't do the application start up logic.
>
> I don't know if it makes sense to roll this listener into OWB instead of
> keeping it outside.  It could be controlled via external configuration I
> suppose.  Everything else seems to work well.
>
> Let me know, I can provide a patch.
>
> John
>
> On Tue, Dec 27, 2016 at 12:27 AM John D. Ament 
> wrote:
>
> > Nevermind, I forgot about openwebbeans.properties.  Mix and match for the
> > win.
> >
> > John
> >
> >
> > On Mon, Dec 26, 2016 at 11:55 PM John D. Ament 
> > wrote:
> >
> > Hi,
> >
> > So let's say I'm using Tomcat embedded and OWB.  I bootstrap OWB using
> its
> > normal function, and I have impl, web and resource on my classpath.
> When I
> > ask for the ContainerLifecycle service, I get back a
> WebContainerLifecycle
> > since I have web on the classpath.  So I'm wondering, does it make sense
> to
> > create a fake servlet context in this scenario?  I believe if I do that,
> > OWB will treat these as two different contexts and as a result the
> > instances won't be shared.
> >
> > I'm almost thinking this would require a new plugin in OWB that did a lot
> > of the same work, however it allows the sharing of the context.
> Thoughts?
> >
> > John
> >
> >
>

Re: Handling bootstrap for mixed SE/Servlet scenario

[John D. Ament]

Ok, so in the end I did have to sublcass WebBeansConfigurationListener.
The issue I ran into was that in contextInitialized you're attempting to
start the application.  Since I do my servlet initialization in a @Observes
@Initialized(ApplicationScoped.class) callback, OWB was firing the event
that was already in progress.  This causes a stackoverflow.  My overridden
version doesn't do the application start up logic.

I don't know if it makes sense to roll this listener into OWB instead of
keeping it outside.  It could be controlled via external configuration I
suppose.  Everything else seems to work well.

Let me know, I can provide a patch.

John

On Tue, Dec 27, 2016 at 12:27 AM John D. Ament 
wrote:

> Nevermind, I forgot about openwebbeans.properties.  Mix and match for the
> win.
>
> John
>
>
> On Mon, Dec 26, 2016 at 11:55 PM John D. Ament 
> wrote:
>
> Hi,
>
> So let's say I'm using Tomcat embedded and OWB.  I bootstrap OWB using its
> normal function, and I have impl, web and resource on my classpath.  When I
> ask for the ContainerLifecycle service, I get back a WebContainerLifecycle
> since I have web on the classpath.  So I'm wondering, does it make sense to
> create a fake servlet context in this scenario?  I believe if I do that,
> OWB will treat these as two different contexts and as a result the
> instances won't be shared.
>
> I'm almost thinking this would require a new plugin in OWB that did a lot
> of the same work, however it allows the sharing of the context.  Thoughts?
>
> John
>
>