Changed arguments…can we do better ? :P

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Changed arguments…can we do better ? :P

Max Rydahl Andersen
Hey,

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

Does the -Djava.awt.headless=true have any function besides maybe give a few milliseconds faster startup ?
(asking since this prevents you to launch (for debugging purposes) hsqldb admin and other swing based "inspection" tools)

And last I asked about adding jboss.modules.system.pkgs= arguments to better support common tools that uses java agents such as JProfiler, yourkit, byteman and others
it was said we shouldn't add these specific ones since then we were choosing one over the other ;)

Any reason why byte man gets added and not the others ?

And couldn't we solve this in a better way by having jboss modules look for a property file to pick these up instead of command line arguments ?
i.e. anything found in <cwd>/jboss-modules.properties is added to system properties before it starts loading its actual module + treat jboss.modules.arguments as additional arguments ?

Can't remove the need for  -Djava.awt.headless but would remove need for many of the other custom settings.

I can submit a patch that does this if interested.

/max
http://about.me/maxandersen




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

William Louth (JINSPIRED.COM)
Hi Max,

Yes the existence of this system property already in the script is a
pain for integration with our metering engine as well as other code
profiling solutions.

Kind regards,

William

On 01/02/2012 12:38, Max Rydahl Andersen wrote:

> Hey,
>
> 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
>
> Does the -Djava.awt.headless=true have any function besides maybe give a few milliseconds faster startup ?
> (asking since this prevents you to launch (for debugging purposes) hsqldb admin and other swing based "inspection" tools)
>
> And last I asked about adding jboss.modules.system.pkgs= arguments to better support common tools that uses java agents such as JProfiler, yourkit, byteman and others
> it was said we shouldn't add these specific ones since then we were choosing one over the other ;)
>
> Any reason why byte man gets added and not the others ?
>
> And couldn't we solve this in a better way by having jboss modules look for a property file to pick these up instead of command line arguments ?
> i.e. anything found in<cwd>/jboss-modules.properties is added to system properties before it starts loading its actual module + treat jboss.modules.arguments as additional arguments ?
>
> Can't remove the need for  -Djava.awt.headless but would remove need for many of the other custom settings.
>
> I can submit a patch that does this if interested.
>
> /max
> http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Stephen Coy
In reply to this post by Max Rydahl Andersen

On 01/02/2012, at 10:38 PM, Max Rydahl Andersen wrote:

> Does the -Djava.awt.headless=true have any function besides maybe give a few milliseconds faster startup ?

I don't know about other platforms, but on a Mac the presence of this flag prevents the creation of a dock icon and application menu bar.

Normally we don't want to see this when running a server.


Steve C

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Andrew Dinn
In reply to this post by Max Rydahl Andersen
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.

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.

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 . . .


regards,


Andrew Dinn
-----------
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Max Rydahl Andersen
In reply to this post by William Louth (JINSPIRED.COM)
I meant JBOSS_MODULES_SYSTEM_PKGS environment  variable - but yes, not pretty.

/max

On Feb 1, 2012, at 12:51, William Louth (JINSPIRED.COM) wrote:

> Hi Max,
>
> Yes the existence of this system property already in the script is a
> pain for integration with our metering engine as well as other code
> profiling solutions.
>
> Kind regards,
>
> William
>
> On 01/02/2012 12:38, Max Rydahl Andersen wrote:
>> Hey,
>>
>> 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
>>
>> Does the -Djava.awt.headless=true have any function besides maybe give a few milliseconds faster startup ?
>> (asking since this prevents you to launch (for debugging purposes) hsqldb admin and other swing based "inspection" tools)
>>
>> And last I asked about adding jboss.modules.system.pkgs= arguments to better support common tools that uses java agents such as JProfiler, yourkit, byteman and others
>> it was said we shouldn't add these specific ones since then we were choosing one over the other ;)
>>
>> Any reason why byte man gets added and not the others ?
>>
>> And couldn't we solve this in a better way by having jboss modules look for a property file to pick these up instead of command line arguments ?
>> i.e. anything found in<cwd>/jboss-modules.properties is added to system properties before it starts loading its actual module + treat jboss.modules.arguments as additional arguments ?
>>
>> Can't remove the need for  -Djava.awt.headless but would remove need for many of the other custom settings.
>>
>> I can submit a patch that does this if interested.
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

