Win a copy of Emmy in the Key of Code this week in the General Computing forum!

John Mathew

Greenhorn
+ Follow
since Jun 06, 2002
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by John Mathew

My experience has been that very seasoned developers and very green developers make for difficult pairings. The ideal pairings I have foudn are senior-senior, senior-intermediate and intermediate-junior. senior-junior pairings tend to intimidate the junior and tend to frustrate the senior. intermediate-intermediate may lead to slower learning. But that last one, I'm not sure about.


In XP the pairing has nothing to do with seniority. Pair programming in XP works only if Personal Egos do not interfere woth work. I have found lot more egos in Software engineering than any other field. As for pairing senior- junior, it is mostly done to get the junior on speed with the practices followed in the organization and also is the best way to lear OOP
My Experience has found pair programming as defined in XP very unproductive on everyday programming. What I found working is code review with a peer and also on bug tracking. It does help in designing too. Coding ???, just my experience / opinion
I think there are many companies adopting XP, as for us we have not yet. We have a spiral model in place.
My friend who works for mortgage company developing application in J2EE has found it very interesting and effective.
XP philosophy stress a lot on pair programming, Automated tests, refactoring, continuous integration and short iterative cycle.
The book Xtremeprogramming Explained by Kent Beck is an excellent book, I would say not just for XP but for the development process as a whole. XP has proved successful in short to medium scale projects, but I'm not sure about large scale projects.
There is no difference between the two methods. It is always convinient to use the getInitParameter() and getInitPArameterNames() defined in javax.serrvlet.GenericServlet
Thanks
Rajeev
Hi,
I too have the same question.
I believe it has to do with more Component based programming/engineering than anything else. Entity beans does provide a wrapper around your data. CMPs helps you with no SQL, then all that transactional context blah blah..Gurus also say use session beans to talk to entity beans. I basically use Session beans and plain Old Java Objects with SQL.
Thanks
AK
Hi,
I dont think we install J2EE on the Application server. J2EE is just a specification which Application Servers Implement. We install Application Server. As you pointed out this Application Server will contain both Web Container and EJB Container. Now When talking with web, we need a Web Server. As Ajith said, web server listens to port 80 (which is configurable) and When a request comes in, it forwards it to the Web Container in Application server based on the context(This has to be configured). Now Web container can service the request itself or it can use/talk to EJB container using RMI/IIOP before J2EE 1.3 or local method call in J2EE1.3, service the request and forward it to web server back as HTML. Web Server in turn sends it back to the client. In Sun J2EE 1.3 Reference Implementation all this happens in one JVM. I think this is case with most other Application servers also. You can always have your web server run in different process in the same machine or another machine than the App Server.
Regarding Client Talking to J2EE or Web Server. There is nothing like talking to J2EE. If it is Web Applcation, it has to talk to a web server. If another Application (Swing based) not using HTTP, it can talk to the EJB container using RMI/IIOP.
Now regarding Tomcat and Web Server, I'm not sure, but I believe earlier version of Tomcat came separately with Apache Web Server. Latest Releases 4.0+ Apache is integrated with Tomcat and hence Tomcat is now a web server and webcontainer. Other Application servers which do not have a servlet engine can use Tomcat.
gurus out there please correct if any of the above statement is wrong.
Thanks Ajith for a clear explanation on that, but could you explain this a little more.
When you say "functionality of the web server and a web container is satisfied by the same software", does this mean, it can stay in one box and the EJB Container which is also part of the Application server which provided the web container/web server can be running in another box. So an Application server which implements webserver/container as a single software will have two processes, one for web server/container and another for ejb container and they use RMI/IIOP to talk to each other.
If they dont implement the webserver part then the Web Container and EJB container will run as a single process and Web Server use TCP/IP to communicate to Web Container??
When web container and ejb container run as a single process in a single JVM, do they need RMI/IIOP to communicate?
Hi gurus,
Is there a difference between Web Container and Web Server? If so how do they interact?