Eric Lim

Hi karthik,
That is what we are currently doing. We have a servlet that is started automatically by the app server and then we piggy-back from that by loading the properties from the file system at that point. At the moment it works fine because the web and ejb containers run on the same JVM in our app server. But when you have a situation where the EJB container runs on a different JVM than the web, it's a problem.
How did you implement the start-up class in your case?
thanks
Eric

http://developer.iplanet.com/tech/appserver/framework/index.jsp

Hi
Does anybody know whether you can define a global environment entry (<env-entry> that can be accessed by all EJBs?
As far as I know, environment entries in ejb-jar.xml are EJB-specific but I need a facility to be able to store common EJB properties that are needed by all EJB's in the JNDI name space. Is this available via the standard J2EE EJB deployment descriptor?
If not, can anybody share his experience on how this (i.e. global EJB environment entries) is achieved by some other means? I want to stay away from Property files as much as possible because it could lead to some issues that violate the EJB specs (such as file system access).
thanks
eric

Thanks for all the input.
"Enterprise Architecture Patterns" looks pretty good at first glance.

Hi Tim,
This is quite a different topic but my problem with struts is that there is no distinction in the execute (or perform) method in the Action class whether you are requested to display the ActionForm (i.e the JSP associated with the form) or to handle a submitted ActionForm.
For example, if I had a JSP page that prompts for a password change with a submit button on it, how could I distinguish inside the execute method that it is called to display the page initially or to now process this page and change the password in the database etc? The way we do it at the moment is test for the existence of some parameter value in the request (e.g. the submit button) and decide what to do based on that. Is this the standard way of doing in struts or is there a feature in struts that takes care of this that we don't know? I am looking for a sort of a separate display() method in the Action class that will be called by the framework if requested to display the form rather than use the execute() method as a general handler for these two different events.
I know that in some other framework such as JATO, you will explicitly know whether you are going to display or handle the form because the events that you receive from the framework are very specific.
Thanks,
Eric

Thanks, JiaPei. I guess I need the most definitive answer to this but I also welcome any opinion especially if you have done a non-trivial project that use JDBC from EJB to manage transactions.

Hi all,
I have a question regarding J2EE compliance and Transaction Management in an EJB. Does the EJB 1.1 specs explicitly require that we have to use JTA to demarcate and manage transactions in a bean-managed transaction? That is, if we use JDBC to manage a transaction (using the Connection object commit/rollback) in an EJB, does it make our EJB non-J2EE compliant?
This is very important question for us and I really appreciate any feedback from you on this.
Thanks
eric

Hi Kyle
I'm glad that you asked because I think that's probably where my problem is. At the moment I am using Microsoft Access as a proof of concept and using odbc-jdbc bridge. For some reason I couldn't get a connection successfully from the DataSource using JNDI so I'm using DriverManager.getConnection(). I'm sure I have read somewhere that you have to get the connection from the DataSource using JNDI to make JTA work. Do you think this is where the problem is? By the way, I'm using iPlanet as the application server.
And regarding stepping through the code and viewing the record, I'm actually using MS Access itself to look at the record so they shouldn't be in the same transaction context as my code.
thanks

Thanks for all your reply. I understand that you don't have to and must not manage the transaction yourself using connection.commit() etc. if you are using JTA.
The reason I asked whether you still have to set the auto commit to false in your connection to make JTA work is because I noticed that if I don't set the auto commit to false in my connection, and assuming I am inserting a record to a table, the record gets inserted straight away even if I have not yet reached the commit statement in my UserTransaction. I did this on a debug mode by stepping through the code. Maybe I missed something?
thanks

If an EJB is using JTA to manage transaction, does it matter whether your JDBC connection is set to auto commit true or false, or does it still require the auto commit flag set to false?
Thanks
Eric

Hi,
In your experience with building real-world J2EE-based applications, do you find it practical (or possible to say the least) to place all business logic in EJBs? I find it difficult to imagine an application that completely adheres to this "best practice". There must be some business logic somewhere in the web client that controls the business logic or at least decide which business logic to invoke. Any thoughts?

Thanks for all your input. I missed the point that wrapping a non-serializable class in a serializable class doesn't make it serializable.
thanks

Thanks for all your reply.
The situation is that we have an existing application that we migrated to a J2EE compliant application server (iPlanet). We have an EJB that encapsulates all accesses to the database and one of the methods in this EJB is getConnection() which returns a Key object (that implements Serializable).
The EJB manages which Connection belongs to which Key. The client only maintains the Key and controls the transaction boundary. This means that if the client is ready to commit all changes to the database, it can then call commit(Key key) method in the EJB passing the Key. The EJB then locates the appropriate connection for that key and commits the database changes. This was the architecture we inherited from the old application.
But the problem is that the EJB maintains the list of Key/Connection entries in a static field in the stateless EJB. This is good only if the application server loads only one copy of the class but in our configuration the app server actually clusters several EJB servers running in different JVMs and each loads its own copy of the EJB class. This makes the static Key/Connection list a potential problem as it is not guaranteed that a set of transactions will always be served by the same instance of the EJB server.
In order to solve this problem without major impact to the existing application architecture, we decided to encapsulate the Connection object in the Key that is passed to the client and therefore eliminating the need for the EJB to maintain the Key/Connection list. The client doesn't have to know that a Connection object exists in the Key (e.g. making it a package scope) it receives from the EJB. When it passes back the Key to the EJB to commit the transaction for example, the EJB will get the connection object straight from the Key. This way, it doesn't matter which EJB server instance we end up with.
There will be no issue with Connection being not Serializable because it is encapsulated inside a Key class which implements Serializable.
Given the above scenario, does this make sense to you?
thanks
eric

Hi,
Is it safe to pass a Database Connection object from an EJB to any of its clients? For example, if I have a method in my EJB called getConnection() that returns a database connection, can the Connection object be safely passed or returned by value to the calling client?
Thanks for any help.
eric

Thanks, James. Not exactly what I wanted but it will do.