[gatein-dev] CDI Support in GateIn
Ken Finnigan
kfinniga at redhat.com
Tue Mar 5 15:45:48 EST 2013
I was going through and updating the specification on GateIn for how we would perform injection into the portlet class,
when I realized that, unless I'm mistaken, you're proposed solution doesn't allow me to access the Portlet class instance
to then be able to perform injection on.
>From the PortletContainerLifeCycle ManagedObject, there is no way to retrieve the actual portlet class instance. I think
we do need a new event to be able to cater to this.
Ken
----- Original Message -----
> From: "Julien Viet" <julien at julienviet.com>
> To: "Ken Finnigan" <kfinniga at redhat.com>
> Cc: gatein-dev at lists.jboss.org
> Sent: Friday, March 1, 2013 4:38:22 AM
> Subject: Re: [gatein-dev] CDI Support in GateIn
>
>
> On Feb 28, 2013, at 3:25 PM, Ken Finnigan <kfinniga at redhat.com>
> wrote:
>
> >
> >
> > ----- Original Message -----
> >> From: "Julien Viet" <julien at julienviet.com>
> >> To: "Ken Finnigan" <kfinniga at redhat.com>
> >> Cc: gatein-dev at lists.jboss.org
> >> Sent: Thursday, February 28, 2013 2:46:13 AM
> >> Subject: Re: [gatein-dev] CDI Support in GateIn
> >>
> >>
> >> On Feb 26, 2013, at 7:08 PM, Ken Finnigan <kfinniga at redhat.com>
> >> wrote:
> >>
> >>> Hi Julien,
> >>>
> >>> Thanks for responding so quickly.
> >>>
> >>> Comments inline.
> >>>
> >>> Ken
> >>>
> >>>
> >>> ----- Original Message -----
> >>>
> >>>> From: "Julien Viet" <julien at julienviet.com>
> >>>> To: "Ken Finnigan" <kfinniga at redhat.com>
> >>>> Cc: gatein-dev at lists.jboss.org
> >>>> Sent: Tuesday, February 26, 2013 5:34:44 AM
> >>>> Subject: Re: [gatein-dev] CDI Support in GateIn
> >>>
> >>>> 1/ @PortletLifecycleScoped and @PortletRedisplayScoped :
> >>>
> >>>> It seems similar with the
> >>>> javax.portlet.actionScopedRequestAttributes
> >>>> container runtime options, i.e a portlet using @SessionScoped
> >>>> and
> >>>> enabling the scoped request attributes would provide a similar
> >>>> behavior.
> >>>
> >>>> Why should add a non spec compliant feature to do something
> >>>> similar ?
> >>>
> >>> I may be mistaken, but from looking at the code of gatein-pc, if
> >>> I
> >>> was to
> >>> set javax.portlet.actionScopedRequestAttributes to true in
> >>> portlet.xml then
> >>> any CDI beans that I intended to work as @SessionScoped would no
> >>> longer behave
> >>> that way, as they would be removed at the start of a new
> >>> ActionRequest.
> >>
> >> I was actually asking you if you did not miss that section in
> >> portlet
> >> spec because I found it similar. My opinion is that it looked
> >> similar and I was finding confusing to implement it if the
> >> existing
> >> feature could have been reused.
> >>
> >
> > I wasn't aware of this feature prior to proposing the idea of 2 new
> > CDI
> > Scope for portlet dev, but I think doing what you suggest forces a
> > developer
> > to know whats happening with the combination of @SessionScoped and
> > javax.portlet.actionScopedRequestAttributes set to true. Whereas
> > providing
> > new scopes means that @SessionScoped still works as designed in
> > CDI, and we
> > have new scopes to cater for portlet specific scenarios.
>
> On the other hand actionScopedRequestAttributes is a spec feature and
> the new session scoped feature would be a proprietary way to do
> something similar (unless I am wrong) that would exist only for
> GateIn portal. At some point it will become somehow @Deprecated with
> Portlet 3.0 spec which means we are creating future legacy that will
> need support.
>
> I'm just playing devil's advocate and replace it in context, at the
> end the call is obviously yours :-)
>
> >
> > I've realized after this email exchange that I probably wasn't
> > clear in
> > the spec that these new scopes would not be part of gatein-pc. The
> > scope
> > annotation would be in gatein-api and the implementation within
> > gatein-portal.
> >
>
> Yes I fully get that.
>
> >
> >>>
> >>>> 2/ managed object eventing :
> >>>
> >>>> In the proposal the event is sent by the portlet container impl
> >>>> between the portlet instance creation and the initialization of
> >>>> the
> >>>> portlet.
> >>>
> >>>> Such event should instead be managed by the context around the
> >>>> portlet container impl (i.e the LifeCycle object).
> >>>
> >>>> This is due to the fact that there is only one step in the
> >>>> current
> >>>> life cycle.
> >>>
> >>>> To better solve this problem, we need to break down the life
> >>>> cycle
> >>>> into two phases : create/start and stop/destroy with a new event
> >>>> sent.
> >>>
> >>>
> >>> So you are suggesting modifying PortletContainerObject to have a
> >>> create() in
> >>> addition to start()?
> >>
> >> yes that is the correct way to do it. In addition it should work
> >> also
> >> for portlet filters and enable injection in those as well.
> >>
> >>>
> >>> And then PortletContainerLifeCycle.invokeStart() is modified to
> >>> call
> >>> portletContainer.create() and then portletContainer.start()? With
> >>> a
> >>> call
> >>> to fire an event in between?
> >>
> >> indeed, the call would be made by the layer managing the life
> >> cycle
> >> and not the portlet container itself which is "managed"
> >>
> >>>
> >>> That can work, I didn't think of that as I was seeing if
> >>> ManagedObject needed
> >>> to have managedStart() split, but I couldn't see how that would
> >>> work.
> >>>
> >>> Would the event I created as part of the spec be sufficient?
> >>
> >> I think the event would not be needed anymore and the existing
> >> event
> >> ManagedObjectLifeCycleEvent would be enough. The listener would
> >> have
> >> to test the ManagedObjectLifeCycleEvent#status field and perform
> >> injection when status == LifeCycleStatus.CREATED
> >>
> >
> > Ok, so you're proposing we create LifeCycleStatus.CREATED? My only
> > concern
> > with doing something like that originally was whether there would
> > be lots
> > of unintended side effects. Such as PortletApplicationDeployer that
> > has code
> > such as:
> >
> > if (status == LifeCycleStatus.STARTED)
> > {
> > containerPortletInvoker.addPortletContainer(portletContainer);
> > }
> > else
> > {
> > containerPortletInvoker.removePortletContainer(portletContainer);
> > }
> >
> > which works fine when there are the 3 states on LifeCycleStatus as
> > now, but if
> > we added CREATED then this would no longer work as expected.
> >
> > This may be the only place where this would need to be updated, but
> > wasn't
> > sure how prevalent such code may be either inside or outside
> > gatein-pc?
>
> There is not code using that outside gatein-pc. If there is it would
> be adapted.
>
>
> >
> >
> >>>
> >>>> This way the CDI listener can properly operate on the portlet
> >>>> instance between the created and the started phase.
> >>>
> >>>> On Feb 22, 2013, at 10:23 PM, Ken Finnigan < kfinniga at redhat.com
> >>>> >
> >>>> wrote:
> >>>
> >>>>> All,
> >>>>
> >>>
> >>>>> I've put together a specification on adding support for CDI in
> >>>>> non
> >>>>> JSF portlets in GateIn, and for adding some new CDI scopes
> >>>>> catered
> >>>>> to portlet lifecyles ->
> >>>>> https://community.jboss.org/wiki/CDISupportInGateInPC
> >>>>
> >>>
> >>>>> Feedback and comments welcome.
> >>>>
> >>>
> >>>>> Regards
> >>>>
> >>>>> Ken
> >>>>
> >>>
> >>>>> ========================
> >>>>
> >>>>> Senior Software Engineer / JBoss Enterprise Middleware Red Hat,
> >>>>> Inc.
> >>>>
> >>>
> >>>>> _______________________________________________
> >>>>
> >>>>> gatein-dev mailing list
> >>>>
> >>>>> gatein-dev at lists.jboss.org
> >>>>
> >>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
> >>>>
> >>
> >>
>
>
More information about the gatein-dev
mailing list