Re: PAX:WEB How many war bundles do pax-web support?

[Pavel]

Hi Akhil,

I developed that patch and it worked for multiple virtual hosts. However, I 
wouldn't suggest you 
using OSGi + Jetty. I would suggest using JPMS + Jetty. Jetty now supports 
JPMS. There is
an issue on Jetty (google) how to configure it and set classloading and 
JSP. If you need modularity 
I thinkthis is a better way. If you need dynamism you can consider using 
one JPMS layer for every
web application. We did it in our framework and everything works fine.

Best regards, Pavel

среда, 22 мая 2019 г., 14:28:46 UTC+3 пользователь Akhil Grover написал:
>
> Hi All,
>
> The patch was merged into master but as far as I can see never released. 
> Is there any issue related to the patch? 
> Is there a time line on when this patch will be merged into 7.3.x branch?
>
> Regards,
> Akhil
>
> On Wednesday, October 19, 2016 at 7:53:03 PM UTC+1, Pavel wrote:
>>
>> Hi all
>>
>> I created a patch that allows to use N virtual hosts on one port and M 
>> context path inside
>> each virtual host. The solution is backward compatible with pax-web 6.0. 
>> I created an 
>> issue https://ops4j1.jira.com/browse/PAXWEB-1026 and attached the patch 
>> there.
>>
>> I hope it will be useful for anyone and the developers will include it in 
>> master branch
>> although it must be tested, but unfortunately I really have no time.
>>
>> Best regards, 
>>
>> среда, 12 октября 2016 г., 14:41:47 UTC+3 пользователь iJava написал:
>>>
>>> Ok. Thank you making the situation clear. 
>>>
>>> Best regards,
>>>
>>> среда, 12 октября 2016 г., 14:40:12 UTC+3 пользователь Achim Nierbeck 
>>> написал:

 sorry didn't want to bother you with my bla-bla-bla ... 
 therefore I have nothing else to say. 

 regards, Achim 

 2016-10-12 13:35 GMT+02:00 iJava :

