Re: [gatein-dev] CDI Support in GateIn

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 >>>>> >>> >>> > >