Re: sling.properties changes over time

[Marek Gilbert]

There are other reasons to change the sling.properties in the WAR and  
it sure would be nice to be able to see them when I re-deploy to an  
existing system.  I would still like to know how to manage  
sling.properties the best way.

I do appreciate your response though because specifically for access  
to foreign classes that is a better way and even better does solve my  
immediate problem.

Thanks very much!

--Gil

On Jul 16, 2009, at 1:21 AM, Carsten Ziegeler wrote:

Hi,

I can't comment on the sling.properties problem you're experiencing,  
but
I personally would rather go with fragment bundle exporting the  
packages
you need instead of using boot delegation.
This allows you to change the exported packages by redeploying your
fragment bundle, without restarting and fiddling around with property
files. It also allows you to version the exported packages.
And it makes your application independent from sling launchpad - so if
you want to run your sling application inside another osgi  
container, it
will still work - the sling.properties are launchpad proprietary.

HTH
Carsten

Marek Gilbert wrote:
Greetings,

I make use of bootdelegation to access classes from another framework
that runs outside of OSGi while running launchpad on JBoss.  I  
added the
initial list of packages to access to the
org.apache.sling.launcher.bootdelegation property of my
WEB-INF/sling-properties of my custom launchpad war and initially
everything worked quite well.

The problem I have is that I now need to change a JSP running in  
sling
to add a dependency on an additional package that I did not  
originally
put in my bootdelegation list.  When I change my
WEB-INF/sling.properties to add the new package and redeploy/restart,
sling still cannot see the package, as if I had not added it.

Reading through the Initial Configuration [1] section of the sling
documentation I understand that sling will read through all possible
sources of properties and then at step 11, and then write out
sling.properties.  It goes on to say that I can make subsequent  
changes
by changing the files in the launchpad folder through regular  
filesystem
operations without repacking the WAR.

It seems however that given the order of operations where the  
filesystem
overrides the WAR, that I cannot distribute changes to my
sling.properties file that way, though I'd like to since I have many
servers to change, and I can already deploy WARs across all of them.

I tried removing launchpad/sling.properties from the filesystem to  
see
if sling would regenerate it but the application fails pretty
spectacularly in this case so I'm guessing this isn't the way to  
prompt
sling to regenerate it's sling.properties.

So my questions are these:

 - Is there a way to disable the generation of sling.properties on  
the
filesystem?  i.e. is it possible to always go through steps 1-10  
without
doing step 11 of [1]?

 - Is there some way to ask sling to regenerate this sling.properties
file on the filesystem?

 - I'd like to be able to manage WAR deployment for the first time  
and
subsequent times the same way--barring either of the above do I  
need to
send out a copy of sling.properties separately each time just to be  
sure?

 - If so is there any harm in the in-war and on the filesystem
sling.properties being the same?  The on disk version appears to be a
fully expanded copy and it would be a shame to have to maintain  
changes
to two different sling.properties files.

Thanks very much for your help!

--Gil

[1]
http://sling.apache.org/site/configuration.html#Configuration-InitialConfiguration




--
Carsten Ziegeler
cziege...@apache.org