I have an application currently running based on servlets (app server glassfish). External applications make an HTTP call to that servlet and get response once successfully achieved what its designed for.
I need now to shift the whole application to JSF2.0 as it needs a front end and sticking to servlet/jsp is not an option.
My questions are:
What's the recommended way to achieve the scenario of external applications getting things done through http calls in my JSF2.0 web app (that is currently I am achieving with servlets)
I need to maintain some counters in Application scope; Would you advise me to keep using servlets in my jsf app too and are the application scoped beans callable in servlets?
The way how you described the old application sounds much like a web service.
JSF is a component based MVC framework, not a web service framework. So JSF is basically the wrong tool for the job. If you want to continue with the standard Java EE stack, look at JAX-WS (SOAP) or JAX-RS (RESTful) instead. The latter is "the" standard web service framework these days.
See also:
Servlet vs RESTful
What's the recommended way to achieve the scenario of external applications getting things done through http calls in my JSF2.0 web app (that is currently I am achieving with servlets)
Like BalusC said, JSF is not exactly what you need and is not designed for what you intend to use it for, webservices are. That being said, you could achieve your goals using JSF if developing an effective web service is not in the cards for you ,either because of a lack of technical expertise on your team or the time factor or other technical constraints require you to serve your customers via a webapp (I honestly can't think of any but hey, you never know)
That being said, I'm assuming you already know your way around JSF2: take a look at this answer to a question somewhat similar to yours. Ultimately, since you're in the Java EE 5-6 stack, I'd strongly suggest you begin work on developing webservices (for basic requirements,they're fairly straightforward to develop). You can download a tutorial here or use oracle's tutorial
I need to maintain some counters in Application scope; Would you advise me to keep using servlets in my jsf app too and are the application scoped beans callable in servlets?
Unless you give us your specific use case, there are very few and far between reasons maintain a servlet within a JSF app. Yes, application,session and request scoped beans are accessible from within a servlet. They're simply stored as objects within the scopes they're named for, application scoped beans within the applicationScope, session scoped beans within the session and request scoped beans within the request.
You may use your JSF webapp to serve low level http requests, but it's a square peg in a round hole chief.
Related
I would like to modernize my Struts 1.x application. There are quite a number of articles which advocate migration of codes, instead of rewriting the entire system.
I would like to seek the advice of someone who has successfully modernize legacy applications.
My current system is using struts 1.x and JDBC prepared statements as the data access layer.
I am looking forward to improve the legacy application with the following objectives:
Web Pages should be coded with Responsive Web Design in mind.
Replace struts 1.x with Spring MVC
I am looking to breaking up the modernization into the following phases:
Phase 1 - Change all jsp pages to HTML 5 and CSS 3
Phase 2 - Change all DAO classes to Spring JDBC Template or Spring JPA
and transactions managed by Spring
Phase 3 - Ultimately, replace Struts 1.x Action Forms, Actions with Spring MVC
Before I start the changes, I would like to find out if it is possible for:
Struts 1.x with HTML 5 and CSS 3? I am looking at replacing all struts 1.x html taglibs with HTML 5 and JSTL/EL.
Running Struts 1.x with Spring 3/4? Is it possible to run non-spring managed pojo with Spring beans?
What should I take note of and how/what are the best practices to handle this modernization process? The code base is about 500k of HTML/JSP codes and 3 million Java codes.
It's been a while since I last worked with Struts 1.x, but I see no problem replacing at least most of the Struts tags with JSTL/EL. You should be able to paint HTML5 with Struts 1.x JSPs. I remember working using little or no Struts tags, only JSTL/EL, but this was before HTML5.
You can invoke Spring Context from any Struts ActionForm or, essentially any class within your webapp. You'll probably have to do it manually though and not with annotations, something like this:
WebApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(getServletContext());
With all this said, I can see you're intending to do a serious update of your app, therefore I must ask, are you positive about keeping Struts 1.x? If you want to ditch Struts tags, use Spring 3/4 and HTML 5, why not dispense with Struts entirely and migrate your app to Spring MVC? It's very easy to use, powerful and, needless to say, it integrates perfectly with the Spring components implementing your business logic, persistence, etc.
Cheers.
(Not an answer, informational.)
There's no reason you can't have an S1 app running alongside Spring MVC. It's a reasonable way to migrate piece-by-piece instead of a longer project that does a complete replacement.
Older Spring has direct support for Struts 1. Depending on your timeframe I might consider using the older Spring until you're further along.
Replacing S1 tags with pure HTML/CSS will be a pain because the S1 tags render other stuff besides just the input fields (e.g., labels, error messages, etc.) It's totally doable, especially if you write your own custom tags.
jQuery v. (AngularJS | React | similar) Switching to a full-on client-side app is a big lift, especially if your back-end isn't already designed that way. I wouldn't do that, but you could get a start on it by putting business logic in its own place and using that from the web layer. Then...
... you start to consume API calls on the client side using jQ or other client-side framework injected into the existing pages. Only then would I start considering going full SPA.
The bottom line is you have a fairly large app. Rather than converting the entire thing I would consider removing functionality from the mainline app and break it up into sub-applications, each of which could use whatever tech stack seems reasonable.
I've done a lot of project like this as a consultant: it's a lot of busywork that requires a wide range of knowledge and skills, and it's difficult to get right.
I am newbie in webservices of .net, i am implementing a project of .net with backend in webservices as i got impressed with the benefits and portability of this architecture.
But the confusion is, i want to know the way i am adopting is right or wrong. I have made services with in my project and calling them from code behind classes, where as my service is implementing the database code. I am attaching the screenshot for further explanation.
Not really, when you do this you are calling the classes directly rather than as a service call. This is liable to cause you issues (e.g. if you set up one of your methods to return a certain HTTP response status for example).
If you don't want this to be a service call, then you would be better extracting the logic from the service method into a business layer and have both the service and your page call that code.
If you do want a service call, then you need to add a service ref to your project that points to the service and call it through the generated proxy.
Your approach makes no difference of using a C# class vs using a webservice.For this approach You can use a class instead of a webservice.
Use web services instead of C# classes for the following cases.
You want to expose some functionality to outside world/consumers/other applications
You want to decouple parts of your system so that they can be changed without affecting other parts of application
You want to do make your application scaleable, so you create webserices and deploy those on different servers
I have a application developed based on spring web flow framework. In my application i need to display some advertisements for that i opted for OpenCMS. But Integration of OpenCMS into my application im unable to do that. All available tutorials are like integration of web applications in OpenCMS. Here my requirement is reverse. Any inputs for this will be grateful.
Here some queries i want to know.
Can we Create webservice in the OpenCMS?
Can we call that webservice from my application jsp page?
Any inputs will be grateful.....
Thanks
Eventually a duplicate to Integration of Java application with OpenCms, however the question there is the other way around, how to integrate Spring into OpenCms.
Yes, you can implement web services within OpenCms, you can basically do anything within OpenCms that you can do with Java, JSP, Servlet technologies. You can deploy your own custom jars, taglibs, implement RESTful services, etc.
I think it would be good to explicitly know your difficulties or question in the very detail.
I mean, if you just want OpenCms to act as a web services back end, then it's not 'real' integration, then it's pretty much loosely coupled. Then, you just handle OpenCms as any other web services backend, not much difference. And this way would be pretty easy in terms of 'integration'.
Then, you would let OpenCms return json or xml, instead of html, by creating the templates and assigning them to your resources (i.e. structured content in OpenCms, using cms:contentload tag, but outputting json). That's "basically it". Therefore, not clear where exactly you're currently struggling within OpenCms, please let me know some more details and the current status of your OpenCms setup, experience, etc.
I am currently looking into Flex and Liferay for delivering an RIA. We are replacing a rather large existing application built on an internal AJAX/Java library. For this, Flex seems to meet our needs for development but we've had a wrench thrown into the works. We need to integrate with another internal app that's been built on Liferay and JSF.
After looking into Liferay a bit I'm not convinced that it provides any benefits to our existing application since delivery via a portlet doesn't appear to have any inherent benefits other than achieving the integration with the other application. It also appears to have a number of downsides including smooth interaction between the swf and the rest of the page, hooking into Liferay's user management and their general lack of developer oriented documentation.
It seems to me Liferay is a good solution if you need an internal wiki/news/social application, but for delivery of a robust RIA it seems like we're trying to fit a square peg in a round hole.
My question is this: Is Liferay used for delivering full RIA applications or is it a platform that's better suited to delivering smaller apps? Am I missing something about Liferay that makes it a good fit for RIA?
Thanks in advance for any advice!
You can easily get a Flex app to show up in a portal (Liferay or other) but here are some issues you might run into:
1) Typical portal servers hold all of the state - for all of the portlets - on the server. Every interaction causes a page refresh which rerenders everything on the page based on the serverside state. For Flex applications you don’t usually want the state on the server. And you don’t want every interaction reloading the Flex app. Some portals are getting more Ajax’y which solves part of this but there will always be some interactions in HTML portlets or in the portal chrome that cause a page refresh. This means that Flex applications must done some work to persist state beyond a page refresh. A simple way to do this is using LSOs but this requires a lot of extra plumbing code.
2) Inter-Portlet-Communication (in JSR 168 portals) goes through the server based on a page refresh. This also doesn’t work well with Flex apps. JSR 286 is attempting to solve this to support Ajax portlet IPC. Until then making Flex apps work with standard IPC is difficult (but possible).
3) A big part of portals is entitlements, customizations, and preferences. These are all difficult to use and interact with from Flex. In JSR 168 portals there isn’t a standard way of doing this. In JSR 286 there is a standard which makes it easier for Flex to read and update user preferences.
4) With WSRP and other remote portlet technologies portal servers can consume remote portlets and proxy all requests back to the portlet provider. With Flex this is more difficult because portal servers don’t know how to proxy Flex requests (HTTPService, RemoteObject, DataService, etc). In many cases the only solution is to allow the end user’s machine to talk directly to the portal producer server. However many times this causes problems for IT because it means moving another server to the DMZ and potentially bypassing the security constraints imposed by the portal server, SSO server, Security Appliance, etc.
Have a look at www.qooxdoo.org. This is a framework for writing large applications entirely in javascript. It combines excellent GUI control with a java like programming paradigm for javascript and a clever build process for the final application.
Does anyone know of a good article or tutorial on the Internet demonstrating the use of GWT leveraging a (ASP.NET) web service cross domain?
To my knowledge, interacting with either XML or JSON should be possible from GWT, but becomes a lot more difficult when the web service is on a different domain. I've tried finding an article that demonstrates this setup, but without any luck.
There are a few options available:
use the Cross Site linker - it should make cross domain request easier, simply add <set-linker name="xs"/> in your module file (*.gwt.xml)
window.name hack :) Be sure to read the post with the original dojo proposal
JSONP
many others ;)
But first I recommend reading http://code.google.com/webtoolkit/tutorials/1.6/Xsite.html - it should get you going :)
I was initially going for a JSONP approach (as suggested by Google), in order to do cross site AJAX calls in JavaScript, but ended up with too many hacks that I had to incorporate into the ASP.NET web service in order for it to work.
The solution, in my case, was instead to use GWT RPC to a JAVA servlet, acting as a proxy, which then would call the ASP.NET Web Service using SOAP. The SOAP Java classes was generated using the wslist tool that is part of JAX-WS project (as demonstrated here).
Using the GWT RPC, I was still able to call the JAVA servlet asynchronously, giving the user a seamless experience.