CLI commandline on Windows and long commands
by Wolfgang Knauf
Hi to all,
when using a 7.1 snapshot from last week (2012-02-01) on Windows, I
noticed that "jboss-cli.bat" it is quite unusable when a command is
longer than one line: no chance to navigate from line 2 to the first
line of the command, "cursor left" is stuck at the first char of line 2
(the good olde Oracle SQLPlus times are back ;-)).
Is this a known issue (fixed since this version)? I can't image that I
am first one noticing this ;-)?
Best regards
Wolfgang
14 years, 1 month
Console does not support install/start semantic for bundles
by Thomas Diesler
Folks,
now that we deploy through the GWT console it's a real usability issue
that we don't have a way to determine whether an OSGi bundle should be
automatically started when deployed through the management API.
Here the related issues
[AS7-3693 <https://issues.jboss.org/browse/AS7-3693>] Console does not
support install/start semantic for bundles
[AS7-3694 <https://issues.jboss.org/browse/AS7-3694>] Allow management
client to associate metadata with DeploymentUnit
[AS7-2777 <https://issues.jboss.org/browse/AS7-2777>] Add notion of
start/stop for deployments
[AS7-378 <https://issues.jboss.org/browse/AS7-378>] Support notion of
deployment set
I could have a go at this set of problems because it directly relates to
OSGi bundle deployment. Please note, that JSR-88 also has the notion of
start/stop for JavaEE deployments. You can for example stop a webapp to
temporarily make the http endpoint unavailable. Currently this is
faked/hacked in the jsr88 impl.
I would post proposals for the individual subproblems.
#1 client metadata associated with the DU
#2 start/stop semantic for arbitrary deployments
#3 notion of deployment set and DUPs that can operate on the set rather
than individual DU only
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years, 1 month
Parameterized config of datasources in standalone.xml
by Richard Kilcoyne
I'm working on parameterizing my datasources in standalone.xml. Specifying system properties as ${DB_URL} for connection url, username, password works great using properties passed to jboss via -Dapp.properties, but after the first run, the values are permanently substituted in this file. If my external property file is changed, standalone.xml no longer picks up the change. To re-substitute, I have to get the initial version from the standalone_xml_history dir and overwrite the current version.
Is there a better we to handle external configuration of datasources and if not, is there a better way to reset the standalone.xml config?
Thanks,
Rick
14 years, 1 month
Alternative server configurations
by Paul Robinson
All,
I'm not sure if this is widely known, but there are a set of alternative
server configurations in
./build/src/main/resources/docs/examples/configs/. Some or all of these
need to be kept in sync with the config they where originally derived
from. In particular standalone-xts.xml was derived from
standalone-full.xml and needs updating whenever standalone-full.xml is
changed.
The reason why I'm sending this email is because XTS has been broken
many times due to required changes being made to standalone-full.xml,
but not to standalone-xts.xml.
It's likely that this problem is also happening to the other
configurations in ./build/src/main/resources/docs/examples/configs/.
However, I have not checked and I don't know which config they where
derived from, so it's hard to know under what circumstances they should
be updated.
So this is just a polite reminder, please remember to update
standalone-xts.xml when you update standalone-full.xml.
Cheers,
Paul.
--
Paul Robinson
Web service transactions lead
paul.robinson(a)redhat.com
JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson
(USA), Charlie Peters (USA)
14 years, 1 month
translation of model descriptions
by Heiko Braun
I am about to finish the integration with zanata (https://issues.jboss.org/browse/AS7-3673), which is required to push the message bundles to https://translate.jboss.org. I am currently doing it for the DMR model descriptions, because these are required by the console and should be translated at the same time.
If nobody has any objections I'll finish the integration. But it requires somebody to else to cover the remaining bits and pieces that would need to be translated as well. I.e. log messages.
Thoughts?
Regards, Heiko
14 years, 1 month
New jboss-rpm mailing list
by Marek Goldmann
Hi all,
I want to introduce YAML. Yet Another Mailing List: jboss-rpm
https://lists.jboss.org/mailman/listinfo/jboss-rpm
Because more and more people are interested in hearing and discussing
the state of JBoss AS in Fedora I created the list. This will be the
primarily source of updates on the current works. If you're interested -
please subscribe. We'll use the list also to send patches and discuss
various issues we have in the Java RPM world.
If you're a project leader or just developer who wants to know how to
package properly the project you work on (or make it easier to package
for us), you should subscribe too.
Thanks!
--Marek
14 years, 1 month
IMPORTANT!: I NEED FINALS LIST
by Jason T. Greene
I need finals of everything on this list today, tomorrow at the
*ABSOLUTE LATEST*.
org.infinispan 5.1.1.CR1
org.jboss.arquillian.core 1.0.0.CR7
org.jboss.arquillian.osgi 1.0.0.CR6
org.jboss.as.jbossweb-native 2.0.10.Beta1
org.jboss.com.sun.httpserver 1.0.0.Beta3
org.jboss.ejb3.ext-api 2.0.0-beta-3
org.jboss.iiop-client 1.0.0.Beta2
org.jboss.interceptor 2.0.0.Alpha3
org.jboss.jboss-transaction-spi 7.0.0.CR2
org.jboss.jboss-vfs 3.1.0.CR1
org.jboss.jsfunit 2.0.0.Beta1
org.jboss.logging.jboss-logging 3.1.0.CR2
org.jboss.logging.jboss-logging-tools 1.0.0.CR5
org.jboss.metadata 7.0.0.Beta35
org.jboss.mod_cluster 1.2.0.Beta4
org.jboss.modules.jboss-modules 1.1.0.CR8
org.jboss.osgi.metadata 2.0.0.CR1
org.jboss.remote-naming 1.0.0.Beta4
org.jboss.remoting3 3.2.0.CR9
org.jboss.remoting3.remoting-jmx 1.0.0.Beta1
org.jboss.sasl 1.0.0.Beta9
org.jboss.security.jboss-negotiation 2.2.0.Beta3
org.jboss.shrinkwrap.shrinkwrap 1.0.0-cr-1
org.jboss.shrinkwrap.resolver 1.0.0-beta-5
jboss-jsf-api_2.1_spec 2.0.0.Beta1
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
14 years, 1 month
ClassNotFoundException: org.jboss.as.protocol.mgmt.ProtocolUtils
by Heiko Braun
Has someone seen this as well?
14:16:38,063 ERROR [stderr] (HttpManagementService-threads - 2) Caused by: java.lang.ClassNotFoundException: org.jboss.as.protocol.mgmt.ProtocolUtils from [Module "org.jboss.as.domain-http-interface:main" from local module loader @39ab89 (roots: /home/ec2-user/jboss-as-7.1.0.Final-EAP-preview/modules)]
14 years, 1 month
Re: [jboss-as7-dev] Changed arguments…can we do better ? :P
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.
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
-----------
14 years, 1 month
Scripts in bin/
by Brian Stansberry
We have a bin/util directory that was meant to hold utility scripts and
help keep the bin folder itself a bit cleaner and less intimidating. But
there's no real consistency in usage. Should the following be moved to
bin/util?
jconsole.sh/.bat
wsconsume.sh/.bat
wsprovide.sh/.bat
If these shouldn't move, then I suggest we get rid of bin/util altogether.
Arguably add-user.sh/.bat falls in the same category as the previous
three, but I think that's one where it's critical that it be right out
front.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
14 years, 2 months
