[JBoss ESB Development] - Webservice call SOAP Client Action doesnt work
by mgrande
mgrande [https://community.jboss.org/people/mgrande] created the discussion
"Webservice call SOAP Client Action doesnt work"
To view the discussion, visit: https://community.jboss.org/message/766593#766593
--------------------------------------------------------------
Hi,
First of all,let you know that we are beginners in the development with JBOSS,so sorry if we say any stupid thing.
We have created a SOAPClient Acton in a ESB with this properties first calling a Request and later a Respond:
<action class="es.vass.util.MyRequestActionMyRequestAction" name="PreparaRequest"/>
<action class="org.jboss.soa.esb.actions.soap.SOAPClient" name="weatherMola">
<property name="wsdl" value="http://www.webservicex.com/globalweather.asmx?WSDL"/>
<property name="SOAPAction" value="http://www.webserviceX.NET/GetCitiesByCountry"/>
<property name="responseAsOgnlMap" value="true"/>
</action>
<action class="es.vass.util.MyRequestActionMyRequestAction" name="PreparaRequest"/>
We call the action with a ESB message and it returns:
09:37:18,244 INFO [InquiryHelper] uddi:juddi.apache.org:c79564de-eb3d-470d-aba7-c85217fc70c8 is modified Wed Oct 17 16:03:03 CEST 2012 1350482583192
09:37:23,360 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
09:37:23,362 INFO [STDOUT] Request map is: {GetCitiesByCountry.CountryName=Spain}
09:37:23,362 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
09:37:23,396 INFO [STDOUT] Progress: 1 - Caching definition from url [http://www.webservicex.com/globalweather.asmx?WSDL]
09:37:24,576 INFO [STDOUT] Progress: 1 - Loading definition from cache
09:37:24,582 INFO [STDOUT] Retrieving document at 'http://www.webservicex.com/globalweather.asmx?WSDL'.
09:37:24,660 INFO [SchemaUtils] Loading schema types from [http://www.webservicex.com/globalweather.asmx?WSDL]
09:37:24,677 INFO [SchemaUtils] Getting schema http://www.webservicex.com/globalweather.asmx?WSDL
09:37:25,635 INFO [SchemaUtils] schema for [http://www.webserviceX.NET] contained [{}] namespaces
09:37:26,246 INFO [WsdlImporter] Finding importer for {http://www.webserviceX.NET}GlobalWeatherHttpPost
09:37:26,248 INFO [WsdlImporter] Missing importer for {http://www.webserviceX.NET}GlobalWeatherHttpPost
09:37:26,248 INFO [WsdlImporter] Finding importer for {http://www.webserviceX.NET}GlobalWeatherSoap12
09:37:26,317 INFO [WsdlImporter] Importing binding {http://www.webserviceX.NET}GlobalWeatherSoap12
09:37:26,322 INFO [Soap12HttpBindingImporter] importing endpoint http://www.webservicex.com/globalweather.asmx
09:37:26,393 INFO [Soap12HttpBindingImporter] importing operation GetCitiesByCountry
09:37:26,394 INFO [Soap12HttpBindingImporter] importing operation GetWeather
09:37:26,395 INFO [WsdlImporter] Finding importer for {http://www.webserviceX.NET}GlobalWeatherSoap
09:37:26,395 INFO [WsdlImporter] Importing binding {http://www.webserviceX.NET}GlobalWeatherSoap
09:37:26,396 INFO [Soap11HttpBindingImporter] importing endpoint http://www.webservicex.com/globalweather.asmx
09:37:26,413 INFO [Soap11HttpBindingImporter] importing operation GetCitiesByCountry
09:37:26,422 INFO [Soap11HttpBindingImporter] importing operation GetWeather
09:37:26,423 INFO [WsdlImporter] Finding importer for {http://www.webserviceX.NET}GlobalWeatherHttpGet
09:37:26,423 INFO [WsdlImporter] Missing importer for {http://www.webserviceX.NET}GlobalWeatherHttpGet
09:37:26,423 INFO [WsdlImporter] Finding importer for {http://www.webserviceX.NET}GlobalWeatherHttpGet
09:37:26,457 INFO [WsdlImporter] Missing importer for {http://www.webserviceX.NET}GlobalWeatherHttpGet
09:37:26,457 INFO [WsdlImporter] Finding importer for {http://www.webserviceX.NET}GlobalWeatherHttpPost
09:37:26,458 INFO [WsdlImporter] Missing importer for {http://www.webserviceX.NET}GlobalWeatherHttpPost
09:37:26,479 INFO [STDOUT] Progress: 1 - Caching definition from url [http://www.webservicex.com/globalweather.asmx?WSDL]
09:37:26,932 INFO [STDOUT] Progress: 1 - Loading definition from cache
09:37:26,948 INFO [STDOUT] Retrieving document at 'http://www.webservicex.com/globalweather.asmx?WSDL'.
09:37:26,974 INFO [SchemaUtils] Loading schema types from [http://www.webservicex.com/globalweather.asmx?WSDL]
09:37:26,974 INFO [SchemaUtils] Getting schema http://www.webservicex.com/globalweather.asmx?WSDL
09:37:27,104 INFO [SchemaUtils] schema for [http://www.webserviceX.NET] contained [{}] namespaces
09:37:27,231 INFO [SchemaUtils] Getting schema http://www.webservicex.com/globalweather.asmx?WSDL
09:37:27,729 WARN [ActionProcessingPipeline] No fault address defined for fault message! To: JMSEpr [ PortReference < <wsa:Address jms:127.0.0.1:1099#queue/esb_channel/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : 127.0.0.1:1099/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:destination-name : queue/esb_channel/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowledge-mode : AUTO_ACKNOWLEDGE/>, <wsa:ReferenceProperties jbossesb:transacted : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/jms/> > ] MessageID: 76891731-9980-4511-a82e-8fc03d6cd53b RelatesTo: jms:correlationID#76891731-9980-4511-a82e-8fc03d6cd53b
09:37:27,813 INFO [InquiryHelper] uddi:juddi.apache.org:e60d75e7-29e1-4455-82df-3cfff3236390 is modified Tue Oct 16 17:45:39 CEST 2012 1350402339761
It doesnt do anything else and we dont see any respond. We have truied the webservice with SoapUI and we know that its working. What can check to know what can be wrong?
We are working with JBOSS AS 5.1 and JBOSS ESB 4.10 in a local server. We use for the development JBOSS developer.
Thanks you in ad
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/766593#766593]
Start a new discussion in JBoss ESB Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 2 months
- 2
- 1
[JBoss Tools Development] - How To Build JBoss Tools 4.1 FAQ
by Nick Boldt
Nick Boldt [https://community.jboss.org/people/nickboldt] created the document:
"How To Build JBoss Tools 4.1 FAQ"
To view the document, visit: https://community.jboss.org/docs/DOC-48358
--------------------------------------------------------------
*Frequently Asked Questions: How Do I Build JBoss Tools 4.1?*
*
*
*+How do I configure my settings.xml?+*
* Follow https://community.jboss.org/docs/DOC-15170 these instructions to add reference to JBoss Repositories into your settings.xml. You'll also probably need access to the SNAPSHOT repository. So here is what you should see in your ~/.m2/settings.xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
....
<profiles>
....
<profile>
<id>jboss-default</id>
<repositories>
<!-- To resolve parent artifact -->
<repository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public/</url>
</repository>
<repository>
<id>jboss-snapshots-repository</id>
<name>JBoss Snapshots Repository</name>
<url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url>
</repository>
</repositories>
<pluginRepositories>
<!-- To resolve parent artifact -->
<pluginRepository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public/</url>
</pluginRepository>
<pluginRepository>
<id>jboss-snapshots-repository</id>
<name>JBoss Snapshots Repository</name>
<url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>jboss-default</activeProfile>
...
</activeProfiles>
</settings>
+*My build is failing due to OutOfMemory or PermGen issues! How do I give Maven more memory?*+
+*
*+
* To configure the amount of memory used by Maven, you can define MVN_OPTS as follows, either in the mvn / mvn.bat script you use to run Maven, or set as global environment variables. Here's how to do so for http://forums.fedoraforum.org/showthread.php?t=262465 Fedora, https://help.ubuntu.com/community/EnvironmentVariables Ubuntu, http://forums.techarena.in/windows-xp-support/1152405.htm Windows, http://www.digitaledgesw.com/node/31 OSX.
set MAVEN_OPTS=-Xms512m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m
+*How do I build via commandline?*+
1. Fetch code from github
2. Run maven
3. Repeat for other projects
cd ~/jbosstools
git clone https://github.com/jbosstools/jbosstools-base
cd ~/jbosstools/jbosstools-base
mvn verify
+*How do I build in Eclipse (with m2e)?*+
* To be written+*
*+
+*How do I build a single project?*+
* Generally, you need only fetch the sources, and run `mvn verify`. See 'How do I build via commandline?' or 'How do I build in Eclipse (with m2e)?' above.
+*
*+
+*How do I build a series of projects (eg., Base, Server, Webservices) ?*+
* Assuming your goal is to change sources in *multiple* projects, then build them all to verify everything still compiles, you will need to fetch sources, then build the projects in dependency order.
* This workflow is useful when you're looking to change framework code in an upstream project like Base on which Webservices or Server depends, and verify that API changes don't break the downstream project's code.
* Rather than using `mvn verify`, you must use `*mvn install*` so that the downstream build will use YOUR locally-built content in your ~/.m2, rather than looking to the internet for the last published upstream dependencies.
cd ~/jbosstools
git clone https://github.com/jbosstools/jbosstools-base
git clone https://github.com/jbosstools/jbosstools-server
git clone https://github.com/jbosstools/jbosstools-webservices
cd ~/jbosstools/jbosstools-base; mvn install
cd ~/jbosstools/jbosstools-server; mvn install
cd ~/jbosstools/jbosstools-webservices; mvn verify
+*Which is better - `mvn clean install` or `mvn verify` ?*+
* Use `*install*` to create artifacts in your ~/.m2 folder which will be checked when building anything which depends on those artifacts (in addition to checking the internet). Also useful for doing subsequent offline builds with the `*-o*` or `*--offline*` flag.
* Use `*verify*` to build, but NOT install anything into your ~/.m2 folder.
+*How do I clean out artifacts I might have installed to my ~/.m2/repo ?*+
+*What if I've already built something locally, but I want to build against the server version instead of my local repo?*+
* There are http://wiki.eclipse.org/Tycho/Target_Platform#Locally_built_artifacts two approaches that work here:
0.1. override temporarily when building, using *-Dtycho.localArtifacts=ignore*, or
0.2. delete *~/.m2/repository/.meta/p2-local-metadata.properties*
+*How do I build a target platform?*+
* Currently, you should not need to build a target platform locally if you're building w/ maven via commandline. But if you'd like to materialize a target platform for use in Eclipse, you can do so like this:
1. Fetch target platforms project from github
2. Switch to the correct branch
3. Run maven
4. Results will be in jbosstools/multiple/target/jbosstools-multiple.target.repo/ or jbdevstudio/multiple/target/jbdevstudio-multiple.target.repo/
cd ~/jbosstools
git clone https://github.com/jbosstools/jbosstools-target-platforms
cd ~/jbosstools/jbosstools-target-platforms
git checkout 4.3.0
mvn install
cd ~/jbosstools/jbosstools-target-platforms/jbosstools/multiple/target/jbosstools-multiple.target.repo/
+*
*+
+*Why is there more than one target platform?*+
* Every time we make changes to the target platform, either to add/remove something, or to change the included version, we release a new version.
* In order to verify we can build against the oldest version of a target platform (eg., one based on Eclipse 4.2.0, or "minimum" target platform) but also run tests against the latest for that stream (eg., based on Eclipse 4.2.2, or "maximum" target platform), we need to maintain multiple versions.
* By default, your build will use the default "minimum" target platform specified in the JBoss Tools parent pom. To easily build against the default "maximum", use *-Pmaximum*. See also 'What profiles do I need to build? What Maven properties are useful when building?'
+*How do I specify which target platform to use when building?*+
* See 'What profiles do I need to build? What Maven properties are useful when building?'
+*How to I skip running tests? How do I make tests not fail? Or only fail after ALL tests run?
*+
+*
*+
* To skip running tests, you can use these Maven flags:* *-Dmaven.test.skip=true*
* *-DskipTests*
* If your reason for skipping tests is to see if everything can run without being stuck on the first test failure, you might also like these flags:* *-fae*, *--fail-at-end* : Fail at end of build only
* *-fn*, *--fail-never* : Never fail the build regardless of result
* You can also cause test failures to result in JUnit output without failing the build using these flags:* *-Dmaven.test.error.ignore=true*
* *-Dmaven.test.failure.ignore=true*
+*How can I debug tests in Eclipse when run from Tycho (with Surefire)?*+
* See http://www.jboss.org/tools/docs/testing.html http://www.jboss.org/tools/docs/testing.html
+*How do I build docs?*+
* See https://community.jboss.org/docs/DOC-13341 Building JBoss Tools Documentation.
+*What profiles do I need to build? What Maven properties are useful when building?
*+
* Most of the time, you don't need any profiles or -D properties. Here are some profiles and properties you might want to use in special cases.
** *-Pmaximum* : selects the default maximum target platform version instead of the default minimum one. Useful when running tests to verify that your code works against a newer target platform (eg., Eclipse 4.2.2 instead of 4.2.0)
** *-DTARGET_PLATFORM_VERSION* : allows you to pick a specific target platform version from those available in Nexus.
* See also 'How to I skip running tests? How do I make tests not fail? Or only fail after ALL tests run?' above for test-related properties.
+*
*++*Anything else?*+
* See also this FAQ: https://community.jboss.org/docs/DOC-10796 https://community.jboss.org/wiki/JBossToolsFAQ
+*
*+
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48358]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 2 months
- 1
- 0
Re: [jboss-dev-forums] [PicketBox Development] - JBoss AS7: Enabling JASPI Authentication for Web Applications
by 61 Monzillo
61 Monzillo [https://community.jboss.org/people/monzillo] commented on the document
"JBoss AS7: Enabling JASPI Authentication for Web Applications"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-17782#comment-11566
--------------------------------------------------
I created a java.net project for maintenance of the jaspic/jsr-196 spec.
the project includes an issue tracker, and an email list for those interested in participating in the mainteneance of the spi.
http://java.net/projects/jaspic-spec http://java.net/projects/jaspic-spec
--------------------------------------------------
11 years, 2 months
- 1
- 0
[EJB3 Development] - Re: Google App Engine Support for EJB
by Ales Justin
Ales Justin [https://community.jboss.org/people/alesj] created the discussion
"Re: Google App Engine Support for EJB"
To view the discussion, visit: https://community.jboss.org/message/797190#797190
--------------------------------------------------------------
Ah, OK. :-)
Well, in CapeDwarf EJBs will work, as you can mix-n-match GAE and JEE stuff.
But that of course doesn't make it portable.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/797190#797190]
Start a new discussion in EJB3 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 2 months
- 2
- 1
[PicketBox Development] - WebJASPIOptionalAuthenticator, spec compliant?
by arjan tijms
arjan tijms [https://community.jboss.org/people/atijms] created the discussion
"WebJASPIOptionalAuthenticator, spec compliant?"
To view the discussion, visit: https://community.jboss.org/message/797150#797150
--------------------------------------------------------------
I "discovered" the valve WebJASPIOptionalAuthenticator in the JBoss AS (7.1.1, 7.1.3) source code. It doesn't seem to be documented anywhere, but judging from the code and from trying out it appears to do authentication for unprotected resources.
The comment above the class says that authentication of unprotected resources is optional, but I couldn't find a reference to this in the source code. Regardless, all other JASPIC/JASPI/JSR 196 implementations that I tested (GlassFish, Geronimo, WebSphere) always call the SAM for unprotected resources. See:
/**
* <p>
* This class implements a JASPI authenticator for unprotected resources. In the JASPI Servlet profile, authentication
* for unprotected resources is optional but it is still allowed. When performed, the JASPI authentication modules must
* grant access to the unprotected resources irrespective of the caller, which may be anonymous (i.e, no security info
* supplied).
* </p>
*
* @author <a href="mailto:sguilhen@redhat.com">Stefan Guilhen</a>
*/
@SuppressWarnings("unused")
public class WebJASPIOptionalAuthenticator extends ValveBase {
Additionally, while the class is called when configured in jboss-web.xml for unprotected resources, it doesn't seem to actually work. From the source code, it's clear that the callbackhandler isn't being processed:
boolean isValid = sam.isValid(messageInfo, new Subject(), messageLayer, appContext, cbh);
if (isValid) {
WebLogger.WEB_SECURITY_LOGGER.debugf("JASPI validation for unprotected request context %s succeeded", request.getServletPath());
sam.secureResponse(messageInfo, new Subject(), messageLayer, appContext, cbh);
}
Compare this to the corresponding fragment in WebJASPIAuthenticator, which does process the callbackhandler:
if (sam != null) {
result = sam.isValid(messageInfo, clientSubject, messageLayer, appContext, cbh);
}
// the authentication process has been a success. We need to register the principal, username, password and roles
// with the container
if (result) {
PasswordValidationCallback pvc = cbh.getPasswordValidationCallback();
CallerPrincipalCallback cpc = cbh.getCallerPrincipalCallback();
// get the client principal from the callback.
Principal clientPrincipal = cpc.getPrincipal();
if (clientPrincipal == null) {
clientPrincipal = new SimplePrincipal(cpc.getName());
}
// if the client principal is not a jboss generic principal, we need to build one before registering.
if (!(clientPrincipal instanceof JBossGenericPrincipal))
clientPrincipal = this.buildJBossPrincipal(clientSubject, clientPrincipal);
this.register(request, response, clientPrincipal, authMethod, pvc.getUsername(),
new String(pvc.getPassword()));
if (this.secureResponse)
sam.secureResponse(messageInfo, new Subject(), messageLayer, appContext, cbh);
}
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/797150#797150]
Start a new discussion in PicketBox Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 2 months
- 1
- 0
[JBoss Web Services Development] - How to access webservice deployed to jboss 5.1.0 GA
by ptn77 ptn77
ptn77 ptn77 [https://community.jboss.org/people/ptn77] created the discussion
"How to access webservice deployed to jboss 5.1.0 GA"
To view the discussion, visit: https://community.jboss.org/message/796244#796244
--------------------------------------------------------------
Hello All,
Sorry for this Newbie question, but it's my first time deploying webservices on jboss. I have successfully deployed my webservice to jboss (No webservice deployment errors when I start jboss), but I can't seem to figure out how to access the service from the browser.
I've tried going to localhost:8080/jbossws under registered webservices, but did not see anything there.
I see in the jmx console under the web.deployment the .war file for my webservice is listed there.
I've also tried browsing to the url for my webservice listed in the wsdl, but got a page not found error.
I'm not sure what else I should check.
Any help is appreciated!!
Thanks in Advance!!
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/796244#796244]
Start a new discussion in JBoss Web Services Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 2 months
- 1
- 1
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Layered Distributions and Module Path Organization
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] commented on the document
"Layered Distributions and Module Path Organization"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47927#comment-11552
--------------------------------------------------
Updated with the following:
1) More details on how product.conf is used.
2) Separation of the specification of what layers should be used by jboss-modules into a modules/layers.conf file.
3) Use of modules/system instead of modules/internal
4) Fixed various path descriptions that omitted the "system" (fka "internal") level.
--------------------------------------------------
11 years, 2 months
- 1
- 0
[JBoss AS 7 Development] - Layered Distributions and Module Path Organization
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] modified the document:
"Layered Distributions and Module Path Organization"
To view the document, visit: https://community.jboss.org/docs/DOC-47927
--------------------------------------------------------------
h1. +*This proposal is slightly WIP*+
h1. Overview
This document describes notions for how different software distributions based on the JBoss AS 7 project can integrate with the base AS and with each other in a controlled manner.
+*
*+
h1. Fundamental Concepts
h2. Distribution
A coherent set of software produced by a "project" or a "product". JBoss AS 7 is a project. JBoss EAP is such a product. Both play similar technical roles in the JBoss ecosystem, but there are significant differences in how the two are made available to end users.
This article uses "distribution" as a replacement for constantly saying "project/product" everywhere. It's not a great term; if someone has a better one, please suggest it.
h2. Distribution Base
The "distribution base" is the core set of modules, bundles and miscellaneous files that is common to all layered distributions. It may itself be usable standalone project or product.
Currently the software produced by the JBoss AS 7 project and the JBoss EAP product are the distribution bases relevant to this discussion. In the future a more limited subset of functionality may become the distribution base, with the full set of functionality currently provided in community AS and EAP coming as layered distributions or add-ons.
h2. Layered Distribution
A distribution that builds on top of the distribution base, potentially superceding some of the distribution base's functionality. A layered distribution is allowed to supercede any aspect of the distribution base's functionality. The less the layered distribution does this, the easier it will be for the layered distribution to manage things like patching, but, if necessary, a layered distribution can supercede anything in the distribution base.
A layered distribution build on top of another layered distribution, provided it has worked out the necessary procedures to ensure compatibility.
h2. Identity
An identity is a named set of distribution base + layered distribution(s) that is certified as a valid combination. The distribution base by itself may or may not be a valid identity. Currently it is; in the future it may not be.
The software produced by a given layered distribution may be associated with more than one identity.
h3. Patching and Identities
Patches are applicable to an identity. A given patch can apply to more than one identity, if there are no conflicts between the identities in terms of how they use the items modified by a patch. The metadata associated with a patch will indicate the identities to which it is applicable.
Patches are comprised of one or more discrete +patch elements+ each of which is produced by the distribution base or by one of the layered distributions associated with the identity. A patch element includes metadata describing the element along with any added or modified files. The patch element metadata will identify the provider of the patch component. A given patch element can be used in multiple different patches. For example, a patch element upgrading the distribution base can be included in several patches produced by different identities, with each patch also including a patch element upgrading a layered distribution used in that identity.
For example, let's say an identity named I consists of the distribution base and a layered distribution named A. Version 1.0 of identity I is based on version 2.0 of the distribution base and version 1.0 of layered distribution A. The distribution base produces a patch element that will move it to version 2.1. The producers of the I identity could then produce a patch that will result in version 1.1 of identity A. This would include a patch element upgrading layered distribution A to its version 1.1, as well as the separate element that provides the distribution base upgrade to its 2.1. There are two main benefits of this sharing approach:
* The modules and bundles provided by the distribution base upgrade are associated with the original 2.1 patch provided by the distribution base, not just with the enclosing patch provided by A. This will make possible the sharing of modules/bundles provided by patches across installations.
* Incorporating one patch within another as a simple discrete unit helps avoid errors during patch production.
For modules and bundles within a patch, once the patch is applied the association of the module or bundle with the distribution base or layer that provided it is retained within the installation. The association is encoded within the filesystem path that points to the patch version of the module or bundle.
Miscellaneous files within a patch are not associated with the distribution base or any particular layered distribution once they are installed. For example bin/standalone.sh is bin/standalone.sh no matter what patch component added or modified it.
Each identity produces a patch stream. Because a given patch can apply to more than one identity, the same patch can appear in multiple patch streams.
The distribution base and layered distributions can produces +patch elements+ but they cannot themselves produce +patches+ or a patch stream. Since a patch must be associated with an an identity, only an identity (or a group of cooperating identities) can produce a patch.
If there is an identity that consists of nothing but the distribution base, that identity can produce a patch. But this is logically not the same thing as saying the distribution base itself produced the patch, even though the practical effect is similar.
h2. Installation
An installation is a single filesystem location containing the distribution base plus zero or more layered distributions. It includes the bin/ dir from which processes are launched. The root of the installation is the path indicated by the $JBOSS_HOME environment variable referred to in the scripts and indicated by the jboss.home.dir system property used in the java code.
h3. Installation Identity
Each installation has a *+single identity+*. Because an installation only has a single identity, there is no confusion as to which layered distribution "owns" a particular filesystem location in that installation. Further, because the identity of an installation can be easily determined (see "Establishing Identity" below), external tools can quickly understand the functionality provided by a given installation, even if no process is currently running from the installation.
+TODO further spell out the importance of single identity.+
h3. Sharing Files Across Installations+
+
The files that comprise modules and bundles are potentially sharable across installations. Making it easy for users to do this should be a key goal.
Miscellaneous files are not sharable across installations. An end user could potentially share them using symlinks, but doing so is not a supported feature nor is it a recommended practice.
Patches are not sharable across installations. The +modules and bundles that the patch provides+ are potentially sharable, but the miscellaneous files provided by a patch are not sharable. The patching history metadata that the patching tool records in the installation is also not sharable -- the metadata is associated with the given installation. However, making it easy to share the the modules and bundles provide by a patch across installations should be a key goal.
h2. Add-On Distribution
An add-on distribution is a set of software that extends the capabilities of a given "identity". An add-on can only extend capabilities. It is not allowed to supercede capabilities of the identity it extends. For modules and OSGi bundles, the module and bundle loading logic provided by the distribution base will enforce this behavior. For miscellaneous files, it is up to the people providing an add-on to ensure that the add-on does not overwrite any file provided by the distribution base, any layered distribution associated with the identity or any other add-ons associated with the identity. Conversely, once the providers of an identity have accepted an add-on into their ecosystem, it is their responsibility to ensure that they do not add any files to their distributions that will conflict with files already provided by the add-on.
In practice, the most likely sources of conflict will be the xml files in the configuration directories and the .conf files in the bin directory. Conflicts over xml files are solvable by having add-on providers ship their own xml file variants rather than attempting to modify the standard ones that ship with the identity.
A given add-on is allowed to extend the capabilities of more than one identity.
An add-on may require the presence of other add-ons.
h3. Patching and Add-ons
Add-on distributions produce their own patch stream. The patches produced by an add-on indicate the versions of the identity that must be present for the patch to apply. More than one identity can be listed, since add-ons may be applicable to multiple identities. The patches produced by an add-on also indicate the existing version of the add-on that must be present, as well as the version of any other required add-ons.
Add-ons cannot use patches in their own stream to fix problems in the identity on which they depend. Add-ons depend on the patch stream provided by their dependent identity to provide such fixes. Modules and bundles provided by an add-on or its patches will have lower precedence in the module loading order than those that come from the distribution base or layered distributions, so any fix to such a module/bundle provided by an add-on patch will have no effect.
h1. Installers
+TODO discussion of RPM+
h2. Distribution Base Installers
The distribution base can be installed via a simple unzip. If the distribution base is itself an identity, see also "Identity Installers"
h2. Identity Installers
An identity can be installed via:
* An unzip onto an empty filesystem location of a zip file that includes the distribution base and all layered distributions.
* An unzip onto a filesystem location that already contains a depended upon identity or the installation base of a zip that only includes the layered distribution(s) to be added.
* An installer program that does one or the other or both of the above and also provides a user interface that allows the user to customize the installation.
It is a goal but not an initial requirement to allow installation to be performed via the patching tool. The benefit of this is the patching tool incorporates a number of compatibility checks that can help a user avoid invalid combinations.
A further goal is to make the logic contained in the patching tool available to installer programs via a library.
*+Once an identity is installed into a given filesystem location, the identity of that installation is irrevocably changed.+* When an identity is installed it has the right to modify any miscellaneous files in the installation filesystem, so once an identity is installed, the identity of the installation is changed. In many (hopefully nearly all) cases it may be possible for a user to remove files added by an identity install and get the installation back to its previous identity, but doing this is not a supported feature of the software and is not a recommended practice.
*+However, once support for installing patches via the patching tool is available, reverting an identity installation will be possible.+* The patching tool maintains backup copies of any miscellaneous files modified by a patch, making it possible to restore those files.
h2. Add-on Installer
An identity can be installed via:
* An unzip onto an empty filesystem location of a zip file that includes the distribution base and all layered distributions along with the add-on itself.
* An unzip onto a filesystem location that contains the depended upon identity of a zip that only includes the add-on.
* An installer program that does one or the other or both of the above and also provides a user interface that allows the user to customize the installation.
It is a goal but not an initial requirement to allow installation to be performed via the patching tool. The benefit of this is the patching tool incorporates a number of compatibility checks that can help a user avoid invalid combinations.
A further goal is to make the logic contained in the patching tool available to installer programs via a library.
*+Once an add-on is installed into a given filesystem location, the identity of that installation is not changed, and it must be possible to reverse the installation.+* An add-on is merely additive, so removing it is a matter of deleting what was added. This could be done via a script provided by the add-on, via an installer program, or manually by a user following a set of instructions.
h1. Establishing Identity
It +must+ be possible for external tools to determine the identity of a given installation without requiring the software based on that installation to be running. It's also necessary for the software based on an installation to determine its own identity.
The identity of an installation is provided via the bin/product.conf file located in the distribution. The product.conf file is a simple properties file that contains the following property:
slot=<simple string name for identity>
For example:
slot=eap
The value of "slot" is used by the running software to identify the "slot" portion of the identifier of a jboss-modules module. The software uses the slot to load a module named org.jboss.as.product:<value of slot property>, e.g. org.jboss.as.product:eap. The software will then read manifest properties included in the META-INF/MANIFEST.MF file located in that module to find out other identifying information for the identity. Currently supported manfiest properties include:
* JBoss-Product-Release-Name -- Provides the name of the identity for use in the management API and in places like the startup and shutdown log messages.
* JBoss-Product-Release-Version -- Provides the version of the identity for use in the management API and in places like the startup and shutdown log messages.
* JBoss-Product-Console-Slot -- Used to drive what variant of the management console should be loaded. The notion here is there are different streams of consoles being produced, one for community AS releases and one for product releases, differentiated primarily by cosmetic differences. This property drives which of the two streams of console releases should be used when the console module is loaded. The use of "Slot" in this property name is a bit unfortunate since it implies an implementation detail that may very well change. The name of the property may change in a future minor release of the AS or EAP and will very likely change in the next major release.
If no bin/product.conf file exists, the installation is assumed to be the community version of the distribution base.
If the product.conf file contains other properties besides slot, the software will use those properties to set system properties in the runtime. However, the properties in the file will not take precedence over other mechanisms for setting system properties (i.e. the command line, the standard scripts or the xml configuration files.) Note also that the reading of product.conf occurs after primordial boot, so this mechanism should not be used for setting properties needed immediately on launch. The values are unknown to the JVM launcher, will be unknown to jboss-modules when it sets up the modular classloading environment, and will be unknown to the logging system until any logging subsystem in the xml configuration file is processed.
The software based on the installation will also need to know the name of any layered distributions used by the identity, in order of the precedence to be used when loading their modules and/or bundles. This information will be done via a modules/layers.conf file located in the distribution. This file will be a simple properties file that includes a single property:
layers=<comma delimited list of layered distribution names with earlier names taking precedence>
For example, assuming we have layered distribution named "soa" and "brms" with "brms" taking precedence over "soa":
layers=brms,soa
There is no need to include "base" in the list of layers; if not present "base" will be appended to the list of layers as the lowest precedence layer. It is legal to include "base" in the list, though.
If the modules/layers.conf file does not exist or no layered distributions are named in it, only the base and any add-ons will be used.
h1. Module Loading
JBoss AS currently loads modules based on a "module path" which is a list of filesystem locations which JBoss Modules searches for modules. In our standard launch scripts, users are able to manipulate this module path by setting the $JBOSS_MODULEPATH environment variable. If not set, $JBOSS_MODULEPATH is set to $JBOSS_HOME/modules.
This mechanism creates a single default location under which modules can be located. This is problematic when layered distributions and add-ons wish to install their own modules, since there are no clear rules as to how those modules should be installed or how they relate to one another.
h2. Goals
* To make it easy for layered distributions or add-ons to add their modules to the set of available modules or remove their modules from the set of available modules, without fear of physically overwriting modules provided by others.
* To establish clear rights and responsibilities for providers of the distribution base, layered distributions and add-ons with respect to how their modules should be managed.
* To establish clear rules for how distributions that add modules that must take precedence over other modules provided by other distributions with the same name and slot should:* locate those modules
* indicate at launch time to the modular classloading system the precedence order
* To make it easy for end users to alter the module path for their own purposes by setting $JBOSS_MODULEPATH without needing to concern themselves with details of how the modules provided by the distribtuion base, layered distributions, or add-ons relate to one another. Reserve the use of $JBOSS_MODULEPATH and the value of the -mp command line argument passed to jboss-modules for end use uses.
h2. Rights and Responsibilities of Module Providers
All modules provided as part of the distribution base can be depended upon by any add-on associated with an identity.
If the distribution base by itself is an identity (i.e. with no additional layered distribution required), the providers of the distribution base accept the following with respect to that identity:
* The version of the module the distribution base provides will take precedence over a module with the same name and slot provided by any add-on.
* As a consequence of this, any modification of that module in a patch will need to be tested for compatibility with add-ons based on the version of the identity being patched.
* As a subset of the previous point, within a major version family the distribution base cannot remove a module that is depended upon by an add-on, even if the distribution base itself no longer needs that module.
If the distribution base is part of an identity along with one or more layered distributions, the providers of the distribution base accept the following with respect to that identity:
* The distribution base has the same responsibilities with respect to add-ons that it has in the case of add-ons without any layered distribution.
* However, if a layered distribution in an identity provides a module with the same name and slot as the one provided by the distribution base, the distribution base no longer has responsibility to provide the module. The layered distribution's version of the module takes precedence.
* The distribution base can modify a module that is depended upon by a layered distribution in a way that breaks functionality of the layered distribution. Providers of identities that include layered distributions are responsible for testing patch elements produced by the distribution base before making them available for use with the identity. If the distribution base patch element in some way breaks the functionality of an identity, either the patch element should not be provided for the identity, or the patch that incorporates the distribution base patch element should also include a layered distribution patch element that fixes the problem.* However, the distribution base should take great care not to break layered distributions with which it is associated when it produces patch elements. Distribution base patch element production should involve reasonable testing of all relevant identities such that problems can be found and resolved before the distribution base patch element ships.
* The distribution base can remove a module that is not depended upon by any add-on but which is depended upon by a layered distribution. Providers of identities that include layered distributions are responsible for testing patch elements produced by the distribution base before making them available for use with the identity. If the distribution base removes a module depended upon by a layered distribution, the patch that incorporates the distribution base patch element should also include a layered distribution patch element that adds the module as part of the layered distribution.
* If an identity add-on depends on a module provided by the distribution base and the distribution base wishes to remove the module, that is allowed provided some layered distribution is willing to begin providing the same module in an overall patch.
All modules provided as part of a layered distribution can be depended upon by any add-on associated with an identity. They cannot be depended upon by the distribution base. When a layered distribution includes a module it accepts the following:
* The version of the module it provides will take precedence over a module with the same name and slot provided by the distribution base or by any add-on.
* As a consequence of this, any modification of that module in a patch element will need to be tested for compatibility with add-ons based on that version of the identity. Any functionality provided by the distribution base and supported by the identity will also have to be tested.
* As a subset of the previous point, within a major version family the layered distribution cannot remove a module that is depended upon by an add-on, even if the layered distribution itself no longer needs that module.
* A layered distribution can remove a module that is not depended upon by any add-on.
If a layered distribution participates in an identity with another layered distribution that depends on it, the depended-on layer accepts the following:
* If the dependent layered distribution provides a module with the same name and slot as the one provided by the depended-on layer, the depended-on layer no longer has responsibility to provide the module to the dependent or to any add-ons. The dependent layered distribution's version of the module takes precedence.
* The depended-on layer can modify a module that is depended upon by another layer in a way that breaks functionality of the dependent. Providers of identities that include layered distributions are responsible for testing patch elements produced by the component layers before making them available for use with the identity. If the depended-on layer's patch element in some way breaks the functionality of an identity, either the patch should not be provided for the identity, or the patch element that incorporates the depended-on layer's patch component should also include a patch element to a dependent layer that fixes the problem.* However, a depended-on layer should take great care not to break dependent layers when it produces patch elements. Layered distribution patch production should involve reasonable testing of all relevant identities such that problems can be found and resolved before the depended-on layer's patch ships.
* A depended-on layer can remove a module that is not depended upon by any add-on but which is depended upon by another layer. Providers of identities that include layered distributions are responsible for testing patch elements produced by a depended-upon layered distribution before making them available for use with the identity. If the depended-upon layer removes a module that is depended upon by another layer, the patch that incorporates the depended-upon layer's patch element should also include a patch element from the dependent layer distribution that adds the module as part of that layered distribution.
* If an add-on depends on a module provided by the layered distribution and the layered distribution wishes to remove the module, that is allowed provided some other layered distribution in the identity is willing to begin providing the same module in an overall patch.
When an add-on includes a module, it accepts the following with respect to any identity with which the add-on is associated:
* The distribution base or a layered distribution may ship a module with the same name and slot, and that module +*will*+ take precedence over the module provided by the add-on.
* Another add-on may ship a module with the same name and slot, and that module +*may*+ take precedence over the module provided by this layered distribution or add-on.
* Another add-on may ship a module with the same name and slot, and the version provided by this layered distribution or add-on +*may*+ take precedence over the module provided by the other add-on.
* As a consequence of this, any modification of the depended-upon module in a patch element will need to be tested for compatibility with any add-on based on the same major version of the identity.* The providers of the add-on are responsible for providing an adequate set of tests to the providers of the identity.
* The distribution base or a layered distribution cannot depend upon a module provided by an add-on.
* As a consequence of the previous point, an add-on can remove a module in a patch, without fear of breaking the core functionality of an identity.
* An add-on can depend up a shareable module provided by another add-on upon which it depends, but +only with the express consent of the providers of that add-on+. Such dependencies are strongly discouraged.
* If an add-on allows another add-on to depend upon its modules, it takes on the following responsibilities:* Any modification of that module in a patch or version upgrade will need to be tested for compatibility with any dependent add-ons. Testing procedures must be created to ensure that any patches produced by the depended-upon add-on do not break the dependent add-on.
* As a subset of the previous point, within a major version family the add-on cannot remove a module that is depended upon by another add-on, even if the add-on itself no longer needs that module.
h2. Module Organization on the Filesystem
This section will describe how the above points are reflected in the actual organization of modules on the filesystem.
h4. Requirement for Standardized Module Loading
JBoss Modules can support other mechanisms for finding module content and loading it besides the filesystem-based module path mechanism. Theoretically a custom boot module loader implementation could be specified at process launch, with that module loader using some other means for locating module content. This article proposes that this capability be declared as unsupported for JBoss AS and products based upon it. Rather, the AS will have a specified boot module loader implementation.
Users of the AS community project are free to use a non-standard boot module loader implementation, but if they do so and certain features provided by the AS don't work, that is their problem.
h3. Filesystem Layout
Modules would be organized on the filesystem as follows:
modules
+ system
++ add-ons
+++ abc
+++ def
++ layers
+++ base
+++ vuw
+++ xyz
The system level exists to separate modules associated with the distribution base, layered distribution or add-ons from those the end user may store in the modules directory. +(Note: in earlier versions of this document, "internal" was used instead of "system" with a request for suggestions of something better.)+
h3. Translation of Filesystem Layout into Module Loading Precedence
For any location provided by the user via the -mp switch, the module loader will look for the system structure. The module loader will understand the structure above and will apply module loading precedence rules as follows.
Assume the above structure exists under $JBOSS_HOME and that the user sets $JBOSS_MODULEPATH as follows
JBOSS_MODULESPATH=/user/me/my-modules;$JBOSS_HOME/modules
In addition, the bin/product.conf file declares that the identity of the install is xyz, the xyz layered distribution should be loaded and the xyz layered distribution depends on the vuw layered distribution.
Assume also that patches named base-1, abc-1, def-1, vuw-1, xyz-1 and xyz-2 have been applied.
The module loader would look for modules on the filesystem in following locations, starting with first and terminating as soon as the module is found:
/user/me/my-modules
/modules (in case the user placed modules directly in under this directory)
/modules/system/layers/xyz/patches/xyz-2
/modules/system/layers/xyz/patches/xyz-1
/modules/system/layers/xyz
/modules/system/layers/vuw/patches/vuw-1
/modules/system/layers/vuw
/modules/system/layers/base/patches/base-1
/modules/system/layers/base
/modules/system/add-ons/abc/patches/abc-1
/modules/system/add-ons/abc
/modules/system/add-ons/def/patches/def-1
/modules/system/add-ons/def
The precedence order between /modules/system/add-ons/abc and /modules/system/add-ons/def is arbitrary. An add-on should never assume its modules will take precedence over those of any other add-on's modules.
The fact that the various patches locations are included in the path is entirely due to +metadata+ that the patching tool will store in the $JBOSS_HOME/patches directory. The mere presence of a directory like /modules/system/layers/xyz/patches/xyz-2 is insufficient to trigger inclusion of that directory in the module search path. However, when the patching tool installs the patch, the actual location of the +module contents+ will be in /modules/system/layers/xyz/patches/xyz-2 -- only patching related metadata will be stored in $JBOSS_HOME/patches. This behavior is important for allowing sharing of modules across installations.
h2. Sharing Modules Across Installations
The above behavior makes it relatively straightforward for a user to share modules across installations. For example, the user could set up a shared module repo in /user/me with the following structure
jboss-module-repo
+ add-ons
++ abc
++ def
+ layers
++ base
++ vuw
++ xyz
The $JBOSS_HOME/modules/system location in each installation on the filesystem could then be replaced with a symlink to /user/me/jboss-module-repo.
The downside to this very simple sharing is the abc and def add-ons will be visible and used by all installations, whether or not they are relevant to the installation's identity. A solution to this problem would be to do more symlinks:
$JBOSS_HOME/modules/system/layers -> /user/me/jboss-module-repo/layers
$JBOSS_HOME/modules/system/add-ons/abc -> /user/me/jboss-module-repo/add-ons/abc
$JBOSS_HOME/modules/system/add-ons/def -> /user/me/jboss-module-repo/add-ons/def
As an improvement at some point we could define some sort of file format (say xml) and allow a file with that format to be placed in $JBOSS_HOME/modules/system in lieu of the subdirectories. The file would include all of the mapping information for the external repo. The boot module loader, patching tool and any programmatic installers would know how to read and update that file. The file would only include information for the add-ons relevant to the installation.
h3. Implications for the Patching Tool
The possibility of module sharing doesn't remove the requirement to apply a patch to each installation on a given filesystem. Applying the patch to each installation is required in order to:
* update any miscellaneous files
* record the patching metadata for the particular installation
* allow the patching tool to understand what combinations of layered distributions and add-ons are relevant to the given installation
However, the patching tool should recognize the possibility of this kind of module sharing. When it applies a patch it should recognize that the modules may already exist on the filesystem and should not apply them again if not necessary. It should however record some information in, e.g. /modules/system/layers/xyz/patches/xyz-2 indicating that the installation being patched is using that set of patch modules. This information will prevent deletion of patch modules used by multiple installations if one of the installations uses the patching feature's cleanup functions.
h1. OSGi Bundle Loading
OSGi bundle loading will follow the same rules as for module loading. The file used to specify what layers should be used will be a layers.conf file found in each directory in the bundle path (i.e. $JBOSS_HOME/bundles/layers.conf.) +The bundle loading mechanism will not use+ +$JBOSS_HOME/modules/layers.conf for identifying layers. Identities that wish to include bundles in layers other than the base will need to provide a $JBOSS_HOME/bundles/layers.conf.+
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47927]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 2 months
- 1
- 0
Re: [jboss-dev-forums] [JBoss Web Development] - JBoss 6.0 : Deployment in error
by Libor Krzyžanek
Libor Krzyžanek [https://community.jboss.org/people/lkrzyzanek] replied to the discussion
"JBoss 6.0 : Deployment in error"
To view the discussion, visit: https://community.jboss.org/message/796858#796858
--------------------------------------------------------------
Hello,
I don't understand why my deployment failed because all times when I run the server this error message occurs:
02:59:16,071 INFO [AbstractJBossASServerBase] Server Configuration:
JBOSS_HOME URL: file:/C:/Eclipse/jboss-6.0.0.Final/
Bootstrap: $JBOSS_HOME\server/default/conf/bootstrap.xml
Common Base: $JBOSS_HOME\common/
Common Library: $JBOSS_HOME\common/lib/
Server Name: default
Server Base: $JBOSS_HOME\server/
Server Library: $JBOSS_HOME\server/default/lib/
Server Config: $JBOSS_HOME\server/default/conf/
Server Home: $JBOSS_HOME\server/default/
Server Data: $JBOSS_HOME\server/default/data/
Server Log: $JBOSS_HOME\server/default/log/
Server Temp: $JBOSS_HOME\server/default/tmp/
02:59:16,075 INFO [AbstractServer] Starting: JBossAS [6.0.0.Final "Neo"]
02:59:17,797 INFO [ServerInfo] Java version: 1.6.0_31,Sun Microsystems Inc.
02:59:17,797 INFO [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
02:59:17,797 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 20.6-b01,Sun Microsystems Inc.
02:59:17,798 INFO [ServerInfo] OS-System: Windows 7 6.1,x86
02:59:17,798 INFO [ServerInfo] VM arguments: -Dprogram.name=JBossTools: JBoss 6.0 Runtime -Xms256m -Xmx768m -XX:MaxPermSize=256m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.endorsed.dirs=C:\Eclipse\jboss-6.0.0.Final\lib\endorsed -Djava.library.path=C:/Eclipse/jboss-6.0.0.Final/bin/native -Dfile.encoding=Cp1252
02:59:17,842 INFO [JMXKernel] Legacy JMX core initialized
02:59:24,527 INFO [AbstractServerConfig] JBoss Web Services - Stack CXF Server 3.4.1.GA
02:59:25,351 INFO [JSFImplManagementDeployer] Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0]
02:59:29,460 ATTENTION [FileConfigurationParser] AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal
02:59:32,881 ATTENTION [FileConfigurationParser] AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal
02:59:33,119 INFO [JMXConnector] starting JMXConnector on host localhost:1090
02:59:33,315 INFO [MailService] Mail Service bound to java:/Mail
02:59:34,661 INFO [HornetQServerImpl] live server is starting..
02:59:34,753 INFO [JournalStorageManager] Using NIO Journal
02:59:34,785 ATTENTION [HornetQServerImpl] Security risk! It has been detected that the cluster admin user and password have not been changed from the installation default. Please see the HornetQ user guide, cluster chapter, for instructions on how to do this.
02:59:35,612 INFO [NettyAcceptor] Started Netty Acceptor version 3.2.1.Final-r2319 localhost:5455 for CORE protocol
02:59:35,618 INFO [NettyAcceptor] Started Netty Acceptor version 3.2.1.Final-r2319 localhost:5445 for CORE protocol
02:59:35,623 INFO [HornetQServerImpl] HornetQ Server version 2.1.2.Final (Colmeia, 120) started
02:59:35,689 INFO [WebService] Using RMI server codebase: http://localhost:8083/ http://localhost:8083/
02:59:35,919 INFO [jbossatx] ARJUNA-32010 JBossTS Recovery Service (tag: JBOSSTS_4_14_0_Final) - JBoss Inc.
02:59:35,929 INFO [arjuna] ARJUNA-12324 Start RecoveryActivators
02:59:35,975 INFO [arjuna] ARJUNA-12296 ExpiredEntryMonitor running at sam., 9 févr. 2013 02:59:35
02:59:36,103 INFO [arjuna] ARJUNA-12310 Recovery manager listening on endpoint 127.0.0.1:4712
02:59:36,104 INFO [arjuna] ARJUNA-12344 RecoveryManagerImple is ready on port 4712
02:59:36,104 INFO [jbossatx] ARJUNA-32013 Starting transaction recovery manager
02:59:36,129 INFO [arjuna] ARJUNA-12163 Starting service com.arjuna.ats.arjuna.recovery.ActionStatusService on port 4713
02:59:36,134 INFO [arjuna] ARJUNA-12337 TransactionStatusManagerItem host: 127.0.0.1 port: 4713
02:59:36,218 INFO [arjuna] ARJUNA-12170 TransactionStatusManager started on port 4713 and host 127.0.0.1 with service com.arjuna.ats.arjuna.recovery.ActionStatusService
02:59:36,278 INFO [jbossatx] ARJUNA-32017 JBossTS Transaction Service (JTA version - tag: JBOSSTS_4_14_0_Final) - JBoss Inc.
02:59:36,316 INFO [arjuna] ARJUNA-12202 registering bean jboss.jta:type=ObjectStore.
02:59:37,071 INFO [AprLifecycleListener] The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:/Eclipse/jboss-6.0.0.Final/bin/native
02:59:37,238 INFO [TomcatDeployment] deploy, ctxPath=/invoker
02:59:37,642 INFO [ModClusterService] Initializing mod_cluster 1.1.0.Final
02:59:37,703 INFO [RARDeployment] Required license terms exist, view vfs:/C:/Eclipse/jboss-6.0.0.Final/server/default/deploy/jboss-local-jdbc.rar/META-INF/ra.xml
02:59:37,717 INFO [RARDeployment] Required license terms exist, view vfs:/C:/Eclipse/jboss-6.0.0.Final/server/default/deploy/jboss-xa-jdbc.rar/META-INF/ra.xml
02:59:37,726 INFO [RARDeployment] Required license terms exist, view vfs:/C:/Eclipse/jboss-6.0.0.Final/server/default/deploy/jms-ra.rar/META-INF/ra.xml
02:59:37,748 INFO [HornetQResourceAdapter] HornetQ resource adaptor started
02:59:37,756 INFO [RARDeployment] Required license terms exist, view vfs:/C:/Eclipse/jboss-6.0.0.Final/server/default/deploy/mail-ra.rar/META-INF/ra.xml
02:59:37,771 INFO [RARDeployment] Required license terms exist, view vfs:/C:/Eclipse/jboss-6.0.0.Final/server/default/deploy/quartz-ra.rar/META-INF/ra.xml
02:59:37,901 INFO [SimpleThreadPool] Job execution threads will use class loader of thread: Thread-2
02:59:37,950 INFO [SchedulerSignalerImpl] Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl
02:59:37,950 INFO [QuartzScheduler] Quartz Scheduler v.1.8.3 created.
02:59:37,954 INFO [RAMJobStore] RAMJobStore initialized.
02:59:37,958 INFO [QuartzScheduler] Scheduler meta-data: Quartz Scheduler (v1.8.3) 'JBossQuartzScheduler' with instanceId 'NON_CLUSTERED'
Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
NOT STARTED.
Currently in standby mode.
Number of jobs executed: 0
Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 10 threads.
Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support persistence. and is not clustered.
02:59:37,961 INFO [StdSchedulerFactory] Quartz scheduler 'JBossQuartzScheduler' initialized from an externally opened InputStream.
02:59:37,962 INFO [StdSchedulerFactory] Quartz scheduler version: 1.8.3
02:59:37,962 INFO [QuartzScheduler] Scheduler JBossQuartzScheduler_$_NON_CLUSTERED started.
02:59:38,531 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
02:59:39,391 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
02:59:39,603 INFO [xnio] XNIO Version 2.1.0.CR2
02:59:39,618 INFO [nio] XNIO NIO Implementation Version 2.1.0.CR2
02:59:39,891 INFO [remoting] JBoss Remoting version 3.1.0.Beta2
02:59:40,047 INFO [TomcatDeployment] deploy, ctxPath=/
02:59:40,098 INFO [service] Removing bootstrap log handlers
02:59:40,199 INFO [org.apache.coyote.http11.Http11Protocol] Démarrage de Coyote HTTP/1.1 sur http-localhost%2F127.0.0.1-8282
02:59:40,203 INFO [org.apache.coyote.ajp.AjpProtocol] Starting Coyote AJP/1.3 on ajp-localhost%2F127.0.0.1-8009
02:59:40,204 INFO [org.jboss.bootstrap.impl.base.server.AbstractServer] JBossAS [6.0.0.Final "Neo"] Started in 24s:124ms
02:59:40,811 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/Ecommerce
02:59:40,815 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=jboss.web.deployment:war=/Ecommerce state=Create mode=Manual requiredState=Installed: java.net.URISyntaxException: Illegal character in path at index 21: file:/C:/Users/MFOUKA MOKONO/workspace2/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_6.0_Runtime_Server1354807548842/deploy/Ecommerce.war/
at java.net.URI$Parser.fail(URI.java:2810) [:1.6.0_31]
at java.net.URI$Parser.checkChars(URI.java:2983) [:1.6.0_31]
at java.net.URI$Parser.parseHierarchical(URI.java:3067) [:1.6.0_31]
at java.net.URI$Parser.parse(URI.java:3015) [:1.6.0_31]
at java.net.URI.<init>(URI.java:577) [:1.6.0_31]
at java.net.URL.toURI(URL.java:918) [:1.6.0_31]
at org.jboss.vfs.VFS.getChild(VFS.java:174) [jboss-vfs.jar:3.0.0.GA]
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:223) [:6.0.0.Final]
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:146) [:6.0.0.Final]
at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:477) [:6.0.0.Final]
at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) [:6.0.0.Final]
at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.0.0.Final]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_31]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_31]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_31]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_31]
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA]
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA]
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA]
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA]
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA]
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) [:2.2.0.GA]
at $Proxy41.start(Unknown Source) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:53) [:2.2.0.GA]
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:41) [:2.2.0.GA]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:301) [:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.0.GA]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.GA]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.GA]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.Final]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileDeployAction.deploy(ProfileDeployAction.java:151) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileDeployAction.installActionInternal(ProfileDeployAction.java:94) [:0.2.2]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.profileservice.dependency.ProfileActivationWrapper$BasicProfileActivation.start(ProfileActivationWrapper.java:190) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationWrapper.start(ProfileActivationWrapper.java:87) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationService.activateProfile(ProfileActivationService.java:215) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationService.activate(ProfileActivationService.java:159) [:0.2.2]
at org.jboss.profileservice.AbstractProfileService.activateProfile(AbstractProfileService.java:154) [:0.2.2]
at org.jboss.system.tools.ProfileServiceToolsFacade.addURI(ProfileServiceToolsFacade.java:233) [:6.0.0.Final]
at org.jboss.system.tools.LegacyDeploymentScannerAdapter.addURL(LegacyDeploymentScannerAdapter.java:140) [:6.0.0.Final]
at org.jboss.system.tools.DeploymentScanner.addURL(DeploymentScanner.java:91) [:6.0.0.Final]
at org.jboss.system.tools.DeploymentScanner.addURL(DeploymentScanner.java:83) [:6.0.0.Final]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_31]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_31]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_31]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_31]
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA]
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA]
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA]
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA]
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA]
at org.jboss.system.server.jmx.MBeanServerWrapper.invoke(MBeanServerWrapper.java:138) [:6.0.0.Final (Build SVNTag:JBoss_6.0.0.Final date: 20101228)]
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) [:1.6.0_31]
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) [:1.6.0_31]
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) [:1.6.0_31]
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) [:1.6.0_31]
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) [:1.6.0_31]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_31]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_31]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_31]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_31]
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:303) [:1.6.0_31]
at sun.rmi.transport.Transport$1.run(Transport.java:159) [:1.6.0_31]
at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_31]
at sun.rmi.transport.Transport.serviceCall(Transport.java:155) [:1.6.0_31]
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) [:1.6.0_31]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) [:1.6.0_31]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) [:1.6.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_31]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_31]
Besides I try to remove the war but the same defect occurs. I want solve this defect in order to continue.
Thanks for your help!!!!
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/796858#796858]
Start a new discussion in JBoss Web Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 2 months
- 1
- 0
[jBPM Development] - Getting the exception in INFO log level instead as ERROR
by Manoj Kannan K
Manoj Kannan K [https://community.jboss.org/people/manojkannan] created the discussion
"Getting the exception in INFO log level instead as ERROR"
To view the discussion, visit: https://community.jboss.org/message/796983#796983
--------------------------------------------------------------
In the jboss server log, am getting the org.drools.WorkItemHandlerNotFoundException in the INFO level. In production, log level will be only in ERROR. How to change the log level to ERROR for exception thrown in jbpm..
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/796983#796983]
Start a new discussion in jBPM Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 2 months
- 1
- 0