javax.namin.Reference

[blackers]

I have used an example to get an MBean to register a class with JNDI. however when I try and get the class using

Object fa = (Object) ic.lookup("fileManager");
System.out.println(fa.getClass());

the output is javax.naming.Reference.

I have used an example I found on the Web to register the class with JNDI.


-------------------------------


InitialContext rootCtx = new InitialContext();

Name fullName = rootCtx.getNameParser("").parse(JndiName);

Name parentName = fullName;
if (fullName.size() > 1)
parentName = fullName.getPrefix(fullName.size() - 1);
else
parentName = new CompositeName();
Context parentCtx = createContext(rootCtx, parentName);
Name atomName = fullName.getSuffix(fullName.size() - 1);
String atom = atomName.get(0);
NonSerializableFactory.rebind(parentCtx, atom, fileAction);


---------------------

Am I on the right Track? I would have expected to do something like the following.

FileAction fa = (FileAction) ic.lookup("fileManager");
fa.test();

but this throws ClassCastException.

Thanks in advance.

Mat

[blackers]

I have found that this works fine locally. i.e from EJB but not from a separate application. This is fine, as this is what I want it for anyway.

[jonlee]

You're binding to a JNDI namespace that is not accessible externally. You have the same problem if you try to locate a DataSource from outside the JBoss JVM.

[blackers]

Is
<Statement 1>
---------
FileAction fa = (FileAction) ic.lookup("fileManager");
fa.test();
---------

any different than
<Statement 2>
---------
FileAction fa = new FileAction();
fa.test();
---------

Obviously the top one is already instantiated by the MBean. However at the moment I am a little confused by the difference in the two statements above. How does the first statement (if it indeed does) get around using file i/o from within an EJB? (assuming fa.test() copies the contents of one file and creates a new one).

Does the second statement also get around this. Or do neither of them? Do I need to try another way. Although I should add that it does work at the moment using JNDI the way I want it too and does not have any problems deploying or running.

I am currently using 3.0.6 would I get errors when deploying on 3.2.x or 4.0?


Thanks
Mat

[jonlee]

Essentially, the object that performs the file I/O should not be created within the EJB container. Ideally, some might say the file I/O establishment should also not be performed in the container - opening and closing the connection is performed outside the container.

So you have a file connection object factory that receives a request from the EJB for a file connection object. You manufacture the object (outside the container), establish the connection to the file and pass the object to the EJB. The EJB does it's work and signals it has finished (by returning the object). The return of the object involves clean-up such as closing the file connection - performed outside the container.

The difference in the two conditions you provide is that you are instantiating the object within the container in the second instance - however, you might not handle the cleanup so well in your implementation as there is no explicit return of the object so to speak.

You might want to consider the Pool implementation (source branch called pool) - provided in the JBoss source. It is a good example of a managed object with explicit external manufacture and explicit return. You probably don't want all the pooling aspects, but the factory has the important features for your instance.

[blackers]

Thanks for your help on this one Jon. In the end I used org.apache.commons.pool as I could not find the org.jboss.pool.ObjectPool etc in any of the jar files that come with JBoss 3.0.6. I found it similar to the jboss implementation (at least for the features I needed). I downloaded the source as you reccomended and found it very helpful. I also determined that the pooling features could benefit my application.

Appreciate the help

Thanks
Mat

[jonlee]

Glad it worked for you. It shouldn't matter which example you use - just the JBoss one has the JBoss programming style heritage.

The actual classes for the object pool are no longer included in the binary distributions - from 3.0.x on. However, it exists in the source - probably as an example implementation. Since it extends the ServiceMBean and the object pool implementation is self-contained, it makes a nice, complete, non-trivial example. The built JAR is called jboss-pool.jar and would live in the server/instance/lib directory. This information is just in case anyone reading this wonders what we are talking about.

But, as I said, as long as you had an example for implementation that is understandable - that was the real objective.