[gatein-dev] CDI Support in GateIn
Ken Finnigan
kfinniga at redhat.com
Wed Mar 6 11:38:01 EST 2013
Ok, so we'd also need to add getPortlet() onto PortletContainerObject,
as at present its only on PortletContainerImpl.
----- Original Message -----
> From: "Julien Viet" <julien at julienviet.com>
> To: "Ken Finnigan" <kfinniga at redhat.com>
> Cc: gatein-dev at lists.jboss.org
> Sent: Wednesday, March 6, 2013 3:07:44 AM
> Subject: Re: [gatein-dev] CDI Support in GateIn
>
> we should expose this via the life cyclle event :
>
> the event has the related managed object -> the
> ManagedPortletContainer interface.
>
> On this interface we add a getPortletInstance() method that returns
> the current instance.
>
>
> On Mar 5, 2013, at 9:45 PM, Ken Finnigan <kfinniga at redhat.com> wrote:
>
> > 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