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>.
Related
In a "computer system" there are two web servers that manage independent applications, both using JSP technology. There is a necessity to have access from server A to information stored in server B. In case of interconnection with:
Invocation of a data access service with GET/POST of an URL.
Definition and use of Web services.
Direct integration in Java, with Java RMI.
Which would be the best solution? Why? What are the advantages and disadvantages of each of them?
A solution would be to use REST API on the server from where you need to invoke the information. You might want to use an ajax call or just include contact via iframe.
Get call will be simple and quick to develop and maintain however if it is low latency and high throughput application then you might want to go with Java RMI.
Everytime I build my Service Fabric solution in Visual Studio, the ApplicationManifest and ServiceManifest are modified and Default Services entries are added for all Reliable Actors in my solution.
How can I prevent that?
Note: Default Services are not created for the Reliable Services which is what I am expecting.
Ultimately, our goal is to create an "empty" Named Application instance every time a new tenant/customer signs up through our Web Portal (one instance of the application type per tenant).
Then the tenant can enable/disable features through our Web Portal which translates to creating/removing an instance of an Actor/Service types inside the tenant's application instance.
Thanks for providing guidance if this is not the right way to implement isolation in multi-tenancy scenario in Service Fabric.
Thanks Kiryl... I finally found an article that explains the way to disable the generation of in the application manifest while building the Service Fabric application in Visual Studio.
Open the .csproj of the Actor project and modify the following property to "false"
<UpdateServiceFabricManifestEnabled>false</UpdateServiceFabricManifestEnabled>
You can find the article here: https://github.com/Azure/service-fabric-issues/issues/271
Cheers!
I'd say you can't... There was a time I was trying to set my own settings for partitioning scheme(switch the default one to Named partitioning or change low/high key for UniformInt64) but VS was overriding them no matter what I did. Turned out it was an expected behavior as I 'misunderstood' how partitioning is applied with actors, so VS gladly was 'fixing' my mistakes. See Can't change partitioning scheme for actors for the reference. The bottom line is, seems like VS adjusts Actors Service manifest to preserve the holy purpose of actors as a pattern.
As for multi-tenant application, consider deploying a separate app type with its own settings per each customer/tenant.
P.S. I was able to get what I want by deploying Actors Service manually rather than via VS, but that's another story.
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.
I am trying to identify the correct set of technologies to develop an application that supports the following.
Provide web service capabilities (preferably REST)
Be able to handle updates to multiple data resources in a single transaction
Have some of form persistence capability.
Based on these basic requirements, my current plan is to build a REST based service using JAX-RS and JPA to handle persistence and use EJB to be able to handle multiple updates to different resources in a single transaction.
Are these the correct set of technologies or am I making my application bulkier.
Thanks for any suggestions. Finally, the application will be deployed on Websphere Application Server v8.5
Yes, those sound like reasonable technology choices for your project. There are all part of Java EE, which provides a ton of other nice features, too, so it provides some room for your application to "grow" without having to worry about being bogged down with huge numbers of libraries from different vendors. In my opinion, using Java EE is not alone a cause for worry about "bulkiness".
Since the application is going to be deployed onto WebSphere Application Server V8.5 there's no need to constrain yourself with available technologies if they are already a part of the runtime environment.
Having said that I however thought about the developers who will develop the application and may suffer from the time it takes to do frequent restarts, redeployments and such. It's not to say WAS 8.5 can't handle them, but since it's a full-blown application server meant for production environment, it might be too much for your development environment. If so, read on.
There's a lighter profile of WAS available - WebSphere Application Server 8.5 Liberty Profile. It's based on WebSphere AS's codebase, has a small footprint, and is precisely for customers who know the deployment platform is WAS, but they need a lighter solution on their development laptops.
It might be very well-tailored for your needs and if Eclipse is the IDE you may be pleasantly surprised how much slimmer the development environment became with Liberty Profile.
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?