Valery Lezhebokov

http://www-01.ibm.com/support/docview.wss?uid=swg21229508

If you are outside of the container (or create an object yourself) then the only way is the JNDI lookup. In EJB 3.x it shouldn't be that painful since the JNDI names have been standardized under java:global namespace.
I suppose the method mentioned by Hebert Coelho would work for JSF ManagedBeans but not for EJBs.

Note that you have two ways of reading/updating the entity fields: property access and filed access. EJB 3.0 implies JPA 2.0 in which you can define the access by @Access annotation. The default is FIELD. That means that even though you have your getters and setters the persistence provider will access the fields directly (via reflection) bypassing these methods.
Sorry, didn't see that you use method annotations. Then yes you thoughts about when these methods are invoked are correct.

Rajni Patel wrote:Hi,

I have created project in EJB which is now in already production which is in UNIX platform. I want to change some properties in property file and xml file and but i can not build appllication again.
Is there any possibilies, which i can change my property class and xml file (configuration file) ?

Thanks in advance.

Just change your files and redeploy your application or restart the server.

massimiliano cattaneo wrote:
The problem is that if the method thrown an exception (RuntimeException) the Transaction associated is rolledback and also the message is put back in the Queue ( if the Queue is used as destination of the message)

According to spec all RuntimeException (System Exceptions) should be logged, so I think it would be visible in the logs if that was the case.

I don't know this for sure, because the server often leaves no error logs around the time of the crash, it just becomes non-responsive, yet the process is still running. I will often see CPU in use, which I have found to be JMS related processes still running in the background. I don't know for sure, maybe they're unrelated; but I still want to separate the bean processes into their own application server.

I don't know the details of the architecture, but I guess that the majority of the work is done on the JMS consumer side. In this case indeed spiting up the job among several consumers make sense, but before doing that you really need to be sure that it's necessary. Having everything in one JVM is often always much simpler (especially from maintenance pov).

Andriy Kharchuk wrote:

From what I understand, if transaction is open Stateful EBJs are never passivated. Am I missing anything?

As massimiliano cattaneo already mentioned the SFSB life cycle is the most rich one. Here is a nice state diagram that may help to understand it:

http://sqltech.cl/doc/oas10gR31/web.1013/b28221/img/lifesfsb.gif

Jaikiran Pai wrote:Please post the relevant part of the build script and also the entire error that you are seeing.

+1

Seems that the problem actually occurs at deployment phase and not when the application is built. Generally it means that for some reason the following can't be found "PATH_TO_JBOSS\jboss\server\default\deployers\ejb3.deployer\". Waiting for more details from you...

massimiliano cattaneo wrote:Hello,
Pay attention that the @PreDestroy Method is not called in this case (@StatefulTimeout).

In fact it's true only if the bean is in the Passivated state. If time out occurs in Method-Ready state, then the @PreDestroy method will be invoked.

In your example - using scriplets in JSP is considered as bad practice, that is why use EL to access parameters:
{$param['name']}

Try to make class MyPage coderanch, i.e.:

public class MyPage extends HttpServlet

It should work. What the getParameterMap() method returns?

Here it is in the blog

Isn't it something wrong with the quotes here
_VM_PROPERTIES='"-Djava.library.path='lwjgl/native/linux"'
?

Hi,

what do you want to do with the file? If you need to read it, then I suggest to use this.getClass().getResourceAsStream(fileName) for that purpose.

Hope this helps,
V.

For me the real power of the interfaces is in decoupling components, and that becomes more important in large applications. Interfaces define behavior, while classes define how this behavior is achieved. E.g. you might have an interface
interface PropertiesLoader{ Properties load(); }
and several implementations of this interface which load properties from different sources like XML, DB, file etc. Then in the main (or any other class) you may create the loader and use interface reference to point to it:
PropertiesLoader loader = new XmlPropertiesLoader();

After creating you can pass the loader around to any number of methods/classes, and if in some time you decide to load your properties from a DB, all you will need to do is to change one line:
PropertiesLoader loader = new DbPropertiesLoader(); .
without touching the rest of the code.

Hope this helps.