search

scm-manager / scm-manager

The easiest way to share and manage your Git, Mercurial and Subversion repositories over http.
https://scm-manager.org
GNU Affero General Public License v3.0
136 stars 29 forks source link

scm-webapp-1.41 on GF 4.1 #633

Closed cesmarvin closed 4 years ago

cesmarvin commented 10 years ago

Original report by Steven Siebert (Bitbucket: smsiebe, GitHub: smsiebe).

This seems to have been addressed on the an email thread [1], but I don't see a formal issue.

summary: scm-manager bundles jersey 1.18 which conflicts with GF 4.1, which is a 2.10.4. On restart, the webapp classloader 'wins' and provides the v1.18 javax.ws.rs.core.UriBuilder causing a AbstractMethodException.

In your thread, you mentioned "the only way seems to be an update to jersey 2.x and this is not possible until the guice integration is not ready", linking to the still open JERSEY-1950 [2], this is blocked by a lack of functionality in Guice (which seems to be by design in some regard) and hasn't received very much attention [3]. There does not seem to be an end in sight for the standoff that started in 2013.

So, as it stands, scm-manager cannot be deployed on GF 4.1...but I believe it's fair to say it can quite possibly have the same problems when deploying on any JAX-RS 2 (JavaEE7) container? Doing some quick searches in the forum for WildFly issues seems to turn up similar issues - some hackery (implementation specific tricks) can be employed to get it working...though it seems other related issues has stifled things again.

IMO, waiting on Jersey or Guice to budge is going to make scm-manager look bad as EE7 becomes the standard in production environments -- and I really like this project. What can I do to help? I would be glad to help refactor the guice components to use CDI - with the benefit that you least you know it plays nice with EE. If not, is there anything else I can help with to get this resolved?

[1] https://groups.google.com/forum/#!msg/scmmanager/Kn_9NkPYHjk/On7QG2DQXUoJ

[2] https://java.net/jira/browse/JERSEY-1950

[3] https://code.google.com/p/google-guice/issues/detail?id=778

cesmarvin commented 10 years ago

Original comment by Sebastian Sdorra (Bitbucket: sdorra, GitHub: sdorra).

I think a switch to a cdi implementation such as weld is not possible, because scm-manager uses a lot of guice specific functions which are not covered by the cdi spec. But perhaps we could switch to resteasy, this could bring jax-rs 2 (with guice) and wildfly support. But i don't know if it is possible to use resteasy in glassfish.

cesmarvin commented 10 years ago

Original comment by Steven Siebert (Bitbucket: smsiebe, GitHub: smsiebe).

Ah, fair enough.

I just took a look a RestEasy -- it's documentation isn't very easy =) Just a little confusing because it states it follows JSR 311, which is JAX-RS 1.1...but in some release notes does state it supports JAX-RS 2.0 client. A quick look on github cleared it up, though...it seems like full JAX-RS 2.0 support....so their docs should say JSR 339 =)

aaanyway. I haven't seen any comments on the GF forums about problems with RestEasy with GF 4.x...and I can't see a reason why there would be unless there is some transient dependency issues like this one =). Would you entertain a patch attempting this approach?

cesmarvin commented 10 years ago

Original comment by Sebastian Sdorra (Bitbucket: sdorra, GitHub: sdorra).

I don't know, if it is possible to use resteasy in scm-manager 1.x. I think such a change could break existing plugins, which rely on the jersey api. The change is planned for scm-manager 2 (have a look at milestone 3).

cesmarvin commented 10 years ago

Original comment by Steven Siebert (Bitbucket: smsiebe, GitHub: smsiebe).

That's no problem with me...I created a personal branch to try things out and made it against the trunk =)

I probably made in invalid assumption, perhaps you can correct me. I noticed that those plugins weren't in the reactor, but I assumed that they all depended on the scm-client-api and scm-client-impl to abstract out the actual REST calls, and when I replaced those jersey dependencies with jax-rs 2.x client API work, all the other clients would continue to work because there would be no API change. If this is not the case -- then it will be a lot more work and indeed would be a reason to backlog this change for v2.

I started looking into it with an "explitory" branch and made some fairly good headway in getting the scm-manager 2.0-SNAPSHOT project (and modules within that reactor) converted over...the remaining work on that branch really was to conver the jersey rest client over to a JAX-RS 2.x client (using the specification instead of impl specific). I've been fairly successful removing jersey and just programming to the API for the most part -- though I did find I had to make a couple resteasy dependencies in the scm-webapp, some for convenience (multipart upload for plugins) and some because I don't currently know a way to do it with the JAX-RS API at the moment (ie defining a the mediatype mapping). And, of course, needing to add the resteasy-guice magic =) I think, overall, the migration to JAX-RS 2.x will bring the added benefit of making it easier to replace the implementation later on if necessary. If my assumptions were corred, and updating rest-client-impl is all that it would take, though, it really wouldn't require too much work to finish and test.

The other concern I had, that probably reenforces "fixing" this issue in v2, is that replacing jaxrs 1.x with jaxrs 2.x will of course have and equal and opposite reaction -- with jax-rs v2.0 dependencies, scm-manager will work on EE7 and above containers, but not on EE 6 and below without changing out the application servers API and JAX-RS implementation. =(

Let me know what you think, I'll be glad to continue me work and make a pull request when complete.

cesmarvin commented 10 years ago

Original comment by Sebastian Sdorra (Bitbucket: sdorra, GitHub: sdorra).

Hi Steven, Plugins have their own repositories, expect the core plugins (git, hg and svn). The plugins do not rely on the scm-client-api, they rely on the scm-core module (which has a dependency to jersey). Each plugin is able to register its own restful endpoints and it is possible that they do this with jersey specific stuff. The scm-client-* modules are for external integration with scm-manager (e.g.: scm-cli-client). I think the we should switch in v2.

Thank you for your work

cesmarvin commented 10 years ago

Original comment by Steven Siebert (Bitbucket: smsiebe, GitHub: smsiebe).

Sigh - I seriously brain farted there - of course they don't make use of the client-api...I mixed the architectural details of this project with another I'm working.

Yes, of course, that makes sense. =) No problem - v2 is perfect for us...I'll be able to use the standalone version in the mean time and use a reverse proxy in front.

I'll move forward over the weekend with the goal of getting the server and core modules working.

S

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.