/max
http://about.me/maxandersen




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Max Rydahl Andersen
In reply to this post by Stephen Coy

On Feb 1, 2012, at 13:04, Stephen Coy wrote:

>
> On 01/02/2012, at 10:38 PM, Max Rydahl Andersen wrote:
>
>> Does the -Djava.awt.headless=true have any function besides maybe give a few milliseconds faster startup ?
>
> I don't know about other platforms, but on a Mac the presence of this flag prevents the creation of a dock icon and application menu bar.

That only happens if your app doesn't have a console (i.e. not started on command line or started via some other external script) afaik.

> Normally we don't want to see this when running a server.


Yes, its an annoying behavior OSX has here for non-console run apps for which ./standalone -Djava.awt.headless=true is the best way to
use when running without console.

So yeah for that it makes sense to have it default I guess.

Any other reasons?

/max
http://about.me/maxandersen




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Max Rydahl Andersen
In reply to this post by Andrew Dinn
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

William Louth (JINSPIRED.COM)
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Andrew Dinn
In reply to this post by Max Rydahl Andersen
On 02/01/2012 03:29 PM, Max Rydahl Andersen wrote:
>> 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.

No, it's not actually the same at all. Very far from it.

With jprofiler etc you know in advance that you want to profile your
program run or whatever. With byteman you don't know until something
goes wrong that you might need to load the Byteman agent, install some
trace rules and see what is going wrong. Most customers don't even know
that this is an option. However, our support team do and regularly use
it to talk customers through problems which arise in both sandbox and
live installs. Without this preliminary step the customer has to stop
and restart the AS in order to load the Byteman agent and Byteman rules
and this often means that the problem goes away -- i.e. important
support opportunity lost.

Anyway, I don't really need to convince you of this. Our support team
have already convinced *me* that this is a vital config option. If you
want to remove this on the grounds that it is just like all these other
cases I suggest you talk them first. Otherwise when the support problems
start piling up you are definitely not going to be Mr Popular.

> Yes, I just suggest we make this list include more than just byteman and
> take it *off* the commandline into a setting.

It is a setting already. The fact that it is set using a shell script
doesn't really change that. If you want to argue for an alternative
control well, I'll leave that to our usability experts.

>> 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.

There is one file to rule them all as far as the normal startup
mechanism is concerned. At least that's precisely how Jason described it
some months back -- unless, perhaps, he has changed his mind?

That may not be of any help to you if you are starting the AS by other
means but surely you can provide equivalent configuration options and an
API to configure them. In which case just be sure to include this in
your default config. It may not be so important to your usrs but I
suspect that is not the case.

regards,


Andrew Dinn
-----------
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

jtgreene
Administrator
In reply to this post by William Louth (JINSPIRED.COM)
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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

jtgreene
Administrator
In reply to this post by Max Rydahl Andersen
On 2/1/12 5:38 AM, Max Rydahl Andersen wrote:
> Does the -Djava.awt.headless=true have any function besides maybe give a few milliseconds faster startup ?
> (asking since this prevents you to launch (for debugging purposes) hsqldb admin and other swing based "inspection" tools)

This was a patch submitted by a user awhile back. The reason is that if
an application uses any of the image libraries in AWT (it's pretty
common these days to use capthas for exmaple), the JVM will fail if
graphics libraries are not installed. Since we don't really have a need
to launch GUI elements at this point it makes sense to save these users
some heartache. As to a database admin thing, we ship H2 for sample
usage, and they don't use swing. They provide an admin war though, that
we show how to deploy in one of the quickstarts.

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Max Rydahl Andersen
In reply to this post by Andrew Dinn
>
> Anyway, I don't really need to convince you of this. Our support team have already convinced *me* that this is a vital config option. If you want to remove this on the grounds that it is just like all these other cases I suggest you talk them first. Otherwise when the support problems start piling up you are definitely not going to be Mr Popular.

Andrew - i'm not saying byte man should not be supported out of box - i'm saying there are other mechanisms that will fail too thus wishing to add them.
i.e. jvisualvm also seems to have problems if not explicitly listed and that is part of a default hotspot jvm.

>> Yes, I just suggest we make this list include more than just byteman and
>> take it *off* the commandline into a setting.
>
> It is a setting already. The fact that it is set using a shell script doesn't really change that. If you want to argue for an alternative control well, I'll leave that to our usability experts.

