I have to convert a WebSphere portal application to a standard web application which can be deployed to WebSphere itself for now (and to JBoss later).
How can I find what built-in portal features are being used?
I have full code access. Are there any tools for this? What are the things I should consider?
Depends on how the application has been developed and which version of the portlet spec your application was built against.
If we take the case of porting a single portlet to a standard J2EE where the latest portlet spec is used the application might be using more modern practices e.g. be using resourceURLs and Ajax calls from JS to communicate with the backend.
This is the best case scenario, where you can take the JSP remove the portlet specific stuff e.g. the context roots and portlet name spaces. Then convert your resourceURLs into servlets by creating servlets which either call the same service methods or depending on how the code was written taken the code straight for the serveResource methods in the Portlet class.
Now worst case scenario for porting, this is where the portlet makes heavy use of actionURLs and other portal features which are very specific to the portlet spec. I'd guess that the best way of going about porting these is to try emulate the behavior of the portlet. You could try to hold all of your state information on the backend like a portlet does and replace these actionURLs/renderURLs with JSPs/servlets appropriately while having some object on the backend which stores the current state of the page for each user.
Hope this helps, more information on your project would obviously make it easier to help.
In regards to finding out what portlet specific features have been used look at the portlet class' imports and the tags used in the JSP along with the portlet.xml
Related
Hello I've been googling a lot about this.
I want to test my JSf application without deploying it in to Server, so basically i want perform mock test like test.
I've used JSFUnit before. If its possible with JSFUnit itself, HOW to DO THAT?
Is there any other JSF 2.0 testing framework which is simple to use and can simulate container for running tests without container ?
[Along with names please provide some tutorial or example references also]
Please help!!
You could check out the Arquillian Project
You cand find a 1h video tutorial on Testing JSF Applications with Arquillian and Selenium here
Updated Feb 2018: OpenBrace Limited has closed down, and its ObMimic product is no longer supported.
Although not specifically designed for JSF testing, the ObMimic library of Servlet API test-doubles might be suitable.
It provides plain-Java, out-of-container simulations of Servlet API objects that are accurate enough and configurable enough to be able to run the JSF servlet. This lets you test complete GETs and POSTs of JSF pages without needing to deploy to a server or use a container.
Your tests can create and configure whatever Servlet API objects are necessary for each test (including a ServletContext with any necessary resources, mappings etc), use these to initialise and invoke the JSF servlet to process a request, and then examine the results. Your tests can also install JSF PhaseListeners to access the FacesContext and examine any relevant JSF data structures at appropriate points during the JSF processing.
The ObMimic website and documentation includes a "How to Test JSF Pages" guide that goes into this in some detail, including example code.
Note that as well as testing "real" JSF pages, you can also use this approach with test-specific JSF pages that just invoke or trigger whatever JSF code you are trying to test (i.e. each test can install any desired JSF page text into the ServletContext and then use the JSF servlet to run it).
I am a new web developer who is struggling to even set up local development environment with Eclipse. My goal is to eventually put my idea into a cool website that could be hosted on 64MB private JVM Tomcat 6 server (here).
I tried everything I could last 4 days reading bunch of tutorial sites and came up with an Eclipse project which could be downloaded. download.
I am overwhelmed with integrating so many frameworks (I wasn't an open source guy before), I feel that I'm stuck. Following are some questions I have.
How come when I run above project on Tomcat 6 server on local machine, I have to access it with "http://localhost/richfaces-tomcat6/" I want to be able to access it with "http://localhost/Namo/". Because "Namo" is going to be my website name.
How come "http://localhost/richfaces-tomcat6/index.xhtml" is not showing the inputText at all?
How come I cannot use "#Named" annotation for the managed beans? Instead I have to use "#ManagedBean". I read some where that #ManagedBean is really for the legacy system. Does this matter?
I am trying to code in JSF 2 with a bit of Ajax features on the site. I read some where Richfaces is useful. Am I even on the right track with setting these up?
I know I am asking a lot of questions. I am so ready to have something set up locally and hit the books for JSF but I can't even get started on it which is very frustrating. I would really appreciate it if somebody could help me or guide me to right direction.
How come when I run above project on Tomcat 6 server on local machine, I have to access it with "http://localhost/richfaces-tomcat6/" I want to be able to access it with "http://localhost/Namo/". Because "Namo" is going to be my website name.
The context path defaults to the Eclipse project name. You should have edited the context path in one of the last steps of the Eclipse project creation wizard. You can always edit it afterwards in the Web Project Settings section of the project's properties (rightclick project and choose Properties).
How come "http://localhost/richfaces-tomcat6/index.xhtml" is not showing the inputText at all?
Apparenty the request URL did not match the URL pattern of the FacesServlet as definied in web.xml. The given URL expects it to be mapped on an <url-pattern> of *.xhtml. Eclipse defaults to /faces/* and/or *.jsf and would require you to open the page by either http://localhost/richfaces-tomcat6/faces/index.xhtml or http://localhost/richfaces-tomcat6/index.jsf. But mapping the FacesServlet on *.xhtml is much better.
How come I cannot use "#Named" annotation for the managed beans? Instead I have to use "#ManagedBean". I read some where that #ManagedBean is really for the legacy system. Does this matter?
The #Named annotation is part of CDI which is part of Java EE 6. Tomcat is however a simple JSP/Servlet container and not a full fledged Java EE container. You'd either need to install CDI yourself if you want to use it on Tomcat, or to replace Tomcat by a fuller fledged Java EE container, such as Glassfish 3 or JBoss AS. See also the Weld documentation (Weld is the codename of the CDI reference implementation). Note that you don't necessarily need CDI to get JSF to run. Using #ManagedBean ought to be sufficient for a simple web application.
I am trying to code in JSF 2 with a bit of Ajax features on the site. I read some where Richfaces is useful. Am I even on the right track with setting these up?
JSF2 already supports Ajax out the box with the <f:ajax> tag. RichFaces is just a component library which offers more enhanced components and skinnability support on top of the standard component set. See also Communication in JSF 2.0.
1, 2 JSF 2.0 tutorial with eclipse tomcat
3 #ManagedBean makes sense for applications that use JSF but do not use JSR 299
4 yes you can do some cool stuff using RF, also jsf 2.0 has support of <f:ajax> so without RF using default implementation you could also do the AJAX stuff
You have severe memory constraints, so I'd better recommend to look at lightweight templating engines like Velocity or Freemarker for your pages and MVC frameworks like Struts/Struts 2 or Spring MVC.
I'm a Grails developer and I started development on Liferay 2 months ago.
I believe that if I can use Grails on Liferay I will increase my productivity by 2.
So here is my questions :
- What plugins to use to develop Liferay portlets ? I used some grails plugins but I got an error when generating portlet.xml.
- How can I configure the Grails dispatcher to work with Liferay. For example : to dispatch urls like this /web/guest/test?myportletId_WAR_aname_action=/user/show/1&myportletId_WAR_aname_windowstate=exclusive... to usercontroller and invoke show action ?
- How to get actionRequest, ActionResponse when invoking the action ?
Regards
As long as you consider the portlet as a particular view into your app it should definitely be possible. You could do it using a simple spec Java portlet that pulls information out of your main project, or look at the current Spring MVC Portlet and Groovy Portlet to see if those could be shortcuts for your implementation. I have worked with both (albeit not in the context of a Grails project) and can happily report that they work well with stock Liferay.
I'm reasonably sure that you can't create a portlet using Grails. You can of course write portlets in Groovy using GORM for data access. GSP isn't currently available outside of Grails so you might have to live with JSP for the views.
I've found that using the portlet support in spring MVC makes your life a little bit easier than raw portlets.
Good luck
Look for discussion of com.liferay.util.bridges.wai.WAIPortlet . I've taken little Grails apps that I've built, dropped them in the hot deploy directory on a generic Liferay 6.06 install as an experiment, and presto, they show up as portlets! I guess Liferay cooks up generic portlet.xml etc. for them. They aren't beautiful, nor are they tied into Liferay's Services API or database, but they run as a portlet, and of course you can also find them where they should be as stand-alone webapps. Fun!
The portlet API deos not provide any reference to the enclosing servlet request and response objects. I know it is not the preferred model of interaction with the user, but it seems draconian to remove all access.
I understand that for portlet driven interaction with the user, you want to use portlet URLs, and let the portlet container manage all the complexity.
However if you have a number of portlets which are basically showing variants of the same data, it makes sense for them to be able to use the enclosing request to drive the data.
We ended up using using a Liferay specific call to get the request, and it all seems to work as we wish.
However I do feel the guilt.
So my question really is, is there an underlying deep reason for the prohibition, or is it just to enforce the authors view of the API environment?
The portlet doesn't run right into the Servlet container, but rather what is called a Portlet container.
You should be able to access to the corresponding information, PortletRequest, PortletResponse, and PortletContext.
The reason is that two instances of the same portlet can run next to each other in the same page, but still be isolated with their own lifecycle. The portal will "multiplex" that transparently for you, and it will convert from the servlet world to the portlet world. Portlet bridges are also available to develop portlets with non-portlet technologies (e.g. JSF). I agree that all this is usually (very) complicated to use (because of the many frameworks and implementations available), but when you think of how it works conceptually, it's quite nice.
The exact details will depend on the technologies you chose to develop the portlet. But I feel like there should be a way to do what you want using the portlet API.
I am trying to get familiar with Java EE 6 by reading http://java.sun.com/javaee/6/docs/tutorial/doc/gexaf.html. I am a bit confused about the use of JSF.
Usually, the way I develop my Web App would be, Servlet would act like a controller and JSP would act like a View in an MVC model. So Does JSF try to replace this structure? Below are the quote from the above tutorial:
Servlet are best suited for service-oriented App and control function of presentation-oriented App like dispatching request
JSF and Facelet are more appropriated for generating mark-up like XHTML, and generally used for presentation-oriented App
Not sure if I understand the above quote too well, they did not explain too well what is service-oriented vs presentation-oriented.
A JavaServer Faces application can map HTTP requests to component-specific event handling and manage components as stateful objects on the server.
Any knowledgeable Java developer out there can give me a quick overview about JSF, JSP and Servlet? Do I integrate them all, or do I use them separated base on the App? if so then what kind of app use JSF in contrast with Servlet and JSP
A JavaServer Faces application can map HTTP requests to component-specific event handling and manage components as stateful objects on the server.
Sound like what servlet can do, but not sure about manage components as stateful objects on the server. Not even sure what that mean? Thanks in advance.
JSF basically enables you to develop a web application with only model objects (JavaBeans) and views (JSP/XHTML pages). With "plain vanilla" JSP/Servlet you'll have to bring in a lot of code to control, preprocess, postprocess, gather data, validate, convert, listen, etc the HTTP request and response. And then I'm not talking about refactoring it to a high (abstract) degree so that you can also end up the same way as JSF does (just a JavaBean class and a JSP/XHTML page per use case).
I've posted a more detailed answer on the subject before here: What is the difference between JSF, Servlet and JSP?
In JSF uses one specific Servlet (the Faces Servlet) to handle all incoming requests and dispatch them to the appropriate beans.
JSF is a component-based MVC framework, while JSP is a view technology.
You can use JSP with JSF, although Facelets is the preferred view technology.
JSF provide an abstraction layer with several responsibilities, but most important it handles all the messy details of HTML forms and transferring data back and forth between web pages and Java POJO beans (getX, setX methods), which is notoriously difficult to do right.
It also provides navigation and in the latest incarnation in Java EE 6 rudimentary AJAX support is available allowing for simple updates of the web page as the user inputs data.
You might find it easier to think of it as a way to avoid writing JavaScript yourself.
If you like XML choose JSF. In case that you are an actionlistener fan
doPost,doGet etc choose Servlet and JSP.
JSF Framework targets to simplify development integration of web-based user interfaces. As #bozho stated you can mix JSP and JSF. However, the "view" component in JSF is facelets - which can be viewed as little UI widgets, which are more or less self contained with respect to DHTML styling and JavaScript event generation and call back.
"Should I bother learning.. ?"
Not sure. I haven't seen JSF picking up that much steam even though it was around (Atleast in theory) for last 5 years.