[gatein-dev] CDI Support in GateIn
Julien Viet
julien at julienviet.com
Wed Mar 6 03:07:44 EST 2013
we should expose this via the life cyclle event :
the event has the related managed object -> the ManagedPortletContainer interface.
On this interface we add a getPortletInstance() method that returns the current instance.
On Mar 5, 2013, at 9:45 PM, Ken Finnigan <kfinniga at redhat.com> wrote:
> 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 at julienviet.com>
>> To: "Ken Finnigan" <kfinniga at redhat.com>
>> Cc: gatein-dev at 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 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
>>>>>>
>>>>
>>>>
>>
>>
More information about the gatein-dev
mailing list