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 (JIRA)" <ji...@apache.org> on 2010/02/17 13:43:27 UTC

[jira] Commented: (SLING-1364) Inside a Bundle Project it is not possible to executed an embedded Test with LaunchPad, Cargo and Jetty

    [ https://issues.apache.org/jira/browse/SLING-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834754#action_12834754 ] 

Justin Edelson commented on SLING-1364:
---------------------------------------

adding new prepare-test-webapp goal in r910814 and added sample project (/samples/inplace-integration-test/) in r910815

> Inside a Bundle Project it is not possible to executed an embedded Test with LaunchPad, Cargo and Jetty
> -------------------------------------------------------------------------------------------------------
>
>                 Key: SLING-1364
>                 URL: https://issues.apache.org/jira/browse/SLING-1364
>             Project: Sling
>          Issue Type: Bug
>          Components: Maven Plugins
>         Environment: Mac, Java 6, Apache Sling from SVN Trunk
>            Reporter: Andreas Schaefer
>            Assignee: Justin Edelson
>         Attachments: pom copy.xml
>
>
> Inside a bundle project I could not start an integration test. Even though I could create a launchpad bundles firing up the embedded Web container (Cargo / Jetty) or even just Jetty fails.
> Steps to reproduce it:
> 1) Create a Servlet
> 2) Create a Bundle that contains the Servlet
> 3) Take the POM from launchpad / /testing and move these maven plugins inside the integration test profile: launchpad and war
> 4) Make sure the launchpad plugin is called after the JAR file is created (pre-integration-test)
> Running that with 'mvn -P jcrinstall-tests integration-test' fails because Sling is never launched even though launchpad-bundles is created and the war files seems to be fine.
> Running the same without Cargo and plain Jetty fails because now Sling is deployed inside "${basedir}/sling/_" and also the System Console is not coming up even though the sling home page does.
> Cheers - Andy

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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 Justin Edelson <ju...@gmail.com>.
On Thu, Feb 18, 2010 at 4:50 PM, Felix Meschberger <fm...@gmail.com>wrote:

> Hi,
>
> On 18.02.2010 19:39, Justin Edelson wrote:
> > On 2/18/10 12:31 PM, Andreas Schaefer wrote:
> >> Hi Justin
> >>
> >> Sorry, forgot to read the failsave plugin documentation first.
> >>
> >> That said I see that the 'sling home directory' is created in the
> project's base directory even though in the Jetty configuration it is set to
> 'target/sling'. In my project I configured the 'maven-clean-plugin' to clean
> up that directory as well but it still feels wrong to have to do that.
> >>
> >> Does anybody know how to set the sling home directory for the
> integration test so that I will end up in the 'target' directory ?
> >>
> >
> > Hmmm. The launchpad.testing module is configured to set the system
> > property sling.home, but this is ignored. In a webapp, you have to
> > configure sling.home via an init-param. I just committed a change to the
> > sample app in r911513[1] to use an init-param in jetty (when using mvn
> > jetty:run-war), but I don't see a way to do this with cargo.
> >
> > It seems like a system property should be usable here. I know there are
> > concerns about system properties in webapps in general, but this seems
> > like a good case for allowing the use of one (although init-param should
> > take precedence).
> >
> > WDYT?
>
> System properties can be used in the web app case, too, but it is
> disabled by default.
>
> The main problem is, that we might have multiple sling web applications
> installed in a single servlet container and we want to prevent them to
> all use the same sling.home value.
>
> How about if sling.home is read from a system property, it get the servlet
context path appended to it?


> So I am worried to read system properties in the war case.
>
> In fact, we should fix the integration launching to use the standalone
> sling instead of the sling web app with cargo.

Well, we *really* should be running the integration tests against
standalone, webapp, and karaf. But I haven't looked at how to best do this.

Justin


