NetBeans Forums

 FAQFAQ   SearchSearch   MemberlistMemberlist   RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
  

Enterprise app client, additional jars and Java web start: ClassNotFoundException
Goto page 1, 2  Next
 
Post new topic   Reply to topic    NetBeans Forums -> Java EE Users
View previous topic :: View next topic  
Author Message
dbritton



Joined: 02 Jul 2009
Posts: 20

PostPosted: Tue Oct 27, 2009 2:23 am    Post subject: Enterprise app client, additional jars and Java web start: ClassNotFoundException Reply with quote

Hi
I have an Enterprise Application Client that works with Java web start.
The client is running on glassfish v2 and being developed with Netbeand IDE 6.7. When I add the use of an additional jar in the app, I cannot start it via Java web start. I get NoClassDefFoundError. I cannot figure how to get access to the jnlp file to add the additional jar file. How do I add the new dependant jar file to the Enterprise Application Client?

I read that I might need glassfish v3 to get access to the jnlp file. For some reason the Application Properties for my Enterprise Application Client only lists "GlassFish V2" for server selections. Interesting, I have a Web Project that allows selection of all three applicaiton servers I have installed. How can I change an Enterprise Applicaiton Client from glassfish v2 to v3?

Thanks in advance,
David
Back to top
dbritton



Joined: 02 Jul 2009
Posts: 20

PostPosted: Tue Oct 27, 2009 1:26 pm    Post subject: Reply with quote

Am I barking up the wrong tree here !?!

Do I need to abort using an Enterprise Application Client and go to a
simple java application to get Java Web Start to work?
Back to top
Tim Quinn
Posted via mailing list.





PostPosted: Tue Oct 27, 2009 1:41 pm    Post subject: Enterprise app client and Java web start Reply with quote

dbritton wrote:
Quote:
Hi

I have an Enterprise Application Client that works with Java web start.

The client is running on glassfish v2 and being developed with Netbeand IDE 6.7. When I add the use of an additional jar in the app, I cannot start it via Java web start. I get NoClassDefFoundError. I cannot figure how to get access to the jnlp file to add the additional jar file. How do I add the new dependant jar file to the Enterprise Application Client?



I read that I might need glassfish v3 to get access to the jnlp file. For some reason the Application Properties for my Enterprise Application Client only lists "GlassFish V2" for server selections. Interesting, I have a Web Project that allows selection of all three applicaiton servers I have installed. How can I change an Enterprise Applicaiton Client from glassfish v2 to v3?



Thanks in advance,

David




Back to top
Tim Quinn
Posted via mailing list.





PostPosted: Tue Oct 27, 2009 1:48 pm    Post subject: Enterprise app client and Java web start Reply with quote

Hi, David.

dbritton wrote:
Quote:
Hi

I have an Enterprise Application Client that works with Java web start.

The client is running on glassfish v2 and being developed with Netbeand IDE 6.7. When I add the use of an additional jar in the app, I cannot start it via Java web start. I get NoClassDefFoundError. I cannot figure how to get access to the jnlp file to add the additional jar file. How do I add the new dependant jar file to the Enterprise Application Client?

As you mentioned, GlassFish v2 does not provide access to the generated
JNLP for customization. But for this use case you should not need it.
If you build an EAR that contains the app client and also the library
JAR and you package the library JAR in the EAR's /lib directory (or some
other directory if you specify the <library-directory> setting in
application.xml) then GlassFish should make that JAR available
automatically to the app client, even when launched using Java Web Start.

From what you described it sounds as if adjusting the packaging might
resolve this.

Quote:


I read that I might need glassfish v3 to get access to the jnlp file.
Support for influencing the generated JNLP will probably not be present
until v3.1, although it's possible that an "early access" update between
v3 and v3.1 could contain an early look at it. We just had too much on
our list to get to everything.

- Tim
Quote:
For some reason the Application Properties for my Enterprise Application Client only lists "GlassFish V2" for server selections. Interesting, I have a Web Project that allows selection of all three applicaiton servers I have installed. How can I change an Enterprise Applicaiton Client from glassfish v2 to v3?



Thanks in advance,

David




Back to top
dbritton



Joined: 02 Jul 2009
Posts: 20

