I'm sending this here before I submit a JIRA. JAX-RS deployments need to import more dependencies, specifically: * the jackson libraries * Apache Http Client 4 libraries Jackson and HC4 are often used within jax-rs deployments because users need to add additional configuration and initialization that can only be done programmatically.

Another thing: Can modules be declared with empty <resources>? It would be cool if we could have a resteasy module with which all it did was define what modules it would export to a deployment. Right now this metadata is hardcoded, correct? This sucks for multiple reasons. One: users will have to manually define a lot of module dependencies, or they will end up including resteasy and thirdparty libraries that may conflict and cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I want to provide *ALL* features that come with the resteasy distribution. Sure I could include and export everything within the current resteasy default module, but I would rather have separate modules for these features.

Another alternative could be to only distribute and export the core resteasy modules with AS7. Then, users would just include other resteasy features/components/jars directly within their deployments.

On 9/12/2012 2:39 PM, Jason Greene wrote: > > On Sep 12, 2012, at 1:13 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> I'm sending this here before I submit a JIRA. >> >> JAX-RS deployments need to import more dependencies, specifically: >> >> * the jackson libraries >> * Apache Http Client 4 libraries >> >> Jackson and HC4 are often used within jax-rs deployments because users >> need to add additional configuration and initialization that can only be >> done programmatically. > > OK but are you sure you want to support direct usage of those libraries? Part of the reason why we don't re-export third party libs we use is because we want the flexibility to upgrade/drop/replace, and we don't want to support a user using say google collections, just because we made use of it in our code base. > > (In case it sounds that way, I'm not arguing against you, I am just legitimately asking if you want to worry about maintenance of those items. If so no problem) Yes, we have to expose and support direct usage. They are both intricate in developing JAX-RS applications. Resteasy client framework is just a layer on top of Apache HC. For example, we rely on HC4 APIs to set up user/password and other authentication settings. Jackson annotations are used a lot as well as creating ObjectMapper's(JAXBContext equivalent) directly that are plugged in through JAX-RS apis (ContextResolver). I want to really apologize for not checking up on this months and months ago. I incorrectly assumed that things would just work and be exposed as they were in AS6. A lot of this is related to my lack of understanding of the module system too. >> >> Another thing: >> >> Can modules be declared with empty <resources>? It would be cool if we >> could have a resteasy module with which all it did was define what >> modules it would export to a deployment. Right now this metadata is >> hardcoded, correct? This sucks for multiple reasons. One: users will >> have to manually define a lot of module dependencies, or they will end >> up including resteasy and thirdparty libraries that may conflict and >> cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I >> want to provide *ALL* features that come with the resteasy distribution. >> Sure I could include and export everything within the current resteasy >> default module, but I would rather have separate modules for these features. > > Sure we do that for javaee for example (aggregation modules). If you would like to make an aggregate for JAX-RS thats fine, the only problem is you will prevent people from being able to exclude anything in that list. So to use an example if you add apache http client 4.1, and a user decides they want 3.0 or 5.0, they would have to exclude the aggregate module, and then include everything in it except http client. You could also do various different common combinations. I just don't see a way around it. Couldn't they also just modify the aggregation module? Maybe you need to add a feature to JBoss Modules that allows a deployment to override the version of an exported dependency?