>
> Regards
> Felix
>
> >
> > Justin
> >
> > [1] http://svn.apache.org/viewvc?rev=911513&view=rev
> >
> >
> >> Thanks - Andy
> >>
> >> On Feb 17, 2010, at 11:48 AM, Justin Edelson wrote:
> >>
> >>> There is a way to do this with surefire configuration, but it's easier
> >>> to go along with the surefire/failsafe conventions:
> >>>
> >>> Unit Tests end in Test
> >>> Integration Tests end in IT
> >>>
> >>> Justin
> >>>
> >>> On Feb 17, 2010, at 11:59 AM, Andreas Schaefer <sc...@me.com>
> wrote:
> >>>
> >>>> Hi Justin
> >>>>
> >>>> Thanks for that. It works perfectly in my project as well now. The
> >>>> only thing I want to mention is that one MUST NOT add the suffix
> >>>> 'Test' to the test classes in order to avoid that the tests are
> >>>> executed.
> >>>>
> >>>> I will try later to see if I can exclude the tests from running by
> >>>> default.
> >>
> >
> >
>

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

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 Justin Edelson <ju...@gmail.com>.
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 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....

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 Bertrand Delacretaz <bd...@apache.org>.
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.

-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 18.02.2010 19:39, Justin Edelson wrote:
> On 2/18/10 12:31 PM, Andreas Schaefer wrote:
>> Hi Justin
>>
>> Sorry, forgot to read the failsave plugin documentation first.
>>
>> That said I see that the 'sling home directory' is created in the project's base directory even though in the Jetty configuration it is set to 'target/sling'. In my project I configured the 'maven-clean-plugin' to clean up that directory as well but it still feels wrong to have to do that.
>>
>> Does anybody know how to set the sling home directory for the integration test so that I will end up in the 'target' directory ?
>>
> 
> Hmmm. The launchpad.testing module is configured to set the system
> property sling.home, but this is ignored. In a webapp, you have to
> configure sling.home via an init-param. I just committed a change to the
> sample app in r911513[1] to use an init-param in jetty (when using mvn
> jetty:run-war), but I don't see a way to do this with cargo.
> 
> It seems like a system property should be usable here. I know there are
> concerns about system properties in webapps in general, but this seems
> like a good case for allowing the use of one (although init-param should
> take precedence).
> 
> WDYT?

System properties can be used in the web app case, too, but it is
disabled by default.

The main problem is, that we might have multiple sling web applications
installed in a single servlet container and we want to prevent them to
all use the same sling.home value.

So I am worried to read system properties in the war case.

In fact, we should fix the integration launching to use the standalone
sling instead of the sling web app with cargo.

Regards
Felix

> 
> Justin
> 
> [1] http://svn.apache.org/viewvc?rev=911513&view=rev
> 
> 
>> Thanks - Andy
>>
>> On Feb 17, 2010, at 11:48 AM, Justin Edelson wrote:
>>
>>> There is a way to do this with surefire configuration, but it's easier
>>> to go along with the surefire/failsafe conventions:
>>>
>>> Unit Tests end in Test
>>> Integration Tests end in IT
>>>
>>> Justin
>>>
>>> On Feb 17, 2010, at 11:59 AM, Andreas Schaefer <sc...@me.com> wrote:
>>>
>>>> Hi Justin
>>>>
>>>> Thanks for that. It works perfectly in my project as well now. The
>>>> only thing I want to mention is that one MUST NOT add the suffix
>>>> 'Test' to the test classes in order to avoid that the tests are
>>>> executed.
>>>>
>>>> I will try later to see if I can exclude the tests from running by
>>>> default.
>>
> 
> 

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 Justin Edelson <ju...@gmail.com>.
On 2/18/10 12:31 PM, Andreas Schaefer wrote:
> Hi Justin
> 
> Sorry, forgot to read the failsave plugin documentation first.
> 
> That said I see that the 'sling home directory' is created in the project's base directory even though in the Jetty configuration it is set to 'target/sling'. In my project I configured the 'maven-clean-plugin' to clean up that directory as well but it still feels wrong to have to do that.
> 
> Does anybody know how to set the sling home directory for the integration test so that I will end up in the 'target' directory ?
> 

