CLI arguments convention
by Alexey Loubyansky
It's not entirely consistent, at the moment. I'd like to get some
feedback on it and what's more convenient for you.
An example of inconsistency
deploy my.war my_war_name.war my_war_runtime_name.war
here are three arguments: the deployment, the name and the runtime name.
The last two are optional but if you want to specify them, you have to
know the order in which they should appear.
On the other hand, there is, e.g. create-jms-cf which has lots of
arguments and where it's impossible to learn all of them, so it looks like
create-jms-cf name=mycf entries=cf/mycf ...
In addition, it's kind of a proprietary convention. We discussed this
with Max today and I'm looking into the GNU convention for command line
arguments, i.e. adding '--' prefix for arg names. But also, to keep
things simple, have arguments that don't require an arg name in front of
them, e.g. in case of deploy, the following would be equivalent:
deploy --file=my.war --name=my_war_name.war
--runtime-name=my_war_runtime_name.war
deploy my.war --name=my_war_name.war --my_war_runtime_name.war
And another point is the use of '='. Some command lines don't use it, e.g.
deploy --file my.war --name my_war_name.war --runtime-name
my_war_runtime_name.war
and some do
deploy --file=my.war --name=my_war_name.war
--runtime-name=my_war_runtime_name.war
Any preferences? Are there any other things you'd like to improve?
Thanks,
Alexey
13 years
Why is JMS message persistence disabled by default?
by Jaikiran Pai
The JMS message requirements
http://download.oracle.com/javaee/6/tutorial/doc/bncfu.html state that:
"The most reliable way to produce a message is to send a PERSISTENT
message within a transaction. *JMS messages are PERSISTENT by default*".
However, currently while testing 7.0.0.Beta3 I noticed that this isn't
the case. Sending out 3 messages to a queue and restarting the server
loses the messages. Before restarting I did use the JConsole to make
sure that the message count shows up correctly and it did. On restart I
see the count reset to 0. Looking at the messaging subsystem, I notice
that we have set:
<!-- disable messaging persistence -->
<persistence-enabled>false</persistence-enabled>
This shouldn't be the case, since it breaks JMS spec out of the box. By
the way, I tried setting it to persistence-enabled=true and testing this
whole flow again. But I still see the message count reset to 0 on a
server restart. I'll see if I can figure out why the persistence-enabled
flag change isn't taking effect.
-Jaikiran
13 years
Additional info on metrical attributes
by Heiko W.Rupp
Hi,
I know that we discussed that somewhat in Neuchâtel, but I don't recall any outcome:
For the http connector I see (I just took this as example, as this is one of the
few metrics that exist at all at the moment).
"processingTime" => {
"type" => INT,
"access-type" => "metric",
"storage" => "runtime"
},
For RHQ (and probably other management tools), this metric could use more information:
- units (is that seconds, millis, shoes) ?
- a textual description
- an indicator if this is a steadily climbing/falling metric or if values can be "arbitrary"
Can those be added please?
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years
META-INF directory in dependency modules
by Marius Bogoevici
Hi,
I have couple of questions regarding access to resources in imported
modules. I noticed the following:
1) Assume that there's a module X, which contains resources under
META-INF, eg. META-INF/x.foo
2) Deployment Y declares a dependency on module X (via
META-INF/MANIFEST.MF 'Dependencies:') - to my best understanding the
same would happen even if there was a module Y declaring a <dependency/>
on X
If that is the case, the classloader of module Y will be able to find
resources contained in one of the jars of module X, except for anything
undeneath META-INF - so META-INF/x.foo will not be found.
In summary:
classLoaderModuleY.getResources("META-INF/x.foo") , 0 results
classLoaderModuleY.getResources("META-INF") will basically return an
entry for each and every JAR from dependencies
classLoaderModuleY.getResources("x/foo/bar/stuff") returns resource
'stuff' found in package x.foo.bar exported by module X
Apart from META-INF/services which is treated in a special fashion, how
is it possible to install and consume a set of libraries as modules
(e.g. shared libraries), if they contain files underneath META-INF,
since they are not accessible from within the referencing module? And
why is there a default restriction on META-INF (the way I read the
modules.xsd schema, this behaviour can never be overridden through the
module definition)?
Thanks,
Marius
13 years
CLI error
by Heiko Braun
Exception in thread "main" java.lang.NoSuchMethodError: org.jboss.as.cli.handlers.SimpleTabCompleterWithDelegate.<init>([Ljava/lang/String;Lorg/jboss/as/cli/CommandArgumentCompleter;)V
at org.jboss.as.cli.handlers.PrefixHandler.<init>(PrefixHandler.java:42)
at org.jboss.as.cli.handlers.PrefixHandler.<init>(PrefixHandler.java:38)
at org.jboss.as.cli.CommandLineMain.<clinit>(CommandLineMain.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.modules.Module.run(Module.java:261)
at org.jboss.modules.Main.main(Main.java:236)
13 years
JBAS-9268: OOM when uploading content through HTTP API
by Heiko Braun
I've run into a OOM issue when uploading content through the HTTP API again.
(https://issues.jboss.org/browse/JBAS-9268)
I did take a look at the current implementation and propose that we change it in the following way:
- read multipart contents from mime boundary
- replace the custom multipart stream implementation with a mature one (leans on apache commons fileupload)
I've got this changes tested and verified in a custom branch:
https://github.com/heiko-braun/jboss-as/commits/out_of_memory
However before going ahead, I would like get some feedback from
a) the original author (Jonathan Pearlin. Welcome onboard btw)
b) Jason wrt the Apache License sources (See org.jboss.as.domain.http.server.multipart.asf.*)
Regards, Ike
13 years
start/stop as7 server?
by André Dietisheim
Hi
I try to start and stop as7 programmatically by using the management
API. I unfortunately could not find any snippets that worked so far. The
ServerDeploymentManager has a TODO and indicates that shutdown has not
yet been implemented. DomainClient has a #stopServer method, but it
looks like it only works for as7 in domain mode. Do I miss something?
I'd highly appreciate any pointes.
Thanks
André
13 years
AS 7 stacktraces
by Max Rydahl Andersen
Just realized that AS 7 spits out extra context in the error log about java stacktraces (its not in the error pages shown to users):
Every stacktrace line has things like [jbossweb-7.0.0.Beta8.jar:7.0.0.Beta2]
My question is how I go from that information to the *actual* jar.
Doing a
find . -name jbossweb-7.0.0.Beta8*
gives me /modules/org/jboss/as/web/main/jbossweb-7.0.0.Beta8.jar
but I assume there could actually be multiple jars with that name in separate modules.
What I'm looking for is a way from tooling to be sure I'm going to show the *right* jar's sourcecode and not just
one random one of many possible ones ;)
...btw. i'm still really interested in understanding how we can provide a classpath based on AS 7 modules to users
so they don't have to also get Maven and other things to work before they can start building/deploying to AS 7.
My assumption is that if there is an algorithm to figure out the above, I can use that to also provide a full classpath
eventually ;)
/max
http://about.me/maxandersen
13 years
