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 [email protected]
