Behavior of @javax.enterprise.context.SessionScoped when using CDI-Bridge

[Michael Scholz, geändert vor 9 Jahren.]

Hey guys,

I have a question when using (the non-JSF) annotation @SessionScoped within Liferay Faces.

I expected this to bind to the PortletSession but some tests showed that the annotated bean is shared between different portlets.

So my questions are:

• What is the desired behavior?
• If it should be bound to the PortletSession - are there any ideas why it works differently for us (e.g. wrong config file setup)?

Thanks and best regards,

Michael

[Neil Griffin, geändert vor 9 Jahren.]

Hi Michael,

CDI was designed primarily with the Servlet-API in mind, not the Portlet-API. Because of that, the CDI implementation (Weld, OpenWebBeans, CanDI) interprets beans annotated with @javax.enterprise.context.SessionScoped to be stored as an HttpSession attribute, not a PortletSession attribute.

There is a mechanism in the CDI API that might permit us to "reinterpret" what SessionScoped means in a JSF portlet -- which would be the responsibility of the JSF Portlet Bridge. However, we haven't done any implementation work regarding this yet.

Kind Regards,

Neil

[Neil Griffin, geändert vor 9 Jahren.]

Hi Michael,

I forgot to mention that you might want to try the new @javax.faces.view.ViewScoped annotation provided by JSF 2.2. The lifespan of ViewScoped is shorter than SessionScoped, but often times that is a benefit, not a drawback. You can use Liferay Faces Bridge 4.2.0-m1 for testing.

Kind Regards,

Neil

[Michael Scholz, geändert vor 9 Jahren.]

Hi Neil,

thanks for your answers.

In fact I was thinking about the new JSF scopes (maybe also @FlowScoped would be a candidate for us).

But as we are using Liferay within JBoss EAP 6.1.1, we are currently stuck to JSF 2.1 (, but we keep an eye on any new releases of JBoss and Liferay Faces with 2.2 compatibility.


One additional question: shouldn't it be rather easy to add a CDI-Extension to the CDI-Bridge which offers an additional CDI Scope @PortletSessionScoped?
I'd rate this as great enhancement to the current implementation when thinking of combining CDI and Portlet 2.0.

Best regards,

Michael

[Michael Scholz, geändert vor 9 Jahren.]

I made a code proposal for the requested enhancement with "PortletSessionScope".

Checkout this GitHub pull request

[Neil Griffin, geändert vor 9 Jahren.]

Hi Michael,

Thanks so much for the contribution! I took the liberty of creating LPS-48810 in order to track this to closure. When you get a chance, please send a new pull request to ngriffin7a/liferay-plugins.

In the LPS ticket, provide a link to your GitHub pull request and respond to the Contributor License Agreement displayed by clicking the Contribute Solution button.

Thanks again,

Neil

[Michael Scholz, geändert vor 9 Jahren.]

Hi Neil,

I must admit that I need some assitance on this.

I don't have a JIRA account - as it seems.

Trying the credentials from the community login did not work

Can I simply create a new account? Do I have to use the same username or so? Or can I "derive" a JIRA account in some way from my community account.

Regards,

Michael

[Neil Griffin, geändert vor 9 Jahren.]

Hi Michael,

Please take a look at the How to Contribute instructions and let me know if that helps.

Thanks,

Neil

[Michael Scholz, geändert vor 9 Jahren.]

Hi Neil,

that did it

I just did not understand clearly if I should have created a completely new pull request or if I just should have attached the referenced one.


For the moment, I added the referenced one. If this was not okay, please let me know.

Best regards,

Michael

[Neil Griffin, geändert vor 9 Jahren.]

Hi Michael,

The pull request will likely be closed by an admin because it was sent to the liferay/liferay-plugins repository.

When you get a chance, please create a new pull request and send it to my ngriffin7a/liferay-plugins repository.

When you send the pull request, GitHub displays a UI similar to this that allows you to choose the destination repository.

Thanks again,

Neil

[Juan Gonzalez, geändert vor 9 Jahren.]

In addition, please add the LPS id. to the beginning of commit(s) message(s) so they can be tracked afterwards.

[Michael Scholz, geändert vor 9 Jahren.]

Hi @all,

I'll create a new pull request for this.

Can you please revert my "contribution" to the JIRA ticket that I have already done?

It look like a cannot do a second one.

Regards,

Michael

[Neil Griffin, geändert vor 9 Jahren.]

I just re-opened the issue so I think you should be able to click on the "Contribute Solution" button again.

Juan is right about mentioning the LPS number in the commit, but don't worry about it this time. I'll take care of it should the patch get officially merged.

[Michael Scholz, geändert vor 9 Jahren.]

Hi Neil,

I just finished my work. If forked from your repo and created a new pull request with according name and commit messages.

Please note that I had to re-implement my proposals from LPS-39592 as they were not (yet) applied to the CDIPortletFilter.

This might cause merging problems, but it was a necessary change.

Best regards,

Michael

[Neil Griffin, geändert vor 9 Jahren.]

Hi Michael,

Your initial work, forking liferay/liferay-plugins was correct. Once you have forked liferay/liferay-plugins you should then be able to send a pull request to ngriffin7a/liferay-plugins.

Would it be too much to ask you re-create your fork and to send another pull request? We realize that this has been very time consuming for you, and we are grateful for your contribution.

Thanks,

Neil

[Michael Scholz, geändert vor 9 Jahren.]

Hi Neil,

it is okay.

But I'll do it tomorrow, when I'm back in the Office.

Anyway - I found that implementing correct destroy behavior takes some more considerations, so it's maybe even better to start from a fresh branch ;)

Regards,

Michael

[Michael Scholz, geändert vor 9 Jahren.]

Hi Neil,

I created a new pull request.

Some things to mention:

• You need again to reset the JIRA issue (or update it with the new URL)
• I wasn't able to implement according cleanup/destroy behavior, because I did not find a way how to hook into PortletSession termination
• This might be something for the real experts ;). I provided a method com.liferay.cdi.portlet.bridge.CDIPortletSessionContext.destroyPortletSessionBeans() which can be called from a respective interception point.

Best regards,

Michael

[Neil Griffin, geändert vor 9 Jahren.]

Hi Michael,

I re-opened the LPS-48810 issue so you should be able to post the new pull request URL.

Regarding session termination, do you have time to develop a class that implements HttpSessionListener? For example, Liferay Faces Bridge has a class named BridgeSessionListener.java

Thanks,

Neil

[Michael Scholz, geändert vor 9 Jahren.]

Hi Neil,

I think I need more advice for the listener topic.

As the beans in case of @PortletSessionScoped are stored within the PortletSession I need to get this object upon invalidation, not the HttpSession object.

So can a HttpSession object help me out?

I can imagine that the PortletSession objects are somehow stored within the HttpSession in case of Liferay, but I don't know how to get them.

Additionally, the cdi-portlet-bridge-shared project seems to have no dependency on any Liferay specific implementation. Is there a standard way how to get the PortletSessions from the HttpSession?

I also had a look at the BridgeSessionListener, this did not help me.

Best regards,

Michael

[Neil Griffin, geändert vor 9 Jahren.]

Hi Michael,

You are right -- PortletSession is a layer of abstraction over HttpSession. I think that is probably true for most of the portlet containers that implement the Portlet API (not just Liferay Portal).

Line 210 of BridgeSessionListener.java looks like this:

// If the current session attribute name is namespaced with the standard portlet prefix, then it
// is an attribute that was set using PortletSession.setAttribute(String, Object).
if ((attributeName != null) && attributeName.startsWith("javax.portlet.p.")) {
    ...
}

This should be a way to determine if an attribute was a PortletSession attribute. It should be possible to iterate through each one and determine if it is a bean annotated with @PortletSessionScoped.

Kind Regards,

Neil

[Michael Scholz, geändert vor 9 Jahren.]

Hi Neil,

an HttpSessionListener did not help (the attributes were already cleaned up when the listener was called), but an HttpSessionAttributeListener did it.

I even do not need to check the attribute name, I instead just need to check the type of the attribute (which is a unique wrapper type around the real bean).

I updated the pull request accordingly.

From my side, everything is now finished.

Best regards,

Michael

[Neil Griffin, geändert vor 9 Jahren.]

Hi Michael,

Thanks again for your contribution! As you develop and test your portlets over the next few weeks, please let us know how well @PortletSessionScoped is working in your environment.

Kind Regards,

