This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 196158 - Run application client on Jboss finishes with error
Summary: Run application client on Jboss finishes with error
Status: RESOLVED WONTFIX
Alias: None
Product: javaee
Classification: Unclassified
Component: App Client (show other bugs)
Version: 7.0
Hardware: PC Linux
: P3 normal (vote)
Assignee: David Konecny
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-01 12:31 UTC by Martin Fousek
Modified: 2016-07-07 08:55 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Fousek 2011-03-01 12:31:26 UTC 
Product Version: NetBeans IDE Dev (Build 110301-9609b899e64d)
Java: 1.6.0_20; OpenJDK 64-Bit Server VM 19.0-b09
System: Linux version 2.6.35-25-generic running on amd64; UTF-8; en_US (nb)
AS: jboss-6.0.0.Final, jboss-5.0.1.GA

I'm not able to run application client on JBoss. There is possible to deploy the application which finishes successfully, but the run ends with:
run-deploy:
Unable to access jarfile /home/marfous/NetBeansProjects/ApplicationClient17/${client.jar}
Java Result: 1

The same error is there for JBoss 5 and JBoss 6 server.
Comment 1 Petr Hejl 2011-03-03 12:30:04 UTC 
This is no really a problem in jboss plugin.

In build script there is target -as-retrieve-option-workaround where client.jar is configured. But this target is executed only when there is a property j2ee.appclient.mainclass.args and no j2ee.clientName property. The case for jboss is there is j2ee.clientName so clinet.jar (used in many places) is not set at all.

This worked for me, but I'm not sure about its correctness:
    <target depends="-as-retrieve-option-workaround-args, -as-retrieve-option-workaround-name" name="-as-retrieve-option-workaround"/>  
    <target if="j2ee.appclient.mainclass.args" name="-as-retrieve-option-workaround-args" unless="j2ee.clientName">
        ... original target code ...
    </target>
    <target unless="j2ee.appclient.mainclass.args" name="-as-retrieve-option-workaround-name" if="j2ee.clientName">
        <property name="client.jar" value="${dist.dir}/${j2ee.clientName}"/>
        <sleep seconds="3"/>
    </target>

This is however not enough. There is also java.system.class.loader set to org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader in run-appclient macro. This will obviously lead to CNFE for jboss. When this is commented out the appclient finally runs ok on jboss.
Comment 2 David Konecny 2011-03-03 19:25:58 UTC 
AppClient deployment always targeted GlassFish only
Comment 3 rabbiaumair 2011-06-28 06:05:22 UTC 
@David Konecny: I am facing the exact same problem with JBoss 6.0.0 and NetBeans 7. Does this mean I cannot run the application client from NetBeans 7 if the application server is JBoss 6?
Comment 4 David Konecny 2011-06-28 19:27:48 UTC 
(In reply to comment #3)
> @David Konecny: I am facing the exact same problem with JBoss 6.0.0 and
> NetBeans 7. Does this mean I cannot run the application client from NetBeans 7
> if the application server is JBoss 6?

Unfortunately your conclusion is correct. AppClient deployment is server specific and it was never implemented for any other server than GF. The cause is in AppClient specification itself - it encourages each server to come up with their own deployment story.
Comment 5 Martin Balin 2016-07-07 08:55:59 UTC 
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss