On 09/12/2012 02:37 PM, Bill Burke wrote:
On 9/12/2012 2:39 PM, Jason Greene wrote:
>
> On Sep 12, 2012, at 1:13 PM, Bill Burke <bburke(a)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?
No, overriding won't work. In this case I think the best approach is to
include these constituent APIs in with the aggregate and pull it in to
the deployment when they use JAX-RS. If JAX-RS uses a specific HC
version then the user simply doesn't have the option of using any other
version when using JAX-RS - there's no getting around that. But it
might be good to only import these libraries into the deployment if
they're actually using JAX-RS.
--
- DML