10:14 p.m.
Chris sent me this rant on overriding built in Resteasy. I replied how
to fix it on his blog. The biggest problem is javaee.api which sucks in
every EE API. Is there a reason you don't trust the subsystems to suck
in the EE APIs they need?
-------- Original Message --------
Subject: dzone rant on resteasy/modules
Date: Fri, 07 Feb 2014 13:49:02 -0500
From: Chris Bredesen <cbredesen(a)redhat.com>
To: Bill Burke <bburke(a)redhat.com>
Just saw this by accident, have fun!
http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
-CB
--
Chris Bredesen
Supervisor, Software Engineering
Red Hat Global Support Services
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:23 p.m.
I think it was just expedience honestly. I agree it would be better to
selectively include API modules by subsystem. Aggregate modules seem to
just cause problems in practice.
On 02/07/2014 03:14 PM, Bill Burke wrote:
Chris sent me this rant on overriding built in Resteasy. I replied
how
to fix it on his blog. The biggest problem is javaee.api which sucks in
every EE API. Is there a reason you don't trust the subsystems to suck
in the EE APIs they need?
-------- Original Message --------
Subject: dzone rant on resteasy/modules
Date: Fri, 07 Feb 2014 13:49:02 -0500
From: Chris Bredesen <cbredesen(a)redhat.com>
To: Bill Burke <bburke(a)redhat.com>
Just saw this by accident, have fun!
http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
-CB
--
- DML
11:23 p.m.
New subject: dzone rant on resteasy/modules
Part of the problem we run into is that the spec says that all java ee APIs
are supposed to be available everywhere. We find situations were like people
use a JSF API inside of a CDI initializer or an EJB initializer.
On Feb 7, 2014, at 3:23 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
I think it was just expedience honestly. I agree it would be better
to
selectively include API modules by subsystem. Aggregate modules seem to
just cause problems in practice.
On 02/07/2014 03:14 PM, Bill Burke wrote:
> Chris sent me this rant on overriding built in Resteasy. I replied how
> to fix it on his blog. The biggest problem is javaee.api which sucks in
> every EE API. Is there a reason you don't trust the subsystems to suck
> in the EE APIs they need?
>
>
> -------- Original Message --------
> Subject: dzone rant on resteasy/modules
> Date: Fri, 07 Feb 2014 13:49:02 -0500
> From: Chris Bredesen <cbredesen(a)redhat.com>
> To: Bill Burke <bburke(a)redhat.com>
>
> Just saw this by accident, have fun!
>
> http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
>
> -CB
>
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
11:26 p.m.
New subject: dzone rant on resteasy/modules
Although I think I am going off an a tangent because it doesn’t prevent subsystem
controlled imports. As longs as subsystems add the imports to all deployment types things
are fine. I agree as well that we should be splitting all of these up.
On Feb 7, 2014, at 4:23 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
Part of the problem we run into is that the spec says that all java
ee APIs
are supposed to be available everywhere. We find situations were like people
use a JSF API inside of a CDI initializer or an EJB initializer.
On Feb 7, 2014, at 3:23 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
> I think it was just expedience honestly. I agree it would be better to
> selectively include API modules by subsystem. Aggregate modules seem to
> just cause problems in practice.
>
> On 02/07/2014 03:14 PM, Bill Burke wrote:
>> Chris sent me this rant on overriding built in Resteasy. I replied how
>> to fix it on his blog. The biggest problem is javaee.api which sucks in
>> every EE API. Is there a reason you don't trust the subsystems to suck
>> in the EE APIs they need?
>>
>>
>> -------- Original Message --------
>> Subject: dzone rant on resteasy/modules
>> Date: Fri, 07 Feb 2014 13:49:02 -0500
>> From: Chris Bredesen <cbredesen(a)redhat.com>
>> To: Bill Burke <bburke(a)redhat.com>
>>
>> Just saw this by accident, have fun!
>>
>> http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
>>
>> -CB
>>
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
8:35 p.m.
New subject: dzone rant on resteasy/modules
On 2/7/2014 5:23 PM, Jason Greene wrote:
Part of the problem we run into is that the spec says that all java
ee APIs
are supposed to be available everywhere. We find situations were like people
use a JSF API inside of a CDI initializer or an EJB initializer.
That is indeed a
problem.
We should really push to have this part of the spec stricken or
revised. In the case of JSF, I've seen customers run into real problems
when they try to access the JSF API from non-web tiers. It might work
for some JSF API's but many calls will fail unexpectedly because there
is no underlying HttpServletRequest.
The lesson here is that you shouldn't let someone use an API in an
environment it wasn't designed for. And the JEE spec should discourage
unintended use rather than make an unsupportable blanket statement that
everything can be used everywhere.
On Feb 7, 2014, at 3:23 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
> I think it was just expedience honestly. I agree it would be better to
> selectively include API modules by subsystem. Aggregate modules seem to
> just cause problems in practice.
>
> On 02/07/2014 03:14 PM, Bill Burke wrote:
>> Chris sent me this rant on overriding built in Resteasy. I replied how
>> to fix it on his blog. The biggest problem is javaee.api which sucks in
>> every EE API. Is there a reason you don't trust the subsystems to suck
>> in the EE APIs they need?
>>
>>
>> -------- Original Message --------
>> Subject: dzone rant on resteasy/modules
>> Date: Fri, 07 Feb 2014 13:49:02 -0500
>> From: Chris Bredesen <cbredesen(a)redhat.com>
>> To: Bill Burke <bburke(a)redhat.com>
>>
>> Just saw this by accident, have fun!
>>
>> http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
>>
>> -CB
>>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:58 p.m.
On semi related note, why does app need direct dependancy to all 10+ rest
easy modules?
couldn't that be done by simply having one/two dependancies that than have
all the other deps exported?
that way it would be much easier to override whole rest easy version.
but ee spec issue still remains...
On Fri, Feb 7, 2014 at 10:14 PM, Bill Burke <bburke(a)redhat.com> wrote:
Chris sent me this rant on overriding built in Resteasy. I replied
how
to fix it on his blog. The biggest problem is javaee.api which sucks in
every EE API. Is there a reason you don't trust the subsystems to suck
in the EE APIs they need?
-------- Original Message --------
Subject: dzone rant on resteasy/modules
Date: Fri, 07 Feb 2014 13:49:02 -0500
From: Chris Bredesen <cbredesen(a)redhat.com>
To: Bill Burke <bburke(a)redhat.com>
Just saw this by accident, have fun!
http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
-CB
--
Chris Bredesen
Supervisor, Software Engineering
Red Hat Global Support Services
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
11:14 p.m.
I've had this conversation with Stuart before about resteasy modules.
We didn't come to a conclusion as there's pro's and con's each way.
BTW, You can't exclude exports, which is the very same problem we're
seeing with ee spec module.
IMO, the problem is with JBoss Modules. If you add an exclude for a
module, you should expect that module to be excluded. Even if that
module is exported by an implicit dependency.
On 2/7/2014 4:58 PM, Tomaž Cerar wrote:
On semi related note, why does app need direct dependancy to all 10+
rest easy modules?
couldn't that be done by simply having one/two dependancies that than
have all the other deps exported?
that way it would be much easier to override whole rest easy version.
but ee spec issue still remains...
On Fri, Feb 7, 2014 at 10:14 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Chris sent me this rant on overriding built in Resteasy. I replied how
to fix it on his blog. The biggest problem is javaee.api which sucks in
every EE API. Is there a reason you don't trust the subsystems to suck
in the EE APIs they need?
-------- Original Message --------
Subject: dzone rant on resteasy/modules
Date: Fri, 07 Feb 2014 13:49:02 -0500
From: Chris Bredesen <cbredesen(a)redhat.com
<mailto:cbredesen@redhat.com>>
To: Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>>
Just saw this by accident, have fun!
http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
-CB
--
Chris Bredesen
Supervisor, Software Engineering
Red Hat Global Support Services
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:28 p.m.
Right now JBoss Modules acts purely on paths, so when you import
something you specify what paths to filter out. This is why I say using
aggregate modules is a bad idea. It makes more sense to have a
user-friendly name for conceptual imports. For example either I want
resteasy (in which case I want all the imports that I need, even if I
don't know I need them (and I won't if I'm a normal user)), or I don't
(in which case I want nothing). Why not categorize imports by
subsystem and have the flag for the subsystem actually exclude the
imports as the user expects?
On 02/07/2014 04:14 PM, Bill Burke wrote:
I've had this conversation with Stuart before about resteasy
modules.
We didn't come to a conclusion as there's pro's and con's each way.
BTW, You can't exclude exports, which is the very same problem we're
seeing with ee spec module.
IMO, the problem is with JBoss Modules. If you add an exclude for a
module, you should expect that module to be excluded. Even if that
module is exported by an implicit dependency.
On 2/7/2014 4:58 PM, Tomaž Cerar wrote:
> On semi related note, why does app need direct dependancy to all 10+
> rest easy modules?
> couldn't that be done by simply having one/two dependancies that than
> have all the other deps exported?
>
> that way it would be much easier to override whole rest easy version.
>
> but ee spec issue still remains...
>
>
> On Fri, Feb 7, 2014 at 10:14 PM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> Chris sent me this rant on overriding built in Resteasy. I replied how
> to fix it on his blog. The biggest problem is javaee.api which sucks in
> every EE API. Is there a reason you don't trust the subsystems to suck
> in the EE APIs they need?
>
>
> -------- Original Message --------
> Subject: dzone rant on resteasy/modules
> Date: Fri, 07 Feb 2014 13:49:02 -0500
> From: Chris Bredesen <cbredesen(a)redhat.com
> <mailto:cbredesen@redhat.com>>
> To: Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>>
>
> Just saw this by accident, have fun!
>
> http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
>
> -CB
>
> --
> Chris Bredesen
> Supervisor, Software Engineering
> Red Hat Global Support Services
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
--
- DML
11:35 p.m.
I think the problem is that RestEasy has N extensions (plugins) per 1 subsystem. So the
generic subsystem exclude doesn’t really match.
On Feb 7, 2014, at 4:28 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
Right now JBoss Modules acts purely on paths, so when you import
something you specify what paths to filter out. This is why I say using
aggregate modules is a bad idea. It makes more sense to have a
user-friendly name for conceptual imports. For example either I want
resteasy (in which case I want all the imports that I need, even if I
don't know I need them (and I won't if I'm a normal user)), or I don't
(in which case I want nothing). Why not categorize imports by
subsystem and have the flag for the subsystem actually exclude the
imports as the user expects?
On 02/07/2014 04:14 PM, Bill Burke wrote:
> I've had this conversation with Stuart before about resteasy modules.
> We didn't come to a conclusion as there's pro's and con's each way.
> BTW, You can't exclude exports, which is the very same problem we're
> seeing with ee spec module.
>
> IMO, the problem is with JBoss Modules. If you add an exclude for a
> module, you should expect that module to be excluded. Even if that
> module is exported by an implicit dependency.
>
> On 2/7/2014 4:58 PM, Tomaž Cerar wrote:
>> On semi related note, why does app need direct dependancy to all 10+
>> rest easy modules?
>> couldn't that be done by simply having one/two dependancies that than
>> have all the other deps exported?
>>
>> that way it would be much easier to override whole rest easy version.
>>
>> but ee spec issue still remains...
>>
>>
>> On Fri, Feb 7, 2014 at 10:14 PM, Bill Burke <bburke(a)redhat.com
>> <mailto:bburke@redhat.com>> wrote:
>>
>> Chris sent me this rant on overriding built in Resteasy. I replied how
>> to fix it on his blog. The biggest problem is javaee.api which sucks in
>> every EE API. Is there a reason you don't trust the subsystems to suck
>> in the EE APIs they need?
>>
>>
>> -------- Original Message --------
>> Subject: dzone rant on resteasy/modules
>> Date: Fri, 07 Feb 2014 13:49:02 -0500
>> From: Chris Bredesen <cbredesen(a)redhat.com
>> <mailto:cbredesen@redhat.com>>
>> To: Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>>
>>
>> Just saw this by accident, have fun!
>>
>> http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
>>
>> -CB
>>
>> --
>> Chris Bredesen
>> Supervisor, Software Engineering
>> Red Hat Global Support Services
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
11:43 p.m.
Not following you. Its already catagorized, isn't it? Via the implicit
dependencies added by the jaxrs subsystem? The problem of the OP was
that a different subsystem is adding java.ee.api. The user wanted to
use Resteasy 3.0.6 with EAP 6 and couldn't find the magic sauce to do it.
On 2/7/2014 5:35 PM, Jason Greene wrote:
I think the problem is that RestEasy has N extensions (plugins) per 1
subsystem. So the generic subsystem exclude doesn’t really match.
On Feb 7, 2014, at 4:28 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
> Right now JBoss Modules acts purely on paths, so when you import
> something you specify what paths to filter out. This is why I say using
> aggregate modules is a bad idea. It makes more sense to have a
> user-friendly name for conceptual imports. For example either I want
> resteasy (in which case I want all the imports that I need, even if I
> don't know I need them (and I won't if I'm a normal user)), or I
don't
> (in which case I want nothing). Why not categorize imports by
> subsystem and have the flag for the subsystem actually exclude the
> imports as the user expects?
>
> On 02/07/2014 04:14 PM, Bill Burke wrote:
>> I've had this conversation with Stuart before about resteasy modules.
>> We didn't come to a conclusion as there's pro's and con's each
way.
>> BTW, You can't exclude exports, which is the very same problem we're
>> seeing with ee spec module.
>>
>> IMO, the problem is with JBoss Modules. If you add an exclude for a
>> module, you should expect that module to be excluded. Even if that
>> module is exported by an implicit dependency.
>>
>> On 2/7/2014 4:58 PM, Tomaž Cerar wrote:
>>> On semi related note, why does app need direct dependancy to all 10+
>>> rest easy modules?
>>> couldn't that be done by simply having one/two dependancies that than
>>> have all the other deps exported?
>>>
>>> that way it would be much easier to override whole rest easy version.
>>>
>>> but ee spec issue still remains...
>>>
>>>
>>> On Fri, Feb 7, 2014 at 10:14 PM, Bill Burke <bburke(a)redhat.com
>>> <mailto:bburke@redhat.com>> wrote:
>>>
>>> Chris sent me this rant on overriding built in Resteasy. I replied how
>>> to fix it on his blog. The biggest problem is javaee.api which sucks
in
>>> every EE API. Is there a reason you don't trust the subsystems to
suck
>>> in the EE APIs they need?
>>>
>>>
>>> -------- Original Message --------
>>> Subject: dzone rant on resteasy/modules
>>> Date: Fri, 07 Feb 2014 13:49:02 -0500
>>> From: Chris Bredesen <cbredesen(a)redhat.com
>>> <mailto:cbredesen@redhat.com>>
>>> To: Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>>
>>>
>>> Just saw this by accident, have fun!
>>>
>>> http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
>>>
>>> -CB
>>>
>>> --
>>> Chris Bredesen
>>> Supervisor, Software Engineering
>>> Red Hat Global Support Services
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:54 p.m.
Got it. Ok this looks like an oversight. We should remove javax.ws.rs.api from javaee.api
and have the rest easy subsystem add that API as desired.
On Feb 7, 2014, at 4:43 PM, Bill Burke <bburke(a)redhat.com> wrote:
Not following you. Its already catagorized, isn't it? Via the
implicit
dependencies added by the jaxrs subsystem? The problem of the OP was
that a different subsystem is adding java.ee.api. The user wanted to
use Resteasy 3.0.6 with EAP 6 and couldn't find the magic sauce to do it.
On 2/7/2014 5:35 PM, Jason Greene wrote:
> I think the problem is that RestEasy has N extensions (plugins) per 1 subsystem. So
the generic subsystem exclude doesn’t really match.
>
> On Feb 7, 2014, at 4:28 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
>
>> Right now JBoss Modules acts purely on paths, so when you import
>> something you specify what paths to filter out. This is why I say using
>> aggregate modules is a bad idea. It makes more sense to have a
>> user-friendly name for conceptual imports. For example either I want
>> resteasy (in which case I want all the imports that I need, even if I
>> don't know I need them (and I won't if I'm a normal user)), or I
don't
>> (in which case I want nothing). Why not categorize imports by
>> subsystem and have the flag for the subsystem actually exclude the
>> imports as the user expects?
>>
>> On 02/07/2014 04:14 PM, Bill Burke wrote:
>>> I've had this conversation with Stuart before about resteasy modules.
>>> We didn't come to a conclusion as there's pro's and con's
each way.
>>> BTW, You can't exclude exports, which is the very same problem
we're
>>> seeing with ee spec module.
>>>
>>> IMO, the problem is with JBoss Modules. If you add an exclude for a
>>> module, you should expect that module to be excluded. Even if that
>>> module is exported by an implicit dependency.
>>>
>>> On 2/7/2014 4:58 PM, Tomaž Cerar wrote:
>>>> On semi related note, why does app need direct dependancy to all 10+
>>>> rest easy modules?
>>>> couldn't that be done by simply having one/two dependancies that
than
>>>> have all the other deps exported?
>>>>
>>>> that way it would be much easier to override whole rest easy version.
>>>>
>>>> but ee spec issue still remains...
>>>>
>>>>
>>>> On Fri, Feb 7, 2014 at 10:14 PM, Bill Burke <bburke(a)redhat.com
>>>> <mailto:bburke@redhat.com>> wrote:
>>>>
>>>> Chris sent me this rant on overriding built in Resteasy. I replied
how
>>>> to fix it on his blog. The biggest problem is javaee.api which sucks
in
>>>> every EE API. Is there a reason you don't trust the subsystems
to suck
>>>> in the EE APIs they need?
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: dzone rant on resteasy/modules
>>>> Date: Fri, 07 Feb 2014 13:49:02 -0500
>>>> From: Chris Bredesen <cbredesen(a)redhat.com
>>>> <mailto:cbredesen@redhat.com>>
>>>> To: Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>>
>>>>
>>>> Just saw this by accident, have fun!
>>>>
>>>> http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
>>>>
>>>> -CB
>>>>
>>>> --
>>>> Chris Bredesen
>>>> Supervisor, Software Engineering
>>>> Red Hat Global Support Services
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>
>>
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
11:56 p.m.
New subject: dzone rant on resteasy/modules
We need to audit the rest as well the exclude subsystem feature was added after javaee.api
was created so there is other stuff in here that needs to be pulled out.
On Feb 7, 2014, at 4:54 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
Got it. Ok this looks like an oversight. We should remove
javax.ws.rs.api from javaee.api and have the rest easy subsystem add that API as desired.
On Feb 7, 2014, at 4:43 PM, Bill Burke <bburke(a)redhat.com> wrote:
> Not following you. Its already catagorized, isn't it? Via the implicit
> dependencies added by the jaxrs subsystem? The problem of the OP was
> that a different subsystem is adding java.ee.api. The user wanted to
> use Resteasy 3.0.6 with EAP 6 and couldn't find the magic sauce to do it.
>
> On 2/7/2014 5:35 PM, Jason Greene wrote:
>> I think the problem is that RestEasy has N extensions (plugins) per 1 subsystem.
So the generic subsystem exclude doesn’t really match.
>>
>> On Feb 7, 2014, at 4:28 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
>>
>>> Right now JBoss Modules acts purely on paths, so when you import
>>> something you specify what paths to filter out. This is why I say using
>>> aggregate modules is a bad idea. It makes more sense to have a
>>> user-friendly name for conceptual imports. For example either I want
>>> resteasy (in which case I want all the imports that I need, even if I
>>> don't know I need them (and I won't if I'm a normal user)), or I
don't
>>> (in which case I want nothing). Why not categorize imports by
>>> subsystem and have the flag for the subsystem actually exclude the
>>> imports as the user expects?
>>>
>>> On 02/07/2014 04:14 PM, Bill Burke wrote:
>>>> I've had this conversation with Stuart before about resteasy
modules.
>>>> We didn't come to a conclusion as there's pro's and con's
each way.
>>>> BTW, You can't exclude exports, which is the very same problem
we're
>>>> seeing with ee spec module.
>>>>
>>>> IMO, the problem is with JBoss Modules. If you add an exclude for a
>>>> module, you should expect that module to be excluded. Even if that
>>>> module is exported by an implicit dependency.
>>>>
>>>> On 2/7/2014 4:58 PM, Tomaž Cerar wrote:
>>>>> On semi related note, why does app need direct dependancy to all 10+
>>>>> rest easy modules?
>>>>> couldn't that be done by simply having one/two dependancies that
than
>>>>> have all the other deps exported?
>>>>>
>>>>> that way it would be much easier to override whole rest easy
version.
>>>>>
>>>>> but ee spec issue still remains...
>>>>>
>>>>>
>>>>> On Fri, Feb 7, 2014 at 10:14 PM, Bill Burke <bburke(a)redhat.com
>>>>> <mailto:bburke@redhat.com>> wrote:
>>>>>
>>>>> Chris sent me this rant on overriding built in Resteasy. I
replied how
>>>>> to fix it on his blog. The biggest problem is javaee.api which
sucks in
>>>>> every EE API. Is there a reason you don't trust the
subsystems to suck
>>>>> in the EE APIs they need?
>>>>>
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: dzone rant on resteasy/modules
>>>>> Date: Fri, 07 Feb 2014 13:49:02 -0500
>>>>> From: Chris Bredesen <cbredesen(a)redhat.com
>>>>> <mailto:cbredesen@redhat.com>>
>>>>> To: Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>>
>>>>>
>>>>> Just saw this by accident, have fun!
>>>>>
>>>>> http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
>>>>>
>>>>> -CB
>>>>>
>>>>> --
>>>>> Chris Bredesen
>>>>> Supervisor, Software Engineering
>>>>> Red Hat Global Support Services
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
3:56 a.m.
I thought I had fixed the javaee api issue by replacing its usage
everywhere in Wildfly with the relevant individual EE module.
It looks like a few static modules still depend on it but that should not
affect deployments.
Stuart
On Fri, Feb 7, 2014 at 11:14 PM, Bill Burke <bburke(a)redhat.com> wrote:
Chris sent me this rant on overriding built in Resteasy. I replied
how
to fix it on his blog. The biggest problem is javaee.api which sucks in
every EE API. Is there a reason you don't trust the subsystems to suck
in the EE APIs they need?
-------- Original Message --------
Subject: dzone rant on resteasy/modules
Date: Fri, 07 Feb 2014 13:49:02 -0500
From: Chris Bredesen <cbredesen(a)redhat.com>
To: Bill Burke <bburke(a)redhat.com>
Just saw this by accident, have fun!
http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
-CB
--
Chris Bredesen
Supervisor, Software Engineering
Red Hat Global Support Services
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:35 p.m.
The OP was on EAP I believe.
On 2/7/2014 9:56 PM, Stuart Douglas wrote:
I thought I had fixed the javaee api issue by replacing its usage
everywhere in Wildfly with the relevant individual EE module.
It looks like a few static modules still depend on it but that should
not affect deployments.
Stuart
On Fri, Feb 7, 2014 at 11:14 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Chris sent me this rant on overriding built in Resteasy. I replied how
to fix it on his blog. The biggest problem is javaee.api which sucks in
every EE API. Is there a reason you don't trust the subsystems to suck
in the EE APIs they need?
-------- Original Message --------
Subject: dzone rant on resteasy/modules
Date: Fri, 07 Feb 2014 13:49:02 -0500
From: Chris Bredesen <cbredesen(a)redhat.com
<mailto:cbredesen@redhat.com>>
To: Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>>
Just saw this by accident, have fun!
http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
-CB
--
Chris Bredesen
Supervisor, Software Engineering
Red Hat Global Support Services
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3722
days inactive
3724
days old
13 comments
6 participants
participants (6)
-
Bill Burke -
David M. Lloyd -
Jason Greene -
ssilvert＠redhat.com -
Stuart Douglas -
Tomaž Cerar