Re: [gatein-dev] CDI Support in GateIn

From: "Julien Viet" <julien(a)julienviet.com&gt; To: "Ken Finnigan" <kfinniga(a)redhat.com&gt; Cc: gatein-dev(a)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(a)redhat.com&gt; 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(a)julienviet.com&gt; >> To: "Ken Finnigan" <kfinniga(a)redhat.com&gt; >> Cc: gatein-dev(a)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(a)redhat.com&gt; >> wrote: >> >>> >>> >>> ----- Original Message ----- >>>> From: "Julien Viet" <julien(a)julienviet.com&gt; >>>> To: "Ken Finnigan" <kfinniga(a)redhat.com&gt; >>>> Cc: gatein-dev(a)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(a)redhat.com&gt; >>>> wrote: >>>> >>>>> Hi Julien, >>>>> >>>>> Thanks for responding so quickly. >>>>> >>>>> Comments inline. >>>>> >>>>> Ken >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> >>>>>> From: "Julien Viet" <julien(a)julienviet.com&gt; >>>>>> To: "Ken Finnigan" <kfinniga(a)redhat.com&gt; >>>>>> Cc: gatein-dev(a)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(a)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(a)lists.jboss.org >>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>> >>>> >>>> >> >>