PostPosted: Wed Dec 02, 2009 2:36 pm    Post subject: Reply with quote

Tim,
Thanks for you answer. I followed your advice and got it working!!!!

Regards,
Dave
Back to top
dbritton



Joined: 02 Jul 2009
Posts: 20

PostPosted: Thu Dec 17, 2009 4:35 pm    Post subject: Reply with quote

Ok, now I'm trying to upgrade to glassfish v3. Either by changing the
existing v2 app that works or creating a new Enterprise Application with
an Enterprise Application Client to use v3 right off, I get the following
exception when trying to use Java Web Start:

com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://localhost:10050/___JWSappclient/___system/___dyn/___system.jnlp


Any help would be apprectiated.
David
Back to top
Tim Quinn
Posted via mailing list.





PostPosted: Thu Dec 17, 2009 4:47 pm    Post subject: Re: Enterprise app client, additional jars and Java web start: ClassNotFoundException Reply with quote

Hi, David.

Sometimes during a failed Java Web Start launch the dialog box has tabs
for another exception. Please check there to see if there's more
information. (It's probably a file not found error, but let's be sure.)

Also, please check the server.log for any errors that might have been
recorded either during deployment of the application or when you tried
to launch the client.

- Tim

dbritton wrote:
Quote:
Ok, now I'm trying to upgrade to glassfish v3. Either by changing the
existing v2 app that works or creating a new Enterprise Application with
an Enterprise Application Client to use v3 right off, I get the following
exception when trying to use Java Web Start:

com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://localhost:10050/___JWSappclient/___system/___dyn/___system.jnlp


Any help would be apprectiated.
David




Back to top
dbritton



Joined: 02 Jul 2009
Posts: 20

PostPosted: Thu Dec 17, 2009 6:45 pm    Post subject: Reply with quote

Tim,
Thanks for the quick response. I followed up on you leads and found an error message in the glassfish log not being able to access a file that started with "C:\Program%20Files". Seeing the other thread and your comments, I removed glassfish (which was installed with the netbeans bundle) and reinstalled in c:\glassfishv3.

I now get a little further. The java console shows:
#### Java Web Start Error:
#### Found unsigned entry in resource: file:/C:/glassfishv3/glassfish/domains/domain1/generated/xml/JWSv3/JWSv3-app-client_jar/JWSv3-app-client.jar

How do I get past this?

Another observation is that when I have v3 selected I cannot "run" the app-client by right clicking on it and selecting run. I can select debug and it will run. netbeans spits out the following error:
org.glassfish.appclient.client.acc.UserError: ACC007: The app client directory W:\u\WebSpun\src\java\netbeans\JWSv3\JWSv3-app-client does not contain a manifest; the app client container cannot process it.
Java Result: 1

Should I be able to "run" the client like I can in v2?

Thanks David
Back to top
dbritton



Joined: 02 Jul 2009
Posts: 20

PostPosted: Thu Dec 17, 2009 7:01 pm    Post subject: Reply with quote

Here is the server log file from deploying the app. The ejb jar is empty and I remember getting this error on v2.

Dave


[#|2009-12-17T13:58:10.490-0500|INFO|glassfishv3.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=30;_ThreadName=http-thread-pool-4848-(1);|Loading application JWSv3#JWSv3-war.war at JWSv3-war|#]

[#|2009-12-17T13:58:10.490-0500|INFO|glassfishv3.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=30;_ThreadName=Thread-1;|Loading application JWSv3#JWSv3-war.war at JWSv3-war|#]

[#|2009-12-17T13:58:10.490-0500|INFO|glassfishv3.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=30;_ThreadName=http-thread-pool-4848-(1);|Loading application JWSv3#JWSv3-war.war at JWSv3-war|#]

[#|2009-12-17T13:58:10.491-0500|WARNING|glassfishv3.0|javax.enterprise.system.container.appclient.org.glassfish.appclient.server.core.jws|_ThreadID=30;_ThreadName=Thread-1;|ACDEPL112: Error attempting to process extensions from the manifest of JAR file C:\glassfishv3\glassfish\domains\domain1\generated\xml\JWSv3\JWSv3-app-client_jar\JWSv3-ejb.jar; ignoring it and continuing
java.io.FileNotFoundException: C:\glassfishv3\glassfish\domains\domain1\generated\xml\JWSv3\JWSv3-app-client_jar\JWSv3-ejb.jar (The system cannot find the file specified)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:114)
at java.util.jar.JarFile.<init>(JarFile.java:133)
at java.util.jar.JarFile.<init>(JarFile.java:97)
at org.glassfish.appclient.server.core.jws.ExtensionFileManager.findExtensionTransitiveClosure(ExtensionFileManager.java:264)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.processExtensionReferences(JavaWebStartInfo.java:331)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.startJWSServices(JavaWebStartInfo.java:308)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.access$100(JavaWebStartInfo.java:96)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo$1.run(JavaWebStartInfo.java:254)
at org.glassfish.appclient.server.core.jws.JavaWebStartState.transition(JavaWebStartState.java:84)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.start(JavaWebStartInfo.java:250)
at org.glassfish.appclient.server.core.AppClientServerApplication.start(AppClientServerApplication.java:134)
at org.glassfish.appclient.server.core.AppClientServerApplication.start(AppClientServerApplication.java:126)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:126)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:241)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:236)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:339)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1224)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:365)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:8Cool
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
|#]