Neil

[Michael Scholz, geändert vor 9 Jahren.]

Hi Neil,

we already use the feature heavily within different portlets (all JSF-based btw.) and it does the job well.

We use it to store search parameters for different search forms (each within different portlets on different pages).

Search parameter management is contained in one central CDI bean which @Injects the parameter model via the new annotation.

This creates the following call chain: Portlet -> JSF View -> @RequestScoped CDI view bean -> @RequestScoped CDI helper bean -> @PortletSessionScoped search parameters bean.

Although resolvement goes over several beans, the search parameters are actually private to the originating Portlet, so parameters are not shared between Portlets and navigating around and coming back restores correctly the originally stored search parameters.

I'll not be at work in August so I won't be able to give additional feedback at this time.

Maybe I have some news in September, but I don't expect any problems.

I just have one single "theoretical" concern: the implementation currently caches the PortletRequest object within a ThreadLocal variable. This means it won't work correctly, if one PortletRequest is spread over several Threads, which hopefully can not occur.

Best regards,

Michael

[Neil Griffin, geändert vor 9 Jahren.]

Hi Michael,

The main developer of Liferay's portlet container did a quick review of the ThreadLocal issue, and he said it should be fine. However, he did say that PortletRequestContainer.unregisterPortletRequest() should call "currentPortletRequest.remove()"

Kind Regards,

Neil

[Michael Scholz, geändert vor 9 Jahren.]

Hi Neil,

thanks for the feedback.

I followed the recommendation of your developer and updated the pull request accordingly,

Kind regards,

Michael

[Chicon Samu, geändert vor 9 Jahren.]

Hi, I am interested in your solution. Is there a dependency available? How is the dependency called?

[Michael Scholz, geändert vor 9 Jahren.]

Hi Samu,

the solution will hopefully be included within the following dependency:

<dependency>
<groupId>com.liferay.cdi</groupId>
<artifactId>cdi-portlet-bridge-shared</artifactId>
<version>TO COME</version>
</dependency>

I got no answer from Liferay guys yet, when this will be done.

The current version 6.2.0.2 does not yet contain it.

Regards,

Michael

[Neil Griffin, geändert vor 9 Jahren.]

An updated version of cdi-portlet-bridge-shared.jar has not yet been scheduled. I wanted to mention however that @PortletSessionScoped is under consideration by JSR 362. For more information, see the Portlet 3.0 Meeting Minutes from 30 September 2014.

[Alfonso Mateos, geändert vor 8 Jahren.]

Hi Neil, I see that the issue is still open, is there any expectation to face it in a near future?
https://issues.apache.org/jira/browse/PORTLETBRIDGE-197

As a workaroud, do you think this link can do it in the meanwhile?
https://github.com/camunda/camunda-consulting/blob/master/snippets/liferay/camunda-bpm-liferay-process-application/src/main/java/org/camunda/demo/liferay/tasklist/outtake/CdiEnabledBridgeEventHandler.java

I also add the related classes:
https://github.com/camunda/fox-engine/blob/master/modules/activiti-cdi/src/main/java/org/activiti/cdi/impl/util/BeanManagerLookup.java
https://github.com/camunda/camunda-consulting/blob/master/snippets/liferay/camunda-bpm-liferay-process-application/src/main/java/org/camunda/demo/liferay/tasklist/outtake/ProcessApplicationTaskSelectedEventHandler.java

[Neil Griffin, geändert vor 8 Jahren.]

Hi Alfonso,

Thanks so much for asking about PORTLETBRIDGE-197 -- We are working to introduce more integration with CDI 1.1 (Java EE 7) into the Portlet 3.0 Spec. Additional integration with CDI for the JSF Portlet Bridge will probably be based on Portlet 3.0. But since Portlet 3.0 is not yet finished, these are features that would be coming in the the future.

For today, our current integration with JSF and CDI Portlets is described in the wiki article titled Developing JSF Portlets with CDI. If you want to self-inject a CDI bean, I recommend that you use CDIBeanManagerUtil from our CDI Portlet Bridge.

Kind Regards,

Neil

[Kyle Joseph Stiemann, geändert vor 9 Jahren.]

Moved from Home » Liferay Faces to Home » Liferay Faces » Liferay Faces - English subcategory.

- Kyle