Bill Burke <mailto:bburke@redhat.com> 13 September 2012 5:37 AM On 9/12/2012 2:39 PM, Jason Greene wrote: > On Sep 12, 2012, at 1:13 PM, Bill Burke&lt;bburke(a)redhat.com&gt; wrote: > >> I'm sending this here before I submit a JIRA. >> >> JAX-RS deployments need to import more dependencies, specifically: >> >> * the jackson libraries >> * Apache Http Client 4 libraries >> >> Jackson and HC4 are often used within jax-rs deployments because users >> need to add additional configuration and initialization that can only be >> done programmatically. > OK but are you sure you want to support direct usage of those libraries? Part of the reason why we don't re-export third party libs we use is because we want the flexibility to upgrade/drop/replace, and we don't want to support a user using say google collections, just because we made use of it in our code base. > > (In case it sounds that way, I'm not arguing against you, I am just legitimately asking if you want to worry about maintenance of those items. If so no problem) Yes, we have to expose and support direct usage. They are both intricate in developing JAX-RS applications. Resteasy client framework is just a layer on top of Apache HC. For example, we rely on HC4 APIs to set up user/password and other authentication settings. Jackson annotations are used a lot as well as creating ObjectMapper's(JAXBContext equivalent) directly that are plugged in through JAX-RS apis (ContextResolver). I want to really apologize for not checking up on this months and months ago. I incorrectly assumed that things would just work and be exposed as they were in AS6. A lot of this is related to my lack of understanding of the module system too. >> Another thing: >> >> Can modules be declared with empty<resources>? It would be cool if we >> could have a resteasy module with which all it did was define what >> modules it would export to a deployment. Right now this metadata is >> hardcoded, correct? This sucks for multiple reasons. One: users will >> have to manually define a lot of module dependencies, or they will end >> up including resteasy and thirdparty libraries that may conflict and >> cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I >> want to provide *ALL* features that come with the resteasy distribution. >> Sure I could include and export everything within the current resteasy >> default module, but I would rather have separate modules for these features. > Sure we do that for javaee for example (aggregation modules). If you would like to make an aggregate for JAX-RS thats fine, the only problem is you will prevent people from being able to exclude anything in that list. So to use an example if you add apache http client 4.1, and a user decides they want 3.0 or 5.0, they would have to exclude the aggregate module, and then include everything in it except http client. You could also do various different common combinations. I just don't see a way around it. Couldn't they also just modify the aggregation module? Maybe you need to add a feature to JBoss Modules that allows a deployment to override the version of an exported dependency?

>> Another alternative could be to only distribute and export the core >> resteasy modules with AS7. Then, users would just include other >> resteasy features/components/jars directly within their deployments. >> > Yeah that could work as well. > What do you think is better and would create less headaches for users? An aggregate module? Or just ship with core resteasy? I think we may be stuck with an aggregate module as the alternative would break backward compatibility? Jason Greene <mailto:jason.greene@redhat.com> 13 September 2012 4:39 AM On Sep 12, 2012, at 1:13 PM, Bill Burke&lt;bburke(a)redhat.com&gt; wrote: > I'm sending this here before I submit a JIRA. > > JAX-RS deployments need to import more dependencies, specifically: > > * the jackson libraries > * Apache Http Client 4 libraries > > Jackson and HC4 are often used within jax-rs deployments because users > need to add additional configuration and initialization that can only be > done programmatically. OK but are you sure you want to support direct usage of those libraries? Part of the reason why we don't re-export third party libs we use is because we want the flexibility to upgrade/drop/replace, and we don't want to support a user using say google collections, just because we made use of it in our code base. (In case it sounds that way, I'm not arguing against you, I am just legitimately asking if you want to worry about maintenance of those items. If so no problem) > Another thing: > > Can modules be declared with empty<resources>? It would be cool if we > could have a resteasy module with which all it did was define what > modules it would export to a deployment. Right now this metadata is > hardcoded, correct? This sucks for multiple reasons. One: users will > have to manually define a lot of module dependencies, or they will end > up including resteasy and thirdparty libraries that may conflict and > cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I > want to provide *ALL* features that come with the resteasy distribution. > Sure I could include and export everything within the current resteasy > default module, but I would rather have separate modules for these features. Sure we do that for javaee for example (aggregation modules). If you would like to make an aggregate for JAX-RS thats fine, the only problem is you will prevent people from being able to exclude anything in that list. So to use an example if you add apache http client 4.1, and a user decides they want 3.0 or 5.0, they would have to exclude the aggregate module, and then include everything in it except http client. You could also do various different common combinations. > Another alternative could be to only distribute and export the core > resteasy modules with AS7. Then, users would just include other > resteasy features/components/jars directly within their deployments. > Yeah that could work as well. _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev Bill Burke <mailto:bburke@redhat.com> 13 September 2012 4:13 AM I'm sending this here before I submit a JIRA. JAX-RS deployments need to import more dependencies, specifically: * the jackson libraries * Apache Http Client 4 libraries Jackson and HC4 are often used within jax-rs deployments because users need to add additional configuration and initialization that can only be done programmatically. Another thing: Can modules be declared with empty <resources>? It would be cool if we could have a resteasy module with which all it did was define what modules it would export to a deployment. Right now this metadata is hardcoded, correct? This sucks for multiple reasons. One: users will have to manually define a lot of module dependencies, or they will end up including resteasy and thirdparty libraries that may conflict and cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I want to provide *ALL* features that come with the resteasy distribution. Sure I could include and export everything within the current resteasy default module, but I would rather have separate modules for these features. Another alternative could be to only distribute and export the core resteasy modules with AS7. Then, users would just include other resteasy features/components/jars directly within their deployments.

