Misleading error message on extension add failure
by Bartosz Baranowski
Im not sure what is a general policy about logging such things but... it seems odd. If Im wrong, please ignore.
Ive been playing with extension test cases and here is what I found out:
1. If Extension Add handler fails, no error/warn message is displayed.
2. Above is false IF level is set to debug:
:59,685 DEBUG org.jboss.as.controller.management-operation JBAS014616: Operation ("add") failed - address: ([("extension" => "jmxrmiconnector")]) - failure description: "org.jboss.modules.ModuleLoadException: Error loading module from /home/baranowb/redhat/git/jboss-as/testsuite/integration/basic/../../../build/target/wildfly-8.0.0.Alpha1-SNAPSHOT/modules/jmxrmiconnector/main/module.xml"
3. Above message is cryptic at best - "Error loading module" - what error, where, why?
Full stack trace for #2
15:06:26,373 ERROR stderr org.jboss.modules.ModuleLoadException: Error loading module from /home/baranowb/redhat/git/jboss-as/testsuite/integration/basic/../../../build/target/wildfly-8.0.0.Alpha1-SNAPSHOT/modules/jmxrmiconnector/main/module.xml
15:06:26,373 ERROR stderr at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:292)
15:06:26,374 ERROR stderr at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:256)
15:06:26,374 ERROR stderr at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:144)
15:06:26,374 ERROR stderr at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:138)
15:06:26,374 ERROR stderr at java.security.AccessController.doPrivileged(Native Method)
15:06:26,375 ERROR stderr at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:138)
15:06:26,375 ERROR stderr at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:389)
15:06:26,375 ERROR stderr at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:293)
15:06:26,376 ERROR stderr at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:240)
15:06:26,376 ERROR stderr at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:222)
15:06:26,376 ERROR stderr at org.jboss.modules.Module.loadServiceFromCallerModuleLoader(Module.java:322)
15:06:26,377 ERROR stderr at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:84)
15:06:26,377 ERROR stderr at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:70)
15:06:26,378 ERROR stderr at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:439)
15:06:26,378 ERROR stderr at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:321)
15:06:26,379 ERROR stderr at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228)
15:06:26,380 ERROR stderr at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:223)
15:06:26,380 ERROR stderr at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235)
15:06:26,381 ERROR stderr at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124)
15:06:26,381 ERROR stderr at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148)
15:06:26,382 ERROR stderr at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97)
15:06:26,382 ERROR stderr at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114)
15:06:26,382 ERROR stderr at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
15:06:26,383 ERROR stderr at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
15:06:26,383 ERROR stderr at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
15:06:26,383 ERROR stderr at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
15:06:26,384 ERROR stderr at java.lang.Thread.run(Thread.java:722)
15:06:26,384 ERROR stderr at org.jboss.threads.JBossThread.run(JBossThread.java:122)
15:06:26,385 ERROR stderr Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[21,52]
15:06:26,385 ERROR stderr Message: Failed to add resource root 'service-loader-resources' at path 'service-loader-resources'
15:06:26,385 ERROR stderr at org.jboss.modules.ModuleXmlParser.parseResourceRoot(ModuleXmlParser.java:756)
15:06:26,386 ERROR stderr at org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:712)
15:06:26,386 ERROR stderr at org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:538)
15:06:26,386 ERROR stderr at org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:369)
15:06:26,387 ERROR stderr at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:287)
15:06:26,387 ERROR stderr ... 27 more
Here is link to commit: https://github.com/wildfly/wildfly/commit/3973d7cd2edcf913461dc65902ff471...
12 years, 4 months
Classpath management for as7.2 / eap6.1 / wildfly
by Rob Stryker
Hi all:
The jbosstools team has been instructed by you all not to reach in to
the modules folder for the purposes of classpath management in eclipse.
We've also been told api would be forthcoming to assist us discover what
jars should be added to projects so that users can get up and running as
fast as possible. And a final reminder, our use case requires a
non-running server to discover the appropriate jars to add.
Was just wondering if this was anywhere on the plan, or if we should
abandon waiting and simply hard-code our classpaths as we have in the
past. Our users are getting upset as we just released alpha2 and our
next is beta1. A beta with this serious error would only win user
condemnation as incomplete if we provide no classpath management for web
/ seam / etc projects.
https://issues.jboss.org/browse/WFLY-1026
12 years, 4 months
Jackson 1 and 2 coexistence
by Bill Burke
Jackson 2 has a different package name from Jackson 1, so they are
completely incompatible. My suggestion?
* Ship with both jackson 1 and jackson 2 modules
* Ship with both Restasy jackson 1 and 2 providers
* Make Jackson2 the default Resteasy provider
For resteasy-based apps, the negative is that anybody relying on
jackson1 apis directly will have to either upgrade (which I think is as
easy as changing package names) or manually set up the apropriate
jboss-module includes/excludes.
Thoughts? Let me know if you have any objections to this approach as I
want to document this within Resteasy and push the appropriate changes
to Wildfly.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 4 months
identify runtime operations ?
by Heiko Braun
Is it possible to identify operations that affect the runtime state (i.e. start/stop services) ?
I was looking at a datasource example, but couldn't find any metadata related to that:
[standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:read-operation-description(name=enable)
{
"outcome" => "success",
"result" => {
"operation-name" => "enable",
"description" => "Enable the data-source",
"request-properties" => {"persistent" => {
"type" => BOOLEAN,
"description" => "if true enable attribute is persisted",
"expressions-allowed" => false,
"required" => true,
"nillable" => false,
"default" => true
}},
"reply-properties" => {},
"read-only" => false
}
}
Regards, Heiko
12 years, 5 months