i'm trying to reduce the need for having "special controls"

>>> 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.
>
> There is one file to rule them all as far as the normal startup mechanism is concerned. At least that's precisely how Jason described it some months back -- unless, perhaps, he has changed his mind?

I don't see such one file.

I see standalone.conf.bat and standalone.conf and they are not honored unless you use bash/bat to launch with.

> That may not be of any help to you if you are starting the AS by other means but surely you can provide equivalent configuration options and an API to configure them. In which case just be sure to include this in your default config. It may not be so important to your usrs but I suspect that is not the case.

of course I can provide equal options but the day more options gets added this needs to updated too.

Which is why I ask to actually get one file and file format (which doesn't assume existence of bash or windows command bat engine) that rule's most of them.

/max
http://about.me/maxandersen




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Max Rydahl Andersen
In reply to this post by jtgreene

On Feb 1, 2012, at 18:12, Jason T. Greene wrote:

> On 2/1/12 5:38 AM, Max Rydahl Andersen wrote:
>> Does the -Djava.awt.headless=true have any function besides maybe give a few milliseconds faster startup ?
>> (asking since this prevents you to launch (for debugging purposes) hsqldb admin and other swing based "inspection" tools)
>
> This was a patch submitted by a user awhile back. The reason is that if an application uses any of the image libraries in AWT (it's pretty common these days to use capthas for exmaple), the JVM will fail if graphics libraries are not installed.

That's a very good reason.

> Since we don't really have a need to launch GUI elements at this point it makes sense to save these users some heartache. As to a database admin thing, we ship H2 for sample usage, and they don't use swing. They provide an admin war though, that we show how to deploy in one of the quick starts.

sure - I was just giving an example and just wanted to understand why its there before we add it to tools.

/max
http://about.me/maxandersen




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

David Lloyd-2
In reply to this post by Andrew Dinn
On 02/01/2012 09:54 AM, Andrew Dinn wrote:

> On 02/01/2012 03:29 PM, Max Rydahl Andersen wrote:
>>> 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.
>
> No, it's not actually the same at all. Very far from it.
>
> With jprofiler etc you know in advance that you want to profile your
> program run or whatever...[etc]

Profiler vendors have made a general move towards no longer needing this
setting (JProfiler in particular does not require it anymore).

--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Stuart Douglas
In reply to this post by Andrew Dinn

Did you consider having byteman instrument the Class Loaders in the target vm, to always delegate to the system class loader if the class being loading starts with "org.byteman" ?

I am pretty sure this is how JProfiler gets around the need for this setting.  

Stuart

On 01/02/2012, at 11:14 PM, Andrew Dinn 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.
>
> 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.
>
> 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 . . .
>
>
> regards,
>
>
> Andrew Dinn
> -----------
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Andrew Dinn
Hi Stuart,

On 02/01/2012 09:17 PM, Stuart Douglas wrote:
> Did you consider having byteman instrument the Class Loaders in the
> target vm, to always delegate to the system class loader if the class
> being loading starts with "org.byteman" ?
>
> I am pretty sure this is how JProfiler gets around the need for this
> setting.

I did consider this but I decided against it for two reasons:

1) the existing mechanism in JBoss modules already does the basic job of
making Byteman classes available everywhere. So, duplicating it seemed
inefficient both at devtime and at runtime.

2) doing the job properly will also involve adding exemptions for other,
non-Byteman classes referenced at the point of injection and I am
considering a better mechanism to make this work

To explain the latter, imagine that a rule injected into a JBossTS class
needs access EJB types/methods. However, Byteman currently has to
type-check and link the rule using the loader of the target class. So,
you are snookered if the JTS module does not import the EJB classes.

I think I can get round this by adding i) module import statements to
Byteman rule scripts ii) a plugin to the Byteman agent which resolves
module imports and hands Byteman a multi-module loader for
type-check/load, allowing rules to be linked against the union of the
target module and the imported modules.

Of course the plugin and the import syntax would have to be module
loader-specific.So, you would need an OSGI plugin, a JBoss Modules
plugin, a Jigsaw plugin etc. But it should be easy to define a generic
API for delegation of loader issues. So, watch this space.

regards,