Bill Burke <mailto:bburke@redhat.com> 13 September 2012 8:22 AM On 9/12/2012 6:02 PM, Stuart Douglas wrote: > > >> Bill Burke <mailto:bburke@redhat.com> >> 13 September 2012 5:37 AM >> On 9/12/2012 2:39 PM, Jason Greene wrote: >>> On Sep 12, 2012, at 1:13 PM, Bill Burke&lt;bburke(a)redhat.com&gt; wrote: >>> >>>> I'm sending this here before I submit a JIRA. >>>> >>>> JAX-RS deployments need to import more dependencies, specifically: >>>> >>>> * the jackson libraries >>>> * Apache Http Client 4 libraries >>>> >>>> Jackson and HC4 are often used within jax-rs deployments because >>>> users >>>> need to add additional configuration and initialization that can >>>> only be >>>> done programmatically. >>> OK but are you sure you want to support direct usage of those >>> libraries? Part of the reason why we don't re-export third party >>> libs we use is because we want the flexibility to >>> upgrade/drop/replace, and we don't want to support a user using say >>> google collections, just because we made use of it in our code base. >>> >>> (In case it sounds that way, I'm not arguing against you, I am just >>> legitimately asking if you want to worry about maintenance of those >>> items. If so no problem) >> >> Yes, we have to expose and support direct usage. They are both >> intricate in developing JAX-RS applications. Resteasy client framework >> is just a layer on top of Apache HC. For example, we rely on HC4 APIs >> to set up user/password and other authentication settings. Jackson >> annotations are used a lot as well as creating >> ObjectMapper's(JAXBContext equivalent) directly that are plugged in >> through JAX-RS apis (ContextResolver). >> >> I want to really apologize for not checking up on this months and >> months >> ago. I incorrectly assumed that things would just work and be exposed >> as they were in AS6. A lot of this is related to my lack of >> understanding of the module system too. >> >>>> Another thing: >>>> >>>> Can modules be declared with empty <resources>? It would be cool >>>> if we >>>> could have a resteasy module with which all it did was define what >>>> modules it would export to a deployment. Right now this metadata is >>>> hardcoded, correct? This sucks for multiple reasons. One: users >>>> will >>>> have to manually define a lot of module dependencies, or they will >>>> end >>>> up including resteasy and thirdparty libraries that may conflict and >>>> cause CCEs. Two: Its very hard for me to provide a patch to AS7 >>>> if I >>>> want to provide *ALL* features that come with the resteasy >>>> distribution. >>>> Sure I could include and export everything within the current >>>> resteasy >>>> default module, but I would rather have separate modules for these >>>> features. >>> Sure we do that for javaee for example (aggregation modules). If >>> you would like to make an aggregate for JAX-RS thats fine, the only >>> problem is you will prevent people from being able to exclude >>> anything in that list. So to use an example if you add apache http >>> client 4.1, and a user decides they want 3.0 or 5.0, they would >>> have to exclude the aggregate module, and then include everything >>> in it except http client. You could also do various different >>> common combinations. >> >> I just don't see a way around it. Couldn't they also just modify the >> aggregation module? Maybe you need to add a feature to JBoss Modules >> that allows a deployment to override the version of an exported >> dependency? > > If these are just added to the deployment as dependencies via the > JaxrsDependencyProcessor then they can be excluded and overridden by an > entry in jboss-deployment-structure.xml. If you make one big aggregation > module you loose that flexibility. > If we changed the JaxrsDependencyProcessor to import Apache HC 4.1. How would the user upgrade to Apache HC 4.2? Do they not have to create a new module for 4.2 and import it within their jboss-deployment-structure.xml? Why not have them do one more step and work with the aggregate module instead? They can always version the aggregate module too, right? If they get used to working with an aggregate module, isn't it a lot easier for them to support multiple different versions of Resteasy for different applications?

