Po-yu Chien

I`m reading the book "Core J2EE Patterns" and come across the definition of fine and coarse grained entity bean. In general, fine-grained entity bean are considered bad practice; however in documentation of Pramati Server "The promise of perfect persistance from EJB2.0", fine grained entity beans are good.
So, the concept that fine-grained entity bean is bad may be a "EJB1.x only" concept?

Struts is coming up with several interesting extensions:
-Tiles
-Validator
-Workflow
The bad thing is that you have to use appropriate ActionServlet implementation for each extension. Therefore you cannot, theoratically, use tiles for multiple view reppresentation, validator for form calidation and control flow with workflow extension at the same time. That`s pity. If only those great features may work together.....

I currently use both eclipse and netbeans, and found that they behave slightly different on how they integrate with Ant. For example, I tried to use eclipse to run build.xml of several open source projects, all fail at point of javac task. Such task runs well under netbeans. Can someone give me a hint on how to get Ant work right on eclipse? Otherwise I have to code in eclipse, and build and debug using netbeans......

Of course you can store login data in database, however this still fails to address the user<->data matching issue, unless you develop your own matching mechanism. And IMHO it`s not a good idea. By the time when I was using PHP, I already tried storing session data in DBMS in order to achieve cross-server session synchronization, and it does not scale well.
As for the Facade application that handles authentication....that`s nice. In fact, that appears to be how will single sign-on look like with web services(theserverside.com has an article on this). But I don`t think this may be a solution for those who uses application server`s security model. It`s strange that servlet spec does not bring up this issue

Thanks David.
I didn`t notice that data are avialable between webapps in Tomcat. However, since application servers are not expected to behave in the same way here, therefore I cannot rely on this Tomcat specific feature.
Seems that there is no good way for cross app authentication

If it were for merely authentication, I think going back to the OLD way--setting cookies--would be ok. But sometimes you would like to share some session data which may not be so adequate to expose to user through setting cookies. Now the protection brings inconvenience.
The solution I found is to use perhaps encrypted url rewriting whenever session data between two apps must be shared. That`s an ugly solution, and I hope someone can bring up something better

In Tomcat, an session belongs to only one web application. That`s a problem, because if you user session for user authentication, user may need to login multiple times switching between web apps. Is that a Tomcat-only behaviour?How to overcome it?

Thanks for such immediate response :-)

It is common in web application to adopt helper classes to bridge presentation tier and business tier. I have some question about helper class strategy, though.
According to Model-View-Controller architecture, the only bridge between View and Model should be controller. That brings a problem: assume that we have a web application
whose layout uses jsp which imitate a framed web page by using multiple page inclusions.
Every included page has some dynamic behaviour; normally, this would be a good place to apply Helper classes for each included jsp, however it seems to break MVC reccomendations.
Did I misunderstood MVC and Helper classes methodology?

In some situation, people tend to rely more on
local application which store data locally.

You should do identicat operation to jre under
program files directory.
I believe that`s your problem.

DAO is more likely to be used in independent projects. How do you think about adopting JDO in a J2EE product instead of DAO?
Which one is better for a product? And which one performs better?

Great!
Thanks for the information!

I`m writing a little client-server applcation using j2sdk1.4.0 . Currently I use plain socket communication(using cool java.nio.* stuff) for prototyping, and I `m evaluating swiching to SOAP in near future. But I`d know the performance trad-off in this case...can someone shed some light, and make some judgment on validity? My applcation`s main purpose consists of allowing client to send message to server, and server logs the message and send to cell phone through SMS.
Thanks in advance.

Great.
I think all framworks out there all do something better one another; we developers just need to know which do better fit for job.