If byteman really needs to be added to the appserver for development
usage then at least make this internal to code itself checking the
property property and possibly some other property at runtime to
determine whether you should append the org.jboss.byteman leaving
jboss.modules.system.pkgs tools using this property for production usage.
The problem I have with the way this has been done up to now is that we
have this property in the script and then the same property set by a
tool integration script. Which one gets precedence is undefined - at
least I have yet to see the behavior specified.
On 01/02/2012 16:29, Max Rydahl Andersen wrote:
> Someone just mentioned that Max posted this question regarding
AS7 startup:
>
>> Going over the AS7.1 server and how startup arguments has changed we
>> noticed besides the -logmodule not being needed the following two was
>> added:
>>
>> -Djboss.modules.system.pkgs=org.jboss.byteman
>> -Djava.awt.headless=true
>> . . .
>> Any reason why byte man gets added and not the others ?
> Yes. If you don't add this at startup then the module loader will hide
> all the Byteman classes from all JBoss classloaders. This means that you
> cannot decide to install a Byteman agent after AS startup in order to
> debug/trace behaviour in a broken App Server. It just won't work (TM).
> That's going to give our support team (not to mention our developers who
> need to use Byteman for testing) a major headache.
Yes, I know - same problem for those wanting to use jprofiler, yourkit, eclemma, and
others.
> Of course, we could always advise all AS7 users to configure this
> setting in their own startup and leave it undefined by default but in
> practice that's just going to be a FAIL. David Lloyd and I discussed
> this some months back (July 11?) and having checked that adding this to
> the startup had *negligible* overhead it was added as a default.
Yes, I just suggest we make this list include more than just byteman and
take it *off* the commandline into a setting.
> Also, I think the idea of adding this via a properties file sounds nice
> at first but actually it is just splitting up the config by another
> name. One file to rule them all . . .
The problem is there are not one file to rule them all.
There is one per OS and tools that need to launch cannot use the .bat/.sh files
since no way to portably and reliably kill the process.
/max
http://about.me/maxandersen
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev