[jboss-as7-dev] [AS7-367] exposing deployment details via the mgmt api

[Brian Stansberry]

Part of what needs to come out of this discussion is how to organize the 
information; i.e. don't just assume a simple single "type" deployment; 
think about ears, wars that package ejbs etc.

Re: overriding descriptors, we've previously supported that in places 
via JMX; i.e. some of our mbeans expose attributes that have the effect 
of overriding some value that came from a deployment descriptor. We can 
still do that; IMO we should. The management metadata exposes whether an 
attribute is stored to CONFIGURATION or RUNTIME, so the effect is visible.

The resources that expose those kinds of attributes don't have to map 
1:1 to some deployment descriptor though. For example if we had an 
attribute that lets the user change the session timeout for a webapp it 
doesn't have to be in a resource that models web.xml. It can be in a 
resource that models the session manager, a la the mbean we've always had.

I don't want to worry about persisting deployment descriptor overrides 
back to domain/standalone.xml at this point; i.e. any attributes that 
override deployment settings should be Storage.RUNTIME.

On 5/5/11 5:16 AM, Heiko Braun wrote:
>
>
> Exposing this information is certainly helpful.
> I've added JDBC drivers and resource adapters to the list.
>
> But overriding DD's? Better not.
> You would need to be able to persist the changes.
>
> But r/o access to certain deployment related data is certainly a good thing.
>
>
> Ike
>
> On May 5, 2011, at 12:48 AM, Emanuel Muckenhuber wrote:
>
>> I was wondering about our requirements of exposing more detailed
>> deployment related information via our management API.
>> https://issues.jboss.org/browse/AS7-367 lists things like deployed
>> servlets, ejbs, ... with related invocation stats and other metrics.
>>
>> In general this sounds more dynamic than other parts of our current mgmt
>> api and the structure mostly depend on how much detail we expose - and
>> maybe more importantly if we actually want to allow overriding
>> deployment descriptors using this mechanism right from the beginning?
>>
>> Any thoughts on this are welcome,
>> Emanuel
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat