Configuration of subsystem webservices - ${jboss.bind.address}
by Wolf-Dieter Fink
Because of the single point of configuration I would like to have the
<wdsl-host> as a reference to one of the <interfaces> declarations.
Is it possible or a JIRA enhancement?
And for a domain is it a bug?
I found this in 7.1.1.Final (standalone.xml and domain.xml)
<subsystem xmlns="urn:jboss:domain:webservices:1.1">
<modify-wsdl-address>true</modify-wsdl-address>
<wsdl-host>${jboss.bind.address:127.0.0.1}</wsdl-host>
13 years, 9 months
read statistics of active datasources via CLI
by Wolf-Dieter Fink
With the mngmt-console the statistics of Pool- and
PreparedStatementCache usage can be displayed.
But I did not found it via CLI cmd
data-source --profile=full --name=ExampleDS read-resource
Is there a possibility to read this via CLI?
- Wolf
13 years, 9 months
node0, node1 and port offsets
by Richard Achmatowicz
Hi
I've just spent a lot of time tracking down some problems with tests
failing with two IPv6 addresses which lead me to some arquillian.xml
files, like this:
<group qualifier="iiop">
<!-- The server than invokes the exposed EJB's -->
<container qualifier="iiop-client" default="true">
<configuration>
<property name="jbossHome">${basedir}/target/jbossas-iiop-client</property>
<property name="javaVmArguments">${server.jvm.args}
-Djboss.inst=${basedir}/target/jbossas-iiop-client</property>
<property
name="serverConfig">${jboss.server.config.file.name:standalone.xml}</property>
<property name="managementAddress">${node0}</property>
<property name="managementPort">${as.managementPort:9999}</property>
</configuration>
</container>
<!-- The server that expsoses EJB's via IIOP -->
<container qualifier="iiop-server" default="false">
<configuration>
<property name="jbossHome">${basedir}/target/jbossas-iiop-server</property>
<property name="javaVmArguments">${server.jvm.args}</property>
<property
name="serverConfig">${jboss.server.config.file.name:standalone.xml}</property>
<!-- we use port offsets in the configuration build -->
<property name="managementAddress">${node1}</property>
<property name="managementPort">10099</property>
</configuration>
</container>
</group>
These configurations use both separate node IPs *and* port offsets, and
yet the builds for the configurations only use port offsets. This
results in Arquillian looking in the wrong place for some servers have
actually started. For example, the arquillian.xml configuration above
tells arquillian to look for a host running at ${node1}:10099; but the
server configuration built by iiop-build.xml uses port offsets, so the
second server's managment address is ${node0}:10099. The test fails
because Arquillian can never connect to the host ${node1}:10099. We have
some tests which use a single node and port offsets, some tests which
use distinct nodes and port offsets, and I also expect some tests which
use distinct nodes and no offsets.
In the past, we have used two approaches to run two servers on a single
node: using distinct IP addresses and the same ports or using a single
IP address and ports distinguished by port offsets. The first was the
standard case; the second was generally used for testing the port offset
mechanism, IIRC. We need one or the other but not both.
Should we consider returning to that standard in which we use distinct
IPs and no offsets for the general case, and only use port offsets when
testing the port offset mechanism?. Using two separate interfaces rather
than one arguably a more realistic test than one interface with port
offsets. Also, having different multi-host configurations for each test
makes debugging more of a pain, as it is one less thing you can assume
about a test when trying to figure out what is going on. Also, looking
at different IPs in two sets of logs is easier and less error prone than
calculating offsets in your head in my experience.
The problem configurations I saw were in integration/iiop,
integration/manual-mode, and integration/multi-node.
Richard
13 years, 10 months
AS7 Naming URL resolution
by Bartosz Baranowski
Hi
Not quite sure if Im correct on this but Ive been digging a bit in naming code of AS7 and here is what Ive found(I might have missed something but..):
1. NamingContext appends Context.URL_PACKAGES_PREFIXES with "org.jboss.as.naming.interfaces"
2. The "org.jboss.as.naming.interfaces" has single interface for "java" URL - which it seems is never used.
3. InitialContext:50 has static variable which maps URL scheme to ObjectFactory. Mappings are added/removed upon Extension/Subsystem start. At runtime it holds mappings like "ejb", "corba", "iiop" and similar. This does not include handlers for URLs like 'rmi', 'ldap' etc, and this is a a glitch.
Trick here is that NamingManager and InitialContext from JDK use Context.URL_PACKAGES_PREFIXES only in case when NamingManager has no InitialContextFactoryBuilder set. So this is basically what happens when application tries lookup from AS7:
1. JDK InitialContext uses NamingManager to create default CTX - this is AS7 InitialContext impl. This step bypasses URL_PACKAGES_PREFIXES code
2. Parse lokup name - this includes some hack for "java:" prefix
3. AS7 InitialContext check if there is URL scheme and check InitialContext:50 if it contains this scheme
4. If not, use AS7 NamingContext lookup - which essentially performs lookup in ServiceBasedNamingStore.
Now this missing part which works with package prefixes makes for instance JMXConnector unusable without explicitly setting custom InitialContext factory in env. There is ofcourse AS7 wide ObjectFactory but its used only for inmodule lookups - that is in case that ServiceBasedNamingStore returns something meaningful and not throw exception. Now after this long intro:
1. org.jboss.as.naming.interfaces.java seems not to be used since "java:" is handled with some hacks - possibly this package can be removed?
2. Is there any policy against URL_PACKAGES to be used to lookup context factory ? Right now its not used, effectively removing support for code like:
String urlString = "service:jmx:rmi:///jndi/rmi://any_host:1090/jmxrmi";
JMXServiceURL serviceURL = new JMXServiceURL(urlString);
Map<String, String> env = null;
connector = JMXConnectorFactory.connect(serviceURL, env);
If not, AS7 can fallback, in case it does not find any locally cached instance of factory, to this property and try to find factory class?
13 years, 10 months
Anyone implementing ServerDeploymentManager?
by Brian Stansberry
Is anyone out there directly implementing interface
org.jboss.as.controller.client.helpers.standalone.ServerDeploymentManager?
(I'm only interested in folks doing this *outside the AS codebase* -- we
know all about stuff in the AS codebase.)
The expectation was no one would be, but folks might for some reason be
wrapping the standard impl the ServerDeploymentManager.Factory class
provides.
I'm asking because [1] proposes adding a close() method to the interface
to fix [2].
[1] https://github.com/jbossas/jboss-as/pull/1792
[2] https://issues.jboss.org/browse/AS7-3979
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
13 years, 10 months
Stress and benchmark testsuite modules
by Ondřej Žižka
Hi,
stress and benchmark modules are still empty.
How about disabling them by removing them from <modules> ?
Also, what are the intents? Is that up to QA to fill these with tests,
or do we plan to craft up some rough tests?
Regards,
Ondra
13 years, 10 months
AS7 on JRE
by Siamak Sadeghianfar
Hi,
Is it possible to run AS7 on JRE? I know that jsp compilation needs JDK. Is there any other functionality that enforce use of JDK?
Best Regards,
Siamak Sadeghianfar
13 years, 10 months
What to do about jboss-common-core?
by Brian Stansberry
We need to decide what we want to do about usage of the
jboss-common-core library.
A pull request[1] has come in that brings a bunch of jboss-common-core
classes into the AS 7 codebase.
I know in the past we've discouraged use of jboss-common-core for
various reasons, the biggest AIUI being:
1) It's a dumping ground that brings in a lot of unnecessary classes.
2) Some of the stuff in there may not be well suited to AS 7 but is well
suited to earlier, supported releases. So to use it in both basically
means a semi-fork (i.e. branch it.) Forks increase maintenance burdens.
But pulling a bunch of classes out of it and into the AS itself is just
going to turn some module of the AS into a dumping ground. And it's
essentially a fork, but one where the forked code is in completely
separate code bases. I'd rather have people use jboss-common-core than
do that.
[1] https://github.com/jbossas/jboss-as/pull/1739
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
13 years, 10 months
