Re: [gatein-dev] CDI Support in GateIn

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

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.

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

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