JBoss 4/5 MBeans such as NamingAlias are defined in XML as follows
<mbean code="org.jboss.naming.NamingAlias" name=":service=NamingAlias,fromName=queue/original">
<attribute name="ToName">queue/linked</attribute>
<attribute name="FromName">queue/original</attribute>
</mbean>
Paying attention to the attributename=":service=NamingAlias,fromName=queue/original I see the parameters service and fromName.
Following the instructions to create a custom MBean here:
https://developer.jboss.org/wiki/ExampleHelloWorldService
The XML configuration for the MBean created is
<server>
<mbean code="com.acme.HelloWorldService" name="acme.com:service=HelloWorld">
<attribute name="Message">Hello World</attribute>
</mbean>
</server>
I noticed only service is specified in the name attribute.
Is service mandatory for all the beans? What about adding additional parameters such as fromName? Can these values be used from within the class that implements the MBean or are those mandated?
The name attribute can be any valid (and unique) JMX ObjectName. The keys and values themselves do not have any special significance other than their subjective significance to the developer.
In the first example, the ObjectName does not specify a domain (the value to the left of the colon) so the MBeanServer assumes the default domain, which in this case would be jboss so notionally:
:service=NamingAlias,fromName=queue/original == jboss:service=NamingAlias,fromName=queue/original
The ObjectName (and it's embedded domain and key/values) can be used within the class. In standard JMX, one would typically make the impl implement MBeanRegistration which injects the MBeanServer and ObjectName when the bean is registered. However, the example you referenced is a specialized JBoss ServiceMBean which does this automatically and your implementation will store the ObjectName in the field called serviceName.
Related
I would like to set in the WildFly/JBoss ejb3 subsystem enable-graceful-txn-shutdown to true.
Tried two approaches:
<subsystem xmlns="urn:jboss:domain:ejb3:4.0" enable-graceful-txn-shutdown="true">
and
<subsystem xmlns="urn:jboss:domain:ejb3:4.0">
<enable-graceful-txn-shutdown value="true"/>
Both times I got a Validation error in standalone.xml:
'enable-graceful-txn-shutdown' isn't an allowed attribute for the
'subsystem'
element 'enable-graceful-txn-shutdown' isn't an allowed
element here
What is the right place?
Your subsystem tag's namespace is incorrect, enable-graceful-txn-shutdown isn't defined in urn:jboss:domain:ejb3:4.0 but in urn:jboss:domain:ejb3:5.0 (which is new in Wildfly 11).
If you check the XSD defining this namespace (which can be found in the docs/schema dir of your wildfly install, in this case as the wildfly-ejb3_3_5_0.xsd file), you'll find as Omoro pointed out that this tag should be at the root of your subsystem with a value boolean attribute, i.e.
<subsystem xmlns="urn:jboss:domain:ejb3:5.0">
<enable-graceful-txn-shutdown value="true"/>
Below is my sample Soap Response for a service hosted in camel cxf
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:XpgIntegratedPaymentResponse xmlns:ns2="http://test:9090/wsx/services/WemXpgPaymentService"/>
</soap:Body>
</soap:Envelope>
Now I don't want to generate "ns2" namespace prefix in response.
Can anyone help?
if you want to drop the namespace of that element so that it is serialized as no-namespaced XpgIntegratedPaymentResponse, the common approach is to use CXF's transform feature.
see more info here:
http://cxf.apache.org/docs/transformationfeature.html#TransformationFeature-Changinginputandoutputelementnamesandnamespaces
in your particular case, you will need the following entry
<entry key="{http://test:9090/wsx/services/WemXpgPaymentService"}XpgIntegratedPaymentResponse"
value="XpgIntegratedPaymentResponse"/>
Are you using Camel 2.11+ ? You can control the namespaces mapping:
Taken from:
http://camel.apache.org/jaxb.html
When marshalling using JAXB or SOAP then the JAXB implementation will automatic assign namespace prefixes, such as ns2, ns3, ns4 etc. To control this mapping, Camel allows you to refer to a map which contains the desired mapping.
Notice this requires having JAXB-RI 2.1 or better (from SUN) on the classpath, as the mapping functionality is dependent on the implementation of JAXB, whether its supported.
For example in Spring XML we can define a Map with the mapping. In the mapping file below, we map SOAP to use soap as prefix. While our custom namespace "http://www.mycompany.com/foo/2" is not using any prefix.
<util:map id="myMap">
<entry key="http://www.w3.org/2003/05/soap-envelope" value="soap"/>
<!-- we dont want any prefix for our namespace -->
<entry key="http://www.mycompany.com/foo/2" value=""/>
</util:map>
To use this in JAXB or SOAP you refer to this map, using the namespacePrefixRef attribute as shown below. Then Camel will lookup in the Registry a java.util.Map with the id "myMap", which was what we defined above.
<marshal>
<soapjaxb version="1.2" contextPath="com.mycompany.foo" namespacePrefixRef="myMap"/>
</marshal>
I cannot seem to get configuring port-offsets via properties file on the domain managed setup to start multiple server instances in a server group.
I have the following configuration in host.xml:
<servers>
<server name="instance-one" group="main-server-group" auto-start="true">
<socket-bindings port-offset="${jboss.instance1.offset}"/>
</server>
<server name="instance-two" group="main-server-group" auto-start="true">
<!-- server-two avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
<socket-bindings port-offset="${jboss.instance2.offset}"/>
</server>
</servers>
The properties are configured via properties file (custom-domain.properties):
jboss.domain.base.dir=custom-domain
jboss.instance1.offset=10300
jboss.instance2.offset=20300
And I try to startup the domain using
./domain.sh -P=custom-domain.properties
The problem is that jboss.instance1.offset and jboss.instance2.offset are not being applied to the corresponding properties in host.xml. If I have hardcoded values in the host.xml it appears to start up instance 1 and instance 2 on the hardcoded port offsets.
Does custom property configuration not work in domain setup?
Thanks for any help.
Can I dump a properties file somewhere in one of the JBoss 6 directories, and pick it up from the classpath?
Or even better, does anybody know the mechanism behind a configuration file like $JBOSS_HOME/server/default/deploy/jboss-logging.xml? Changes to this file seem to trigger an event, so that a running instance can process the modifications (without having to bounce the AS).
A possibility is to configure SystemPropertiesService in ./conf/jboss-service.xml.
This allows you to configure system properties in-place, or load them from a properties file:
<server>
<mbean code="org.jboss.varia.property.SystemPropertiesService"
name="jboss.util:type=Service,name=SystemProperties">
<!-- Load properties from each of the given comma seperated URLs -->
<attribute name="URLList">
http://somehost/some-location.properties,
./conf/somelocal.properties
</attribute>
<!-- Set propertuies using the properties file style. -->
<attribute name="Properties">
property1=This is the value of my property
property2=This is the value of my other property
</attribute>
</mbean>
</server>
For more details, refer to: http://docs.jboss.org/jbossas/admindevel326/html/ch10.html
They have made this even easier in JBoss EAP 6 (AS 7).
Pass Property File as Startup Parameter
This can be added within the main start up script or passed as parameter
./standalone.sh --properties=/Users/john.galt/dev/config/ds/jboss.properties
If these properties are read, they will be rendered in the server log as the first statement.
3:58:41,633 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties:
DSsettings.password = password
DSsettings.user-name = admin
DSsettings.connection-url = jdbc:oracle:fat:#activedb:1521:DEV
[Standalone] =
awt.nativeDoubleBuffering = true
NOTE: As these settings are logged in server log, ensure no clear text passwords are in the property files in production
Use passed in system properties
You could use these system properties with following syntax.
Example Usage in a data source file
<xa-datasource jndi-name="java:jboss/ds" pool-name="cPool" jta="true" enabled="true" use-ccm="true">
<xa-datasource-property name="URL">
${DSsettings.connection_url}
</xa-datasource-property>
<driver>oracle</driver>
...
<security>
<user-name>${DSsettings.user-name}</user-name>
<password>${DSsettings.password}</password>
</security>
...
</xa-datasource>
In JBoss 6 use: ./deploy/properties-service.xml
On JBoss AS7 properties-service.xml no longer exist, the below is the solution:
http://www.mastertheboss.com/jboss-server/jboss-configuration/how-to-inject-system-properties-into-jboss
I have a web-app that requires two settings:
A JDBC datasource
A string token
I desperately want to be able to deploy one .war to various different containers (jetty,tomcat,gf3 minimum) and configure these settings at application level within the container.
My code does this:
InitialContext ctx = new InitialContext();
Context envCtx = (javax.naming.Context) ctx.lookup("java:comp/env");
token = (String)envCtx.lookup("token");
ds = (DataSource)envCtx.lookup("jdbc/datasource")
Let's assume I've used the glassfish management interface to create two jdbc resources: jdbc/test-datasource and jdbc/live-datasource which connect to different copies of the same schema, on different servers, different credentials etc. Say I want to deploy this to glassfish with and point it at the test datasource, I might have this in my sun-web.xml:
...
<resource-ref>
<res-ref-name>jdbc/datasource</res-ref-name>
<jndi-name>jdbc/test-datasource</jndi-name>
</resource-ref>
...
but
sun-web.xml goes inside my war, right?
surely there must be a way to do this through the management interface
Am I even trying to do the right thing? Do other containers make this any easier? I'd be particularly interested in how jetty 7 handles this since I use it for development.
EDIT Tomcat has a reasonable way to do this:
Create $TOMCAT_HOME/conf/Catalina/localhost/webapp.xml with:
<?xml version="1.0" encoding="UTF-8"?>
<Context antiResourceLocking="false" privileged="true">
<!-- String resource -->
<Environment name="token" value="value of token" type="java.lang.String" override="false" />
<!-- Linking to a global resource -->
<ResourceLink name="jdbc/datasource1" global="jdbc/test" type="javax.sql.DataSource" />
<!-- Derby -->
<Resource name="jdbc/datasource2"
type="javax.sql.DataSource"
auth="Container"
driverClassName="org.apache.derby.jdbc.EmbeddedDataSource"
url="jdbc:derby:test;create=true"
/>
<!-- H2 -->
<Resource name="jdbc/datasource3"
type="javax.sql.DataSource"
auth="Container"
driverClassName="org.h2.jdbcx.JdbcDataSource"
url="jdbc:h2:~/test"
username="sa"
password=""
/>
</Context>
Note that override="false" means the opposite. It means that this setting can't be overriden by web.xml.
I like this approach because the file is part of the container configuration not the war, but it's not part of the global configuration; it's webapp specific.
I guess I expect a bit more from glassfish since it is supposed to have a full web admin interface, but I would be happy enough with something equivalent to the above.
For GF v3, you may want to try leveraging the --deploymentplan option of the deploy subcommand of asadmin. It is discussed on the man page for the deploy subcommand.
We had just this issue when migrating from Tomcat to Glassfish 3. Here is what works for us.
In the Glassfish admin console, configure datasources (JDBC connection pools and resources) for DEV/TEST/PROD/etc.
Record your deployment time parameters (in our case database connect info) in properties file. For example:
# Database connection properties
dev=jdbc/dbdev
test=jdbc/dbtest
prod=jdbc/dbprod
Each web app can load the same database properties file.
Lookup the JDBC resource as follows.
import java.sql.Connection;
import javax.sql.DataSource;
import java.sql.SQLException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
/**
* #param resourceName the resource name of the connection pool (eg jdbc/dbdev)
* #return Connection a pooled connection from the data source
* associated with resourceName
* #throws NamingException will be thrown if resource name is not found
*/
public Connection getDatabaseConnection(String resourceName)
throws NamingException, SQLException {
Context initContext = new InitialContext();
DataSource pooledDataSource = (DataSource) initContext.lookup(resourceName);
return pooledDataSource.getConnection();
}
Note that this is not the usual two step process involving a look up using the naming context "java:comp/env." I have no idea if this works in application containers other than GF3, but in GF3 there is no need to add resource descriptors to web.xml when using the above approach.
I'm not sure to really understand the question/problem.
As an Application Component Provider, you declare the resource(s) required by your application in a standard way (container agnostic) in the web.xml.
At deployment time, the Application Deployer and Administrator is supposed to follow the instructions provided by the Application Component Provider to resolve external dependencies (amongst other things) for example by creating a datasource at the application server level and mapping its real JNDI name to the resource name used by the application through the use of an application server specific deployment descriptor (e.g. the sun-web.xml for GlassFish). Obviously, this is a container specific step and thus not covered by the Java EE specification.
Now, if you want to change the database an application is using, you'll have to either:
change the mapping in the application server deployment descriptor - or -
modify the configuration of the existing datasource to make it points on another database.
Having an admin interface doesn't really change anything. If I missed something, don't hesitate to let me know. And just in case, maybe have a look at this previous answer.