Archiv für Kategorie Entwicklung

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

Verfasst von Hendrik Busch unter Entwicklung am 27. Mai 2009

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

, , , , , , ,

4 Kommentare

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

Verfasst von Hendrik Busch unter Entwicklung am 8. August 2008

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:

Zum Rest des Beitrags »

, , , , , , ,

2 Kommentare

OpenSource und das inhärente Problem

Verfasst von Hendrik Busch unter Entwicklung am 7. Juni 2008

OpenSource ist eine tolle Sache und ich stehe voll dahinter. Als Java-Entwickler ärgere ich mich immer, wenn ich Bibliotheken benutzen muss, bei denen ich mir nicht ansehen kann, wie sie funktionieren. Denn wenn sie mal nicht funktionieren, bleibt nur noch der Support des Herstellers, obwohl das Problem vielleicht trivial ist.
Viele behaupten immer noch, OpenSource hätte zahlreiche Probleme wie z.B. Sicherheit und Qualität. Aus Erfahrung kann ich sagen, wenn die Community groß genug ist (wie bei vielen bekannten Projekten) dann gibt es weder ein Sicherheitsproblem noch ein Qualitätsproblem. Lediglich Fehler, die auch in closed source Software zu Problemen führen kann, z.B. mangelnde Absprache (siehe Debian/OpenSSL-Debakel).
OpenSource hat aber ein anderes, inhärentes Problem, und das ist die mangelnde Duldung durch Unternehmen, die mit Software an sich und obskuren Patenten ihr Geld verdienen. Das konnte ich heute wieder sehen, als ich eine Mail von SourceForge mit den Stimmkategorien für die OpenSource Awesomeness Wahl bekam. Dort gibt es u.a. die Kategorien:

  • Most Likely to Be Ambiguously Accused of Patent Violation
  • Most Likely to Get Users Sued

Andererseits spiegeln die Kriterien auch das Selbstverständnis und den Idealismus von OpenSource wider:

  • Most Likely to Change the World

, , , ,

Keine Kommentare

JAX-WS and soap:address

Verfasst von Hendrik Busch unter Entwicklung am 27. Mai 2008

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

PLAIN TEXT
XML:
  1. <service name="MyService">
  2.     <port name="MyPort" binding="tns:MyPortBinding">
  3.       <soap:address location="http://localhost:8080/my-service/myAction"/>
  4.     </port>
  5. </service>

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:

PLAIN TEXT
XML:
  1. <service name="MyService">
  2.     <port name="MyPort" binding="tns:MyPortBinding">
  3.         <soap:address location="http://prod-ws.mycompany.tld/my-service/myAction"/>
  4.     </port>
  5. </service>

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

, , , , , , ,

3 Kommentare

Wartungsfaule Webentwickler

Verfasst von Hendrik Busch unter Entwicklung am 16. März 2008

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

,

Keine Kommentare