You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Justin Edelson <ju...@gmail.com> on 2010/02/19 14:53:37 UTC

Re: read sling.home from a system property in webapp? (was Re: [jira] Commented: (SLING-1364) Inside a Bundle Project it is not possible to executed an embedded Test with LaunchPad, Cargo and Jetty)

On 2/19/10 4:39 AM, Felix Meschberger wrote:
> Hi,
> 
> On 19.02.2010 09:20, Bertrand Delacretaz wrote:
>> On Thu, Feb 18, 2010 at 10:50 PM, Felix Meschberger <fm...@gmail.com> wrote:
>>> ...we should fix the integration launching to use the standalone
>>> sling instead of the sling web app with cargo....
>>
>> Yes, that was my idea behind experimenting with maven-launchpad-plugin
>> this week.
>>
>> Haven't had time to go further, but that would drastically simplify
>> the integration testing pom, at the expense of a small bit of code to
>> launch the Sling runnable jar before running the tests.
> 
> Since there are phases before and after the integration-test phase to
> prepare and cleaup around integration tests this is possible from the
> maven POV. And the rest should probably be possible with either some
> existing maven plugin (jar runner or such a thing) or a fallback to some
> ant hackery....

If we're going to do this, let's do it right:
launchpad:start - starts the standalone app in a forked process
launchpad:stop - stops the standalone process
launchpad:run - runs the standalone app in the same process

Justin

P.S. Even with these goals, I still think we should be running
integration tests against the webapp version.

> 
> Regards
> Felix
>>
>> -Bertrand
>>


Re: read sling.home from a system property in webapp? (was Re: [jira] Commented: (SLING-1364) Inside a Bundle Project it is not possible to executed an embedded Test with LaunchPad, Cargo and Jetty)

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

On 19.02.2010 14:58, Bertrand Delacretaz wrote:
> On Fri, Feb 19, 2010 at 2:53 PM, Justin Edelson <ju...@gmail.com> wrote:
>> On 2/19/10 4:39 AM, Felix Meschberger wrote:
>>> ...Since there are phases before and after the integration-test phase to
>>> prepare and cleaup around integration tests this is possible from the
>>> maven POV...
> 
>> If we're going to do this, let's do it right:
>> launchpad:start - starts the standalone app in a forked process
>> launchpad:stop - stops the standalone process
>> launchpad:run - runs the standalone app in the same process

I just reallized, that for a long time now the Sling standalone
application launchar can be configured to listen on a socket to be
remotely terminated:

$ java -jar org.apache.sling.launchpad-6-SNAPSHOT-standalone.jar -h
usage: org.apache.sling.launchpad.app.Main [ start | stop | status ] [
-j adr ] [ -l loglevel ] [ -f logfile ] [ -c slinghome ] [ -a address ]
[ -p port ] [ -h ]
    start         listen for control connection (uses -j)
    stop          terminate running Sling (uses -j)
    start         check whether Sling is running (uses-j)
    -j adr        host and port to use for control connection in the
format '[host:]port' (default localhost:63000)
    -l loglevel   the initial loglevel (0..4, FATAL, ERROR, WARN, INFO,
DEBUG)
    -f logfile    the log file, "-" for stdout (default logs/error.log)
    -c slinghome  the sling context directory (default sling)
    -a address    the interfact to bind to (use 0.0.0.0 for any) (not
supported yet)
    -p port       the port to listen to (default 8080)
    -h            prints this usage message

So, in the pre-integration-test phase, standalone could be started with
"start" and using the Hudson port number provider to define a port for
the -j option. Likewise in the post-integration-test phase Sling may be
stopped again using "stop".

Regards
Felix

> 
> Agreed.
> 
>> ...P.S. Even with these goals, I still think we should be running
>> integration tests against the webapp version....
> 
> Do you think we need to run all tests against each launchpad variant
> (standalone, webapp, karaf)?
> 
> I'd say we need to run the full test suite against the standalone
> launchpad, and just run smoke tests on the webapp and karaf variants
> to make sure they basically work. We'd be testing their build, not the
> sling functionality inside, that would be tested against standalone.
> 
> -Bertrand
> 

Re: read sling.home from a system property in webapp? (was Re: [jira] Commented: (SLING-1364) Inside a Bundle Project it is not possible to executed an embedded Test with LaunchPad, Cargo and Jetty)

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Feb 19, 2010 at 2:53 PM, Justin Edelson <ju...@gmail.com> wrote:
> On 2/19/10 4:39 AM, Felix Meschberger wrote:
>> ...Since there are phases before and after the integration-test phase to
>> prepare and cleaup around integration tests this is possible from the
>> maven POV...

> If we're going to do this, let's do it right:
> launchpad:start - starts the standalone app in a forked process
> launchpad:stop - stops the standalone process
> launchpad:run - runs the standalone app in the same process

Agreed.

> ...P.S. Even with these goals, I still think we should be running
> integration tests against the webapp version....

Do you think we need to run all tests against each launchpad variant
(standalone, webapp, karaf)?

I'd say we need to run the full test suite against the standalone
launchpad, and just run smoke tests on the webapp and karaf variants
to make sure they basically work. We'd be testing their build, not the
sling functionality inside, that would be tested against standalone.

-Bertrand