Implicit dependencies on jmx from webservices
by Scott Stark
If I remove the jmx subsystem from the current JBoss AS
7.1.0.Alpha2-SNAPSHOT build, I see the webservices deployer fail with
the following NPE on startup:
Caused by: java.lang.NullPointerException
at
org.jboss.as.webservices.deployers.EndpointRecordProcessorDeploymentAspect.<init>(EndpointRecordProcessorDeploymentAspect.java:54)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method) [:1.6.0_26]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[:1.6.0_26]
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
[:1.6.0_26]
at java.lang.Class.newInstance0(Class.java:355) [:1.6.0_26]
at java.lang.Class.newInstance(Class.java:308) [:1.6.0_26]
at
org.jboss.as.webservices.parser.WSDeploymentAspectParser.parseDeploymentAspect(WSDeploymentAspectParser.java:140)
... 187 more
There is an implicit dependency on the jboss.mbean.server service being
used on the NPE line:
setMbeanServer((MBeanServer)
WSServices.getContainerRegistry().getService(ServiceName.JBOSS.append("mbean",
"server"))
.getService().getValue());
Shouldn't this be an externalized dependency declared to the msc via
injection?
14 years, 9 months
AS7 logging changes
by Jaikiran Pai
I have been noticing that James has been helping us moving over to the
new Logger APIs for i18n. He's converting various classes to use the new
logger APIs, where we traditionally used Logger.getLogger(klass.class).
But I also see that any new code/class that gets added by others
(atleast me), ends up using the old style of logging thus adding more
work for James later on. This I guess is going to be never ending. Is
there some wiki/instructions which lists down what needs to be done with
logging and what APIs should be used going forward? Whatever new code I
add, I can make sure that I use the new APIs.
-Jaikiran
14 years, 9 months
Adding a subsystem via CLI
by Scott Stark
Can a complete subsystem configuration be added via the CLI? Based on
the current docs and help, it does not seem so. One common usage in
openshift is the desire to extend the base as7 cartridge to add new
application type support. Examples are torquebox and switchyard. I don't
expect that the modules for the subsystem would be added via the CLI,
just the domain configuration.
[standalone@localhost:9999 /] help --commands
Commands available in the current context:
add-jms-cf add-jms-queue add-jms-topic batch
cd clear command connect
data-source deploy help history
ls pwd quit remove-jms-cf
remove-jms-queue remove-jms-topic undeploy version
xa-data-source
To read a description of a specific command execute 'command_name --help'.
14 years, 10 months
Building jboss-logging-tools
by Sanne Grinovero
Hi all,
I'm looking for the patch of LOGTOOL-34, which seems to have been
fixed past night, but it seems I can't understand the organization of
the git repositories.
The issue seems to be fixed by David Lloyd, but I could only find it
in James Perkins's own repository in a branch named "fixes"; I still
can't build it as it depends on version 3.1.0.Beta3-SNAPSHOT of
org.jboss.logging:jboss-logging, but I couldn't find this in any
source repository.
any suggestion please?
Regards,
Sanne
14 years, 10 months
Two thread pools sections in management API
by David Bosschaert
I found that in the management API there are two places where thread
pools can be created:
/subsystem=threads
and
/subsystem=ejb3/thread-pool=*
It seems that the latter defines pools that are used in
/subsystem=ejb3/service=*
Should they not be using thread pools defined in the threads subsystem
instead?
Cheers,
David
14 years, 10 months
CLI - change IP address
by Rostislav Svoboda
Hi Brian.
I noticed that AS7-1299 is resolved so I tried to change IP address for public interface.
First attempt was fine
/interface=public:write-attribute(name="criteria",value="any-ipv4-address")
I failed when I tried to add specific IP address
/interface=public:write-attribute(name="criteria",value=[("inet-address"="10.34.3.154")])
{
"outcome" => "failed",
"failure-description" => "Illegal interface criteria [(\"inet-address\"=\"10.34.3.154\")]; must be any-address, any-ipv4-address or any-ipv6-address or a list of criteria elements",
"rolled-back" => true,
"response-headers" => {"process-state" => "reload-required"}
}
I tried few variations but without success. What is the right format?
Please add few lines into https://docs.jboss.org/author/display/AS71/Admin+Guide#AdminGuide-CLIRecipes it would help others too.
Thanks,
Rosta
14 years, 10 months
Integration test failing
by Vimal Kansal
Hi,
I am building As7 on Windows 7, jdk 1.6 update 27 64 bit and since
yesterday, I am seeing this errot :
Failed tests:
testDistributeEjbApp(org.jboss.as.test.smoke.embedded.deployment.EnterpriseDeploymentTestCase):
expected:<Completed> but was:<Failed>
testDistributeEARApp(org.jboss.as.test.smoke.embedded.deployment.EnterpriseDeploymentTestCase):
expected:<Completed> but was:<Failed>
Tests in error:
testListAvailableModules(org.jboss.as.test.smoke.embedded.deployment.EnterpriseDeploymentTestCase):
Deployment timeout:
org.jboss.as.ee.deployment.spi.status.ProgressObjectImpl@4ab8fba5
Can somebody please help.
Thx
Vimal
14 years, 10 months
(XA)Datasources subresources and use cases
by Stefano Maestri
Hi all,
I've recently worked on adding subresources for configuration properties
to resource-adapters and now I'm working on datasources and xa-datasources.
While a pure subresources approach is working out of the box for RAs,
since add operations work only on DMR and services and runtime metadata
information are created during rar deployment, it's not the same for
(xa)DS. Here add operation effectively deploy the datasources, so adding
properties as subresources comes after effective deployment.
IOW the subresources can't be used during runtime creation of a
datasource, but only during parsing. Having connection-properties and
xa-datasource-properties as subresources should make easier and more
standard to add/remove them.
Since currently we are supporting datasource creation from console and
cli and since I think it's a wanted feature I have a proposal to make it
possible also with subresources.
Basically the idea is to use the current enable/disable status to make
possible to edit a datasource. Datasource are always created disabled
(boolean parameter enable will be removed from add operation), and
permit to add/remove subresource in this status. Then console/cli have
to enable the datasource making it available and registered in jndi.
It's not possible to edit a datasource enabled, it must be disabled
first. Of course this approach could be extended not only to
subresources, but also to all editable field that currently require a
server reload.
comments or problem you can see in this approach?
regards
S.
14 years, 10 months