Hmmm. The launchpad.testing module is configured to set the system
property sling.home, but this is ignored. In a webapp, you have to
configure sling.home via an init-param. I just committed a change to the
sample app in r911513[1] to use an init-param in jetty (when using mvn
jetty:run-war), but I don't see a way to do this with cargo.

It seems like a system property should be usable here. I know there are
concerns about system properties in webapps in general, but this seems
like a good case for allowing the use of one (although init-param should
take precedence).

WDYT?

Justin

[1] http://svn.apache.org/viewvc?rev=911513&view=rev


> Thanks - Andy
> 
> On Feb 17, 2010, at 11:48 AM, Justin Edelson wrote:
> 
>> There is a way to do this with surefire configuration, but it's easier
>> to go along with the surefire/failsafe conventions:
>>
>> Unit Tests end in Test
>> Integration Tests end in IT
>>
>> Justin
>>
>> On Feb 17, 2010, at 11:59 AM, Andreas Schaefer <sc...@me.com> wrote:
>>
>>> Hi Justin
>>>
>>> Thanks for that. It works perfectly in my project as well now. The
>>> only thing I want to mention is that one MUST NOT add the suffix
>>> 'Test' to the test classes in order to avoid that the tests are
>>> executed.
>>>
>>> I will try later to see if I can exclude the tests from running by
>>> default.
> 


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 Andreas Schaefer <sc...@me.com>.
Hi Justin

Sorry, forgot to read the failsave plugin documentation first.

That said I see that the 'sling home directory' is created in the project's base directory even though in the Jetty configuration it is set to 'target/sling'. In my project I configured the 'maven-clean-plugin' to clean up that directory as well but it still feels wrong to have to do that.

Does anybody know how to set the sling home directory for the integration test so that I will end up in the 'target' directory ?

Thanks - Andy

On Feb 17, 2010, at 11:48 AM, Justin Edelson wrote:

> There is a way to do this with surefire configuration, but it's easier
> to go along with the surefire/failsafe conventions:
> 
> Unit Tests end in Test
> Integration Tests end in IT
> 
> Justin
> 
> On Feb 17, 2010, at 11:59 AM, Andreas Schaefer <sc...@me.com> wrote:
> 
>> Hi Justin
>> 
>> Thanks for that. It works perfectly in my project as well now. The
>> only thing I want to mention is that one MUST NOT add the suffix
>> 'Test' to the test classes in order to avoid that the tests are
>> executed.
>> 
>> I will try later to see if I can exclude the tests from running by
>> default.


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 Justin Edelson <ju...@gmail.com>.
There is a way to do this with surefire configuration, but it's easier
to go along with the surefire/failsafe conventions:

Unit Tests end in Test
Integration Tests end in IT

Justin

On Feb 17, 2010, at 11:59 AM, Andreas Schaefer <sc...@me.com> wrote:

