Re: Pax Web the discovery of the Servlet Initializers seems to be fundamentally flawed.
Hello
niedz., 1 lis 2020 o 18:56 'paul stanley' via OPS4J
napisał(a):
> Hi Grzegorz,
>
> Sorry about the delay in getting back to you.
>
> I realise your concerns about sci's from different webapps interfering
> with each other. However the SCI mechanism appears to be the way that the
> other web technologies, such as JAXRS and SpringMVC have a chance to detect
> and influence the creation of the servlet.
>
JaxRS and SpringMVC were designed to work in JavaEE runtime (or just flat
classpath for non servlet applications) which has well defined hierarchical
ClassLoader model, so scanning for SCIs is easy - just start with current
ClassLoader (assigned to the WAR for example) and walk through parents.
OSGi has also (very) well defined ClassLoader model - but it's not
hierarchical, it's _network_ bidirectional graph of ClassLoaders...
>
> Given that ServiceLoader architecture is being used, is it unreasonable
> that all possible instances for the SCI get asked to look at the bundle and
> initialize the context is appropriate?
>
Hmm, I'm not sure I understand... SCI in onStartup() gets an instance of
ServletContext and array of classes - it should not be bundle aware...
>
> If not, then we need another way to extend the WebExtender with other web
> frameworks, allowing them to get involved with servlet creation. Which
> does not include altering the webapp in some OSGI specific way.
>
I'm not sure we can extend the WebExtender (quite low level framework) with
some web framework (SpringMVC, JaxRS, Wicket, Tapestry, name it - all more
high level)
But fear not - the best way to detect proper SCIs (IMO) is simply to use
WAB archives, so all jars from Bundle-ClassPath manifest header (which by
default means all jars from /WEB-INF/lib of the bundle) are scanned for
SCIs and web-fragment.xmls.
regards
Grzegorz Grzybek
>
> Cheers
> Paul
> On 30 Oct 2020, at 08:46, Grzegorz Grzybek wrote:
>>
>> Hello
>>
>> czw., 29 paź 2020 o 19:50 Matt Pavlovich < m...@hyte.io> napisał(a):
>>
>>> Paul--
>>>
>>> You might checkout a BundleTracker. A BundleTracker is ensured to get a
>>> callback for every bundle, regardless as to when your bundle started. With
>>> a BundleListener, there is a race condition that you may not be activated
>>> before some bundles that you care about.
>>>
>>
>> It's not about bundle tracker or listener. Whiteboard implementation uses
>> such tracker to ensure that when a bundle is gone, all associated contexts
>> and web elements should be deregistered.
>> It's more about which bundles should be scanned for
>> ServletContainerInitializers. imagine you install two "sets" of bundles
>> (e.g., Karaf features) - you don't want SCIs from one feature (web
>> application) to be used in another feature/web application...
>>
>> regards
>> Grzegorz Grzybek
>>
>>
>>>
>>> ref:
>>> https://docs.osgi.org/specification/osgi.core/7.0.0/util.tracker.html#d0e52020
>>>
>>> -Matt
>>>
>>> On Thursday, October 29, 2020 at 1:17:19 PM UTC-5
>>> 8.apri...@googlemail.com wrote:
>>>
Thanks Grzegorz. I know what you mean about doing my "normal job", I
also have be careful as to what can be shared to the community.
I realise that the ServiceLoader is a bit of a problem and I've already
had to alter other standard services to be bundle-aware. Which is why I
think implementing a Bundle Listener could be a better approach for the
SCI's.
I'm out of the office for a couple of weeks so I'm going to look
prototyping a solution when I get back.
Cheers
Paul
On 29 Oct 2020, at 13:28, Grzegorz Grzybek < gr.gr...@gmail.com>
wrote:
> Hello
>
> You're generally right. I'm working on Pax Web 8 improvements (actual,
> full implementation of OSGi CMPN R6+ Whiteboard specification +
> HttpService
> specification + Web Applications Specification) and I tackled the problem
> of ServletContainerInitializers.
>
> The problem is that OSGi CMPN spec doesn't mention SCIs at all, only
> Web Applications Specification generally assumes that "web bundle" should
> be processed ("extended") by the implementation which involves web.xml
> parsing + fragments parsing + (possibly) "classpath scanning". See for
> example:
>
> A WAB can optionally contain a web.xml resource to specify additional
>> configuration. This web.xml must be found with the Bundle
>> *findEntries* method at the path WEB-INF/web.xml. The findEntries
>> method includes fragments, allowing the web.xml to be provided by a
>> fragment.
>>
>
> So here there's nothing about "scanning other bundles" not referred
> through "fragment" relationship.
>
> Also:
>
> Unlike a WAR, a WAB is not constrained to package classes and code
>> resources in the WEB-INF/classes directory or dependent JARs in
>> WEB-INF/lib/ only. These entries can be packaged in any way that's valid
>> for an
Re: Pax Web the discovery of the Servlet Initializers seems to be fundamentally flawed.
Hi,
SpiFly can help, and you can always use direct war/webapp (not webbundle).
Regards
JB
On Sun, Nov 1, 2020 at 6:56 PM 'paul stanley' via OPS4J <
ops4j@googlegroups.com> wrote:
> Hi Grzegorz,
>
> Sorry about the delay in getting back to you.
>
> I realise your concerns about sci's from different webapps interfering
> with each other. However the SCI mechanism appears to be the way that the
> other web technologies, such as JAXRS and SpringMVC have a chance to detect
> and influence the creation of the servlet.
>
> Given that ServiceLoader architecture is being used, is it unreasonable
> that all possible instances for the SCI get asked to look at the bundle and
> initialize the context is appropriate?
>
> If not, then we need another way to extend the WebExtender with other web
> frameworks, allowing them to get involved with servlet creation. Which
> does not include altering the webapp in some OSGI specific way.
>
> Cheers
> Paul
> On 30 Oct 2020, at 08:46, Grzegorz Grzybek wrote:
>>
>> Hello
>>
>> czw., 29 paź 2020 o 19:50 Matt Pavlovich < m...@hyte.io> napisał(a):
>>
>>> Paul--
>>>
>>> You might checkout a BundleTracker. A BundleTracker is ensured to get a
>>> callback for every bundle, regardless as to when your bundle started. With
>>> a BundleListener, there is a race condition that you may not be activated
>>> before some bundles that you care about.
>>>
>>
>> It's not about bundle tracker or listener. Whiteboard implementation uses
>> such tracker to ensure that when a bundle is gone, all associated contexts
>> and web elements should be deregistered.
>> It's more about which bundles should be scanned for
>> ServletContainerInitializers. imagine you install two "sets" of bundles
>> (e.g., Karaf features) - you don't want SCIs from one feature (web
>> application) to be used in another feature/web application...
>>
>> regards
>> Grzegorz Grzybek
>>
>>
>>>
>>> ref:
>>> https://docs.osgi.org/specification/osgi.core/7.0.0/util.tracker.html#d0e52020
>>>
>>> -Matt
>>>
>>> On Thursday, October 29, 2020 at 1:17:19 PM UTC-5
>>> 8.apri...@googlemail.com wrote:
>>>
Thanks Grzegorz. I know what you mean about doing my "normal job", I
also have be careful as to what can be shared to the community.
I realise that the ServiceLoader is a bit of a problem and I've already
had to alter other standard services to be bundle-aware. Which is why I
think implementing a Bundle Listener could be a better approach for the
SCI's.
I'm out of the office for a couple of weeks so I'm going to look
prototyping a solution when I get back.
Cheers
Paul
On 29 Oct 2020, at 13:28, Grzegorz Grzybek < gr.gr...@gmail.com>
wrote:
> Hello
>
> You're generally right. I'm working on Pax Web 8 improvements (actual,
> full implementation of OSGi CMPN R6+ Whiteboard specification +
> HttpService
> specification + Web Applications Specification) and I tackled the problem
> of ServletContainerInitializers.
>
> The problem is that OSGi CMPN spec doesn't mention SCIs at all, only
> Web Applications Specification generally assumes that "web bundle" should
> be processed ("extended") by the implementation which involves web.xml
> parsing + fragments parsing + (possibly) "classpath scanning". See for
> example:
>
> A WAB can optionally contain a web.xml resource to specify additional
>> configuration. This web.xml must be found with the Bundle
>> *findEntries* method at the path WEB-INF/web.xml. The findEntries
>> method includes fragments, allowing the web.xml to be provided by a
>> fragment.
>>
>
> So here there's nothing about "scanning other bundles" not referred
> through "fragment" relationship.
>
> Also:
>
> Unlike a WAR, a WAB is not constrained to package classes and code
>> resources in the WEB-INF/classes directory or dependent JARs in
>> WEB-INF/lib/ only. These entries can be packaged in any way that's valid
>> for an OSGi bundle as long as such directories and JARs are part of
>> bundle
>> class path as set with the Bundle-ClassPath header and any attached
>> fragments. JARs that are specified in the Bundle-ClassPath header are
>> treated like JARs in the WEB-INF/lib/ directory of the Servlet
>> specification. Similarly, any directory that is part of the
>> Bundle-ClassPath header is treated like WEB-INF/classes directory of the
>> Servlet specification.
>>
>
> So again - you can "bring" additional libraries to your "bundle
> classpath" by referring them in "Bundle-ClassPath" header. No scanning of
> everything (that's for example tracked by BundleListener).
>
> And about java.util.ServiceLoader (which should in theory be a
> suggestion to how ServletContainerInitializer "services" are found),
> "java.util.ServiceLoader#load(java.lang.Class,
Re: Pax Web the discovery of the Servlet Initializers seems to be fundamentally flawed.
Hi Grzegorz,
Sorry about the delay in getting back to you.
I realise your concerns about sci's from different webapps interfering with
each other. However the SCI mechanism appears to be the way that the other web
technologies, such as JAXRS and SpringMVC have a chance to detect and influence
the creation of the servlet.
Given that ServiceLoader architecture is being used, is it unreasonable that
all possible instances for the SCI get asked to look at the bundle and
initialize the context is appropriate?
If not, then we need another way to extend the WebExtender with other web
frameworks, allowing them to get involved with servlet creation. Which does
not include altering the webapp in some OSGI specific way.
Cheers
Paul
On 30 Oct 2020, 08:46, at 08:46, Grzegorz Grzybek wrote:
>Hello
>
>czw., 29 paź 2020 o 19:50 Matt Pavlovich napisał(a):
>
>> Paul--
>>
>> You might checkout a BundleTracker. A BundleTracker is ensured to
>get a
>> callback for every bundle, regardless as to when your bundle started.
>With
>> a BundleListener, there is a race condition that you may not be
>activated
>> before some bundles that you care about.
>>
>
>It's not about bundle tracker or listener. Whiteboard implementation
>uses
>such tracker to ensure that when a bundle is gone, all associated
>contexts
>and web elements should be deregistered.
>It's more about which bundles should be scanned for
>ServletContainerInitializers. imagine you install two "sets" of bundles
>(e.g., Karaf features) - you don't want SCIs from one feature (web
>application) to be used in another feature/web application...
>
>regards
>Grzegorz Grzybek
>
>
>>
>> ref:
>>
>https://docs.osgi.org/specification/osgi.core/7.0.0/util.tracker.html#d0e52020
>>
>> -Matt
>>
>> On Thursday, October 29, 2020 at 1:17:19 PM UTC-5
>8.apri...@googlemail.com
>> wrote:
>>
>>>
>>> Thanks Grzegorz. I know what you mean about doing my "normal job",
>I
>>> also have be careful as to what can be shared to the community.
>>>
>>> I realise that the ServiceLoader is a bit of a problem and I've
>already
>>> had to alter other standard services to be bundle-aware. Which is
>why I
>>> think implementing a Bundle Listener could be a better approach for
>the
>>> SCI's.
>>>
>>> I'm out of the office for a couple of weeks so I'm going to look
>>> prototyping a solution when I get back.
>>>
>>> Cheers
>>> Paul
>>> On 29 Oct 2020, at 13:28, Grzegorz Grzybek
>wrote:
>>>
Hello
You're generally right. I'm working on Pax Web 8 improvements
>(actual,
full implementation of OSGi CMPN R6+ Whiteboard specification +
>HttpService
specification + Web Applications Specification) and I tackled the
>problem
of ServletContainerInitializers.
The problem is that OSGi CMPN spec doesn't mention SCIs at all,
>only Web
Applications Specification generally assumes that "web bundle"
>should be
processed ("extended") by the implementation which involves web.xml
>parsing
+ fragments parsing + (possibly) "classpath scanning". See for
>example:
A WAB can optionally contain a web.xml resource to specify
>additional
> configuration. This web.xml must be found with the Bundle
>*findEntries*
> method at the path WEB-INF/web.xml. The findEntries method
>includes
> fragments, allowing the web.xml to be provided by a fragment.
>
So here there's nothing about "scanning other bundles" not referred
through "fragment" relationship.
Also:
Unlike a WAR, a WAB is not constrained to package classes and code
> resources in the WEB-INF/classes directory or dependent JARs in
> WEB-INF/lib/ only. These entries can be packaged in any way that's
>valid
> for an OSGi bundle as long as such directories and JARs are part
>of bundle
> class path as set with the Bundle-ClassPath header and any
>attached
> fragments. JARs that are specified in the Bundle-ClassPath header
>are
> treated like JARs in the WEB-INF/lib/ directory of the Servlet
> specification. Similarly, any directory that is part of the
> Bundle-ClassPath header is treated like WEB-INF/classes directory
>of the
> Servlet specification.
>
So again - you can "bring" additional libraries to your "bundle
classpath" by referring them in "Bundle-ClassPath" header. No
>scanning of
everything (that's for example tracked by BundleListener).
And about java.util.ServiceLoader (which should in theory be a
suggestion to how ServletContainerInitializer "services" are
>found),
"java.util.ServiceLoader#load(java.lang.Class,
>java.lang.ClassLoader)"
method simply uses the passed classLoader and the other "load()"
>version
uses TCCL. Neither of these methods scan ALL classloaders (all
>bundles in
OSGi).
In Pax Web 8 I'm definitely going to solve this problem - for now,
>a
bundle that registered "a context"
