I got the impression from reading articles on jsr286 eventing that the eventing feature enables portlets to communicate with one another if they belong to different .war files.
I just want to confirm that even if 2 portlets belong to same war file, the only way they can communicate is through eventing.
Since the whole request forwarding feature of servlets do not apply to portlets. Is this correct?
Portlets events can be used between portlets in the same wars or in different wars. However, one of the limitations of the portlets events is that the 2 portlets must be on the same page.
There are others ways to communicate between 2 portlets. You can use Public Render Parameters. The idea is that the first portlet sets a parameter, and the second portlet can read it in order to retrieve the value.
You can also use the Application scope of the PortletSession to communicate and share data. The application scope (APPLICATION_SCOPE) of a PortletSession is shared between all the portlets of the same war.
Related
I have a monolithic Spring boot application that exposes a REST API /getUserList.
Now we are taking the micro service approach, so that we extracted some business code and create /getCountry microservice REST API.
Normally, /getUserList should call /getCountry to get all countries.
Now for testing purpose, I want to use these two REST API in the same server, but separately. What I can think of is to create two seperate JAR and let one call another. I want to know what is the right way to do this :
Should I list /getCountry as a module of /getUserList? Or should I create a separate project ?
You decided to break your monolith into microservices. You started on the right foot, separating the application logic based on the bounded contexts you defined. In this case you describe "countries" context and the "user" context.
Microservices are independently deployable, so you are correct, they have to be separate jars. Your "user" service will call the "countries" service via the network as usual in microservices architecture.
Usually, each microservice has their own repo (project), so that developers who have to work on the service, do not need to familiarize with a large codebase, or figure out why code not related to their service (bounded context) is there.
That being said, if currently your project is quite small you can decide to keep these as separate modules (do not import countries module in the user module) under the same project and break them later.
When UI is supplied by Angular web application, the responsibility of the other micro service applications gets limited to supplying JSONS. But they still need to support ReST paths and cannot be a monolithic giant. Meaning, can't just make those as JARs and bind it as dependency to some WAR app. Is there a better way to do this than keeping the WAR applications that are just going to supply JSONs as UI less WARs for the sake of making sure that they are not mixed up?
I am working on a web application which uses RAP. In the application there is one bundle which contains the model which is backed by a database. I would like to create bundles which provide REST services which will make use of the model bundle.
I looked at the Application#addEntryPoint but that it just for UI contributions - not for services as such.
I also read FrankAppel's post http://www.codeaffine.com/2011/08/26/raprwt-osgi-integration/ and wonder if RWT and Felix might be the way to go. It looks promising but Felix is new to me.
Is it possible to add these REST bundles to the RAP application and set them up to handle /rest/* URLs? Or would it be more sensible to keep the 2 parts completely separate and to share the model bundle in a different way?
When using RAP, any active bundle may contribute to the usual "org.eclipse.equinox.http.registry.servlets" and "org.eclipse.equinox.http.registry.resources" extension points. You just need to make sure the name of your RAP application's entry point(s) and the paths of your ressources and servlets won't overlap.
So in practice, you can just develop your REST services as if there was no RAP component. The two will happily live side-by-side within the same servlet context.
does anyone know how to share session variables and recover from any portlet in websphere portal, for example I set a session variable (Object) in one portlet and i want to get the value of that variable. How can i do this?.
I'm using Websphere portal 8, and my IDE is RAD 8.5
Regards
If your portlets are deployed in the same webapp, you can use the PortletSession with the scope APPLICATION : portletRequest.getSession().setAttribute("name", "value", PortletSession.APPLICATION_SCOPE).
Otherwise, you need to create your own sharing service that will store variables. It seems that this article could help you : http://www.ibm.com/developerworks/websphere/library/techarticles/0602_hepper/0602_hepper.html
If you want to share objects / state across portlets that are not in the same web module (war file) and you are in WebSphere Portal, you can use a WebSphere Application Server proprietary service called DynaCache. It is mature and commonly used. You can set up a Map object that is shared not only across portlets (really any application code in the same JVM), but can also be set up to share objects across JVMs (like in a cluster). Key programming interface: DistributedMap. Here's a pretty good blog post on setting up a cache instance so your portlets can each look the map up via JNDI and either get or put to it just like any other Map<K,V>.
Why the url mapping for a portlet is not specified in portlet.xml? Unlike 'servlet-mapping' in web.xml?
What is the necessity of doing it through the portal console?
The principle behind portlets is that they can be dropped onto portal pages according to the wishes of the portal site designer, or sometimes according to the wishes of the portal user themselves. If a portlet was accessed via a mapping in the portlet.xml file, then you would have to redeploy the portlet application each time you wanted a new mapping. Using a portal console allows you to place the portlet on any one of the portal pages that you create.
Using a portlet-mapping and navigating to it would also suggest that you would only be able to see that single portlet. Some portlets cooperate on a page, and so these wouldn't function properly without being deployed together on a portal page.
If a portlet was accessed directly, then what would the look and feel of the response be? Portals are generally used with themes which control the overall look and feel of the site and allow the portlets in a site to look consistent with each other. Themes often provide you with a standard header and footer etc. A combination of the Portal and the theme often provide you with page navigation too, built up from the pages that are stored within the Portal.
Also, if portlets are allowed to be invoked directly, then you could be able to bypass the Portal Container's security mechanism.
As an 'and finally', some Portlet Containers actually do let you address a portlet directly for certain specific use cases. And some Portlet Containers internally convert the deployed portlets into servlets - and these do have a servlet-mapping that can be accessed directly (although they might break as they may have expectations that the portlet container has put certain attributes in the servlet request).
So it's not a black-and-white answer. Generally speaking, if you're developing a portlet then you're doing so because you do want your portlet to be invoked from a Portal page and you do want all of the value-added stuff that comes from running within a Portal.
If you don't want these things, then maybe the question is should my application be built using portlets?