On 9/12/2012 2:39 PM, Jason Greene wrote:

On Sep 12, 2012, at 1:13 PM, Bill Burke <bburke@redhat.com> 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?

On Sep 12, 2012, at 1:13 PM, Bill Burke <bburke@redhat.com> 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev