Mail Of The Week: What I Can And Cannot Do With Java EE 6

Got an interesting email with questions regarding Java EE restrictions. Some answers:

>"I have installed Glassfish 3.0.1 and am using NetBeans 6.9.1 for implementing stuff"
Congrats - you saved about 5h :-).

I have a web service running on Glassfish. What can I do now to access an RMI based server? Can I do this: HelloWorldRMI hdl = (HelloWorldRMI) Naming.lookup("rmi://localhost:2000/HelloWorldRMI"); String helloString = hdl.sayHello("WS");
Yes you can. It works perfectly with all servers I know. This is what I do with greenfire.dev.java.net to access the native driver.
Can I also open a socket from the same web service to another C++ based server?
You can open client sockets, but not server sockets. I did it in the past with JBoss, Glassfish and WLS. The spec is a bit fluffy here.
Can I write something to a file?
It will work on most application servers, but it isn't compliant. It is also problematic regarding consistency and concurrency.
You could write a JCA connector for transactional file access. It is easier, than you may think. I wrote a JCA-File connector in my book Real World Java EE Patterns - Rethinking Best Practices See page 181 - Generic JCA connector. My transactional example is comprised of ...4 classes and one XML file.
Can I create my own classloader and load classes through there?
It will mostly work, but is not compliant."...Allowing the enterprise bean to access information about other classes and to access the classes in a manner that is normally disallowed by the Java programming language could compromise security..."
Can I dynamically create classes like this: MyClass myClass = (MyClass) Class.forName("...my.MyClass").newInstance(); String returnString = myClass.sayHello(className);
This is perfect - except obtaining EJBs and CDI managed beans that way :-)

Comments:

The most frustrating limitation of JavaEE - one which I’ve never found a satisfactory solution to :
long running processes. I often need to run a thread continually in the background of the server to continually run simulations etc. I’d like the thread to spawn on startup and shut down politely, and be able to use JavaEE services and call EJBs etc.
I’m an artist, so maybe my requirements are unusual, but it doesn’t seem to me like such a strange thing to want to do.

The last time I looked there seemed to be something called the WorkManager interface in Glassfish, which seems as if it might offer something useful -but using it seems extraordinarily complex.

Posted by Joshua Portway on August 18, 2010 at 04:53 PM CEST #

@Joshua,

you should try @Asynchronous beans: http://www.adam-bien.com/roller/abien/entry/fire_and_forget_without_jms

A JCA connector would also solve your problem... But you are right - a standardized exposure of ExecutorService would make the handling a lot easier,

thanks for sharing your thoughts!,

adam

Posted by adam-bien.com on August 18, 2010 at 05:16 PM CEST #

Java EE 6, section EE.6.2.3, indicates that both web and EJB modules are permitted to read and write files. Obviously any given application server may restrict which files can be read and written.

I was surprised by this, as I swear this was not true in prior versions of J2EE, but I couldn't tell you which ones.

Best,
Laird

Posted by Laird Nelson on August 18, 2010 at 06:34 PM CEST #

@Laird,

it is still "forbidden" by the EJB 3.1 spec (which belongs to Java EE 6). This can be enforced by the application server with security policy settings. So actually it is decision of the administrator what is allowed and what not.

It is a good idea, however, to think twice before you access a shared resource (like a file) from multiple, probably distributed threads, at the same time :-)

thanks for your comment!,

Posted by adam-bien.com on August 18, 2010 at 06:40 PM CEST #

looks like homework to me :)

Posted by Michael Bien on August 18, 2010 at 06:58 PM CEST #

I just came across an project which makes extensive use of ThreadLocal to forward information between different call levels of EJBs. Though I cannot see any technical reason nor any functional reason to do so, the project team is arguing hard to avoid refactoring. I am afraid of hard to find runtime errors when the Java EE container could suspend Beans under load and use the same technical Java thread for different threads of execution. Where are the limits of such an approach and how can I argue against it - the developer team claims that the Java EE 5 spec "does not explicitely forbid" the use of ThreadLocal (as it does with Thread start/stop etc.)?

BTW: Is there a good general overview of (technical) Does and Don'ts for Java EE available?

Posted by Gerd Aschemann on August 23, 2010 at 12:56 PM CEST #