JSF2 environment set up - java

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.

Related

Java EE web applications and environment configuration

Hello stackoverflow Users,
I have found myself working on a Java EE Web Application and I know for a fact that my application is going to be deployed into multiple environments. Each environment may have slightly different configuration of some features, e.g. remote web-service URLs. Additionaly, I would like - if possible - to have the following 2 properties met:
Per environment config should not in web-application repository
This is because I feel it does not belong there. I would not want to manage n-configurations next to my source code. Moreover, if there are secrets there, I would not want every developer to see them...
Enforce completeness of configuration
If I say that I need a certain configuration parameter/resource then it would be meaningless if it was not provided. I would not want my application to start in such case.
Please, can somebody more knowledgable and experienced help me and nudge me into the right direction?
My findings so far
Naturally, I have spent some time searching the answer already ...
Spring framework
I know that spring provides an Environment class as an abstraction of environment-specific configuration. However, I am not using Spring framework, nor does it describe how to put this configuration outside of the web applicatoin.
Java EE JNDI Service
According to the Java EE platform specification, the right way to do it would be to use env-entry, resource-ref and resource-env-ref elements in my WEB-INF/web.xml and have them bound/set to values in the web app container configuration.
This actually sounds very good, except that I don't know how to enforce the completeness of this configuration. I mean, I declare the above mentioned elements, to tell the deployer that I need them, yet I see (tested on tomcat) that application still deploys (and works incorrectly) when some, say resource-env-ref, is not bound.
I don't know how to achieve it tbh, however, if there is nothing better, it still feels like the best thing I could find. :-|
I have taken the JDNI approach.
I have added validation of configuration by introducing a custom ServletContextListener implementation.

Converting WebSphere Portal application to standard Java EE application

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

How to test JSF application without deploying it in to Server?

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).

Grails portlets on liferay

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!

Suitable web framework for the following scenario

I have the following scenario:
I have a view in an Oracle server and all Iwant is to show that view in a web browser, along with an input field or two for basic filtering. No users, no authentication, just this view maybe with a column or two linking to a second page for master detail viewing. The children are just string descriptions of the columns of the master that contain IDs. No inserts or updates.
The question is which is the JAVA based web framework of choice that can accomplish the above in the minimum amount of
code lines
code time(subjective but also kind of objective if someone has expirience with more than one or two frameworks)
configuration effort
deployment effort and requirements.
dependencies and mem footprint
Also:
6. Oracle APEX is not an option.
3,4 and 5 are maybe the same in the sense that they are everything except the functionality coding.
I want something that I can compile, deploy by just FTPing to the database host, run and forget. (e.g. For the deployment aspect, Hudson way comes in mind (java -jar hudson.war and that's all)).
Also: 3,4 have priority over 1 and 2. (Explanation with a rant: I dont mind coding a lot as long as it is application code and not "why do we still use javascript over http for everything" code)
Thanks.
EDIT 1: ROO attempt.
First I tried Spring Roo but here is what happened and it is exactly the kind of stuff i want to avoid:
Downloaded Roo (setup env vars, path, etc)
Saw that it requires Maven (1st smell)
Installed maven
Setup my project in roo shell
Tried to run it and it could not build because maven could not locate artifacts.
Searched the web and eventually found that I need to tweak the generated pom because of a problem between springsource repositories and maven central caused when Oracle is used because of a minor bug in ROO that includes the maven repo and not the spring one... etc...etc..
Abandonded Roo because:
I wanted a simple one page presentation of a table view in a locally installed database, and after 30 minutes I had no progress except for searching maven forums for why maven cant find sth called an "artifact" in a list of sth called "repository".
Take a look at Spring MVC and Spring Roo. the latter will generate you Spring application in a matter of minutes with the database access and then you can add your filtering.
The hudson-like deployment should be easy if you're happy with the features an embedded servlet container like jetty or winstone can provide. Just add a main class that fires up the server and sets a few config variables. That should be possible with any java web framework.
Here's how hudson did it:
http://weblogs.java.net/blog/2007/02/11/hudson-became-self-executable
try (ยต)Micro and see if it works for you. It is Open Source, of course, and I also provided a couple of useful examples to start with. HTH - florin

Categories