[#|2009-12-17T13:58:11.495-0500|INFO|glassfishv3.0|javax.enterprise.system.container.appclient.org.glassfish.appclient.server.core|_ThreadID=30;_ThreadName=Thread-1;|ACDEPL103: Java Web Start services started for the app client JWSv3/JWSv3-app-client.jar (contextRoot: /JWSv3/JWSv3-app-client)|#]

[#|2009-12-17T13:58:11.506-0500|INFO|glassfishv3.0|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=30;_ThreadName=Thread-1;|JWSv3 was successfully deployed in 1,172 milliseconds.|#]
Back to top
Tim Quinn
Posted via mailing list.





PostPosted: Thu Dec 17, 2009 7:30 pm    Post subject: Re: Enterprise app client, additional jars and Java web start: ClassNotFoundException Reply with quote

Hi, again, David.

dbritton wrote:
Quote:
Tim,
Thanks for the quick response. I followed up on you leads and found an error message in the glassfish log not being able to access a file that started with "C:\Program%20Files". Seeing the other thread and your comments, I removed glassfish (which was installed with the netbeans bundle) and reinstalled in c:\glassfishv3.

OK, some progress!
Quote:
I now get a little further. The java console shows:
#### Java Web Start Error:
#### Found unsigned entry in resource: file:/C:/glassfishv3/glassfish/domains/domain1/generated/xml/JWSv3/JWSv3-app-client_jar/JWSv3-app-client.jar

How do I get past this?


As you might know, GlassFish needs to sign certain JARs from the app if
they were not signed before packaging. It's one of these auto-signed
JARs that seems to be a problem.

First, if you haven't already done so please double-check that the
deployment after you relocated the installation directory is successful,
without any errors.

Next, please try the following: Open the Java control panel (I see
you're on Windows, so use Start->Control Panel, then double-click on the
Java icon. In the General tab is a section for Temporary Internet
Files. Click View... and you'll see a list of the files which Java Web
Start has cached locally. IIRC in the upper left should be a drop list
showing Applications and Resources as choices. Select Applications and
then find the entry for your app client and delete it (select it and
then press the Delete key or click the Delete button - a red X in the
toolbar across the top). Then change to the Resources view and find any
JARs particular to your app and delete them also. (All the GlassFish
system JARs are probably OK and you can probably leave them there.)

Then try launching the app client again. That might help.

Another useful experiment might be to try launching your client from
outside NetBeans, using either a browser or the javaws command.
(Double-check the context-root to use for launching this way; it's
displayed as the app is loaded during deployment and app server
restart.) That might help us narrow down whether we have problems on
the NetBeans side or the GlassFish side.
Quote:
Another observation is that when I have v3 selected I cannot "run" the app-client by right clicking on it and selecting run. I can select debug and it will run. netbeans spits out the following error:
org.glassfish.appclient.client.acc.UserError: ACC007: The app client directory W:\u\WebSpun\src\java\netbeans\JWSv3\JWSv3-app-client does not contain a manifest; the app client container cannot process it.
Java Result: 1

Should I be able to "run" the client like I can in v2?

I believe that's the intent. I'm not very familiar with the NetBeans
support for launching the app client directly. Someone else on the list
might be able to shed more light on that part.

One possible difficulty might be that if W: is a network drive. In that
case there might be some operations that are not working as expected as
far as reading that app client. It might be interesting to know if that
is a network drive what happens if you try using a local drive.

- Tim
Back to top
dbritton



Joined: 02 Jul 2009
Posts: 20

PostPosted: Thu Dec 17, 2009 7:34 pm    Post subject: Reply with quote

I don't know what happened but I'm back to this Sad

java.io.FileNotFoundException: http://localhost:8081/___JWSappclient/___system/___dyn/___system.jnlp

I got rid of the above WARNING by unchecking the JWSv3-ejb.jar "package" checkbox inder the JWSv3-app-client properties->library.

In the glassfish install dir under I have
domain1->java-web-start->__system
Back to top
dbritton



Joined: 02 Jul 2009
Posts: 20

PostPosted: Thu Dec 17, 2009 8:17 pm    Post subject: Reply with quote

Tim,

I've checked and the app is being installed in the new glassfish dir.

I checked the java control panel and removed the Temporary Internet Files (I had keep temp files unchecked,
I unchecked it to do your recommendations). No help. Still get

java.io.FileNotFoundException: http://localhost:8081/___JWSappclient/___system/___dyn/___system.jnlp

I can run the client from outside of Netbeans. The client is a simple test
clinet hat has one JFrame with two components on it. I used netbeans to
create the EA with an EAC. Added a JFrame with a label and a button on it.
Modified the war index.jsp to have a link to the clinet app via JWS.

I have done the same experiment on a laptop. Dirve C only. (I haven't moved glassfish install there yet). Same result.

The W: drive is a local data drive on my system, not a Network dirve.

When I deploy the App "JWSv3" (Jave Web Start v3 test), the
domain1->generated>xml->JWSv3 directory is created. It has an empty "signed" subdirectory and three jar files in it:
JWSv3-app-Client.jar
JWSv3_app-clientClient.jar
JWSv3Client.jar

The naming convention seems odd to me.

Regards,
David
Back to top
dbritton



Joined: 02 Jul 2009
Posts: 20

PostPosted: Thu Dec 17, 2009 9:23 pm    Post subject: Reply with quote

Tim,
I created a new domain under glassfish v3. If I run under that new
domain, I get the unsigned exception.

com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: file:/C:/glassfishv3/glassfish/domains/webspunprime/generated/xml/JWSv3/JWSv3-app-client_jar/JWSv3-app-client.jar

If I run under the old one, I get the FileNotFound for System.jnlp.
If I change domains, I screw up the new domain and start to get the
FileNotFound exception. By deleting the new domain and then recreating
it, I can get to the unsigned exception.

Dave
Back to top
Tim Quinn
Posted via mailing list.





PostPosted: Thu Dec 17, 2009 9:59 pm    Post subject: Re: Enterprise app client, additional jars and Java web start: ClassNotFoundException Reply with quote

Sorry this is such a struggle.

dbritton wrote:
Quote:
Tim,

I've checked and the app is being installed in the new glassfish dir.

I checked the java control panel and removed the Temporary Internet Files (I had keep temp files unchecked,
I unchecked it to do your recommendations). No help. Still get

java.io.FileNotFoundException: http://localhost:8081/___JWSappclient/___system/___dyn/___system.jnlp

The default http listener port for GlassFish is 8080, but of course
that's configurable and perhaps you've changed it.


Quote:
I can run the client from outside of Netbeans.
Is this using the appclient command or launching using Java Web Start or
clicking on the link in your index.jsp (or multiple of the above)?

If you can launch using Java Web Start from outside NetBeans - either
using the javaws command or using a browser - then somehow there's a
NetBeans issue.
Quote:
The client is a simple test
clinet hat has one JFrame with two components on it. I used netbeans to
create the EA with an EAC. Added a JFrame with a label and a button on it.
Modified the war index.jsp to have a link to the clinet app via JWS.

I have done the same experiment on a laptop. Dirve C only. (I haven't moved glassfish install there yet). Same result.

The W: drive is a local data drive on my system, not a Network dirve.

OK.
Quote:
When I deploy the App "JWSv3" (Jave Web Start v3 test), the
domain1->generated>xml->JWSv3 directory is created. It has an empty "signed" subdirectory and three jar files in it:
JWSv3-app-Client.jar
JWSv3_app-clientClient.jar
JWSv3Client.jar

The naming convention seems odd to me.
I agree (although I'm used to it by now!), but there is a method to the
madness. Briefly, GlassFish generates at least two JARs for a client
nested in an EAR. (I'm sorry if you mentioned this earlier, but it
looks as if you have an EAR containing one app client.)

The JWSv3Client.jar name is derived from (appName)Client.jar and is
consistent with the naming convention from past releases of GlassFish.
(As much as we can, we use the same files for Java Web Start support as
for appclient support and preserving that name was essential to
preserving backward compatibility with earlier releases.) This JAR's
manifest points to the various xxxClient.jar files (only one in your
case) and also contains any generated class or resource files that apply
to the whole EAR (such as WSDLs) that are needed on the client side.

The JWSv3-app-client.jar is created because Java Web Start deals only
with JARs and you are doing a directory deployment via NetBeans. (It's
on our enhancement list to avoid generating this particular JAR because
part of the advantage of directory deployment is to be faster by
avoiding the need to package your files into JARs and EARs.)

JWSv3_app-clientClient.jar is generated and points to the
JWSv3-app-client.jar and also refers to the JWSv3Client.jar. This is
the JAR that's actually launched by Java Web Start, although normally
you won't need to know that.


OK, about the signed/ directory... The auto-signed files will reside
there, and GlassFish creates each signed JAR when it receives the first
request for that file. (The files need to be signed because app clients
- and the ACC itself - need to run with elevated permissions and Java
Web Start insists on signed JARs to permit that.) That directory is
empty so far because, for the problems you've been encountering,
GlassFish has not yet received a specific request for one of the JARs
that needs to be signed.

Sorry for the long message. The point is that if you are able to launch
successfully from outside NB - and if I understand correctly you can -
then there's something not quite right with how NB is trying to start
the client. We'll need to rely on the folks more familiar with the NB
GlassFish support for help with that.

Vince, any suggestions?

- Tim
Back to top
dbritton



Joined: 02 Jul 2009
Posts: 20

PostPosted: Fri Dec 18, 2009 1:45 am    Post subject: Reply with quote

Tim,


I changed the http listerer to port 8081. Laptop is installed on default port of 8080 and has same symptom.

When I said that I could run the client outside of netbeans, I meant by using "java" to run the client. I tried using javaws and I get the same result. So I don't think there is a Netbeans issue.

Thanks for the explaintion on the directories.

Quote:

OK, about the signed/ directory... The auto-signed files will reside
there, and GlassFish creates each signed JAR when it receives the first
request for that file. (The files need to be signed because app clients
- and the ACC itself - need to run with elevated permissions and Java
Web Start insists on signed JARs to permit that.) That directory is
empty so far because, for the problems you've been encountering,
GlassFish has not yet received a specific request for one of the JARs
that needs to be signed


I thought I had bee requesting those jars via the browser and now javaws.
It seems like glassfish is not signing them and moving them to the signed dir automatically.

Here is a copy of the launch file

Quote:

<?xml version="1.0" encoding="UTF-8"?>
<!--
* To change this template, choose Tools | Templates
* and open the template in the editor.
*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
*
* Copyright 1997-2009 Sun Microsystems, Inc. All rights reserved.
*
* The contents of this file are subject to the terms of either the GNU
* General Public License Version 2 only ("GPL") or the Common Development
* and Distribution License("CDDL") (collectively, the "License"). You
* may not use this file except in compliance with the License. You can obtain
* a copy of the License at https://glassfish.dev.java.net/public/CDDL+GPL.html
* or glassfish/bootstrap/legal/LICENSE.txt. See the License for the specific
* language governing permissions and limitations under the License.
*
* When distributing the software, include this License Header Notice in each
* file and include the License file at glassfish/bootstrap/legal/LICENSE.txt.
* Sun designates this particular file as subject to the "Classpath" exception
* as provided by Sun in the GPL Version 2 section of the License file that
* accompanied this code. If applicable, add the following below the License
* Header, with the fields enclosed by brackets [] replaced by your own
* identifying information: "Portions Copyrighted [year]
* [name of copyright owner]"
*
* Contributor(s):
*
* If you wish your version of this file to be governed by only the CDDL or
* only the GPL Version 2, indicate your decision by adding "[Contributor]
* elects to include this software in this distribution under the [CDDL or GPL
* Version 2] license." If you don't indicate a single choice of license, a
* recipient has the option to distribute your version of this file under
* either the CDDL, the GPL Version 2 or to extend the choice of license to
* its licensees as provided above. However, if you add GPL Version 2 code
* and therefore, elected the GPL Version 2 license, then the option applies
* only if the new code is made subject to such option by the copyright
* holder.
-->
<jnlp
spec="1.0+"
codebase="http://localhost:47762/___JWSappclient/___app/JWSv3"
href="___dyn/JWSv3-app-client.jarClient/___main.jnlp">
<information>
<title>JWSv3-app-client</title>
<vendor>Application Client</vendor>
<homepage href="${appclient.information.homepage.filepath}"/>
<description kind="one-line">JWSv3-app-client</description>
<description kind="short">JWSv3-app-client</description>

<offline-allowed/>
</information>

<security>
<all-permissions/>
</security>

<resources>

<!-- <java version="1.6+"
java-vm-args="-showversion -javaagent=glassfish/modules/gf-client.jar=mode=jws,${agent.args} " /> -->
<java version="1.6+" java-vm-args="" />

<!--
In v3, run the client facade as the main JAR. Eventually Java Web
Start might support the splash screen in the JAR.
-->
<jar href="JWSv3Client/JWSv3-app-clientClient.jar" main="true" />

<!--
If the client is part of an EAR then there will be an EAR-level
generated facade JAR file.
-->
<jar href="JWSv3Client.jar"/>

<!--
These next JARs will have been signed using the
deployer-specified alias, if specified, or the default domain alias.
Note that even though these are fetched within the code base of the
app, we do not sign these once for each app but reuse ones
signed with the same alias.
-->
<jar href="glassfish/modules/gf-client.jar"/>
<jar href="glassfish/modules/gf-client-module.jar"/>

<!--
Refer to extension JNLP documents which list other resources - JARs and JNLPs.

The system extension lists the JARs that are common to all apps. The
facade extension lists the generated facade JAR file for the client.
The client extension lists the client JAR. The library extension
lists JARs from the EAR application to which the client directly
or indirectly refers.
-->
<extension name="___system" href="http://localhost:47762/___JWSappclient/___system/___dyn/___system.jnlp"/>
<extension name="___client" href="___dyn/JWSv3-app-client.jarClient/___client.jnlp"/>

<extension name="libJars-s1as" href="___lib/client-libs-s1as.jnlp"/>

<property name="appclient.system.codebase" value="http://localhost:47762/___JWSappclient/___system"/>
<property name="appclient.is.jws" value="true"/>

<property name="agent.args" value="mode=jws,client=url=http://localhost:47762/___JWSappclient/___app/JWSv3/JWSv3Client/JWSv3-app-clientClient.jar,arg=-targetserver,arg=localhost:47719"/>

<property name="client.facade.jar.path" value="JWSv3Client/JWSv3-app-clientClient.jar"/>
<property name="full.app.codebase.path" value="http://localhost:47762/___JWSappclient/___app/JWSv3"/>
<!--
Properties specified on the request as query parameters (if any)
-->


<!--
Content normally read from files during an appclient script launch.
-->
<property name="sun-acc.xml.content" value="&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;

&lt;!--
Copyright 2004-2005 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
--&gt;

&lt;!--
Please remember to customize this file for your environment. The defaults for
following fields may not be appropriate.
- target-server name, address and port
- Property security.config in message-security-config
--&gt;

&lt;!DOCTYPE client-container PUBLIC &quot;-//Sun Microsystems Inc.//DTD Application Server 8.0 Application Client Container//EN&quot; &quot;http://www.sun.com/software/appserver/dtds/sun-application-client-container_1_2.dtd&quot;&gt;

&lt;client-container&gt;
&lt;target-server name=&quot;Io&quot; address=&quot;localhost&quot; port=&quot;47719&quot;/&gt;
&lt;log-service file=&quot;&quot; level=&quot;WARNING&quot;/&gt;
&lt;message-security-config auth-layer=&quot;SOAP&quot;&gt;
&lt;!-- turned off by default --&gt;
&lt;provider-config class-name=&quot;com.sun.xml.wss.provider.ClientSecurityAuthModule&quot; provider-id=&quot;XWS_ClientProvider&quot; provider-type=&quot;client&quot;&gt;
&lt;request-policy auth-source=&quot;content&quot;/&gt;
&lt;response-policy auth-source=&quot;content&quot;/&gt;
&lt;property name=&quot;encryption.key.alias&quot; value=&quot;s1as&quot;/&gt;
&lt;property name=&quot;signature.key.alias&quot; value=&quot;s1as&quot;/&gt;
&lt;property name=&quot;dynamic.username.password&quot; value=&quot;false&quot;/&gt;
&lt;property name=&quot;debug&quot; value=&quot;false&quot;/&gt;
&lt;/provider-config&gt;
&lt;provider-config class-name=&quot;com.sun.xml.wss.provider.ClientSecurityAuthModule&quot; provider-id=&quot;ClientProvider&quot; provider-type=&quot;client&quot;&gt;
&lt;request-policy auth-source=&quot;content&quot;/&gt;
&lt;response-policy auth-source=&quot;content&quot;/&gt;
&lt;property name=&quot;encryption.key.alias&quot; value=&quot;s1as&quot;/&gt;
&lt;property name=&quot;signature.key.alias&quot; value=&quot;s1as&quot;/&gt;
&lt;property name=&quot;dynamic.username.password&quot; value=&quot;false&quot;/&gt;
&lt;property name=&quot;debug&quot; value=&quot;false&quot;/&gt;
&lt;property name=&quot;security.config&quot; value=&quot;${security.config.path}&quot;/&gt;
&lt;/provider-config&gt;
&lt;/message-security-config&gt;
&lt;/client-container&gt;
"/>
<property name="appclient.login.conf.content" value="/* Copyright 2004 Sun Microsystems, Inc. All rights reserved. */
/* SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. */

default {
com.sun.enterprise.security.auth.login.ClientPasswordLoginModule required debug=false;
};

certificate {
com.sun.enterprise.security.auth.login.ClientCertificateLoginModule required debug=false;
};
"/>
<property name="message.security.config.provider.security.config"
value="&lt;!--
Copyright 2004 Sun Microsystems, Inc. All rights reserved.
SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
--&gt;
&lt;!--
This client side config file pairs with wss-server-config-1.0.xml on the server
and supports the following UseCases:
Usecase 1: Authentication by Protected UsernameToken
Usecase 3: Encrypted UsernameToken and MessageBody
Usecase 4: Response Encryption Key Learnt from Incoming Message

Certificate Alias Information :
1. A certificateAlias under the &lt;xwss:Encrypt&gt; element signifies the certificate
of the recipient of the message.
2. A certificateAlias under the &lt;xwss:Sign&gt; element signifies the certificate of the
sender.

NOTE:

1. the certificateAlias has the above meaning for all the Sign and Encrypt elements below
2. there are several Sign and Encrypt elements below and similarly several RequireSignature and
RequireEncryption elements. Which of them would be actually used at runtime will depend on
the AuthPolicy passed to the module.

For Example : if Auth-Source=Sender then only the &lt;xwss:UsernameToken&gt; elements will be used
and none of the &lt;xwss:Sign&gt; elements will be used.
If Auth-Source=Content then the &lt;xwss:Sign&gt; element will be used

3. The different variations of &lt;xwss:Encrypt&gt; elements in this configuration file are to accomodate
default encryption of the UsernameToken.

4. The actual certificate alias to be used for any Signature operation can be modified during AuthModule
initialization by setting the alias as the value of &quot;signature.key.alias&quot; property in the Module Options Map.
5. The actual certificate alias to be used for any Encrypt operation can be modified during AuthModule
initialization by setting the alias as the value of &quot;encryption.key.alias&quot;
jnlp file truncated after 10K


Sorry for the long response and misleading you about being able to launch
outside of NB. I cannot launch outside of NB.

Regards,
David
Back to top
Display posts from previous:   
Post new topic   Reply to topic    NetBeans Forums -> Java EE Users All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo