8:25 a.m.
----- 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.
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
>>