Bug 1019161

Hi Paul, can you resolve the maven repository issues (or assign to someone else)?

Should be in section Known issues in Beta Release Notes.

Assigning to Weinan to review the POM.  We should be able to fix this, but the POM issue is not a blocker, IMO.

Thanks for collecting the requirement Pavel!

About these two requirements:

1) Missing documentation how to use RESTEasy Spring Integration in EAP-6.2

"incorporate EAP's RESTEasy Spring support to customer's project is just to add the new dependency (resteasy-spring.jar) to his project."

The above requirement needs development work from WildFly team. Why? That's the design of the JBoss Modules. The things in 'modules' are not accessible to user applications deployed on WildFly/AS7. And the jars in your project's 'lib' directory will not be seen by AS server either.

If we want to use the modules in WildFly/AS7, we need to explicitly set it in our app's MANIFEST file like this:

Dependencies: org.resteasy.springframework

or in jboss-deployment-structure.xml. Like:

<jboss-deployment-structure>
   ...
   <dependencies>
     <module name="org.resteasy.springframework">
   </dependencies>
</jboss-deployment-structure>


So it's all user's job to use these modules we 'provided' in modules directory of AS7/WildFly. Or users should put their own jars in their application's lib dir.

You may argue we don't need to import EJB/CDI jars and the application still work. Why that happen? If we have a look on WildFly/AS7 design, we could see these modules are installed to user application by default:

- javax.activation
- javax.annotation
- javax.jms
- javax.security
- javax.transaction
- javax.jws
- javax.xml
- javax.ejb
- org.jboss.resteasy
- javax.persistence
- org.hibernate
- org.jboss.as.web
- org.jboss.as.weld

There are many codes written in WildFly/AS7 to make these modules auto injected and make the injection process conforms to JavaEE standard (For example, the @ApplicationPath should be recognised at WildFly startup)

For this part of work, please ask WildFly upstream to see what's their development plan.

2) Invalid pom file in productized bits

Currently I just build springframework into EAP repo. They are neither supported by WildFly/AS7 nor supported by EAP currently. If users want to use these jars, we could first build our own test application and add these jars as dependencies and run our test application correctly.

Then we could write some documents telling user how to use resteasy-spring and relative jars properly into their own project.

I could work on this part.

The method on telling user how to install resteasy-spring into their own project is not a 'solution' really. It's more like a 'hack' we provided from eap side. Anyway let's start to do this part firstly.

