[wolfgangknauf]

Carefully read the spec: "supported for the application client main class" ;-).

If you declare your injected EJBs as "public static" variables in the main class, you can access them from anywhere inside your client app.

Best regards

Wolfgang

[alrubinger]

Jaikiran, you give a good example of why the spec dictates the fields must be injected into static members. But it's OK to criticize something for being stupid.

"bcn" wrote:
In real-world application that would make it almost useless.

Yep.

Imagine if MC or Spring or any injection container limited you in this regard. The difference is whether your object is managed or not; if you create your own objects, they're not managed and you can't expect injection. If you get it from a container or other lookup store, then that's another story.

I've never liked Application Clients as they are. In addition to these programmatic limitations with injection into the Main class (which completely destroys good program design), you're limited to obtaining services from only one host.

S,
ALR

[sanjuro]

I'm trying this example as documented on the http://www.jboss.org/community/docs/DOC-12835 on JBoss 5.0.0.GA. However I can not get it to work.

Is the Wiki entry no longer up-to-date? Or is something wrong with my configuration?

[jaikiran]

What exactly is not working? You will have to provide us more details about what you are doing and what is the issue. I know there is a very minor change that i have to do that wiki, related to classpath, for JBoss-5.0 GA. However that change, as far as i know, should not stop it from working.

[sanjuro]

I found the problem: Stateless.ear is working perfectly, however only if you JBOSS_HOME does not contain any spaces on Windows.

Haven't figured out why yet. Everything else seems to work just fine with spaces in the path.

[jaikiran]

"Sanjuro" wrote:
however only if you JBOSS_HOME does not contain any spaces on Windows.

It is always recommeded not to install JBoss (or even Java) in a folder contain a space in the path name. You sometimes run into very weird issues when you install in such folders.

[skajotde]

I think JBoss try resolve speces issues, like here https://jira.jboss.org/jira/browse/JBAS-5796.

[bcn]

For those interested:
I tried it and it works perfectly in the described way on the same host.

Next step was to try it from a remote computer, as an application client usually is not installed on the server. So I copied all jars and replaced the jndi IP, but I got:

2009-02-12 10:51:35,821 WARN [main][org.jboss.client.AppClientMain] - <Failed to
 launch using: org.jboss.ejb3.client.ClientLauncher>
java.lang.IllegalStateException: Incompletely deployed:

*** DEPLOYMENTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual S
tate}
ClientContainer -> null{Installed:** UNRESOLVED JndiDepends: 'ConverterClient/me
taData' **}

 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalVa
lidate(AbstractKernelDeployer.java:290)
 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(A
bstractKernelDeployer.java:174)
 at org.jboss.ejb3.client.ClientLauncher.validate(ClientLauncher.java:471
)
 at org.jboss.ejb3.client.ClientLauncher.launch(ClientLauncher.java:269)
 at org.jboss.ejb3.client.ClientLauncher.launch(ClientLauncher.java:174)
 at org.jboss.ejb3.client.ClientLauncher.launch(ClientLauncher.java:138)
 at org.jboss.client.AppClientMain.main(AppClientMain.java:134)

Using jBoss 5.0.0 GA.

One thing I noticed was that the class path does not contain the client classes or the client.jar. That means all classes are fetched from the server?? When I included the client class and its dependencies in the class path of the launcher script, it worked also on a remote machine.

[xmedeko]

Hi,

I am a beginner with JEE. I don't understand, why examples here http://www.jboss.org/community/docs/DOC-12835 have a class with main method in the EAR file. As I understand, the EAR is deployed on the server, but one usually need to deploy clinets on the other machines. Also, the client would need to access the remote interface. So, I thing there should be 3 jars: one for a server, one for a client and a shared jar with interfaces and shared objects. Is that right?

[wolfgangknauf]

Hi,

I think you are basically right. But the server needs some parts of the application client module to prepare the Environment Naming Context (for JNDI lookups or for injection preparation), so it would be quite hard to build different jars for the server side of the client and the client side.
Some IDEs provide the option to use client JARs for the Bean interfaces, which is half the way. I know that Eclipse can do this.
But I don't know of an option to create some "deployable client module artifact".

If there are further questions, start a new thread.

Hope this helps

Wolfgang

[henk53]

"ALRubinger" wrote:
Jaikiran, you give a good example of why the spec dictates the fields must be injected into static members. But it's OK to criticize something for being stupid.

"bcn" wrote:
In real-world application that would make it almost useless.

Yep.

Imagine if MC or Spring or any injection container limited you in this regard. The difference is whether your object is managed or not; if you create your own objects, they're not managed and you can't expect injection. If you get it from a container or other lookup store, then that's another story.

Indeed, the thing is that the main class in a client application is really the only place where a class is loaded and a method is called by the runtime, so this also basically makes it the only candidate for an injection target. Unless, you would accept to run your application in a modified JVM where the new operator is somehow intercepted by the client container. Personally I wouldn't mind that, but I guess a lot of people would object to that.

I've never liked Application Clients as they are. In addition to these programmatic limitations with injection into the Main class (which completely destroys good program design), you're limited to obtaining services from only one host.

I'm not sure if it's really limiting. The idea seems to be to separate your application code from details of where the AS is located. If you inject your main class with a factory EJB that serves to give you other EJBs at any location in your client code that you desire, than I don't really see the problem with that.

Something like:

public class MainClass {

 @EJB
 public EJBFactory factory;

 public static void main(String args[]) {
 MyApp theApp = new MyApp();
 theApp.run();
 }
}

...

public class SomeClass {

 public void SomeMethod() {
 EJBFooBean bean = MainClass.factory.getEJBFooBean();
 bean.invokeBar(); // results in RMI class to AS
 }
}

There's always room for improvement of course, and being able to use @EJB EJBFooBean in SomeClass would be superb, but for the time being the pattern shown above seems to do the trick.

[rafaelri]

Hi Wolfgang

I tried your example but I could only make it work when the queue was deployed inside the application. Everytime I tried to have the queue in a -service.xml file directly on deploy folder I got a RuntimeException complaining as the target object was not bound.

Is it the correct behaviour?

regards,
Rafael Ribeiro

[wolfgangknauf]

Hi Rafael,

I saw your comment on the "How to use an application client..." wiki entry, but unfortunately currently I don't have any time to start up my JBoss :-(.

Did you verify that your Queue exists? Does JNDIView show it? How does your "-service.xml" file look like?

Is the error message on deploy or at runtime?

Best regards

Wolfgang