I am using karaf 3.0.1 with my bundle (https://github.com/johanlelan/camel-cxfrs-blueprint-example). I want to manage properties at runtime but I see that config:update does not create file on /etc, why?
<cm:property-placeholder persistent-id="org.apache.camel.examples.cxfrs.blueprint"
update-strategy="reload">
<!-- list some properties for this test -->
<cm:default-properties>
<cm:property name="cxf.application.in"
value="cxfrs:bean:rest.endpoint?throwExceptionOnFailure=false&bindingStyle=SimpleConsumer&loggingFeatureEnabled=true"/>
<cm:property name="common.tenant.in" value="direct-vm:common.tenant.in"/>
<cm:property name="common.authentication.in" value="direct-vm:common.authentication.in"/>
<cm:property name="application.put.in" value="direct-vm:application.putById"/>
<cm:property name="application.post.in"
value="direct-vm:application.postApplications"/>
<cm:property name="log.trace.level" value="INFO"/>
</cm:default-properties>
</cm:property-placeholder>
In karaf I try to modify an endpoint url:
karaf#root()> config:edit org.apache.camel.examples.cxfrs.blueprint
karaf#root()> config:property-set common.tenant.in direct-vm:test
karaf#root()> config:property-list
service.pid = org.apache.camel.examples.cxfrs.blueprint
common.tenant.in = direct-vm:test
felix.fileinstall.filename = file:/F:/travail/servers/karaf-lan/etc/org.apache.camel.examples.cxfrs.blueprint.cfg
karaf#root()> config:update
karaf#root()>
I precise that my bundle is updated after config:update but no file exists in /etc... I think it works in karaf 2.3.5.
Configurations are persisted by the ConfigurationAdmin service. If you are using Karaf, it uses the implementation from Felix ConfigAdmin [1]. By default Karaf configures ConfigAdmin to store files in its local bundle storage area under /data, but that can be changed by editing the felix.cm.dir property.
Also, the support for the .cfg files comes from Felix FileInstall [2].
[1] http://felix.apache.org/documentation/subprojects/apache-felix-config-admin.html
[2] http://felix.apache.org/site/apache-felix-file-install.html
It is a known issue at karaf 3.0.1
You may use apache karaf 3.0.2 that this bug is fixed.
Related
We are trying to migrate from IBM WAS to Wildfly server.
Below is my ibm-ejb-jar-bnd.xmi file. Where should this binding content be added in Wildfly for listener ports to be active again.
<ejbbnd:EJBJarBinding xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:ejb="ejb.xmi"
xmlns:ejbbnd="ejbbnd.xmi" xmi:id="EJBJarBinding_1224270065671">
<ejbJar href="META-INF/ejb-jar.xml#ejb-jar_ID"/> <ejbBindings
xmi:type="ejbbnd:MessageDrivenBeanBinding"
xmi:id="MessageDrivenBeanBinding_1224270068888"
InputPortName="Listener">
<enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#Listener"/> </ejbBindings> <ejbBindings
xmi:type="ejbbnd:MessageDrivenBeanBinding"
xmi:id="MessageDrivenBeanBinding_1260374215550"
InputPortName="ListenerEvent">
<enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#Listener2"/> </ejbBindings>
<ejbBindings xmi:type="ejbbnd:MessageDrivenBeanBinding"
xmi:id="MessageDrivenBeanBinding_1267212139948"
InputPortName="ListenerUsrEvent">
<enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#Listener3"/> </ejbBindings>
</ejbbnd:EJBJarBinding>
We changed the binding as well in the standalone XML along with changes to the MQ listener jars.
I'm in the process of upgrading jboss from 4.2 to Wildfly 10.
As part of the EJB configuration, in the META-INF folder we have a jboss.xml with container configuration. The configuration is as below.
<?xml version="1.0"?>
<jboss>
<container-configurations>
<container-configuration extends="Standard BMP EntityBean">
<container-name>Standard BMP EntityBean with commit option C</container-name>
<commit-option>C</commit-option>
</container-configuration>
<container-configuration extends="Instance Per Transaction BMP EntityBean">
<container-name>Instance Per Transaction BMP EntityBean with commit option C</container-name>
<commit-option>C</commit-option>
<sync-on-commit-only>true</sync-on-commit-only>
</container-configuration>
</container-configurations>
<enterprise-beans>
<entity>
<ejb-name>TestEjbEntity</ejb-name>
<configuration-name>Instance Per Transaction BMP EntityBean with commit option C</configuration-name>
</entity>
<message-driven>
<ejb-name>ASyncActionExecutor</ejb-name>
<configuration-name>Standard Message Driven Bean</configuration-name>
<destination-jndi-name>queue/ASyncAction</destination-jndi-name>
</message-driven>
</enterprise-beans>
</jboss>
How do I do this in Wildfly 10?
There is no way to configure it as EJB2 EntityBeans are marked as optional for EE7.
Wildfly does not support the use of EnttyBeans, you should also see a WARN or ERROR message if you try to deploy such appliation.
I recommed to migrate to JPA.
I have added system-properties tag in standalone-full.xml, but its not working in standalone mode. However, if I add the same tag in domain.xml it's working for domain mode.
<?xml version='1.0' encoding='UTF-8'?>
<server xmlns="urn:jboss:domain:2.2">
<extensions>
....
</extensions>
<system-properties>
<property name="java.util.Arrays.useLegacyMergeSort" value="true"/>
</system-properties>
</server>
According to this article on jBoss General configuration concepts
System property values can be set in a number of places in domain.xml, host.xml and standalone.xml.
Then what about standalone-full.xml?
I don't want to set it through command line and not even in java code.
In standalone it's probably too late to set it in the configuration files. You'll need to add it to the standalone.conf or standalone.conf.bat in the JAVA_OPTS environment variable. A global property like that needs to be set before anything else attempts to use java.util.Arrays.
If you have started the Wildfly server with standalone-full.xml instead of standalone.xml(the default) than this should be reflected in the start of the server:
standalone.sh -b <hostIP> -c standalone-full.xml -Dorg...
Then this will have effect on first start.
If you change something in this config file, you will need to reload Wildfly(configuration) from jboss cli:
[standalone#localhost:9990 /] :reload
For Wildfly 10 it's working nontheless. I was able to read the property for an instance started with the standalone-full.xml containing some properties.
The manual must be outdated then I guess? Because even Wildfly itself inserts a new property in the standalone-full.xml when using the Wildfly admin webinterface: http://localhost:9990 > Configuration > System Properties (Wildfly will add the property of course to the xml config which was used to start the instance). That's enough proof for me.
Deploying an application in WAS 8 gives me an error:
Cannot find a match for supplied option: "[ejb.jar, ejbName, ejb.jar,META-INF/ibm-ejb-jar-bnd.xml, ejb/ejbName]" for task "BindJndiForEJBNonMessageBinding"
my entry in ibm-ejb-jar-bnd.xml
<session name="ejbName">
<interface class="com.manager.EJBNameManager" binding-name="ejb/ejbName"/></session>
my entry in deploy.jacl
[-BindJndiForEJBNonMessageBinding ejb.jar ejbName ejb.jar,META-INF/ibm-ejb-jar-bnd.xml ejb/ejbName]
my ejb.jar structure has META-INF/ibm-ejb-jar-bnd.xml also.
Was my entry in ibm-ejb-jar-bnd.xml correct? Please enlighten me on this one. Thanks.
Instead of providing the path to your ejb jar bindings (ejb.jar,META-INF/ibm-ejb-jar-bnd.xml), you should be providing the path to your ejb deployment descriptor (e.g. ejb.jar,META-INF/ejb-jar.xml).
In addition, you shouldn't even need the ejb bindings file, because you are creating the binding using JACL. The ibm-ejb-jar-bnd.xml file will automatically be created for you as a result of your deployment.
(Also, as a side note, WAS deprecated its use of JACL in WAS 7, so you should consider using jython for your wsadmin scripts instead.)
What is the correct way to turn off the JBoss hot deploy service?
This is a production environment.
Edit: JBoss version 5.1.0 GA
I think deleting the "deploy/hdscanner-jboss-beans.xml" file is the correct way to do this.
From JBoss in Action, ch. 3.1.5:
The deployer is configured via the deployers.xml and profile.xml descriptor files,
both found in the server/xxx/conf directory. This file defines several POJOs that
manage various deployment responsibilities. Table 3.3 identifies each of these POJOs
and highlights some of the more interesting configuration properties provided by
each one. [...]
And the relevant bits from the table:
Bean: HDScanner
Property: scanEnabled - Set this to true (default) to enable the hot
deployer and to false to disable it. When set to
false, applications are deployed only when the
server is started or when the deploy method on
the MainDeployer MBean is called.
Property: scanPeriod - The number of milliseconds the hot deployer
waits between performing scans. The default is
5000 milliseconds (5 seconds). This value is
ignored if scanEnabled is set to false.
Property: scanThreadName - You can use this to change the name of the
thread from its default of HDScanner. The thread
name enables you to identify the hot deployer
thread if you should take a thread dump.
You can disable and expose it with JMX:
<bean name="HDScanner" class="org.jboss.system.server.profileservice.hotdeploy.HDScanner">
<annotation>#org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.deployment:service=HDScanner", exposedInterface=org.jboss.system.server.profileservice.hotdeploy.Scanner, registerDirectly=false)</annotation>
<start method="start" ignored="true" />
<property name="deployer"><inject bean="ProfileServiceDeployer"/></property>
<property name="profileService"><inject bean="ProfileService"/></property>
<property name="scanPeriod">5000</property>
<property name="scanThreadName">HDScanner</property>
<property name="scanEnabled">false</property>
</bean>
Property: scanEnabled doesn't exist on JBoss 5.x only on JBoss 4.x for the Deployment Scanner.
On JBoss 5.x just delete the hdscanner-jboss-beans.xml from the deploy directory and use the MainDeployer MBean to deploy your applications.