[gatein-dev] CDI Support in GateIn

Fri Mar 1 04:38:22 EST 2013

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