Enterprise Client Community

Hello,

we want to access the CC application by differnt ways.

(.) First as "module" in our own fatclient app. -> Works well.
(.) Second via Webstrart from our LAN network. Here we contact the Tomcat server directly from out LAN.
(.)Thrid via Webstart with an Apache Reverse Proxy in our DMZ, that routes the requests into our LAN.

Here is is a big problem. When we configure our proxy server, that simple HTML Traffic works well.

e.g. https://gate.geis-group.de/portal/gcc2/xyz.html like an LAN internal request to http://ccserver/gcc2/xyz.html

In this URLs, "gcc2" is our project name. "portal" in our external link is the indicator for our proxy to route to the cc server.

Okay, the client is loaded and we get the following message:

No connection to the server. Please check connection parameters:
Address: https://gate01.geis-group.de:80/portal/faces/basement/main.jsp

Our internal tomcat server runs only with http at port 80. Like you see, the client in the internet adds the port 80 to the https request. This is an contradiction in terms. As you know, https could not work with port 80!

The other problem is, in the request URL, he uses "portal" as project name, and removes the gcc2 folder level.

The second problem could maybe be solved with an mod_rewrite at the proxy server. But the port problem could not be handled by the proxy settings!

Maybe you can contact me by phone? Then I would be able to discribe it in an better way

Regards,
Michael Schmuck

Could you please look at my problem?

I can't provide our applications in the internet without having a solution for this problem.

Thanks,
Michael Schmuck

Oops, this message somehow got lost on our side. We just take a look...
Björn

Yes, we had a look... and found the reason. A patch will be available in the next update ("Monday"), but ask you to re-rest, because we did not test proxy with https.

Thanks, Björn

OK, in the meantime the update is available...

Please note:

(1.) the applet html page that is genereated through the CaptainCasa toolset can now be directly called via reverse proxy. Nothing to do here.

(2.) the webstart jnlp has to be adapter. Reason: normally the codebase is hard-coded into the jnlp page... CaptainCasa by default generates a sot-codebase-jnlp in which the codebase is dynamically passed back using a servlet on backend side (have a look into the jnlp: there are two occurances of "$$codepage". This soft-codebase generation always has "Tomcat in its mind", i.e. it does not know about reverse proxies in front of Tomcat.

As consequence you need to driectly speciy the codebase within the JNLP file. This is an example:

Code:

 <?xml version="1.0" encoding="utf-8"?>
 
 <jnlp spec="1.0" codebase="http://localhost:80/p8080/demos/" 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>http://localhost:80/p8080/demos/</argument>
 		<argument>faces/workplace/workplace.jsp</argument>
         <argument>loglevel=INFO</argument>
         <argument>clientlogfile=c:\temp\bbbbbbbbb.txt</argument>
     </application-desc>
 </jnlp>

Pay attention: the codepage needs to end with "/" and the page nees to start with "faces/".

Björn

Some comment: in the meantime the scenario is working. There were some hurdles in addition. I just summarize, maybe some of you come into similar scenarios.

Between Tomcat and Client there are a couple of systems, that do important things, but sometimes are not nice from Enterprise Client point of view ;-):

(.) One system in between was checking the http response to be a properly formed HTML page... i.e. it added <html> and <body> tags around the beautiful XML that is produced by our server side JSF components.

(.) the same system (at least we believe so...) converted <input .../> into <input ...> (no slash). Well in HTML this OK, but if this comes to the client, then the client tells you that there is an end tag missing.

(.) ...and the URL in the <form ...> tag was updatey as well.

It is always quite difficult in a complex scenario to identify this "between system", and even if so, then it is difficult to configure these systems properly (you need to start discussion with your sys admins etc. etc.). So , we adapted the Enterprise Client to react on mal-formed XML, html/body tags, etc.

Conclusion: when leaving the simple Tomcat scenario and going into the "real" scenarios, then it is very useful to exactly have a look into the repsonse coming from Tomcat, and compare it with the response actually arriving in the CaptainCasa client.

To monitor: switch on the client logging. Set loglevel=ALL then the whole http content will be written to log. To see the log switch on the monitoring in the Java system configuration (Java Console).

Björn