June JDJ, The New Format Is Fantastic! But Don't Let Idiots Write...
Roedy Green's article in the June issue of JDJ is not worth the paper that it's printed on. His beginner article on Dates and Calendars doesn't fit in with the rest of the stellar content in an otherwise fantastic issue. As a beginner in the field of Java, I look to JDJ to help me along the way. I can honestly say that I learned nothing from this piece. I hope that your future articles for beginners are more useful. Green can read the rest of this issue and maybe learn from it. Don't let this guy write, he is an idiot…
JDJ is a wonderful publication and the new format makes it even better. I'd like to see a section in each issue devoted to new and less-experienced Java programmers. ""Interfaces vs Abstract Classes"" by Anthony Meyer was a wonderful example of this type of article [Vol. 6, issue 4]. I handed it out to students in my last Java class because it really explained many things.
Some proposals are:
- How and where to do validity checking on data that's entered through Swing components.
- Which Layout managers do programmers ""really"" use? Do they use the Swing classes or a bought-in Layout Manager?
- Do experienced programmers really use threads?
Comments on Jon Stevens' Article
I just read Jon Stevens article about JSP, Struts, Velocity, etc., [""JSP: You Make the Decision,"" Vol. 6, issue 7]. I was really pleased that I'm not the only one who doesn't like JSPs. Great article!
Couldn't have said it better... :-)
I just finished reading Jon Stevens' article and I wanted to write you a quick thanks. You did a great job of explaining the differences between JSP and Velocity and it was a great read. I've been using JSP from the beginning and have been frustrated when working with designers because we couldn't expect them to learn JSP; they would give us HTML instead and we would have to turn that into JSP ""and"" do the back-end logic. Velocity does seem to provide a very nice alternative to this so I'm going to look into it now. Thanks for taking the time to write a straightforward comparison.
Chat with James Gosling
Thanks for the good interview with James Gosling [""Real-World Java with James Gosling,"" Vol. 6, issue 8]. He references a book, Effective Programming, but I can't find it anywhere. Are you sure you have the correct title?
J. David Beutel
The book is Effective Java Programming Language Guide (The Java Series) by Joshua Bloch, Addison-Wesley Professional; ISBN: 0201310058.
J2EE Security Model
I read Sanjay Mahapatra's article, ""J2EE Application Security Model,"" [Vol. 6, issue 8]. While implementing some projects using some of the more popular app servers, we've run into some limitations of the security model. While the container security descriptors are declarative, we find we need finer-grained support. It's one thing to protect certain apps based on the user's generic role, but our apps tend to have user-specific permissions, and the declaration isn't flexible enough.
In your example in Listing 3, you restrict the use of the CustomerServicesEJB to entities in the role of ""customer."" We want to go the next step. For instance, we would want to restrict the customer ""Bob Hoozit"" to viewing only his orders and his invoices.
Are we expecting too much from the J2EE security model or should we be looking at this in a different way?
The scenario you mention: ""restrict the customer 'Bob Hoozit' to viewing only his orders...,"" is relatively easy to implement using the current J2EE security model.
Let's say the customerID/loginID (also the name of the security Principal) for customer Bob Hoozit is: bhoozit.
1. Order creation
When creating a new order, we'll need to persist to the database, the loginID field, along with the other fields that comprise the order. To accomplish this with container-managed persistence, code similar to the snippet below should be used within the ejbCreate() method of OrderEJB.
this.loginId=theContext.getCallerPrincipal().getName() ; //
The above saves bhoozit in the loginID field, if bhoozit was logged in and created this new order.
2. Order retrieval
Now let's say the CustomerServicesEJB has a method retrieveOrders() and the OrderEJB (entity) has a findByCustomer() method. The CustomerServicesEJB::retrieveOrders() method will in turn need to make a method call similar to:
on the remote reference for OrderEJB. The above will cause the invocation of findOrdersByCustomer with the argument (bhoozit), if bhoozit was logged in and attempted this order retrieval.
This will result in each customer being able to see only his or her own orders, with just a couple of lines of code.
Hope this helps.