-
Notifications
You must be signed in to change notification settings - Fork 354
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The jersey-gf-ejb was adopted by the GlassFish as jersey-ejb-component-provider #4920
base: 3.1
Are you sure you want to change the base?
Conversation
dmatej
commented
Dec 1, 2021
•
edited
Loading
edited
- it was a circular dependency between jersey and glassfish
- jersey limited usage of glassfish to versions 4-6, but now started gf7 development
- see commit a8cfbe9fc7cd4e662ea044c111569804b5174c2f in glassfish
It looks like the build succeeds and everything passes, but it just out of the blue says fails anyway. |
This is the failure from Jenkins:
It is not caused by this PR |
Hmmmm, but the failure is caused by Read timeout when some test tried to download this. So it should be enough to rerun the build. Btw jakarta.el is downloaded several times, I don't know what the test is doing, but it is suspicious, especially with so extreme logging.
|
Dropping the EJB module looks suspicious. Will need to test this a bit.
Pros:
At this point we probably do not need to drop the module, it just won't be integrated into the GF. But thank you @dmatej for letting us know the changes in GF. Jersey is planned for the 3.1.0.M1 release quite soonish, I'd like to keep the module for M1 at least. |
I am not sure we can drop this at all. The Spec requirement is to contain EJB support. Dropping the module will de-facto break the requirement. It might be ok, to have the support in the glassfish repository, but it can render Jersey as non-spec compliant if any issue with GF....Keeping the module might prevent such a situation...no matter if no one would use it... |
Hmm, so then there should be some detached project providing standalone EJB container, usable for both Jersey and GlassFish. |
Is the EJB support important for the JAX-RS specs? Or would be easier for JAX-RS and Jersey too if the spec would drop this requirement? Also I believe this is not a task of Jersey (Jersey repo welcome page). Max it should verify that some basic scenarios work with several known use cases close to the real usage:
At least for now I can rebase the PR ... |
Yes, the EJB support is mandatory by the JAX-RS Spec for the Jakarta EE environment where the EJB container is available. |
I am talking about the NEXT version ;) |
…t-provider - it was a circular dependency between jersey and glassfish - jersey limited usage of glassfish to versions 4-6, but now started gf7 development - see commit a8cfbe9fc7cd4e662ea044c111569804b5174c2f in glassfish # Conflicts: # containers/glassfish/jersey-gf-ejb/pom.xml # containers/glassfish/jersey-gf-ejb/src/main/java/org/glassfish/jersey/gf/ejb/internal/EjbComponentInterceptor.java # containers/glassfish/jersey-gf-ejb/src/main/java/org/glassfish/jersey/gf/ejb/internal/EjbComponentProvider.java # containers/glassfish/jersey-gf-ejb/src/main/java/org/glassfish/jersey/gf/ejb/internal/EjbExceptionMapper.java # containers/glassfish/pom.xml