Hi Carsten

> On Dec 29, 2019, at 11:33 PM, Carsten Ziegeler <[email protected]> wrote:
> 
> In general we should do a clear cut, meaning that you can use the FM without 
> running code that also deals with the PM somewhere.

That’s fine with me - so I took everything out of the Launchpad Base and 
started the Feature JAR Launcher over.

> If we need new tooling for the FM, we should not merge it into the existing 
> tooling of the PM. This way we can at some point in time simply put the PM to 
> rest (might be years ahead).

Good to know.

> For example we tried to get all PM related code out of the slingfeature maven 
> plugin. For most of the maven tooling the slingfeature plugin is the 
> replacement for the slingstarter plugin.
> 
> We should probably keep starting/stopping out of that plugin and maybe create 
> a different one that deals just with that.

The issue with Starting / Stopping of a background service is not too difficult 
but it needs to be integrated with the thread that runs the application which 
in this case is the Feature Launcher’s Main class.
As of now the Feature Launcher is running the program as foreground program 
with a shutdown hook. I can run it in the background with ’nohup java -jar … &’ 
but that does not allow to manage the program,
To better management we need to have a tight integration between the Feature 
Launcher and the Background Thread controller. The ControlListener from the 
Launchpad Base seems to be a great fit and seems to require little adjustments 
to work in the Feature Launcher but that one needs to provide support for that 
but that should not be too difficult (Bootstrap / Launcher).

> 
> I'm not sure if we need launchpad-base at all, the feature launcher starts 
> directly the framework and we don't support webapps with the launcher. So 
> most of the code in launchpad base is not needed anymore.
> I would hope that we find some ootb code if we need something to run Sling as 
> a service.

Sling Starter does not provide support for a Unix / Windows Service so I am not 
concerned with that for now.

Thanks - Andy

> 
> Regards
> Carsten
> 
> On 28.12.2019 01:08, Andreas Schaefer wrote:
>> To illustrate this I created a simple test to showcase this. What it does is 
>> to use the Feature Main from the Launchpad Base and together with a Sling 12 
>> FM model it will launch Sling 12.
>> To build do the following:
>> 1. Checkout the Branch ‘feature/SLING-8955-Feature-Launcher-Support’ of 
>> sling-org-apache-sling-launchpad-base module
>> 2. Build it (it will create a version '6.0.2-3.0.0-SNAPSHOT’ so you can 
>> easily delete this from your local maven repo
>> 3. Checkout the latest sling-whiteboard
>> 4. Go to subfolder 'sling-jar-feature-launcher’
>> 5. Build it
>> 6. Go to target sub folder
>> 7. Launch sling with ‘java -jar 
>> org.apache.sling.feature.jar.launcher-0.0.1-SNAPSHOT.jar’
>> 8. Sling should launch and be available on http://localhost:8081 
>> <http://localhost:8081/> (done on purpose to check if I can change the port 
>> number)
>> In the Launchpad Base is tried both (different versions and supporting both 
>> PM and FM) approaches.
>> Cheers - Andy
>>> On Dec 27, 2019, at 3:16 PM, Andreas Schaefer <[email protected]> 
>>> wrote:
>>> 
>>> Hi
>>> 
>>> Running Sling as a Feature Model Application is not too difficult but I am 
>>> not sure where we want to put support for running Sling as a service 
>>> (start, stop, threaddumps) with the Feature Launcher.
>>> 
>>> I would think that it would be best to add this to the Feature Launcher to 
>>> make it easier to other projects than Sling to launch their FM projects as 
>>> a (background) service.
>>> 
>>> Then there is also the question on how to handle the migration to Feature 
>>> Models with respect to Sling Launchpad Base, Sling Starter and the 
>>> Slingstarter Maven plugin. Are we:
>>> - creating different modules
>>> - creating a higher version of the modules from where we do the cutover
>>> - adding support for both (PM and FM)
>>> 
>>> For example Launchpad Base version is currently: 6.0.2-2.6.37-SNAPSHOT. We 
>>> could create a new version (on a separate branch) like 6.0.2-3.0.0-SNAPSHOT 
>>> to develop the FM version on it. Eventually 6.0.2-2.6 will reach the end of 
>>> its life when PM is not supported anymore and 6.0.2-3.x is then becoming 
>>> the master branch only supporting FMs.
>>> 
>>> This only works when we retire PMs for good in a year or so.
>>> 
>>> Cheers - Andy Schaefer
> 
> -- 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> [email protected]

Reply via email to