J2ee today is something between a vast ocean of knowledge and a big mess :-) The main problem with all the j2ee technologies is that they don�t exist only by themselves. To give you an example let�s say you will play with some examples and in couple of weeks you�ll be able to build a web-centric application that uses servlets/jsps and
jdbc to access a database. You are also familiar with the transactional model and probably with jta/jts. Basic knowledge about the implicit/explicit security model is also required, but again let�s say that you�ve picked this up as well.
Next day you�ll go to an interview and we�ll be able to answer to all questions relating the api you�ve used and explain your application architecture (which is not going to be trivial though). One of the possible questions you�ll get might be about
testing. What kind of tools or framework did you uses for testing your app? You�ll go back home, reading more about jakarta cactus tests, testing inside and outside of the container, designing your classes to be fully testable etc. Lot of information though, only to perform a very simple task: testing your application. Next week you�ll be back to the interview again; now you know almost everything and the questions will be about your application design: did you use an MVC
pattern? Did you use
JSF? Aren�t you familiar with XML/XSL? Hence you have to go back home and chose between Jakarta Struts, JSF, Tapestry, or maybe all of them. Once you�re done with this task you�ll see that your interviewer needs you to tell him more about the data access. Are you familiar with any persistence framework, like Hibernate or JDO?
I guess you got my point. As I said from the industry perspective it�s much more information than one can get in a lifetime. You must realize this and
you should focus on defining the way you like to present yourself to employers. You better present yourself as a junior programmer that has only such and such experience, but is eager to learn and become a good developer.
Good luck!
