What I assume happened was the following:

The WAR was incorrectly treated as bundle and therefore installed by the OSGi 
Installer for bundles.
As consequence the according servlets were registered.
 

> On 1. Apr 2020, at 16:00, Robert Munteanu <[email protected]> wrote:
> 
> I agree in principle. But why did these not fail until now?
> 
> Thanks,
> Robert
> 
> On Wed, 2020-04-01 at 15:39 +0200, Konrad Windszus wrote:
>> IMHO there are some test which should only be executed from 
>> https://github.com/apache/sling-org-apache-sling-launchpad-testing-war
>> , namely 
>> https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/blob/bd0c0c270b73e582dc5dfa3ed25231c951d0c98d/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolution/WarSelectorServletTest.java
>> .
>> 
>> That should IMHO be moved to 
>> https://github.com/apache/sling-org-apache-sling-launchpad-testing-war
>> to make sure it is not executed with 
>> https://github.com/apache/sling-org-apache-sling-launchpad-testing.
>> WDYT?
>> 
>> Konrad
>> 
>>> On 1. Apr 2020, at 15:29, Konrad Windszus <[email protected]> wrote:
>>> 
>>> Done with 
>>> https://github.com/apache/sling-org-apache-sling-launchpad-test-bundles/commit/43956dd07234ddc3263ce29c5b7c3f7198ad4caf
>>> <
>>> https://github.com/apache/sling-org-apache-sling-launchpad-test-bundles/commit/43956dd07234ddc3263ce29c5b7c3f7198ad4caf>
>>> ;.
>>> 
>>> That leaves us with 2 remaining issues:
>>> 
>>> [ERROR] Failures: 
>>> [ERROR]   WarSelectorServletTest.testSelectorOne:23-
>>>> ResolutionTestBase.assertServlet:75 Content contains
>>> servlet.class.name property (** Resource dumped by
>>> PlainTextRenderer**
>>> Resource path:/servlet-resolution-
>>> tests/1585747495298/this_is_a_test_node_
>>> Resource metadata: {sling.modificationTime=-1,
>>> sling.characterEncoding=null, sling.parameterMap={},
>>> sling.contentType=null, sling.creationTime=-1,
>>> sling.contentLength=-1, sling.resolutionPath=/servlet-resolution-
>>> tests/1585747495298/this_is_a_test_node_,
>>> sling.resolutionPathInfo=.WAR_TEST_SEL_1.txt}
>>> Resource type: nt:unstructured
>>> Resource super type: -
>>> 
>>> ** Resource properties **
>>> jcr:primaryType: nt:unstructured
>>> text: This is a test node 1585747503024
>>> )
>>> [ERROR]   WarSelectorServletTest.testSelectorTwo:29-
>>>> ResolutionTestBase.assertServlet:75 Content contains
>>> servlet.class.name property (** Resource dumped by
>>> PlainTextRenderer**
>>> Resource path:/servlet-resolution-
>>> tests/1585747495298/this_is_a_test_node_
>>> Resource metadata: {sling.modificationTime=-1,
>>> sling.characterEncoding=null, sling.parameterMap={},
>>> sling.contentType=null, sling.creationTime=-1,
>>> sling.contentLength=-1, sling.resolutionPath=/servlet-resolution-
>>> tests/1585747495298/this_is_a_test_node_,
>>> sling.resolutionPathInfo=.WAR_TEST_SEL_2.txt}
>>> Resource type: nt:unstructured
>>> Resource super type: -
>>> 
>>> ** Resource properties **
>>> jcr:primaryType: nt:unstructured
>>> text: This is a test node 1585747503113
>>> )
>>> 
>>> 
>>> Konrad
>>> 
>>>> On 1. Apr 2020, at 15:21, Robert Munteanu <[email protected]>
>>>> wrote:
>>>> 
>>>> On Wed, 2020-04-01 at 15:16 +0200, Konrad Windszus wrote:
>>>>> The test fails with the following output
>>>>> 
>>>>> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time
>>>>> elapsed: 0.292 s <<< FAILURE! - in
>>>>> org.apache.sling.launchpad.webapp.integrationtest.installer.Ser
>>>>> verSid
>>>>> eInstallerTest
>>>>> [ERROR]
>>>>> noUntransformedResources(org.apache.sling.launchpad.webapp.inte
>>>>> gratio
>>>>> ntest.installer.ServerSideInstallerTest)  Time elapsed: 0.105
>>>>> s  <<<
>>>>> FAILURE!
>>>>> java.lang.AssertionError: Untransformed resources found:
>>>>> [RegisteredResource(url=launchpad:resources/install/5/org.apach
>>>>> e.slin
>>>>> g.launchpad.test-services-war-12-SNAPSHOT.war,
>>>>> digest=1585745808000)]
>>>>>   at
>>>>> org.apache.sling.launchpad.webapp.integrationtest.installer.Ser
>>>>> verSid
>>>>> eInstallerTest.noUntransformedResources(ServerSideInstallerTest
>>>>> .java:
>>>>> 52)
>>>>> 
>>>>> 
>>>>> This is due to the fact that this WAR file is deployed as well 
>>>>> https://github.com/apache/sling-org-apache-sling-launchpad-test-bundles/blob/2c6850a53b12742e3c6fbc018340789166054ebb/src/main/provisioning/bundles.txt#L29
>>>>> IMHO there was never any transformer picking up WAR resources,
>>>>> so I
>>>>> wonder why that dependency is in there?
>>>>> 
>>>>> This could be related to 
>>>>> https://github.com/apache/sling-org-apache-sling-installer-core/commit/33eeae619c5aae2a7a52903edbdd6a85b08e0891
>>>>> , but processing WAR resources with the bundle transformer
>>>>> probably
>>>>> never was a good idea.
>>>>> So right now I tend to just remove the WAR dependency in the
>>>>> bundles.txt.
>>>> 
>>>> That sounds like a good idea, not sure why we do that ... unless
>>>> launchpad-testing-war uses it?
>>>> 
>>>> Robert
>>>> 
>>>>> WDYT?
>>>>> 
>>>>> Konrad
>>>>> 
>>>>> 
>>>>>> On 1. Apr 2020, at 13:43, Konrad Windszus <[email protected]>
>>>>>> wrote:
>>>>>> 
>>>>>> I can do releases on JCR Provider, File Provider and Package
>>>>>> Feature but first someone should investigate
>>>>>> 
>>>>>> org.apache.sling.launchpad.webapp.integrationtest.installer.S
>>>>>> erverS
>>>>>> ideInstallerTest.noUntransformedResources
>>>>>> 
>>>>>> I unfortunately won't have time to look into that this week.
>>>>>> 
>>>>>> Konrad
>>>>>>> On 1. Apr 2020, at 13:25, Robert Munteanu <
>>>>>>> [email protected]>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> On Wed, 2020-04-01 at 13:16 +0200, Bertrand Delacretaz
>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> On Wed, Apr 1, 2020 at 12:36 PM Robert Munteanu <
>>>>>>>> [email protected]>
>>>>>>>> wrote:
>>>>>>>>> ... I noticed that our launchpad tests are in poor
>>>>>>>>> shape...
>>>>>>>> 
>>>>>>>> It looks like 
>>>>>>>> https://issues.apache.org/jira/browse/SLING-9319
>>>>>>>> will
>>>>>>>> fix a number of those, and this means the
>>>>>>>> org.apache.sling/org.apache.sling.installer.provider.jcr/
>>>>>>>> 3.2.0
>>>>>>>> release
>>>>>>>> can be considered broken.
>>>>>>> 
>>>>>>> Thanks, Bertrand!
>>>>>>> 
>>>>>>> Robert
> 

Reply via email to