----- Original Message -----
From: "Julien Viet" <julien(a)julienviet.com>
To: "Ken Finnigan" <kfinniga(a)redhat.com>
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>
wrote:
>
>
> ----- Original Message -----
>> From: "Julien Viet" <julien(a)julienviet.com>
>> To: "Ken Finnigan" <kfinniga(a)redhat.com>
>> 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>
>> wrote:
>>
>>> Hi Julien,
>>>
>>> Thanks for responding so quickly.
>>>
>>> Comments inline.
>>>
>>> Ken
>>>
>>>
>>> ----- Original Message -----
>>>
>>>> From: "Julien Viet" <julien(a)julienviet.com>
>>>> To: "Ken Finnigan" <kfinniga(a)redhat.com>
>>>> 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 :-)
Initially it would be proprietary, but through discussions with Michael
Freedman and Neil Griffin, they would like these scopes to be part of
a new Portlet spec (maybe as part of 3.0). Therefore doing them in
a proprietary way is, hopefully, just a stop gap measure.
Also, we're planning to make these changes in the 3.x series, so if we
determine in the future that they don't warrant porting to 4.x, or there
is a better replacement as part of Portlet Spec 3 that will be part of
GateIn 4.x, then the scopes will not need to be ported over.
So my hope is that these changes, though proprietary, would be short lived
as such on the 3.x series, with a spec version being built into 4.x
>
> 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
>>>>
>>
>>