Pax Web WAR extender, JSF and Aries CDI integration #1622
Assignees
Labels
Milestone
Comments
|
For now I have a WAB with: <Require-Capability>
osgi.cdi.extension;filter:="(osgi.cdi.extension=aries.cdi.http)",
osgi.cdi.extension;filter:="(osgi.cdi.extension=aries.cdi.el.jsp)"
</Require-Capability>
<_cdiannotations>*;discover=annotated</_cdiannotations>I use Aries CDI 1.1.3 with locally fixed https://issues.apache.org/jira/browse/ARIES-2053 Pax Web 8 (snapshot) provides some compatibility fragments that add OSGi contract to jakarta bundles. Another bundle fragment from Pax Web 8 tweaks myfaces-core-impl with: <Fragment-Host>org.apache.myfaces.core.impl</Fragment-Host>
<Require-Capability><![CDATA[
osgi.extender;filter:="(&(osgi.extender=osgi.serviceloader.registrar)(version>=1.0)(!(version>=2.0)))"
]]></Require-Capability>
<Provide-Capability>
osgi.serviceloader;osgi.serviceloader=javax.enterprise.inject.spi.Extension;aries.cdi.extension.mode=implicit
</Provide-Capability>so aries-cdi can load extensions from it and provide them (in implicit mode) to my sample WAB. Almost everything works. But there's:
The other thing is that for now, pax-web-extender-war doesn't take into account whiteboard-registered elements that are supposed to alter the context created for the WAB. I'm working on it. Yet another thing is (cc: @rotty3000) that if I wanted to synchronize with aries-cdi, I could register a |
|
With current implementation of Pax Web 8, where server configuration (consuming configuration changes from many trackers and invocations) is performed in single "pax web config thread", there's a deadlock between Aries CCR thread that first grabbed a CDI container lock and later whiteboard-registers the listener: and pax-web-config thread that passes the listener to jetty instance and calling I could successfully start the Jetty container (or just the listener) in separate threads, but many existing tests I had started to behave randomly. |
|
https://stackoverflow.com/a/47447140/250517 mentions the need to use |
|
Now, I have: even if I see nice set of contexts: the |
|
And it works! I probably didn't understand |
|
Well, almost works. I tried |
|
Finally. Now, the only thing is that I have to think about clever way of:
|
grgrzybek
added a commit
that referenced
this issue
Jul 8, 2021
…DI, MyFaces and Weld. Works only under debugger.
grgrzybek
added a commit
that referenced
this issue
Jul 8, 2021
…DI, MyFaces and Weld. Works only under debugger.
|
After proper handling of listeners (calling |
|
It doesn't now look like deadlock between Aries CDI and Pax Web! Simply the WAR with JSF+CDI is redeployed (because of newly registered CDI context listener) and upon first DEPLOYED event, the test fails (HTTP 404) and stops the bundle. And the bundle stop leads to a deadlock with just redeploying application. |
|
And another deadlock: |
|
The easier deadlock is fixed by rescheduling the start of the context after listener registration in a started context. Proper thread is used to free previous thread's event loop invocation. |
|
Making Whiteboard registrations async (but still synchronized) was a good idea overall, but now some integration tests that wait for "DEPLOYED" events fail (too quick request before the servlet is really available) |
grgrzybek
added a commit
that referenced
this issue
Feb 20, 2022
…nization. All Whiteboard tests work after making Aries-CDI work
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is an issue to collect notes about CDI/JSF integration.
The text was updated successfully, but these errors were encountered: