Enterprise Client Community

Wanted to switch to *.ccwebstart to launch our application, to gain access to the new cookie handling.

Problem is: class AppletStarter seems to be rather strict on how captain casa is installed.

In our case the web application is available under
host:port/name1/name2, and apparently AppletStarter assumes that it is something like host:port/anyname, and gets mixed up by the additional directory level.

Could this be made more flexible somehow?
Manfred

Yes, the web start starter (at least the default way of starting) is more restrictive: because the resolution is done in jnlpservlet on server side (and not through the client context).

Please check the Developer's Guide: there's a documentation on webstart (Intergation Scenarios, Webstart/JNLP the codebase Parameter) that tells more details + how to solve.

Björn

Sorry but I could not extract too useful information solving the problem stated, except for the hint that we should probably implement this stuff by ourselves.

Which means duplicating the cookie stuff, and also face re-implementation of possible future improvements of your class.

But then the most important thing here was your idea how to deal with the cookies (thanks for that...), the implementation is just a few lines of code, so it is not something to worry about too much.

Manfred

Hi,

from my perspective the following information is useful:

(.) the codebase attribute is resolved at Tomat side
(.) you can define an own ".ccwebstart"-template-file in which you can explicitly define an own codebase (chapter before)
(.) you can append the name of the .ccwebstart-template-file to the initiating URL:

I.e.: http://xxxx/xxxx/xxxx.ccwebstart?cctemplate=template1.jnlp, and template1.jnlp being defined like:

Code:

 <?xml version="1.0" encoding="utf-8"?>
 <jnlp spec="1.0" codebase="HERE_THE_OWN_CODEBASE" href="$$name">
 <information>
 <title>CaptainCasa Enterprise Client</title>
 <vendor>CaptainCasa GmbH</vendor>
 <icon href="eclnt/images/splash.png" kind="splash"/>
 </information>
 <security>
 <all-permissions />
 </security>
 <resources>
 <j2se version="1.6+" java-vm-args="-esa -Xnoclassgc"/>
 <jar href="eclnt/lib/eclnt.jar"/>
 </resources>
 <application-desc main-class="org.eclnt.client.page.PageWebStart">
 <argument>HERE_THE_OWN_CODEBASE</argument>
 <argument>faces/@@pagename@@</argument>
 </application-desc>
 </jnlp>

Björn

Hi,
well - we already hacked our own class, and we might stick to it since we are likely to tweak other things as well.

But just to help make your implementation more robust here, lets further plunge into the details.

Lets use http://host:port/abc/def/jkl.ccwebstart as an example, with /abc/def being the root of the captain web application, and this directory contains a jkl.jsp file to be loaded.

problem is that (1) we do not have a globally fixed code base here, the dynamic way to obtain it is just fine, only it has to be done correctly (...but ok, we do handle such things using dynamic deployment elsewhere, so this could be circumvented...), and (2) this still does not produce the correct value in the pagename argument: This turns out to be

faces/def/jkl.jsp

when the

def

is already part of the code base, so this jsp is not found!

Have looked at your implementation and following comments sprung to my mind:

(1) the client jars are specified using a relative uri starting with eclnt (e.g. eclnt/lib/eclnt.jar), so the implementation clearly assumes that the directory of the request must be the root of the captain casa web application.

(2) as a consequence of this comes the specification that if the initial jsp page is in a subdirectory, this has to be provided using a dot notation instead of a slash (e.g. workplace.workplace.ccwebstart - as explained clearly in your documentation, although no motivation is given - and hopefully there are no dots somewhere else in the path).

(3) while this ensures that relative paths are resolved correctly from client point of view, the implementation of the servlet does not make any use of this. At a very early stage of processing all dots are replaced with slashes, and somewhere later, it tries to figure out where to split the url, using at one place the

second

slash, and somewhere else the

forth

. This is clearly bound to fail if anything is different from the usual installation scenario.

Taking into account what is explained in (1), it is both simpler and more flexible to take the split point as the last slashof the original url/uri, and once this is determined, this will yield the correct codebase argument, and, after replacing dots with slashes as a second step, the correct value for @@pagename@@.

While this fixes our queer configuration hope this does not mess up some other.

Manfred