5:47 a.m.
Working with the split repo just questioning if JMX is really needed in
core?
Whilst most distributions would include it I am not convinced it is a
subsystem all must have.
Regards,
Darran Lofthouse.
6:52 a.m.
Unfortunately it is needed.
At least at this point of the project.
I tired hard not to have it back when I was doing just separate core build.
Current dependency tree for it includes:
- wildfly-server
- wildfly-system-jmx
+ arquillian, but that is not a problem anymore given that we moved it out
of core and it is not required anymore.
But probably we can revisit that and try to remove it now that there is no
need for arq anymore in core.
Big chunk of core testsuite will need to be updated to not use jmx
subsystem anymore.
Darren, can you create jira for this and assign it to me? I will take look.
--
tomaz
On Wed, Jul 9, 2014 at 12:47 PM, Darran Lofthouse <
darran.lofthouse(a)jboss.com> wrote:
Working with the split repo just questioning if JMX is really needed
in
core?
Whilst most distributions would include it I am not convinced it is a
subsystem all must have.
Regards,
Darran Lofthouse.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:26 a.m.
IMHO wildfly-system-jmx does not need to be in core. It's analogous to
wildfly-pojo and that's not in core.
We should sort out the wildfly-server dependency, whatever it is, and
either eliminate it or make it something that relies on an optional
capability.
On 7/9/14, 6:52 AM, Tomaž Cerar wrote:
Unfortunately it is needed.
At least at this point of the project.
I tired hard not to have it back when I was doing just separate core build.
Current dependency tree for it includes:
- wildfly-server
- wildfly-system-jmx
+ arquillian, but that is not a problem anymore given that we moved it
out of core and it is not required anymore.
But probably we can revisit that and try to remove it now that there is
no need for arq anymore in core.
Big chunk of core testsuite will need to be updated to not use jmx
subsystem anymore.
Darren, can you create jira for this and assign it to me? I will take look.
--
tomaz
On Wed, Jul 9, 2014 at 12:47 PM, Darran Lofthouse
<darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@jboss.com>> wrote:
Working with the split repo just questioning if JMX is really needed in
core?
Whilst most distributions would include it I am not convinced it is a
subsystem all must have.
Regards,
Darran Lofthouse.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
12:53 p.m.
On Wed, Jul 9, 2014 at 3:26 PM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
We should sort out the wildfly-server dependency, whatever it is,
and
either eliminate it or make it something that relies on an optional
capability.
Agreed, most of the hard deps ware because of ARQ container needs, but that
is gone now.
I have most of work done to move it out. just need some more testing.
One thing that looks fishy is Audit logging (part of controller) that has
hard coded mgmt paths to JMX subsystem
not really sure how this works if jmx is not present.
Kabir, if we move jmx out will there be any issues with that? Beyond fact
that audit logging working only when jmx subsystem is present?
--
tomaz
2:34 p.m.
On 9 Jul 2014, at 18:53, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
On Wed, Jul 9, 2014 at 3:26 PM, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
We should sort out the wildfly-server dependency, whatever it is, and
either eliminate it or make it something that relies on an optional
capability.
Agreed, most of the hard deps ware because of ARQ container needs, but that is gone now.
I have most of work done to move it out. just need some more testing.
One thing that looks fishy is Audit logging (part of controller) that has hard coded mgmt
paths to JMX subsystem
not really sure how this works if jmx is not present.
Kabir, if we move jmx out will there be any issues with that? Beyond fact that audit
logging working only when jmx subsystem is present?
IIRC all it does is when you
remove an audit log handler, to look under subsystem=jmx to make sure it’s audit logger is
not using the handler. So it should not be an issue.
--
tomaz
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12:13 p.m.
As requested: -
https://issues.jboss.org/browse/WFLY-3605
Regards,
Darran Lofthouse.
On 09/07/14 12:52, Tomaž Cerar wrote:
Unfortunately it is needed.
At least at this point of the project.
I tired hard not to have it back when I was doing just separate core build.
Current dependency tree for it includes:
- wildfly-server
- wildfly-system-jmx
+ arquillian, but that is not a problem anymore given that we moved it
out of core and it is not required anymore.
But probably we can revisit that and try to remove it now that there is
no need for arq anymore in core.
Big chunk of core testsuite will need to be updated to not use jmx
subsystem anymore.
Darren, can you create jira for this and assign it to me? I will take look.
--
tomaz
On Wed, Jul 9, 2014 at 12:47 PM, Darran Lofthouse
<darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@jboss.com>> wrote:
Working with the split repo just questioning if JMX is really needed in
core?
Whilst most distributions would include it I am not convinced it is a
subsystem all must have.
Regards,
Darran Lofthouse.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12:53 p.m.
On Wed, Jul 9, 2014 at 7:13 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com
wrote:
As requested: -
https://issues.jboss.org/browse/WFLY-3605
Tnx
1:27 p.m.
My earlier reply on this thread was in the branch focused on the
technical detail of how the dependency arises. Which should be fixed;
sounds like that's happening.
On the broader question of where stuff belongs, JMX is an interesting
case. Lots of users will want JMX. A number of subsystems have optional
dependencies on it, including some like jgroups and infinispan that may
end up being part of their own dist, separate from the full dist.
So what's the plan for catering to these needs? Ship it in the full dist
and those who want it depend on the full dist but configure the
provisioning tool to only grab the JMX modules? Make it a micro-dist?
Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
the "deploy your own services" dist? (I don't like that last one, just
brainstorming...)
On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
Working with the split repo just questioning if JMX is really needed
in
core?
Whilst most distributions would include it I am not convinced it is a
subsystem all must have.
Manageable logging isn't either. Lots of people used logging.properties
for a long time.
Note I'm not advocating removing logging from core; I'm just saying that
no subsystem has to be in core if that's the criteria.
Regards,
Darran Lofthouse.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
1:32 p.m.
Shouldn't it be like an onion?
A more bare core. A Core with monitoring capabilities. And so on.
On 2014-07-09, 2:27 PM, Brian Stansberry wrote:
My earlier reply on this thread was in the branch focused on the
technical detail of how the dependency arises. Which should be fixed;
sounds like that's happening.
On the broader question of where stuff belongs, JMX is an interesting
case. Lots of users will want JMX. A number of subsystems have optional
dependencies on it, including some like jgroups and infinispan that may
end up being part of their own dist, separate from the full dist.
So what's the plan for catering to these needs? Ship it in the full dist
and those who want it depend on the full dist but configure the
provisioning tool to only grab the JMX modules? Make it a micro-dist?
Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
the "deploy your own services" dist? (I don't like that last one, just
brainstorming...)
On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
> Working with the split repo just questioning if JMX is really needed in
> core?
>
> Whilst most distributions would include it I am not convinced it is a
> subsystem all must have.
>
Manageable logging isn't either. Lots of people used logging.properties
for a long time.
Note I'm not advocating removing logging from core; I'm just saying that
no subsystem has to be in core if that's the criteria.
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
1:59 p.m.
The problem with that is that if you take it to its fullest extent you
end up with one subsystem per repo, which is not something we want.
I am not sure where the best place for it is, even if it stays in core
it should be possible for the tooling to exclude it, same with logging.
Otherwise I think the place for it to live would be the web distro, as I
think that people will definitely want to be able to use JMX to manage
that.
Stuart
Fernando Nasser wrote:
Shouldn't it be like an onion?
A more bare core. A Core with monitoring capabilities. And so on.
On 2014-07-09, 2:27 PM, Brian Stansberry wrote:
> My earlier reply on this thread was in the branch focused on the
> technical detail of how the dependency arises. Which should be fixed;
> sounds like that's happening.
>
> On the broader question of where stuff belongs, JMX is an interesting
> case. Lots of users will want JMX. A number of subsystems have optional
> dependencies on it, including some like jgroups and infinispan that may
> end up being part of their own dist, separate from the full dist.
>
> So what's the plan for catering to these needs? Ship it in the full dist
> and those who want it depend on the full dist but configure the
> provisioning tool to only grab the JMX modules? Make it a micro-dist?
> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
> the "deploy your own services" dist? (I don't like that last one, just
> brainstorming...)
>
> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>> Working with the split repo just questioning if JMX is really needed in
>> core?
>>
>> Whilst most distributions would include it I am not convinced it is a
>> subsystem all must have.
>>
> Manageable logging isn't either. Lots of people used logging.properties
> for a long time.
>
> Note I'm not advocating removing logging from core; I'm just saying that
> no subsystem has to be in core if that's the criteria.
>
>> Regards,
>> Darran Lofthouse.
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:35 p.m.
On 7/9/14, 1:59 PM, Stuart Douglas wrote:
The problem with that is that if you take it to its fullest extent
you
end up with one subsystem per repo, which is not something we want.
I am not sure where the best place for it is, even if it stays in core
it should be possible for the tooling to exclude it, same with logging.
Otherwise I think the place for it to live would be the web distro, as I
think that people will definitely want to be able to use JMX to manage
that.
So the web build is becoming the spot where foundational stuff like this
and Elytron come in? The core is uber-minimal for the folks who really
want that, and then web has these things that lots and lots of folks
will want.
In the odd case where folks want this foundational stuff but not
undertow etc, they can just depend on the web build and exclude
undertow. Real corner case. And folks who don't want the foundational
stuff exclude it.
I can see that working out pretty well.
Does logging belong in web then then? Still seems like something that
even the uber-minimalists would want. I ask because it bugs me that we
have two meanings now for "core" -- the old "core" notion that was the
true core with zero subsystems, and now this new wildfly-core dist,
which has subsystems.
Fernando Nasser wrote:
> Shouldn't it be like an onion?
>
> A more bare core. A Core with monitoring capabilities. And so on.
>
>
> On 2014-07-09, 2:27 PM, Brian Stansberry wrote:
>> My earlier reply on this thread was in the branch focused on the
>> technical detail of how the dependency arises. Which should be fixed;
>> sounds like that's happening.
>>
>> On the broader question of where stuff belongs, JMX is an interesting
>> case. Lots of users will want JMX. A number of subsystems have optional
>> dependencies on it, including some like jgroups and infinispan that may
>> end up being part of their own dist, separate from the full dist.
>>
>> So what's the plan for catering to these needs? Ship it in the full dist
>> and those who want it depend on the full dist but configure the
>> provisioning tool to only grab the JMX modules? Make it a micro-dist?
>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
>> the "deploy your own services" dist? (I don't like that last one,
just
>> brainstorming...)
>>
>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>>> Working with the split repo just questioning if JMX is really needed in
>>> core?
>>>
>>> Whilst most distributions would include it I am not convinced it is a
>>> subsystem all must have.
>>>
>> Manageable logging isn't either. Lots of people used logging.properties
>> for a long time.
>>
>> Note I'm not advocating removing logging from core; I'm just saying that
>> no subsystem has to be in core if that's the criteria.
>>
>>> Regards,
>>> Darran Lofthouse.
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
3:09 p.m.
Brian Stansberry wrote:
On 7/9/14, 1:59 PM, Stuart Douglas wrote:
> The problem with that is that if you take it to its fullest extent you
> end up with one subsystem per repo, which is not something we want.
>
> I am not sure where the best place for it is, even if it stays in core
> it should be possible for the tooling to exclude it, same with logging.
>
> Otherwise I think the place for it to live would be the web distro, as I
> think that people will definitely want to be able to use JMX to manage
> that.
>
So the web build is becoming the spot where foundational stuff like this
and Elytron come in? The core is uber-minimal for the folks who really
want that, and then web has these things that lots and lots of folks
will want.
In the odd case where folks want this foundational stuff but not
undertow etc, they can just depend on the web build and exclude
undertow. Real corner case. And folks who don't want the foundational
stuff exclude it.
I can see that working out pretty well.
Does logging belong in web then then? Still seems like something that
even the uber-minimalists would want. I ask because it bugs me that we
have two meanings now for "core" -- the old "core" notion that was
the
true core with zero subsystems, and now this new wildfly-core dist,
which has subsystems.
I'm really not sure. TBH from a practical sense I don't think it makes
any real difference, its more of an idealogical thing.
I guess if we look at web as being 'all the stuff that people will
probably need' then it makes sense that logging, jmx and
deployment-scanner live there instead of core.
Stuart
>
>
> Fernando Nasser wrote:
>> Shouldn't it be like an onion?
>>
>> A more bare core. A Core with monitoring capabilities. And so on.
>>
>>
>> On 2014-07-09, 2:27 PM, Brian Stansberry wrote:
>>> My earlier reply on this thread was in the branch focused on the
>>> technical detail of how the dependency arises. Which should be fixed;
>>> sounds like that's happening.
>>>
>>> On the broader question of where stuff belongs, JMX is an interesting
>>> case. Lots of users will want JMX. A number of subsystems have optional
>>> dependencies on it, including some like jgroups and infinispan that may
>>> end up being part of their own dist, separate from the full dist.
>>>
>>> So what's the plan for catering to these needs? Ship it in the full dist
>>> and those who want it depend on the full dist but configure the
>>> provisioning tool to only grab the JMX modules? Make it a micro-dist?
>>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
>>> the "deploy your own services" dist? (I don't like that last
one, just
>>> brainstorming...)
>>>
>>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>>>> Working with the split repo just questioning if JMX is really needed in
>>>> core?
>>>>
>>>> Whilst most distributions would include it I am not convinced it is a
>>>> subsystem all must have.
>>>>
>>> Manageable logging isn't either. Lots of people used logging.properties
>>> for a long time.
>>>
>>> Note I'm not advocating removing logging from core; I'm just saying
that
>>> no subsystem has to be in core if that's the criteria.
>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
3:26 p.m.
On Jul 9, 2014, at 3:09 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com> wrote:
Brian Stansberry wrote:
> On 7/9/14, 1:59 PM, Stuart Douglas wrote:
>> The problem with that is that if you take it to its fullest extent you
>> end up with one subsystem per repo, which is not something we want.
>>
>> I am not sure where the best place for it is, even if it stays in core
>> it should be possible for the tooling to exclude it, same with logging.
>>
>> Otherwise I think the place for it to live would be the web distro, as I
>> think that people will definitely want to be able to use JMX to manage
>> that.
>>
>
> So the web build is becoming the spot where foundational stuff like this
> and Elytron come in? The core is uber-minimal for the folks who really
> want that, and then web has these things that lots and lots of folks
> will want.
>
> In the odd case where folks want this foundational stuff but not
> undertow etc, they can just depend on the web build and exclude
> undertow. Real corner case. And folks who don't want the foundational
> stuff exclude it.
>
> I can see that working out pretty well.
>
> Does logging belong in web then then? Still seems like something that
> even the uber-minimalists would want. I ask because it bugs me that we
> have two meanings now for "core" -- the old "core" notion that
was the
> true core with zero subsystems, and now this new wildfly-core dist,
> which has subsystems.
I'm really not sure. TBH from a practical sense I don't think it makes
any real difference, its more of an idealogical thing.
I guess if we look at web as being 'all the stuff that people will
probably need' then it makes sense that logging, jmx and
deployment-scanner live there instead of core.
-1 to moving deployment scanner and logging out of core.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
5:18 p.m.
On 7/9/14, 3:26 PM, Jason Greene wrote:
On Jul 9, 2014, at 3:09 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com> wrote:
>
>
> Brian Stansberry wrote:
>> On 7/9/14, 1:59 PM, Stuart Douglas wrote:
>>> The problem with that is that if you take it to its fullest extent you
>>> end up with one subsystem per repo, which is not something we want.
>>>
>>> I am not sure where the best place for it is, even if it stays in core
>>> it should be possible for the tooling to exclude it, same with logging.
>>>
>>> Otherwise I think the place for it to live would be the web distro, as I
>>> think that people will definitely want to be able to use JMX to manage
>>> that.
>>>
>>
>> So the web build is becoming the spot where foundational stuff like this
>> and Elytron come in? The core is uber-minimal for the folks who really
>> want that, and then web has these things that lots and lots of folks
>> will want.
>>
>> In the odd case where folks want this foundational stuff but not
>> undertow etc, they can just depend on the web build and exclude
>> undertow. Real corner case. And folks who don't want the foundational
>> stuff exclude it.
>>
>> I can see that working out pretty well.
>>
>> Does logging belong in web then then? Still seems like something that
>> even the uber-minimalists would want. I ask because it bugs me that we
>> have two meanings now for "core" -- the old "core" notion
that was the
>> true core with zero subsystems, and now this new wildfly-core dist,
>> which has subsystems.
>
> I'm really not sure. TBH from a practical sense I don't think it makes
> any real difference, its more of an idealogical thing.
>
I'd say it's more of a documentation thing. IOW I'm not so much
concerned about conceptual purity of the core dist as I am about having
the same word mean two different things in things like docs. The term
also appears in the management model:
/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=credential
vs subsystem specific stuff:
/core-service=management/access=authorization/constraint=sensitivity-classification/type=datasources/classification=data-source-security
It probably won't really matter though. People are smart and the ones
who aren't probably won't notice.
> I guess if we look at web as being 'all the stuff that people
will
> probably need' then it makes sense that logging, jmx and
> deployment-scanner live there instead of core.
I forgot about the scanner.
-1 to moving deployment scanner and logging out of core.
And the gavel slams. :)
I love the sound of the gavel.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
5:49 a.m.
To me in this thread 'web' is really sounding like the common base most
would really want to use - they can go back to core if they really want
minimalistic.
Web seems to be the holder for the subsystems that get identified as
required by most just not all.
On 09/07/14 21:09, Stuart Douglas wrote:
Brian Stansberry wrote:
> On 7/9/14, 1:59 PM, Stuart Douglas wrote:
>> The problem with that is that if you take it to its fullest extent you
>> end up with one subsystem per repo, which is not something we want.
>>
>> I am not sure where the best place for it is, even if it stays in core
>> it should be possible for the tooling to exclude it, same with logging.
>>
>> Otherwise I think the place for it to live would be the web distro, as I
>> think that people will definitely want to be able to use JMX to manage
>> that.
>>
>
> So the web build is becoming the spot where foundational stuff like this
> and Elytron come in? The core is uber-minimal for the folks who really
> want that, and then web has these things that lots and lots of folks
> will want.
>
> In the odd case where folks want this foundational stuff but not
> undertow etc, they can just depend on the web build and exclude
> undertow. Real corner case. And folks who don't want the foundational
> stuff exclude it.
>
> I can see that working out pretty well.
>
> Does logging belong in web then then? Still seems like something that
> even the uber-minimalists would want. I ask because it bugs me that we
> have two meanings now for "core" -- the old "core" notion that
was the
> true core with zero subsystems, and now this new wildfly-core dist,
> which has subsystems.
I'm really not sure. TBH from a practical sense I don't think it makes
any real difference, its more of an idealogical thing.
I guess if we look at web as being 'all the stuff that people will
probably need' then it makes sense that logging, jmx and
deployment-scanner live there instead of core.
Stuart
>
>>
>>
>> Fernando Nasser wrote:
>>> Shouldn't it be like an onion?
>>>
>>> A more bare core. A Core with monitoring capabilities. And so on.
>>>
>>>
>>> On 2014-07-09, 2:27 PM, Brian Stansberry wrote:
>>>> My earlier reply on this thread was in the branch focused on the
>>>> technical detail of how the dependency arises. Which should be fixed;
>>>> sounds like that's happening.
>>>>
>>>> On the broader question of where stuff belongs, JMX is an interesting
>>>> case. Lots of users will want JMX. A number of subsystems have optional
>>>> dependencies on it, including some like jgroups and infinispan that may
>>>> end up being part of their own dist, separate from the full dist.
>>>>
>>>> So what's the plan for catering to these needs? Ship it in the full
dist
>>>> and those who want it depend on the full dist but configure the
>>>> provisioning tool to only grab the JMX modules? Make it a micro-dist?
>>>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
>>>> the "deploy your own services" dist? (I don't like that
last one, just
>>>> brainstorming...)
>>>>
>>>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>>>>> Working with the split repo just questioning if JMX is really needed
in
>>>>> core?
>>>>>
>>>>> Whilst most distributions would include it I am not convinced it is
a
>>>>> subsystem all must have.
>>>>>
>>>> Manageable logging isn't either. Lots of people used
logging.properties
>>>> for a long time.
>>>>
>>>> Note I'm not advocating removing logging from core; I'm just
saying that
>>>> no subsystem has to be in core if that's the criteria.
>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
6 p.m.
On Wed, Jul 9, 2014 at 9:35 PM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
Does logging belong in web then then? Still seems like something that
even the uber-minimalists would want. I ask because it bugs me that we
have two meanings now for "core" -- the old "core" notion that was
the
true core with zero subsystems, and now this new wildfly-core dist,
which has subsystems.
Core *current* comes with following subsystems:
- logging
- jmx (on the way out)
- deployment-scanner
- remoting
- io (because of remoting)
I agree that jmx needs to go out,
deployment scanner needs to stay.
And remoting is needed to make cli & alike work...
5:51 a.m.
On 10/07/14 00:00, Tomaž Cerar wrote:
On Wed, Jul 9, 2014 at 9:35 PM, Brian Stansberry
<brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote:
Does logging belong in web then then? Still seems like something that
even the uber-minimalists would want. I ask because it bugs me that we
have two meanings now for "core" -- the old "core" notion that
was the
true core with zero subsystems, and now this new wildfly-core dist,
which has subsystems.
Core *current* comes with following subsystems:
- logging
- jmx (on the way out)
- deployment-scanner
- remoting
- io (because of remoting)
I agree that jmx needs to go out,
deployment scanner needs to stay.
And remoting is needed to make cli & alike work...
In my mind the main thing I think that defines the core is that is
provides you with a base manageable server, Remoting is an integral part
of that.
JMX on the other hand is additional functionality layered on top,
closely related to management but not a requirement of it.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:03 a.m.
On 7/9/14, 6:00 PM, Tomaž Cerar wrote:
On Wed, Jul 9, 2014 at 9:35 PM, Brian Stansberry
<brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote:
Does logging belong in web then then? Still seems like something that
even the uber-minimalists would want. I ask because it bugs me that we
have two meanings now for "core" -- the old "core" notion that
was the
true core with zero subsystems, and now this new wildfly-core dist,
which has subsystems.
Core *current* comes with following subsystems:
- logging
- jmx (on the way out)
- deployment-scanner
- remoting
- io (because of remoting)
I agree that jmx needs to go out,
deployment scanner needs to stay.
And remoting is needed to make cli & alike work...
Remoting and io libs are needed, but not the subsystems themselves.
But, we've discussed some having the current <management> stuff becoming
subsystems once we have proper HC extensions/subsystems, so at that
point there *will be* subsystems needed for core.
Seems my concern about two meanings of "core" won't matter at that point
anyway.
Thanks.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
10:43 a.m.
I have send PR removing jmx subsystem from core
https://github.com/wildfly/wildfly-core/pull/57
but to send PR for inclusion to full WildFly repo new release of core is
needed as jmx subsystem is using new transformers API we have in core.
--
tomaz
On Thu, Jul 10, 2014 at 4:03 PM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
On 7/9/14, 6:00 PM, Tomaž Cerar wrote:
>
> On Wed, Jul 9, 2014 at 9:35 PM, Brian Stansberry
> <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>>
wrote:
>
>
> Does logging belong in web then then? Still seems like something that
> even the uber-minimalists would want. I ask because it bugs me that we
> have two meanings now for "core" -- the old "core" notion
that was the
> true core with zero subsystems, and now this new wildfly-core dist,
> which has subsystems.
>
>
> Core *current* comes with following subsystems:
> - logging
> - jmx (on the way out)
> - deployment-scanner
> - remoting
> - io (because of remoting)
>
> I agree that jmx needs to go out,
> deployment scanner needs to stay.
> And remoting is needed to make cli & alike work...
>
>
Remoting and io libs are needed, but not the subsystems themselves.
But, we've discussed some having the current <management> stuff becoming
subsystems once we have proper HC extensions/subsystems, so at that point
there *will be* subsystems needed for core.
Seems my concern about two meanings of "core" won't matter at that point
anyway.
Thanks.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
5:40 a.m.
On 24 Jul 2014, at 17:43, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
I have send PR removing jmx subsystem from core
https://github.com/wildfly/wildfly-core/pull/57
but to send PR for inclusion to full WildFly repo new release of core is needed as jmx
subsystem is using new transformers API we have in core.
It’s a minor thing but our jconsole.* scripts still live in wildfly repo.
For consistency sake, we should have them in the same repo than the jmx subsystem.
No need to do anything if we move back jmx to wildfly soon.
But if we decide to keep jmx in wildfly-core, we should move the jconsole scripts there
too.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
9:11 a.m.
Just an update on whole JMX subsystem move thingy.
It is on halt for now, as there is some work going on that in affects JMX
and it is easier to have it in same code repo for time beeing
I will be moved once this is complete.
--
tomaz
On Mon, Aug 11, 2014 at 12:40 PM, Jeff Mesnil <jmesnil(a)redhat.com> wrote:
On 24 Jul 2014, at 17:43, Tomaž Cerar <tomaz.cerar(a)gmail.com>
wrote:
> I have send PR removing jmx subsystem from core
https://github.com/wildfly/wildfly-core/pull/57
>
> but to send PR for inclusion to full WildFly repo new release of core is
needed as jmx subsystem is using new transformers API we have in core.
It’s a minor thing but our jconsole.* scripts still live in wildfly repo.
For consistency sake, we should have them in the same repo than the jmx
subsystem.
No need to do anything if we move back jmx to wildfly soon.
But if we decide to keep jmx in wildfly-core, we should move the jconsole
scripts there too.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
5:47 a.m.
On 09/07/14 20:35, Brian Stansberry wrote:
On 7/9/14, 1:59 PM, Stuart Douglas wrote:
> The problem with that is that if you take it to its fullest extent you
> end up with one subsystem per repo, which is not something we want.
>
> I am not sure where the best place for it is, even if it stays in core
> it should be possible for the tooling to exclude it, same with logging.
>
> Otherwise I think the place for it to live would be the web distro, as I
> think that people will definitely want to be able to use JMX to manage
> that.
>
So the web build is becoming the spot where foundational stuff like this
and Elytron come in?
My view on Elytron is that the core is going to have to have a
dependency on the Elytron module, the actual APIs and SPIs of Elytron
are going to have to be tightly integrated in the core.
But the subsystem itself and any related additional providers e.g.
PicketLink / KeyCloak are things I would see added in the functional
distributions so yeah based on what Stuart said web probably becomes the
entry point for this.
The core is uber-minimal for the folks who really
want that, and then web has these things that lots and lots of folks
will want.
In the odd case where folks want this foundational stuff but not
undertow etc, they can just depend on the web build and exclude
undertow. Real corner case. And folks who don't want the foundational
stuff exclude it.
I can see that working out pretty well.
Does logging belong in web then then? Still seems like something that
even the uber-minimalists would want. I ask because it bugs me that we
have two meanings now for "core" -- the old "core" notion that was
the
true core with zero subsystems, and now this new wildfly-core dist,
which has subsystems.
>
>
>
> Fernando Nasser wrote:
>> Shouldn't it be like an onion?
>>
>> A more bare core. A Core with monitoring capabilities. And so on.
>>
>>
>> On 2014-07-09, 2:27 PM, Brian Stansberry wrote:
>>> My earlier reply on this thread was in the branch focused on the
>>> technical detail of how the dependency arises. Which should be fixed;
>>> sounds like that's happening.
>>>
>>> On the broader question of where stuff belongs, JMX is an interesting
>>> case. Lots of users will want JMX. A number of subsystems have optional
>>> dependencies on it, including some like jgroups and infinispan that may
>>> end up being part of their own dist, separate from the full dist.
>>>
>>> So what's the plan for catering to these needs? Ship it in the full dist
>>> and those who want it depend on the full dist but configure the
>>> provisioning tool to only grab the JMX modules? Make it a micro-dist?
>>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
>>> the "deploy your own services" dist? (I don't like that last
one, just
>>> brainstorming...)
>>>
>>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>>>> Working with the split repo just questioning if JMX is really needed in
>>>> core?
>>>>
>>>> Whilst most distributions would include it I am not convinced it is a
>>>> subsystem all must have.
>>>>
>>> Manageable logging isn't either. Lots of people used logging.properties
>>> for a long time.
>>>
>>> Note I'm not advocating removing logging from core; I'm just saying
that
>>> no subsystem has to be in core if that's the criteria.
>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
1:55 p.m.
I'd like to vote for adding it into the full dist and configuring the
provisioning tool to grab the JMX modules.
We rely on JMX for accessing specific monitoring metrics and it's
difficult to get at some of the metrics that used to be easily available
in prior versions for some metrics. We've had to jump through some hoops
to get JMX working the way we need in wildfly 8 -- with the new undertow
module, we had to write some code to expose some metrics that used to be
part of the jbossweb module, like avgResponseTimeMS and requestCount.
Would be awesome if JMX support was more complete and part of the full
dist.
Cheers,
John H Patton
On 7/9/14 1:27 PM, "Brian Stansberry" <brian.stansberry(a)redhat.com>
wrote:
My earlier reply on this thread was in the branch focused on the
technical detail of how the dependency arises. Which should be fixed;
sounds like that's happening.
On the broader question of where stuff belongs, JMX is an interesting
case. Lots of users will want JMX. A number of subsystems have optional
dependencies on it, including some like jgroups and infinispan that may
end up being part of their own dist, separate from the full dist.
So what's the plan for catering to these needs? Ship it in the full dist
and those who want it depend on the full dist but configure the
provisioning tool to only grab the JMX modules? Make it a micro-dist?
Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
the "deploy your own services" dist? (I don't like that last one, just
brainstorming...)
On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
> Working with the split repo just questioning if JMX is really needed in
> core?
>
> Whilst most distributions would include it I am not convinced it is a
> subsystem all must have.
>
Manageable logging isn't either. Lots of people used logging.properties
for a long time.
Note I'm not advocating removing logging from core; I'm just saying that
no subsystem has to be in core if that's the criteria.
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
This message, including any attachments, is the property of Sears Holdings Corporation
and/or one of its subsidiaries. It is confidential and may contain proprietary or legally
privileged information. If you are not the intended recipient, please delete it without
reading the contents. Thank you.
2:12 p.m.
If things you need are not exposed via the undertow subsystem management
API, please file feature request JIRAs. Or even better, send a patch if
you exposed it via the subsystem.
On 7/9/14, 1:55 PM, Patton, John wrote:
I'd like to vote for adding it into the full dist and configuring
the
provisioning tool to grab the JMX modules.
We rely on JMX for accessing specific monitoring metrics and it's
difficult to get at some of the metrics that used to be easily available
in prior versions for some metrics. We've had to jump through some hoops
to get JMX working the way we need in wildfly 8 -- with the new undertow
module, we had to write some code to expose some metrics that used to be
part of the jbossweb module, like avgResponseTimeMS and requestCount.
Would be awesome if JMX support was more complete and part of the full
dist.
Cheers,
John H Patton
On 7/9/14 1:27 PM, "Brian Stansberry" <brian.stansberry(a)redhat.com>
wrote:
> My earlier reply on this thread was in the branch focused on the
> technical detail of how the dependency arises. Which should be fixed;
> sounds like that's happening.
>
> On the broader question of where stuff belongs, JMX is an interesting
> case. Lots of users will want JMX. A number of subsystems have optional
> dependencies on it, including some like jgroups and infinispan that may
> end up being part of their own dist, separate from the full dist.
>
> So what's the plan for catering to these needs? Ship it in the full dist
> and those who want it depend on the full dist but configure the
> provisioning tool to only grab the JMX modules? Make it a micro-dist?
> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
> the "deploy your own services" dist? (I don't like that last one, just
> brainstorming...)
>
> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>> Working with the split repo just questioning if JMX is really needed in
>> core?
>>
>> Whilst most distributions would include it I am not convinced it is a
>> subsystem all must have.
>>
>
> Manageable logging isn't either. Lots of people used logging.properties
> for a long time.
>
> Note I'm not advocating removing logging from core; I'm just saying that
> no subsystem has to be in core if that's the criteria.
>
>> Regards,
>> Darran Lofthouse.
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
This message, including any attachments, is the property of Sears Holdings Corporation
and/or one of its subsidiaries. It is confidential and may contain proprietary or legally
privileged information. If you are not the intended recipient, please delete it without
reading the contents. Thank you.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
2:26 p.m.
I'll check if we did. We're looking into releasing the code we built to
expose the metrics, but we have to get approvals and it's taking a while.
Perhaps my thoughts are out of scope for the one conversation I decided to
jump into. :) But, I do like having JMX available in the full dist and
enabling the modules in the provisioning tool. That sounds appealing
irrespective of the trouble we had grabbing various metrics once we got
JMX working. JMX has felt a bit like an afterthought with wildfly.
Cheers,
-john
On 7/9/14 2:12 PM, "Brian Stansberry" <brian.stansberry(a)redhat.com>
wrote:
If things you need are not exposed via the undertow subsystem
management
API, please file feature request JIRAs. Or even better, send a patch if
you exposed it via the subsystem.
On 7/9/14, 1:55 PM, Patton, John wrote:
> I'd like to vote for adding it into the full dist and configuring the
> provisioning tool to grab the JMX modules.
>
> We rely on JMX for accessing specific monitoring metrics and it's
> difficult to get at some of the metrics that used to be easily available
> in prior versions for some metrics. We've had to jump through some
>hoops
> to get JMX working the way we need in wildfly 8 -- with the new undertow
> module, we had to write some code to expose some metrics that used to be
> part of the jbossweb module, like avgResponseTimeMS and requestCount.
> Would be awesome if JMX support was more complete and part of the full
> dist.
>
> Cheers,
>
> John H Patton
>
>
>
> On 7/9/14 1:27 PM, "Brian Stansberry" <brian.stansberry(a)redhat.com>
>wrote:
>
>> My earlier reply on this thread was in the branch focused on the
>> technical detail of how the dependency arises. Which should be fixed;
>> sounds like that's happening.
>>
>> On the broader question of where stuff belongs, JMX is an interesting
>> case. Lots of users will want JMX. A number of subsystems have optional
>> dependencies on it, including some like jgroups and infinispan that may
>> end up being part of their own dist, separate from the full dist.
>>
>> So what's the plan for catering to these needs? Ship it in the full
>>dist
>> and those who want it depend on the full dist but configure the
>> provisioning tool to only grab the JMX modules? Make it a micro-dist?
>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
>> the "deploy your own services" dist? (I don't like that last one,
just
>> brainstorming...)
>>
>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>>> Working with the split repo just questioning if JMX is really needed
>>>in
>>> core?
>>>
>>> Whilst most distributions would include it I am not convinced it is a
>>> subsystem all must have.
>>>
>>
>> Manageable logging isn't either. Lots of people used logging.properties
>> for a long time.
>>
>> Note I'm not advocating removing logging from core; I'm just saying
>>that
>> no subsystem has to be in core if that's the criteria.
>>
>>> Regards,
>>> Darran Lofthouse.
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> This message, including any attachments, is the property of Sears
>Holdings Corporation and/or one of its subsidiaries. It is confidential
>and may contain proprietary or legally privileged information. If you
>are not the intended recipient, please delete it without reading the
>contents. Thank you.
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
This message, including any attachments, is the property of Sears Holdings Corporation
and/or one of its subsidiaries. It is confidential and may contain proprietary or legally
privileged information. If you are not the intended recipient, please delete it without
reading the contents. Thank you.
2:31 p.m.
Patton, John wrote:
I'll check if we did. We're looking into releasing the code
we built to
expose the metrics, but we have to get approvals and it's taking a while.
Perhaps my thoughts are out of scope for the one conversation I decided to
jump into. :) But, I do like having JMX available in the full dist and
enabling the modules in the provisioning tool. That sounds appealing
irrespective of the trouble we had grabbing various metrics once we got
JMX working. JMX has felt a bit like an afterthought with wildfly.
Where JMX lives in the distro should not have any effect on the
capabilities of the JMX subsystem. It will still be the same subsystem
with the same functionality wether it lives in core or the full dist.
Stuart
Cheers,
-john
On 7/9/14 2:12 PM, "Brian Stansberry"<brian.stansberry(a)redhat.com>
wrote:
> If things you need are not exposed via the undertow subsystem management
> API, please file feature request JIRAs. Or even better, send a patch if
> you exposed it via the subsystem.
>
> On 7/9/14, 1:55 PM, Patton, John wrote:
>> I'd like to vote for adding it into the full dist and configuring the
>> provisioning tool to grab the JMX modules.
>>
>> We rely on JMX for accessing specific monitoring metrics and it's
>> difficult to get at some of the metrics that used to be easily available
>> in prior versions for some metrics. We've had to jump through some
>> hoops
>> to get JMX working the way we need in wildfly 8 -- with the new undertow
>> module, we had to write some code to expose some metrics that used to be
>> part of the jbossweb module, like avgResponseTimeMS and requestCount.
>> Would be awesome if JMX support was more complete and part of the full
>> dist.
>>
>> Cheers,
>>
>> John H Patton
>>
>>
>>
>> On 7/9/14 1:27 PM, "Brian
Stansberry"<brian.stansberry(a)redhat.com>
>> wrote:
>>
>>> My earlier reply on this thread was in the branch focused on the
>>> technical detail of how the dependency arises. Which should be fixed;
>>> sounds like that's happening.
>>>
>>> On the broader question of where stuff belongs, JMX is an interesting
>>> case. Lots of users will want JMX. A number of subsystems have optional
>>> dependencies on it, including some like jgroups and infinispan that may
>>> end up being part of their own dist, separate from the full dist.
>>>
>>> So what's the plan for catering to these needs? Ship it in the full
>>> dist
>>> and those who want it depend on the full dist but configure the
>>> provisioning tool to only grab the JMX modules? Make it a micro-dist?
>>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
>>> the "deploy your own services" dist? (I don't like that last
one, just
>>> brainstorming...)
>>>
>>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>>>> Working with the split repo just questioning if JMX is really needed
>>>> in
>>>> core?
>>>>
>>>> Whilst most distributions would include it I am not convinced it is a
>>>> subsystem all must have.
>>>>
>>> Manageable logging isn't either. Lots of people used logging.properties
>>> for a long time.
>>>
>>> Note I'm not advocating removing logging from core; I'm just saying
>>> that
>>> no subsystem has to be in core if that's the criteria.
>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> This message, including any attachments, is the property of Sears
>> Holdings Corporation and/or one of its subsidiaries. It is confidential
>> and may contain proprietary or legally privileged information. If you
>> are not the intended recipient, please delete it without reading the
>> contents. Thank you.
>>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
This message, including any attachments, is the property of Sears Holdings Corporation
and/or one of its subsidiaries. It is confidential and may contain proprietary or legally
privileged information. If you are not the intended recipient, please delete it without
reading the contents. Thank you.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:33 p.m.
On 7/9/14 2:31 PM, "Stuart Douglas" <stuart.w.douglas(a)gmail.com> wrote:
Patton, John wrote:
> I'll check if we did. We're looking into releasing the code we built to
> expose the metrics, but we have to get approvals and it's taking a
>while.
>
> Perhaps my thoughts are out of scope for the one conversation I decided
>to
> jump into. :) But, I do like having JMX available in the full dist and
> enabling the modules in the provisioning tool. That sounds appealing
> irrespective of the trouble we had grabbing various metrics once we got
> JMX working. JMX has felt a bit like an afterthought with wildfly.
Where JMX lives in the distro should not have any effect on the
capabilities of the JMX subsystem. It will still be the same subsystem
with the same functionality wether it lives in core or the full dist.
Yep, that makes sense. :) I'll go back to lurking again.
Cheers,
-john
Stuart
>
> Cheers,
>
> -john
>
>
>
>
> On 7/9/14 2:12 PM, "Brian Stansberry"<brian.stansberry(a)redhat.com>
>wrote:
>
>> If things you need are not exposed via the undertow subsystem
>>management
>> API, please file feature request JIRAs. Or even better, send a patch if
>> you exposed it via the subsystem.
>>
>> On 7/9/14, 1:55 PM, Patton, John wrote:
>>> I'd like to vote for adding it into the full dist and configuring the
>>> provisioning tool to grab the JMX modules.
>>>
>>> We rely on JMX for accessing specific monitoring metrics and it's
>>> difficult to get at some of the metrics that used to be easily
>>>available
>>> in prior versions for some metrics. We've had to jump through some
>>> hoops
>>> to get JMX working the way we need in wildfly 8 -- with the new
>>>undertow
>>> module, we had to write some code to expose some metrics that used to
>>>be
>>> part of the jbossweb module, like avgResponseTimeMS and requestCount.
>>> Would be awesome if JMX support was more complete and part of the full
>>> dist.
>>>
>>> Cheers,
>>>
>>> John H Patton
>>>
>>>
>>>
>>> On 7/9/14 1:27 PM, "Brian
Stansberry"<brian.stansberry(a)redhat.com>
>>> wrote:
>>>
>>>> My earlier reply on this thread was in the branch focused on the
>>>> technical detail of how the dependency arises. Which should be fixed;
>>>> sounds like that's happening.
>>>>
>>>> On the broader question of where stuff belongs, JMX is an interesting
>>>> case. Lots of users will want JMX. A number of subsystems have
>>>>optional
>>>> dependencies on it, including some like jgroups and infinispan that
>>>>may
>>>> end up being part of their own dist, separate from the full dist.
>>>>
>>>> So what's the plan for catering to these needs? Ship it in the full
>>>> dist
>>>> and those who want it depend on the full dist but configure the
>>>> provisioning tool to only grab the JMX modules? Make it a micro-dist?
>>>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
>>>> the "deploy your own services" dist? (I don't like that
last one,
>>>>just
>>>> brainstorming...)
>>>>
>>>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>>>>> Working with the split repo just questioning if JMX is really needed
>>>>> in
>>>>> core?
>>>>>
>>>>> Whilst most distributions would include it I am not convinced it is
>>>>>a
>>>>> subsystem all must have.
>>>>>
>>>> Manageable logging isn't either. Lots of people used
>>>>logging.properties
>>>> for a long time.
>>>>
>>>> Note I'm not advocating removing logging from core; I'm just
saying
>>>> that
>>>> no subsystem has to be in core if that's the criteria.
>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> This message, including any attachments, is the property of Sears
>>> Holdings Corporation and/or one of its subsidiaries. It is
>>>confidential
>>> and may contain proprietary or legally privileged information. If you
>>> are not the intended recipient, please delete it without reading the
>>> contents. Thank you.
>>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>
> This message, including any attachments, is the property of Sears
>Holdings Corporation and/or one of its subsidiaries. It is confidential
>and may contain proprietary or legally privileged information. If you
>are not the intended recipient, please delete it without reading the
>contents. Thank you.
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
This message, including any attachments, is the property of Sears Holdings Corporation
and/or one of its subsidiaries. It is confidential and may contain proprietary or legally
privileged information. If you are not the intended recipient, please delete it without
reading the contents. Thank you.
2:56 p.m.
+1000.
The subsystem management API is what everyone should be using, and not JMX.
Andy
----- Original Message -----
From: "Brian Stansberry"
<brian.stansberry(a)redhat.com>
To: "John Patton" <John.Patton(a)searshc.com>, wildfly-dev(a)lists.jboss.org
Sent: Wednesday, July 9, 2014 1:12:34 PM
Subject: Re: [wildfly-dev] Is JMX Needed in Core?
If things you need are not exposed via the undertow subsystem
management
API, please file feature request JIRAs. Or even better, send a patch
if
you exposed it via the subsystem.
On 7/9/14, 1:55 PM, Patton, John wrote:
> I'd like to vote for adding it into the full dist and configuring
> the
> provisioning tool to grab the JMX modules.
>
> We rely on JMX for accessing specific monitoring metrics and it's
> difficult to get at some of the metrics that used to be easily
> available
> in prior versions for some metrics. We've had to jump through some
> hoops
> to get JMX working the way we need in wildfly 8 -- with the new
> undertow
> module, we had to write some code to expose some metrics that used
> to be
> part of the jbossweb module, like avgResponseTimeMS and
> requestCount.
> Would be awesome if JMX support was more complete and part of the
> full
> dist.
>
> Cheers,
>
> John H Patton
>
>
>
> On 7/9/14 1:27 PM, "Brian Stansberry" <brian.stansberry(a)redhat.com>
> wrote:
>
>> My earlier reply on this thread was in the branch focused on the
>> technical detail of how the dependency arises. Which should be
>> fixed;
>> sounds like that's happening.
>>
>> On the broader question of where stuff belongs, JMX is an
>> interesting
>> case. Lots of users will want JMX. A number of subsystems have
>> optional
>> dependencies on it, including some like jgroups and infinispan
>> that may
>> end up being part of their own dist, separate from the full dist.
>>
>> So what's the plan for catering to these needs? Ship it in the
>> full dist
>> and those who want it depend on the full dist but configure the
>> provisioning tool to only grab the JMX modules? Make it a
>> micro-dist?
>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo
>> as
>> the "deploy your own services" dist? (I don't like that last one,
>> just
>> brainstorming...)
>>
>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>>> Working with the split repo just questioning if JMX is really
>>> needed in
>>> core?
>>>
>>> Whilst most distributions would include it I am not convinced it
>>> is a
>>> subsystem all must have.
>>>
>>
>> Manageable logging isn't either. Lots of people used
>> logging.properties
>> for a long time.
>>
>> Note I'm not advocating removing logging from core; I'm just
>> saying that
>> no subsystem has to be in core if that's the criteria.
>>
>>> Regards,
>>> Darran Lofthouse.
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> This message, including any attachments, is the property of Sears
> Holdings Corporation and/or one of its subsidiaries. It is
> confidential and may contain proprietary or legally privileged
> information. If you are not the intended recipient, please delete
> it without reading the contents. Thank you.
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
11:01 a.m.
Am 09.07.2014 um 20:55 schrieb Patton, John <John.Patton(a)searshc.com>:
We rely on JMX for accessing specific monitoring metrics and
it's
difficult to get at some of the metrics that used to be easily available
in prior versions for some metrics. We've had to jump through some hoops
I second this from the experiences we have in RHQ
--
Heiko Rupp
Project lead RHQ projects http://jboss.org/rhq
11:25 a.m.
On Tue, Jul 29, 2014 at 6:01 PM, Heiko W.Rupp <hrupp(a)redhat.com> wrote:
I second this from the experiences we have in RHQ
And i will second question you, why is this something that needs to be in
barebones wildfly core?
It will stay part of all normal distributions out there. Noting really
changes for RHQ and alike.
5:44 a.m.
Can't a subsystem like this live in it's own repo? Then any
distribution that needs it can just pull it in?
On 09/07/14 19:27, Brian Stansberry wrote:
My earlier reply on this thread was in the branch focused on the
technical detail of how the dependency arises. Which should be fixed;
sounds like that's happening.
On the broader question of where stuff belongs, JMX is an interesting
case. Lots of users will want JMX. A number of subsystems have optional
dependencies on it, including some like jgroups and infinispan that may
end up being part of their own dist, separate from the full dist.
So what's the plan for catering to these needs? Ship it in the full dist
and those who want it depend on the full dist but configure the
provisioning tool to only grab the JMX modules? Make it a micro-dist?
Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
the "deploy your own services" dist? (I don't like that last one, just
brainstorming...)
On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
> Working with the split repo just questioning if JMX is really needed in
> core?
>
> Whilst most distributions would include it I am not convinced it is a
> subsystem all must have.
>
Manageable logging isn't either. Lots of people used logging.properties
for a long time.
Note I'm not advocating removing logging from core; I'm just saying that
no subsystem has to be in core if that's the criteria.
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
6:16 a.m.
I don’t think we want too many repos, that will become a nightmare.
Once we are able to do better assembly of servers depending on capabilities, I think the
problem is gone?
On 10 Jul 2014, at 11:44, Darran Lofthouse <darran.lofthouse(a)jboss.com> wrote:
Can't a subsystem like this live in it's own repo? Then any
distribution that needs it can just pull it in?
On 09/07/14 19:27, Brian Stansberry wrote:
> My earlier reply on this thread was in the branch focused on the
> technical detail of how the dependency arises. Which should be fixed;
> sounds like that's happening.
>
> On the broader question of where stuff belongs, JMX is an interesting
> case. Lots of users will want JMX. A number of subsystems have optional
> dependencies on it, including some like jgroups and infinispan that may
> end up being part of their own dist, separate from the full dist.
>
> So what's the plan for catering to these needs? Ship it in the full dist
> and those who want it depend on the full dist but configure the
> provisioning tool to only grab the JMX modules? Make it a micro-dist?
> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
> the "deploy your own services" dist? (I don't like that last one, just
> brainstorming...)
>
> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>> Working with the split repo just questioning if JMX is really needed in
>> core?
>>
>> Whilst most distributions would include it I am not convinced it is a
>> subsystem all must have.
>>
>
> Manageable logging isn't either. Lots of people used logging.properties
> for a long time.
>
> Note I'm not advocating removing logging from core; I'm just saying that
> no subsystem has to be in core if that's the criteria.
>
>> Regards,
>> Darran Lofthouse.
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
6:25 a.m.
Ok so maybe the alternative we need is.
The subsystem still lives in core but just not included by default,
every sub distribution can then choose to add it if it wants.
On 10/07/14 12:16, Kabir Khan wrote:
I don’t think we want too many repos, that will become a nightmare.
Once we are able to do better assembly of servers depending on capabilities, I think the
problem is gone?
On 10 Jul 2014, at 11:44, Darran Lofthouse <darran.lofthouse(a)jboss.com> wrote:
> Can't a subsystem like this live in it's own repo? Then any
> distribution that needs it can just pull it in?
>
> On 09/07/14 19:27, Brian Stansberry wrote:
>> My earlier reply on this thread was in the branch focused on the
>> technical detail of how the dependency arises. Which should be fixed;
>> sounds like that's happening.
>>
>> On the broader question of where stuff belongs, JMX is an interesting
>> case. Lots of users will want JMX. A number of subsystems have optional
>> dependencies on it, including some like jgroups and infinispan that may
>> end up being part of their own dist, separate from the full dist.
>>
>> So what's the plan for catering to these needs? Ship it in the full dist
>> and those who want it depend on the full dist but configure the
>> provisioning tool to only grab the JMX modules? Make it a micro-dist?
>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
>> the "deploy your own services" dist? (I don't like that last one,
just
>> brainstorming...)
>>
>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>>> Working with the split repo just questioning if JMX is really needed in
>>> core?
>>>
>>> Whilst most distributions would include it I am not convinced it is a
>>> subsystem all must have.
>>>
>>
>> Manageable logging isn't either. Lots of people used logging.properties
>> for a long time.
>>
>> Note I'm not advocating removing logging from core; I'm just saying that
>> no subsystem has to be in core if that's the criteria.
>>
>>> Regards,
>>> Darran Lofthouse.
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
3785
days inactive
3818
days old
32 comments
11 participants
participants (11)
-
Andrig Miller -
Brian Stansberry -
Darran Lofthouse -
Fernando Nasser -
Heiko W.Rupp -
Jason Greene -
Jeff Mesnil -
Kabir Khan -
Patton, John -
Stuart Douglas -
Tomaž Cerar