(In reply to Paul Gier from comment #3)
> Assigning to Weinan to review the POM.  We should be able to fix this, but
> the POM issue is not a blocker, IMO.

+1

It seems like we could change the EAP "eap6-supported-artifacts" BOM, such that anything included in the EAP runtime (even if it's in an optional module) was marked with scope == provided.

If we did that, AND the user injects the BOM (as they should), then they should be able to simply declare a dependency on the spring-integration jar. This would include the spring side of the integration-jar's dependencies in the WAR, but NOT the resteasy ones (since they would have their scope managed to 'provided' by the EAP BOM).

Of course, if the spring-integration POM sets scope appropriately for resteasy, then the user doesn't even have to have the BOM declared correctly in their own project for this to work. We could modify the spring-integration POM itself to do this...but that might mean only the version of spring that we provide is setup to leave resteasy out of the user WAR.

CAVEATS.... :-)

I should also mention, it's possible I'm getting the BOM injection behavior a bit wrong here...it would be good to test it to verify what I'm saying is sane. I'm 95% sure this will work.

Also, it should be said that if the user goes overboard declaring <scope>compile</scope> on resteasy, that will override whatever we put in either the BOM _or_ the spring-integration POM.

Thinking about this more, if we're interested in letting the user create a jboss module out of some arbitrary version of spring, we could create something akin to a quickstart project.

This quickstart would allow them to set the version of spring they wanted to use, along with (probably) their own groupId/artifactId/version combo (?), and could create the jboss-module structure for that version of spring to be installed in EAP. From there, I suppose it would be easy enough to structure the POM for that quickstart to also double as a BOM for the spring integration, declaring scope == provided for the things in the jboss module.

If the user included the EAP BOM + this customized spring BOM (the POM they used to build the spring module, above), then they should be able to avoid deploying spring in their WARs and save some space.

I'm not sure, but this looks like it could be a way of shipping/supporting the instructions for creating the module + BOM without shipping/supporting spring itself...sort of like if we shipped a bash script to do the same thing, only this would work anywhere.

I think we should use Snowdrop (aka Spring on EAP)
see	https://access.redhat.com/site/documentation/en-US/JBoss_Web_Framework_Kit/2.2/html-single/Snowdrop_User_Guide/index.html#idm74038976
It provides installation of spring module for EAP
Without it spring is not working correctly in some cases (see features of Snowdrop)

(In reply to Petr Sakař from comment #10)
> I think we should use Snowdrop (aka Spring on EAP)
> see
> https://access.redhat.com/site/documentation/en-US/JBoss_Web_Framework_Kit/2.
> 2/html-single/Snowdrop_User_Guide/index.html#idm74038976
> It provides installation of spring module for EAP
> Without it spring is not working correctly in some cases (see features of
> Snowdrop)

+1 btw, I haven't looked at this project for a long time, need to refresh my knowledge on it asap. Does it fully support JBoss AS7/WildFly now?

Added a demo project to show how to deploy spring project in EAP:

https://github.com/liweinan/resteasy-spring-eap-integration

Petr, could you please help to verify it?

Please ignore the other two projects: "eap-module-def" and "spring-integration-test-nodep" are for upstream development of WildFly. I'm collecting what to do to enable springframework in WildFly with these two projects and they are not ready for use in EAP yet.

The "eap-module-def" and "spring-integration-test-nodep" are fixed for use. Please help to verify the two approaches by following the instruction: https://github.com/liweinan/resteasy-spring-eap-integration/blob/master/README.md

I'm starting the verification according to instructions in comment#14, but the issue can not be closed without proper documentation or quickstart for EAP 6.2.0

Hello,

I'm the support delivery engineer that usually takes resteasy cases and we raised this RFE since lots of customers were coming from community resteasy or have a "Spring culture" and wanted to use it with resteasy.

We have a really simple resteasy + spring example for EAP 5.x, see [1]. 

Do you think if we adapt it to EAP 6.2 it could be used as a quickstart?

[1] https://access.redhat.com/site/solutions/121683

Created attachment 821035 [details]
patch for SpringBeanProcessor to be able to use resteasy-spring  with spring 2.5.6.SEC03

First results of basic testing - see updated project from comment#14 on github https://github.com/psakar/resteasy-spring-eap-integration resteasy-spring-integration-test

resteasy-spring-2.3.7.Final-redhat-2 can not be used with spring framework version 2.5.6.SEC03 
The deployment of application fails with exception java.lang.ClassNotFoundException: org.springframework.context.event.SmartApplicationListener

The problem is caused by use of interface SmartApplicationListener in SpringBeanProcessor by commit https://github.com/resteasy/Resteasy/commit/fcced9f2ee3aeed5251d60a9c75599936e421f2d 
This interface is available in spring since version 3.0. 

I've attached patch which solves the issue (yet have to be thoroughly tested though).

(In reply to William Antônio from comment #16)
> Hello,
> 
> I'm the support delivery engineer that usually takes resteasy cases and we
> raised this RFE since lots of customers were coming from community resteasy
> or have a "Spring culture" and wanted to use it with resteasy.
> 
> We have a really simple resteasy + spring example for EAP 5.x, see [1]. 
> 
> Do you think if we adapt it to EAP 6.2 it could be used as a quickstart?
> 
> [1] https://access.redhat.com/site/solutions/121683

Hi William, EAP5.x + RESTEasy 1.x is too old, both EAP6 and RESTEasy 2.3.x have a redesign so let's focusing on the current solutions.

(In reply to Petr Sakař from comment #18)
> First results of basic testing - see updated project from comment#14 on
> github https://github.com/psakar/resteasy-spring-eap-integration
> resteasy-spring-integration-test

Thanks for the work Petr, could you please create a PR so I could merge your changes? And I'd like to go on improving the document based on your changes.

> 
> resteasy-spring-2.3.7.Final-redhat-2 can not be used with spring framework
> version 2.5.6.SEC03 
> The deployment of application fails with exception
> java.lang.ClassNotFoundException:
> org.springframework.context.event.SmartApplicationListener
> 
> The problem is caused by use of interface SmartApplicationListener in
> SpringBeanProcessor by commit
> https://github.com/resteasy/Resteasy/commit/
> fcced9f2ee3aeed5251d60a9c75599936e421f2d 
> This interface is available in spring since version 3.0. 
> 
> I've attached patch which solves the issue (yet have to be thoroughly tested
> though).

Let's focus on spring framework 3.x support then? Asking users to patch Springframework seems won't be a solution to them, unless we could ship our own version of springframework, wdyt?

Snowdrop has the option to install various versions of the Springframework as an Add-on Module.  It works on both AS7 and EAP 6.  I need to test it against Wildfly before I will sign off on that.

Under WFK Snowdrop(Spring integration into/on EAP) is supported.

Upstream Jira and PR for Petr's proposed fix for Spring 2.5 compatability:
https://issues.jboss.org/browse/RESTEASY-993
https://github.com/resteasy/Resteasy/pull/423

This has been fixed by building resteasy-spring into 2.3.8[1] and providing a sample project on how to use it[2]. But we are not supporting it directly in EAP 6.x right now.

[1] https://brewweb.devel.redhat.com/buildinfo?buildID=352973
[2] https://github.com/jboss-developer/jboss-wfk-quickstarts/tree/2.6.x-develop/spring-resteasy

The provided quickstart in comment 31 needs to be placed in jboss eap quickstart repository [1], as this is example of spring-resteasy integration in EAP. We also ship quickstarts zip together with the release of the product.

[1] https://github.com/jboss-developer/jboss-eap-quickstart

I think this issue is now out of date.  The spring example is available in the quickstarts zip.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days