> Hi Justin
>
> Thanks for that. It works perfectly in my project as well now. The
> only thing I want to mention is that one MUST NOT add the suffix
> 'Test' to the test classes in order to avoid that the tests are
> executed.
>
> I will try later to see if I can exclude the tests from running by
> default.
>
> -Andy
>
> On Feb 17, 2010, at 4:43 AM, Justin Edelson (JIRA) wrote:
>
>>
>>   [ https://issues.apache.org/jira/browse/SLING-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834754#action_12834754
>>  ]
>>
>> Justin Edelson commented on SLING-1364:
>> ---------------------------------------
>>
>> adding new prepare-test-webapp goal in r910814 and added sample
>> project (/samples/inplace-integration-test/) in r910815
>>
>>> Inside a Bundle Project it is not possible to executed an embedded
>>> Test with LaunchPad, Cargo and Jetty
>>> ---
>>> ---
>>> ---
>>> ---
>>> ---
>>> ---
>>> ---
>>> ---
>>> ---
>>> ---
>>> ---
>>> ---
>>> -------------------------------------------------------------------
>>>
>>>               Key: SLING-1364
>>>               URL: https://issues.apache.org/jira/browse/SLING-1364
>>>           Project: Sling
>>>        Issue Type: Bug
>>>        Components: Maven Plugins
>>>       Environment: Mac, Java 6, Apache Sling from SVN Trunk
>>>          Reporter: Andreas Schaefer
>>>          Assignee: Justin Edelson
>>>       Attachments: pom copy.xml
>>>
>>>
>>> Inside a bundle project I could not start an integration test.
>>> Even though I could create a launchpad bundles firing up the
>>> embedded Web container (Cargo / Jetty) or even just Jetty fails.
>>> Steps to reproduce it:
>>> 1) Create a Servlet
>>> 2) Create a Bundle that contains the Servlet
>>> 3) Take the POM from launchpad / /testing and move these maven
>>> plugins inside the integration test profile: launchpad and war
>>> 4) Make sure the launchpad plugin is called after the JAR file is
>>> created (pre-integration-test)
>>> Running that with 'mvn -P jcrinstall-tests integration-test' fails
>>> because Sling is never launched even though launchpad-bundles is
>>> created and the war files seems to be fine.
>>> Running the same without Cargo and plain Jetty fails because now
>>> Sling is deployed inside "${basedir}/sling/_" and also the System
>>> Console is not coming up even though the sling home page does.
>>> Cheers - Andy
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>

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 Andreas Schaefer <sc...@me.com>.
Hi Justin

Thanks for that. It works perfectly in my project as well now. The only thing I want to mention is that one MUST NOT add the suffix 'Test' to the test classes in order to avoid that the tests are executed.

I will try later to see if I can exclude the tests from running by default.

-Andy

On Feb 17, 2010, at 4:43 AM, Justin Edelson (JIRA) wrote:

> 
>    [ https://issues.apache.org/jira/browse/SLING-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834754#action_12834754 ] 
> 
> Justin Edelson commented on SLING-1364:
> ---------------------------------------
> 
> adding new prepare-test-webapp goal in r910814 and added sample project (/samples/inplace-integration-test/) in r910815
> 
>> Inside a Bundle Project it is not possible to executed an embedded Test with LaunchPad, Cargo and Jetty
>> -------------------------------------------------------------------------------------------------------
>> 
>>                Key: SLING-1364
>>                URL: https://issues.apache.org/jira/browse/SLING-1364
>>            Project: Sling
>>         Issue Type: Bug
>>         Components: Maven Plugins
>>        Environment: Mac, Java 6, Apache Sling from SVN Trunk
>>           Reporter: Andreas Schaefer
>>           Assignee: Justin Edelson
>>        Attachments: pom copy.xml
>> 
>> 
>> Inside a bundle project I could not start an integration test. Even though I could create a launchpad bundles firing up the embedded Web container (Cargo / Jetty) or even just Jetty fails.
>> Steps to reproduce it:
>> 1) Create a Servlet
>> 2) Create a Bundle that contains the Servlet
>> 3) Take the POM from launchpad / /testing and move these maven plugins inside the integration test profile: launchpad and war
>> 4) Make sure the launchpad plugin is called after the JAR file is created (pre-integration-test)
>> Running that with 'mvn -P jcrinstall-tests integration-test' fails because Sling is never launched even though launchpad-bundles is created and the war files seems to be fine.
>> Running the same without Cargo and plain Jetty fails because now Sling is deployed inside "${basedir}/sling/_" and also the System Console is not coming up even though the sling home page does.
>> Cheers - Andy
> 
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>