> Hi Achim
>
> Are you there? Will you answer to my suggestion?
>
> Best regards,
>
> понедельник, 10 октября 2016 г., 9:07:15 UTC+3 пользователь iJava 
> написал:
>>
>> Hi Achim
>>
>> Thank you for detailed explanation. However, I think soon google 
>> mailing list will complain
>> about our bla-bla-bla because there is still no result.
>>
>> Lets get closer to business.
>> So, I think that web-contextpath musn't be across all connectors 
>> because it's logically wrong.
>>
>> What I suggest after short analysis is:
>> 1) The solution must be absolute backward compatible with pax-web 
>> 6.0. (I need this feature
>> and I can't wait ? time for version 7.0.0)
>> 2) In deployed bundles there will be an optional(!) Virtual-Hosts 
>> setting in manifest of war bundle.
>> I think that even it there is any virtual-host settings separate from 
>> bundles in the future,
>>  it is bundle that must say to which virtual host it wants to belong 
>> to.
>> 3) We add virtualHosts collection to org.ops4j.pax.web.service.spi.
>> model.ServerModel + 
>> fix all match* methods. Besides we fix match* in 
>> JettyServerHandlerCollection 
>> 4) it is necessary to allow war bundles with the same context if the 
>> have virtual-hosts setting.
>> I haven't looked yet where it can be done.
>> 5) The suggested solution is a "first attempt" to see how it will be 
>> like and will not
>> require much time (which is the problem #1). If someone has time in 
>> future he\she can
>> always make the solution better.
>>
>> What will you say? 
>>
>> P.S. I considered only for jetty as I wrote above.
>>
>>
>>
>> понедельник, 10 октября 2016 г., 0:03:28 UTC+3 пользователь Achim 
>> Nierbeck написал:
>>
>>> I fully understand your problem, but it can't be solved easily. 
>>> The registration of the Web-ContextPath is per Bundle and over all 
>>> available Connections, while
>>> the VirtualHost component only makes sure it's only available to 
>>> VirtualHost X and the default Connector, while it's not available to 
>>> VirtualHost Y. 
>>>
>>> So for example the following integration Test [1] shows it, the War 
>>> is registered on the given ContextPath and for the given VirtualHost. 
>>> The 
>>> second tests this with the second connector [2]. 
>>>
>>> The Web-ContextPath is verified while the WABs are registerd through 
>>> the web-Extender. [3]
>>> And there a second WAB with the same Web-ContextPath is put on hold. 
>>>
>>> While the VirtualHost is added to the registering Bundle after the 
>>> Web-ContextPath is registered, the final connection between the Bundle 
>>> HttpContext (bound to the Bundle Context and therefore also to the 
>>> WebContext path) is done while registering the HttpContext. 
>>>
>>> So what I got from your descriptions you actually require the second 
>>> part of the jetty virtual host description [7]. 
>>> This can't be done, as this kind of xml isn't parsed by Pax-Web as 

[PAX-LOGGING] Log4J2 problem

[Grzegorz Grzybek]

Hello

(sorry for writing to two mailing lists, but I think it's important).

I've just found nasty problem.

After having lots of fun with pax-logging-service and pax-logging-logback I
wanted to clean up pax-logging-log4j2. But I found that original, already
available pax-logging-log4j2 bundle actually has Export-Package header
(pax-logging-service and pax-logging-logback don't export anything).

The strange thing was that all bundles have:

Export-Package: \
 !*

The difference is that pax-logging-log4j2 additionally has

:

Private-Package: \
...
META-INF; -split-package:=merge-first, \
...

So it ... took the META-INF/MANIFEST.MF from
org.apache.logging.log4j:log4j-core. It wouldn't be a problem if
pax-logging-log4j2 exported something - even single package.

Here's why

(aQute.lib.osgi.Analyzer#calcManifest()):

// Copy old values into new manifest, when they
// exist in the old one, but not in the new one
merge(manifest, dot.getManifest());

pax-logging-log4j2 bundle didn't have any Export-Package (as intended), so
it just inherited it from org.apache.logging.log4j:log4j-core (definitely
*not* as intended...).

This is related to https://ops4j1.jira.com/browse/PAXLOGGING-240 and the
discussion here[1].

To be honest, the only thing I think is sensible here is to stop exporting
anything from pax-logging-log4j2... Extensions should be done via fragments
or pax-logging-api's org.ops4j.pax.logging.spi interfaces (like
PaxAppender).

WDYT?

regards
Grzegorz Grzybek
===
[1]: https://groups.google.com/forum/#!msg/ops4j/yjqOzvrKRkc/t5BXmfyoBgAJ

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CAAdXmhr1W2_3y56mpUUiErHFgKs13jFb2bd4CoC0rvcfaE9M8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PAX:WEB How many war bundles do pax-web support?

[Akhil Grover]

Hi All,

The patch was merged into master but as far as I can see never released. Is 
there any issue related to the patch? 
Is there a time line on when this patch will be merged into 7.3.x branch?

Regards,
Akhil

On Wednesday, October 19, 2016 at 7:53:03 PM UTC+1, Pavel wrote:
>
> Hi all
>
> I created a patch that allows to use N virtual hosts on one port and M 
> context path inside
> each virtual host. The solution is backward compatible with pax-web 6.0. I 
> created an 
> issue https://ops4j1.jira.com/browse/PAXWEB-1026 and attached the patch 
> there.
>
> I hope it will be useful for anyone and the developers will include it in 
> master branch
> although it must be tested, but unfortunately I really have no time.
>
> Best regards, 
>
> среда, 12 октября 2016 г., 14:41:47 UTC+3 пользователь iJava написал:
>>
>> Ok. Thank you making the situation clear. 
>>
>> Best regards,
>>
>> среда, 12 октября 2016 г., 14:40:12 UTC+3 пользователь Achim Nierbeck 
>> написал:
>>>
>>> sorry didn't want to bother you with my bla-bla-bla ... 
>>> therefore I have nothing else to say. 
>>>
>>> regards, Achim 
>>>
>>> 2016-10-12 13:35 GMT+02:00 iJava :
>>>
 Hi Achim

 Are you there? Will you answer to my suggestion?

 Best regards,

 понедельник, 10 октября 2016 г., 9:07:15 UTC+3 пользователь iJava 
 написал:
>
> Hi Achim
>
> Thank you for detailed explanation. However, I think soon google 
> mailing list will complain
> about our bla-bla-bla because there is still no result.
>
> Lets get closer to business.
> So, I think that web-contextpath musn't be across all connectors 
> because it's logically wrong.
>
> What I suggest after short analysis is:
> 1) The solution must be absolute backward compatible with pax-web 6.0. 
> (I need this feature
> and I can't wait ? time for version 7.0.0)
> 2) In deployed bundles there will be an optional(!) Virtual-Hosts 
> setting in manifest of war bundle.
> I think that even it there is any virtual-host settings separate from 
> bundles in the future,
>  it is bundle that must say to which virtual host it wants to belong 
> to.
> 3) We add virtualHosts collection to org.ops4j.pax.web.service.spi.
> model.ServerModel + 
> fix all match* methods. Besides we fix match* in 
> JettyServerHandlerCollection 
> 4) it is necessary to allow war bundles with the same context if the 
> have virtual-hosts setting.
> I haven't looked yet where it can be done.
> 5) The suggested solution is a "first attempt" to see how it will be 
> like and will not
> require much time (which is the problem #1). If someone has time in 
> future he\she can
> always make the solution better.
>
> What will you say? 
>
> P.S. I considered only for jetty as I wrote above.
>
>
>
> понедельник, 10 октября 2016 г., 0:03:28 UTC+3 пользователь Achim 
> Nierbeck написал:
>
>> I fully understand your problem, but it can't be solved easily. 
>> The registration of the Web-ContextPath is per Bundle and over all 
>> available Connections, while
>> the VirtualHost component only makes sure it's only available to 
>> VirtualHost X and the default Connector, while it's not available to 
>> VirtualHost Y. 
>>
>> So for example the following integration Test [1] shows it, the War 
>> is registered on the given ContextPath and for the given VirtualHost. 
>> The 
>> second tests this with the second connector [2]. 
>>
>> The Web-ContextPath is verified while the WABs are registerd through 
>> the web-Extender. [3]
>> And there a second WAB with the same Web-ContextPath is put on hold. 
>>
>> While the VirtualHost is added to the registering Bundle after the 
>> Web-ContextPath is registered, the final connection between the Bundle 
>> HttpContext (bound to the Bundle Context and therefore also to the 
>> WebContext path) is done while registering the HttpContext. 
>>
>> So what I got from your descriptions you actually require the second 
>> part of the jetty virtual host description [7]. 
>> This can't be done, as this kind of xml isn't parsed by Pax-Web as 
>> it's a mediation layer. 
>> In the end you can try to use a vanilla Jetty instead then. 
>>
>> [1] - 
>> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-itest/pax-web-itest-container/pax-web-itest-container-jetty/src/test/java/org/ops4j/pax/web/itest/jetty/JettyConfigurationExtendedIntegrationTest.java#L66
>>
>> [2] - 
>> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-itest/pax-web-itest-container/pax-web-itest-container-jetty/src/test/java/org/ops4j/pax/web/itest/jetty/JettyConfigurationExtendedIntegrationTest.java#L106-L111
>>
>> [3] - 
>> 

Re: pax-web not recognizing JAXB implementation with Java 11

['Achim Nierbeck' via OPS4J]

Hi,

how are you using Pax Web and which version?
As far as I know Java 11 runs smoothly with the setup the Apache Karaf
project has been using.
I was under the impression, we already had some adjustments in the pax web
project for Java 11.

regards, Achim

Am Di., 21. Mai 2019 um 21:38 Uhr schrieb 'Jasper Siepkes' via OPS4J <
ops4j@googlegroups.com>:

> Hi all!
>
> I'm trying to migrate our OSGi application to Java 11. However I cannot
> get pax-web to find the JAXB implementation. Which leads to a exception
> like the one below when it tries to parse a web.xml. I've added `com.sun.*`
> to bootdelegation but oddly enough that doesn't seem to matter.
>
> I'm using the Apache Servicemix jaxb implementation bundle
> (org.apache.servicemix.bundles.jaxb-runtime) together with the Jakarta API
> bundle (jakarta.xml.bind-api). I've also tried adding a fragment which
> makes the jakarta API bundle import the apache servicemix jaxb
> implementation package (com.sun etc.). That also didn't work.
>
> Can someone tell me what the proper way is to make pax-web recognize the
> JAXB implementation?
>
> Regards,
>
> Jasper
>
> --8<-
> [org.ops4j.pax.web.extender.war.internal.parser.WebAppParser] : error
> parsing web.xml
> javax.xml.bind.JAXBException: Implementation of JAXB-API has not been
> found on module path or classpath.
>  - with linked exception:
> [java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory]
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:232)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:351)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:691)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:632)
> at
> org.ops4j.pax.web.extender.war.internal.parser.WebAppParser.parseWebXml(WebAppParser.java:955)
> at
> org.ops4j.pax.web.extender.war.internal.parser.WebAppParser.scanWebFragments(WebAppParser.java:363)
> at
> org.ops4j.pax.web.extender.war.internal.parser.WebAppParser.parse(WebAppParser.java:186)
> at
> org.ops4j.pax.web.extender.war.internal.WebObserver.createExtension(WebObserver.java:145)
> at
> org.ops4j.pax.web.extender.war.internal.Activator.doCreateExtension(Activator.java:82)
> at
> org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
> at
> org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:242)
> at
> org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.addingBundle(AbstractExtender.java:195)
> at
> org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.addingBundle(AbstractExtender.java:54)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:475)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:420)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
> at org.osgi.util.tracker.BundleTracker.open(BundleTracker.java:159)
> at
> org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.startTracking(AbstractExtender.java:154)
> at
> org.ops4j.pax.web.extender.war.internal.Activator.doStart(Activator.java:59)
> at
> org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.start(AbstractExtender.java:117)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:698)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2402)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1539)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.ClassNotFoundException:
> com.sun.xml.bind.v2.ContextFactory
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at
> javax.xml.bind.ServiceLoaderUtil.nullSafeLoadClass(ServiceLoaderUtil.java:92)
> at
> javax.xml.bind.ServiceLoaderUtil.safeLoadClass(ServiceLoaderUtil.java:125)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:230)
> ... 26 more
> --8<-
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>