JUGMeeting #22 - Sito/Axis/JSF/Tapestry

Posted by Paolo Dona' Fri, 18 Nov 2005 23:19:00 GMT

Quando: Sabato 19 Novembre 2005 dalle 09:00 alle 12:30

Programma:

09:00 - Accoglienza
09:15 - “Presentazione del nuovo sito del JUG Padova” a cura di SeeSaw
09:45 - “Introduzione ad Axis” a cura di Enrico Giurin
10:30 - Java Break – Pausa caffe’
10:40 - “Sviluppo di applicazioni web con il framework JSF” a cura di Andrea Nasato
11:25 - “Confronto JSF e Tapestry” Andrea Nasato VS Paolo Dona’
12:30 - Fine meeting 22
13:00 - Pizza con chi vuole fermarsi con noi ;-)

Dove: aula De – piano terra al DEI, via Gradenigo 6/B (ingresso studenti) Padova

INGRESSO SEMPRE LIBERO! -

Il PDF della locandina lo trovate all’indirizzo: http://www.dei.unipd.it/~ieeesb/JUG_Vol/JUGmeeting22.pdf

Vi aspettiamo!!!

Posted in

From which Jar a Class was loaded?

Posted by Paolo Dona' Sun, 13 Nov 2005 08:11:00 GMT

Sometimes in production environments I face problems never encountered during development… It’s a general thing.. could happen with jdbc drivers or xml parsers.

I just feel classes are loaded from a different jar than expected.

This of course could happen if you’re deploying to a very different application server or if you’ve no control over the production server classpath.

I found in javaalmanac.com a code snippet that can help you identify which is the jar containing a specific Class at runtime:

Class cls = MyFoo.class;
ProtectionDomain pDomain = cls.getProtectionDomain();
CodeSource cSource = pDomain.getCodeSource();
URL loc = cSource.getLocation(); 
System.out.println(loc); 
// prints something like "c:/jars/MyFoo.jar"

This way you can check if your class is loaded right from the expected jar, not elsewhere :-).

This has shown to be really useful during my sad production debug sessions.

Hope it can help you as well.

Tags , , ,  | 56 comments

JAXP 1.3 and DoS attacks

Posted by Andrea Nasato Sun, 13 Nov 2005 07:36:00 GMT

One of the new aspects introduced in JAXP 1.3 is the opportunity to specify the security level of the SaxParser used. The target of this feature is to prevent the application from DoS (Denial of Service) attacks, which use some vulnerabilities of XML. There are two main attack categories, let’s see them:

  1. Entity Resolution: suppose that XML stream requires a DTD and this DTD is in an external server and not local to your application. The parser requests the DTD to the server, which can send the DTD slowly or can give it malformed: in this case the parsing stops indefinitely. The solution to this problem is to set to a false value these properties:
    • parser.setFeature(   "http://xml.org/sax/features/external-general-entities",   false)
    • parser.setFeature(   "http://xml.org/sax/features/external-parameter-entities",   false)
    In this way the parser doesn’t call the external server to resolve the DTD.
  2. Overflow attack: XML doesn’t give a limit to the number of attributes of an element, and to the length of an element name. Overflow attacks start from this observation, and their objective is stop the server from fulfilling other requests: if the parser uses the DOM API it maintains a tree representation of XML in memory. When the parser encounters such XML streams it starts allocating objects for each attribute, saturating server memory. If you have such a problem and you use JAXP 1.3 you can set this property: http://javax.xml.XMLConstants/feature/secure-processing. With this property set, your parser rejects this kind of XML streams. You can have notification of such event in the fatalError method of the handler registered with the parser.

So if your boss is paranoid, or if your services could effectively be attacked in such a way, use JAXP 1.3 and those simple rules. If you want more information about JAXP 1.3, this is a good link. For a complete description of DoS attacks with XML this is a good tutorial.

Posted in  | Tags  | 2 comments

ToStringHelper

Posted by Lucio Benfante Fri, 11 Nov 2005 18:49:00 GMT

One of the traits I personally appreciate most in a good programmer is what I call the “constructive laziness”. It is the attitude to build software solutions for avoiding boring activities.

One of the most frequent and boring activities happening in the writing of a Java class is the implementation of the toString method, especially if the class contains lot of attributes and if it is frequently updated.

Last summer, in a mood of constructive laziness than surely doesn’t make me a good programmer, I wrote a small class library that tries to solve this problem. Using such library you can write a toString method as simple as the following:

public String toString() { ToStringHelper.toString(this); }

Read more...

Posted in  | 38 comments

Older posts: 1 ... 12 13 14