Bob Schellink [26/Mar/08 03:01 AM] fix checked in for 1.5M1 and 1.4.1

Malcolm Edgar [26/Mar/08 09:01 AM] How does this scenario work. Tomcat is configured not to unpack WAR files, how will he click resources be made available? regards Malcolm Edgar

Bob Schellink [26/Mar/08 09:23 AM] If a WAR is not unpacked deployment cannot work. The war itself must be self contained. In other words everything the war needs must already be available in the war. Since the developer or server admin decided not to unpack wars, they will have to include everything in the WAR manually. Thus their WAR must include the "click" dir with all resources *before* packing up their war. There is not much Click can do about it since getRealPath() will return null. This is compliant with the Servlet Spec as well. ServletContext#getRealPath states:     "The real path returned will be in a form appropriate to the computer and operating system on which the servlet container is running, including the proper path separators.     This method returns null if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive)." The best we can do is FAQ on this topic. BTW the problem this issues tries to fix is that Click tried to deploy the files to the getRealPath("/") directory even when WAR was not unpacked. If the WAR is not unpacked getRealPath("/") returns null. Click then deployed to this null directory. In my case this null directory ended up under the bin folder:     c:\ apps \ java \ tomcat-6.0.13 \ bin \ null \ ...

Andre Bremer [26/Mar/08 09:52 AM] Perhaps a click "main" method to deploy Click resources would be useful for build scripts like ANT or even Maven ;) Making it easier to build the whole application without a container setup. If someone writes the "main" method I'll help the Maven plugin goal (Perhaps even the Ant task) vyoman

Ahmed Mohombe [26/Mar/08 09:57 AM] > Since the developer or server admin decided not to unpack wars, > they will have to include everything in the WAR manually. > Thus their WAR must include the "click" dir with all resources > *before* packing up their war. IMHO this is too much trouble if one considers the 3rd party controls too. A better approach would be to have a "predeploy" ant task, that the developer could use, and that would call the "onDeploy" for all pages and controls, ensuring correct resources(just before packaging the WAR). Click.xml would also need a predeployed="true" parameter (default false), to know that it's pre-deployed, and not try to do it. IMHO this would be clean and simple for such scenarios. One could use the "predoploy" strategy to increase runtime startup performance too (not just for cases where the WAR won't be unpacked. Ahmed. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Click-development mailing list Click-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/click-development