[jboss-as7-dev] Changed arguments…can we do better ? :P

Jason T. Greene jason.greene at redhat.com
Wed Feb 1 11:06:08 EST 2012


That's why I introduced the JBOSS_MODULE_SYSTEM_PKGS environment 
variable. You set that and it will override the value used by teh 
scripts. You can also set JAVA_OPTS env variable which overrides 
everything.

On 2/1/12 9:40 AM, William Louth (JINSPIRED.COM) wrote:
> 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 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


-- 
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat


More information about the jboss-as7-dev mailing list