Hi Claude, Claude Vedovini schrieb: > my problem currently is that not only UAT and production should use > the same binaries with different sling.home (under linux) but > developers are using windows, thus we cannot have one war for all and > this obviously complicates the build and is error prone for admins and > developers alike.
I understand. So you *don't* set the sling.home init-param and use the built-in default. > > a fact as well is that upgrading Sling could be as simple as dropping > a new war if I had not to unpack it. Exactly, don't touch the war ;-) > > I guess that now that each deployed sling servlet has it's own > subfolder under sling.home to store configuration to, then may be > overriding the sling.home from the system properties could be a good > idea. Since system properties apply to the whole VM, multiple sling web applications deployed to the same servlet container would then use the same sling.home system property, which will not work. For this reason, I removed support for setting sling.home as a system property for the Sling web application (it is only supported for the sling standalone application). In general system properties are fine for standalone applications but for web applications it is a bit more complicated and I am not sure, whether using system properties to configure web applications is a good thing. Regards Felix > > my 2cts > Claude > > On Sun, Jun 7, 2009 at 12:09 PM, Felix Meschberger<fmesc...@gmail.com> wrote: >> Hi, >> >> Claude Vedovini schrieb: >>> Hi all, >>> >>> I use the sling web app on jBoss and I have issue with the location of >>> the sling home folder. >>> >>> >From what I read in [1] it seems one can setup the sling.home property >>> either using the sling.property or the web.xml file, both located >>> inside the sling war file, am I right? >> For the Sling Web app, the sling home folder is set through the >> sling.home init-property of the Sling Servlet or the Sling Servlet Context. >> >> If neither is set, the sling home folder is derived from the servlet >> context path prepended with "sling" and the path converted to a single >> name replacing slashes by underscores. >> >> E.g. sling.home for the web app at /sling/i1 is "sling/_sling_i1". >> >> This ensures sensible default values and prevents collisions if the >> sling web app is installed multiple times in the same container. >> >>> If so, how may I deliver an application that can be deployed on >>> different environments (test, UAT, prod) without repackaging the whole >>> stuff each time? >> If you don't really care, where your sling.home is, you might be happy >> using the default value. >> >> Otherwise, there is not currently another option that to repackage. >> >> If you have a good idea on how to prevent this, we are certainly >> open-ears ;-) >> >> Hope this helps. >> >> Regards >> Felix >> >
