Tag-Archive: web

Ab jetzt auch bei github: ich

Zeit und Geduld reichen noch nicht für einen neue Folge meines ST:TNG Podcasts, aber sie reichen für einige andere Spielereien, z.B. das Rumbasteln mit dem Arduino. Damit ich mich nicht immer ärgern muss, wenn ich mal das ein oder andere Sketch nicht wiederfinde oder wenn ich mal wieder STRG+S gedrückt habe ohne wirklich was speichern (und vor allem Überschreiben) zu wollen, habe ich mir jetzt auch ein github-Repository zugelegt. Viel los ist da noch nicht, aber hier ist schonmal die URL:


Oder wer direkt zu den Arduino-Experimenten möchte, der geht direkt hierhin:


JSF: Multiple ‚javax.faces.ViewState‘ hidden fields

If you happen to have more than one h:form in your JavaServer Faces page, JSF will generate a hidden input field with javax.faces.ViewState as its name and id for each form. This breaks XHTML compatability because you have more than one element with the same id which isn’t allowed. I recently came across this myself and had some trouble finding a solution on Google. The problem results from an error in the JSF specification itself and thus cannot be solved easily but both major implementations have builtin workarounds:

For MyFaces, you can specify a context parameter in your web.xml called org.apache.myfaces.RENDER_VIEWSTATE_ID and set it to false. It will prevent MyFaces from rendering duplicate ids. For more information please refer to the MyFaces Bugtracking system (MYFACES-1700).

If you use the reference implementation (currently Mojarra), the name of the context parameter for the web.xml is com.sun.faces.enableViewStateIdRendering and you must also set it to false to prevent the RI from generating duplicate ids. For more information, please refer to the JSF-RI FAQ or the bugtracking system (issue 443).

Developing lightweight Java web applications – Part 5: Templating with Facelets

Update 2012-05-28: I have deleted the project over at Google Code since I never finished it and it is outdated by now. Please refer to other, more state-of-the-art tutorials regarding building web applications with Java. In addition, comments are also closed on these posts.

Turning the app into a webapp

After creating a small persistence layer for our JPokerStats application, it is now time to finally create a web application out of our sources. If you already have the source files from the previous parts, you may have noticed the src/main/webapp directory that was created by the Maven archetype plugin. Let’s start here.

Getting the sources

As always, you can either go the project website or checkout the associated tag from the source control system:

svn checkout http://jpokerstats.googlecode.com/svn/tags/tutorial_part_05

Integrating Faces and Facelets

A web.xml is already present, and for a JSF application we will need to declare the JSF servlet here. We will also add some additional configuration options for debugging purposes and will map all requests to the /faces/ context to the servlet. This results in the following basic web.xml:


JAX-WS and soap:address

JAX-WS is the easy-to-use Java API for XML-based web services and provides developers with an easy way to implement SOAP-based or ReSTful web services without having to fiddle with SOAP, WSDL or any XML at all (apart from the configuration).

If you use the „from-Java“ approach to JAX-WS, the runtime will automatically generate a WSDL file for your service that will be available under an URL such as http://localhost:8080/my-service/myAction?wsdl. It contains a part such as

to point the clients that later will use this service to the correct URL to address the service itself. Very soon I came across the question, how to deploy this to a production environment, where the service and the client would, of course, run on different machines. The above excerpt from the WSDL isn’t really portable from the way it look.

As a beginner with JAX-WS, at first I found no way to change this URL to reflect another server as localhost and got frustrated with the question how on earth to deploy this web service and change the soap:address part. As it turns out now, you don’t have to change this part.

The service address (as the whole WSDL file) is generated on-the-fly by JAX-WS when a client requests it. The runtime then simply derives the service’s address from the request URL for the WSDL file. So, if you can request it from http://localhost:8080/my-service/myAction?wsdl, the service address will read as shown above. If you deploy this to another server and address it for example with http://prod-ws.mycompany.tld/my-service/myAction?wsdl then the runtime will generate the following address:

and everything will be fine. I hope, I could save you some headache with this.

Wartungsfaule Webentwickler

So was kommt dabei raus, wenn man Softwareentwicklern sagt, ihre Webanwendung solle aus Sicherheitsgründen in Bestätigungs-E-Mails keine Passwörter mehr mitschicken:

Thank you for signing up for EVE Online! Welcome to the community.

Your username is: john.doe
and your password is: Wenn Sie Ihr Passwort vergessen haben, können Sie ein neues über unsere Kennwort-Wiederherstellung bekommen: https://secure.eve-online.com/forgotpassword.aspx

Please keep both in a safe place and do not share them with anyone.

Schön, dass das auch anderen passiert…