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
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
> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>> Working with the split repo just questioning if JMX is really needed in
>> 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.
>> Darran Lofthouse.
>> wildfly-dev mailing list
wildfly-dev mailing list