> I'm not saying that this is necessarily a massive problem, but that is > the price you pay for using an aggregation module. > > Something else we could potentially look at supporting is container > integration for bundled Resteasy, so if you include the Resteasy jars in > your application the scanning + EE integration code will still run, but > it will not add dependencies on the containers Resteasy jars. > What do we do for similar situations involving hibernate, infinispan, and other popular projects? Stuart Douglas <mailto:stuart.w.douglas@gmail.com> 13 September 2012 8:02 AM > Bill Burke <mailto:bburke@redhat.com> > 13 September 2012 5:37 AM > On 9/12/2012 2:39 PM, Jason Greene wrote: >> On Sep 12, 2012, at 1:13 PM, Bill Burke&lt;bburke(a)redhat.com&gt; wrote: >> >>> I'm sending this here before I submit a JIRA. >>> >>> JAX-RS deployments need to import more dependencies, specifically: >>> >>> * the jackson libraries >>> * Apache Http Client 4 libraries >>> >>> Jackson and HC4 are often used within jax-rs deployments because users >>> need to add additional configuration and initialization that can only be >>> done programmatically. >> OK but are you sure you want to support direct usage of those libraries? Part of the reason why we don't re-export third party libs we use is because we want the flexibility to upgrade/drop/replace, and we don't want to support a user using say google collections, just because we made use of it in our code base. >> >> (In case it sounds that way, I'm not arguing against you, I am just legitimately asking if you want to worry about maintenance of those items. If so no problem) > > Yes, we have to expose and support direct usage. They are both > intricate in developing JAX-RS applications. Resteasy client framework > is just a layer on top of Apache HC. For example, we rely on HC4 APIs > to set up user/password and other authentication settings. Jackson > annotations are used a lot as well as creating > ObjectMapper's(JAXBContext equivalent) directly that are plugged in > through JAX-RS apis (ContextResolver). > > I want to really apologize for not checking up on this months and months > ago. I incorrectly assumed that things would just work and be exposed > as they were in AS6. A lot of this is related to my lack of > understanding of the module system too. > >>> Another thing: >>> >>> Can modules be declared with empty<resources>? It would be cool if we >>> could have a resteasy module with which all it did was define what >>> modules it would export to a deployment. Right now this metadata is >>> hardcoded, correct? This sucks for multiple reasons. One: users will >>> have to manually define a lot of module dependencies, or they will end >>> up including resteasy and thirdparty libraries that may conflict and >>> cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I >>> want to provide *ALL* features that come with the resteasy distribution. >>> Sure I could include and export everything within the current resteasy >>> default module, but I would rather have separate modules for these features. >> Sure we do that for javaee for example (aggregation modules). If you would like to make an aggregate for JAX-RS thats fine, the only problem is you will prevent people from being able to exclude anything in that list. So to use an example if you add apache http client 4.1, and a user decides they want 3.0 or 5.0, they would have to exclude the aggregate module, and then include everything in it except http client. You could also do various different common combinations. > > I just don't see a way around it. Couldn't they also just modify the > aggregation module? Maybe you need to add a feature to JBoss Modules > that allows a deployment to override the version of an exported dependency? If these are just added to the deployment as dependencies via the JaxrsDependencyProcessor then they can be excluded and overridden by an entry in jboss-deployment-structure.xml. If you make one big aggregation module you loose that flexibility. I'm not saying that this is necessarily a massive problem, but that is the price you pay for using an aggregation module. Something else we could potentially look at supporting is container integration for bundled Resteasy, so if you include the Resteasy jars in your application the scanning + EE integration code will still run, but it will not add dependencies on the containers Resteasy jars. Stuart >>> Another alternative could be to only distribute and export the core >>> resteasy modules with AS7. Then, users would just include other >>> resteasy features/components/jars directly within their deployments. >>> >> Yeah that could work as well. >> > > What do you think is better and would create less headaches for users? > An aggregate module? Or just ship with core resteasy? I think we may > be stuck with an aggregate module as the alternative would break > backward compatibility? > > Jason Greene <mailto:jason.greene@redhat.com> > 13 September 2012 4:39 AM > On Sep 12, 2012, at 1:13 PM, Bill Burke&lt;bburke(a)redhat.com&gt; wrote: > >> I'm sending this here before I submit a JIRA. >> >> JAX-RS deployments need to import more dependencies, specifically: >> >> * the jackson libraries >> * Apache Http Client 4 libraries >> >> Jackson and HC4 are often used within jax-rs deployments because users >> need to add additional configuration and initialization that can only be >> done programmatically. > > OK but are you sure you want to support direct usage of those libraries? Part of the reason why we don't re-export third party libs we use is because we want the flexibility to upgrade/drop/replace, and we don't want to support a user using say google collections, just because we made use of it in our code base. > > (In case it sounds that way, I'm not arguing against you, I am just legitimately asking if you want to worry about maintenance of those items. If so no problem) >> Another thing: >> >> Can modules be declared with empty<resources>? It would be cool if we >> could have a resteasy module with which all it did was define what >> modules it would export to a deployment. Right now this metadata is >> hardcoded, correct? This sucks for multiple reasons. One: users will >> have to manually define a lot of module dependencies, or they will end >> up including resteasy and thirdparty libraries that may conflict and >> cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I >> want to provide *ALL* features that come with the resteasy distribution. >> Sure I could include and export everything within the current resteasy >> default module, but I would rather have separate modules for these features. > > Sure we do that for javaee for example (aggregation modules). If you would like to make an aggregate for JAX-RS thats fine, the only problem is you will prevent people from being able to exclude anything in that list. So to use an example if you add apache http client 4.1, and a user decides they want 3.0 or 5.0, they would have to exclude the aggregate module, and then include everything in it except http client. You could also do various different common combinations. >> Another alternative could be to only distribute and export the core >> resteasy modules with AS7. Then, users would just include other >> resteasy features/components/jars directly within their deployments. >> > > Yeah that could work as well. > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > Bill Burke <mailto:bburke@redhat.com> > 13 September 2012 4:13 AM > I'm sending this here before I submit a JIRA. > > JAX-RS deployments need to import more dependencies, specifically: > > * the jackson libraries > * Apache Http Client 4 libraries > > Jackson and HC4 are often used within jax-rs deployments because users > need to add additional configuration and initialization that can only be > done programmatically. > > Another thing: > > Can modules be declared with empty <resources>? It would be cool if we > could have a resteasy module with which all it did was define what > modules it would export to a deployment. Right now this metadata is > hardcoded, correct? This sucks for multiple reasons. One: users will > have to manually define a lot of module dependencies, or they will end > up including resteasy and thirdparty libraries that may conflict and > cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I > want to provide *ALL* features that come with the resteasy distribution. > Sure I could include and export everything within the current resteasy > default module, but I would rather have separate modules for these > features. > > Another alternative could be to only distribute and export the core > resteasy modules with AS7. Then, users would just include other > resteasy features/components/jars directly within their deployments. > Bill Burke <mailto:bburke@redhat.com> 13 September 2012 5:37 AM On 9/12/2012 2:39 PM, Jason Greene wrote: > On Sep 12, 2012, at 1:13 PM, Bill Burke&lt;bburke(a)redhat.com&gt; wrote: > >> I'm sending this here before I submit a JIRA. >> >> JAX-RS deployments need to import more dependencies, specifically: >> >> * the jackson libraries >> * Apache Http Client 4 libraries >> >> Jackson and HC4 are often used within jax-rs deployments because users >> need to add additional configuration and initialization that can only be >> done programmatically. > OK but are you sure you want to support direct usage of those libraries? Part of the reason why we don't re-export third party libs we use is because we want the flexibility to upgrade/drop/replace, and we don't want to support a user using say google collections, just because we made use of it in our code base. > > (In case it sounds that way, I'm not arguing against you, I am just legitimately asking if you want to worry about maintenance of those items. If so no problem) Yes, we have to expose and support direct usage. They are both intricate in developing JAX-RS applications. Resteasy client framework is just a layer on top of Apache HC. For example, we rely on HC4 APIs to set up user/password and other authentication settings. Jackson annotations are used a lot as well as creating ObjectMapper's(JAXBContext equivalent) directly that are plugged in through JAX-RS apis (ContextResolver). I want to really apologize for not checking up on this months and months ago. I incorrectly assumed that things would just work and be exposed as they were in AS6. A lot of this is related to my lack of understanding of the module system too. >> Another thing: >> >> Can modules be declared with empty<resources>? It would be cool if we >> could have a resteasy module with which all it did was define what >> modules it would export to a deployment. Right now this metadata is >> hardcoded, correct? This sucks for multiple reasons. One: users will >> have to manually define a lot of module dependencies, or they will end >> up including resteasy and thirdparty libraries that may conflict and >> cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I >> want to provide *ALL* features that come with the resteasy distribution. >> Sure I could include and export everything within the current resteasy >> default module, but I would rather have separate modules for these features. > Sure we do that for javaee for example (aggregation modules). If you would like to make an aggregate for JAX-RS thats fine, the only problem is you will prevent people from being able to exclude anything in that list. So to use an example if you add apache http client 4.1, and a user decides they want 3.0 or 5.0, they would have to exclude the aggregate module, and then include everything in it except http client. You could also do various different common combinations. I just don't see a way around it. Couldn't they also just modify the aggregation module? Maybe you need to add a feature to JBoss Modules that allows a deployment to override the version of an exported dependency? >> Another alternative could be to only distribute and export the core >> resteasy modules with AS7. Then, users would just include other >> resteasy features/components/jars directly within their deployments. >> > Yeah that could work as well. > What do you think is better and would create less headaches for users? An aggregate module? Or just ship with core resteasy? I think we may be stuck with an aggregate module as the alternative would break backward compatibility? Jason Greene <mailto:jason.greene@redhat.com> 13 September 2012 4:39 AM On Sep 12, 2012, at 1:13 PM, Bill Burke&lt;bburke(a)redhat.com&gt; wrote: > I'm sending this here before I submit a JIRA. > > JAX-RS deployments need to import more dependencies, specifically: > > * the jackson libraries > * Apache Http Client 4 libraries > > Jackson and HC4 are often used within jax-rs deployments because users > need to add additional configuration and initialization that can only be > done programmatically. OK but are you sure you want to support direct usage of those libraries? Part of the reason why we don't re-export third party libs we use is because we want the flexibility to upgrade/drop/replace, and we don't want to support a user using say google collections, just because we made use of it in our code base. (In case it sounds that way, I'm not arguing against you, I am just legitimately asking if you want to worry about maintenance of those items. If so no problem) > Another thing: > > Can modules be declared with empty<resources>? It would be cool if we > could have a resteasy module with which all it did was define what > modules it would export to a deployment. Right now this metadata is > hardcoded, correct? This sucks for multiple reasons. One: users will > have to manually define a lot of module dependencies, or they will end > up including resteasy and thirdparty libraries that may conflict and > cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I > want to provide *ALL* features that come with the resteasy distribution. > Sure I could include and export everything within the current resteasy > default module, but I would rather have separate modules for these features. Sure we do that for javaee for example (aggregation modules). If you would like to make an aggregate for JAX-RS thats fine, the only problem is you will prevent people from being able to exclude anything in that list. So to use an example if you add apache http client 4.1, and a user decides they want 3.0 or 5.0, they would have to exclude the aggregate module, and then include everything in it except http client. You could also do various different common combinations. > Another alternative could be to only distribute and export the core > resteasy modules with AS7. Then, users would just include other > resteasy features/components/jars directly within their deployments. > Yeah that could work as well. _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev Bill Burke <mailto:bburke@redhat.com> 13 September 2012 4:13 AM I'm sending this here before I submit a JIRA. JAX-RS deployments need to import more dependencies, specifically: * the jackson libraries * Apache Http Client 4 libraries Jackson and HC4 are often used within jax-rs deployments because users need to add additional configuration and initialization that can only be done programmatically. Another thing: Can modules be declared with empty <resources>? It would be cool if we could have a resteasy module with which all it did was define what modules it would export to a deployment. Right now this metadata is hardcoded, correct? This sucks for multiple reasons. One: users will have to manually define a lot of module dependencies, or they will end up including resteasy and thirdparty libraries that may conflict and cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I want to provide *ALL* features that come with the resteasy distribution. Sure I could include and export everything within the current resteasy default module, but I would rather have separate modules for these features. Another alternative could be to only distribute and export the core resteasy modules with AS7. Then, users would just include other resteasy features/components/jars directly within their deployments.

On 9/12/2012 6:43 PM, Stuart Douglas wrote: >> If we changed the JaxrsDependencyProcessor to import Apache HC 4.1. >> How would the user upgrade to Apache HC 4.2? Do they not have to >> create a new module for 4.2 and import it within their >> jboss-deployment-structure.xml? Why not have them do one more step >> and work with the aggregate module instead? They can always version >> the aggregate module too, right? If they get used to working with an >> aggregate module, isn't it a lot easier for them to support multiple >> different versions of Resteasy for different applications? > > The user should be able to exclude the Apache HC 4.1 (and any Resteasy > modules that depend on it) in jboss-deployment-structure.xml and then > bundle 4.2 and any other Resteasy modules directly in their application. > This way they do not have to actually modify the app server. > Jason also said "I just realized they could class filter the import though which would solve it. They can also take advantage of ordering." Is that as good of a solution? Then we have both a mechanism to define JAX-RS imports for the entire app server (instead of it being hardcoded) and a way to override a specific thing.

-- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com