Andrew Dinn
-----------
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

jtgreene
Administrator
In reply to this post by Max Rydahl Andersen
On 2/1/12 11:51 AM, Max Rydahl Andersen wrote:

>> That may not be of any help to you if you are starting the AS by
>> other means but surely you can provide equivalent configuration
>> options and an API to configure them. In which case just be sure to
>> include this in your default config. It may not be so important to
>> your usrs but I suspect that is not the case.
>
> of course I can provide equal options but the day more options gets
> added this needs to updated too.
>
> Which is why I ask to actually get one file and file format (which
> doesn't assume existence of bash or windows command bat engine) that
> rule's most of them.

I am very much in favor of a shared file for win and linux. I just don't
have any bandwidth to do it for 7.1.0 (1.1 maybe). Such a solution would
require that JBoss Tools parse the file since we have a chicken/egg
problem with VM launching on standalone, and we don't want to have a JVM
launching a JVM in a standalone setup (adds too much time to boot). It
might also require that we write a native launcher on windows.

Although keep in mind that none of those JVM parameters are absolutely
necessary. We got rid of logmodule, which was the only required one.
There is a couple of settings for bootstrap logging, but the system will
still work without it.

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Max Rydahl Andersen
> I am very much in favor of a shared file for win and linux. I just don't have any bandwidth to do it for 7.1.0 (1.1 maybe). Such a solution would require that JBoss Tools parse the file since we have a chicken/egg problem with VM launching on standalone, and we don't want to have a JVM launching a JVM in a standalone setup (adds too much time to boot). It might also require that we write a native launcher on windows.
>

> Although keep in mind that none of those JVM parameters are absolutely necessary. We got rid of logmodule, which was the only required one. There is a couple of settings for bootstrap logging, but the system will still work without it.


For me there are two different kind of arguments/parameters.

The one that are JVM specific/required at Java VM startup and those that are non-JVM specific and can be read by the launcher it self.

It is the latter I'm suggesting to externalize.

OS specific/required at Java VM is currently for standalone.sh (as far as I can see?):

-d32
-client
-Xms64m
-Xmx512m
-XX:MaxPermSize=256m
-Djava.net.preferIPv4Stack=true  
-Dsun.rmi.dgc.client.gcInterval=3600000*
-Dsun.rmi.dgc.server.gcInterval=3600000*
-Djava.awt.headless=true*
-jar "/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/jboss-modules.jar"

*=might not be necessary to setup - depend if those are not getting activated during jboss modules.

Arguments that I would think could be derived by the java launch instead of at command line:

-Dorg.jboss.resolver.warning=true
-Djboss.modules.system.pkgs=org.jboss.byteman
"-Dorg.jboss.boot.log.file=/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/standalone/log/boot.log"
"-Dlogging.configuration=file:/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties"
-mp "/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/modules"
-jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone
-Djboss.home.dir="/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT"

Most of these could just be calculated based on jboss.home.dir as a nice default.

Leaving us with:

-Dorg.jboss.resolver.warning=true
-Djboss.modules.system.pkgs=org.jboss.byteman
-jaxpmodule javax.xml.jaxp-provider

Which could be read in via a properties file or even defaulted?

But Jason, I'm reading your mail as you even want to go to the length of having the vm arguments externalized?


/max
http://about.me/maxandersen




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Brian Stansberry
This implies then two separate files for setting these things, given
that we want setting them to be externalized from
standalone.sh/domain.sh itself.

On 2/3/12 4:52 AM, Max Rydahl Andersen wrote:

>> I am very much in favor of a shared file for win and linux. I just don't have any bandwidth to do it for 7.1.0 (1.1 maybe). Such a solution would require that JBoss Tools parse the file since we have a chicken/egg problem with VM launching on standalone, and we don't want to have a JVM launching a JVM in a standalone setup (adds too much time to boot). It might also require that we write a native launcher on windows.
>>
>
>> Although keep in mind that none of those JVM parameters are absolutely necessary. We got rid of logmodule, which was the only required one. There is a couple of settings for bootstrap logging, but the system will still work without it.
>
>
> For me there are two different kind of arguments/parameters.
>
> The one that are JVM specific/required at Java VM startup and those that are non-JVM specific and can be read by the launcher it self.
>
> It is the latter I'm suggesting to externalize.
>
> OS specific/required at Java VM is currently for standalone.sh (as far as I can see?):
>
> -d32
> -client
> -Xms64m
> -Xmx512m
> -XX:MaxPermSize=256m
> -Djava.net.preferIPv4Stack=true
> -Dsun.rmi.dgc.client.gcInterval=3600000*
> -Dsun.rmi.dgc.server.gcInterval=3600000*
> -Djava.awt.headless=true*
> -jar "/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/jboss-modules.jar"
>
> *=might not be necessary to setup - depend if those are not getting activated during jboss modules.
>
> Arguments that I would think could be derived by the java launch instead of at command line:
>
> -Dorg.jboss.resolver.warning=true
> -Djboss.modules.system.pkgs=org.jboss.byteman
> "-Dorg.jboss.boot.log.file=/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/standalone/log/boot.log"
> "-Dlogging.configuration=file:/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties"
> -mp "/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/modules"
> -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone
> -Djboss.home.dir="/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT"
>
> Most of these could just be calculated based on jboss.home.dir as a nice default.
>
> Leaving us with:
>
> -Dorg.jboss.resolver.warning=true
> -Djboss.modules.system.pkgs=org.jboss.byteman
> -jaxpmodule javax.xml.jaxp-provider
>
> Which could be read in via a properties file or even defaulted?
>
> But Jason, I'm reading your mail as you even want to go to the length of having the vm arguments externalized?
>
>
> /max
> http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Changed arguments…can we do better ? :P

Max Rydahl Andersen
Note, things could be much much simplified if all the properties that are rooted in "JBOSS_HOME" could be defaulted and calculated by the java process launching as7.

Then only in the "exceptional" case would you need to mess with these.

/max

> This implies then two separate files for setting these things, given
> that we want setting them to be externalized from
> standalone.sh/domain.sh itself.
>
> On 2/3/12 4:52 AM, Max Rydahl Andersen wrote:
>>> I am very much in favor of a shared file for win and linux. I just don't have any bandwidth to do it for 7.1.0 (1.1 maybe). Such a solution would require that JBoss Tools parse the file since we have a chicken/egg problem with VM launching on standalone, and we don't want to have a JVM launching a JVM in a standalone setup (adds too much time to boot). It might also require that we write a native launcher on windows.
>>>
>>
>>> Although keep in mind that none of those JVM parameters are absolutely necessary. We got rid of logmodule, which was the only required one. There is a couple of settings for bootstrap logging, but the system will still work without it.
>>
>>
>> For me there are two different kind of arguments/parameters.
>>
>> The one that are JVM specific/required at Java VM startup and those that are non-JVM specific and can be read by the launcher it self.
>>
>> It is the latter I'm suggesting to externalize.
>>
>> OS specific/required at Java VM is currently for standalone.sh (as far as I can see?):
>>
>> -d32
>> -client
>> -Xms64m
>> -Xmx512m
>> -XX:MaxPermSize=256m
>> -Djava.net.preferIPv4Stack=true
>> -Dsun.rmi.dgc.client.gcInterval=3600000*
>> -Dsun.rmi.dgc.server.gcInterval=3600000*
>> -Djava.awt.headless=true*
>> -jar "/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/jboss-modules.jar"
>>
>> *=might not be necessary to setup - depend if those are not getting activated during jboss modules.
>>
>> Arguments that I would think could be derived by the java launch instead of at command line:
>>
>> -Dorg.jboss.resolver.warning=true
>> -Djboss.modules.system.pkgs=org.jboss.byteman
>> "-Dorg.jboss.boot.log.file=/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/standalone/log/boot.log"
>> "-Dlogging.configuration=file:/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties"
>> -mp "/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/modules"
>> -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone
>> -Djboss.home.dir="/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT"
>>
>> Most of these could just be calculated based on jboss.home.dir as a nice default.
>>
>> Leaving us with:
>>
>> -Dorg.jboss.resolver.warning=true
>> -Djboss.modules.system.pkgs=org.jboss.byteman
>> -jaxpmodule javax.xml.jaxp-provider
>>
>> Which could be read in via a properties file or even defaulted?
>>
>> But Jason, I'm reading your mail as you even want to go to the length of having the vm arguments externalized?
>>
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

/max
http://about.me/maxandersen




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev