[Design of JBoss Transaction Services] - java.net.MalformedURLException: unknown protocol: c
by Rhodan
Hello,
due to the lack of an embedded jboss i trie to startup an normal jboss 5.0.1 inside of my application in an seperate process. This works fine, but only the TransactionManager stumbles with the old problem of "spaces on the path".
final Process process = Runtime.getRuntime().exec("javaw.exe -Xms128m -Xmx384m -Djava.protocol.handler.pkgs=org.jboss.virtual.protocol -jar run.jar org.jboss.Main -c default -b 0.0.0.0",null, binDir);
results in this error on Deployment of TransactionManager:
12:35:07,624 ERROR [AbstractKernelController] Error installing to Instantiated: name=TransactionManager state=Described
| java.lang.ExceptionInInitializerError: java.net.MalformedURLException: unknown protocol: c
| at com.arjuna.ats.arjuna.common.arjPropertyManager.<clinit>(arjPropertyManager.java:70)
| at com.arjuna.ats.jbossatx.jta.TransactionManagerService.<clinit>(TransactionManagerService.java:107)
| at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
| at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
| at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
| at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
| at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:149)
| at org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:106)
| at org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:80)
| at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.createTarget(AOPConstructorJoinpoint.java:276)
| at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:97)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
| at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
| at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:66)
| at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
| at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:698)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
| at org.jboss.Main.boot(Main.java:209)
| at org.jboss.Main$1.run(Main.java:547)
| at java.lang.Thread.run(Thread.java:619)
Google gave me the rease that spaces in paths are causing this error. See Sun Bug 6506304. But It's no option to install the jboss (or our desktop application) in a directory without spaces.
So for now the TransactionManager seems to stumble about this problem, so if somebody could look if URL's are correctly handled inside this component.
The problem is, that jboss 5 runs well on directories with spaces - but only if startet inside from my java-application.
Is there an workaround for this bug ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222581#4222581
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222581
15 years, 8 months
[Design of Messaging on JBoss (Messaging/JBoss)] - config files and where the deployers get them from
by ataylor
Currently all the config files are obtained from the classloader via getResources with a harcoded filename. By default we have as a minimum jbm-configuration.xml, jbm-security.xml and jbm-jms.xml altho an optional jbm-queues.xml canbe used.
When we run from within a distro, i.e. './run.sh', all these config files are conatined in the config dir which is added to the classpath by the run.sh script.
We need to be able to specify different config files on starting the server, this is for running clustered and running examples withdifferent configurations.
There are a few ways of doing this.
1. simply specify a different config directory on startup, the script will change the classpath and the config files will be loaded from a different directory using the same filenames. i.e.
./run.sh -cjbm-config,dir=../examples/common/config
2. Specify a different filename for each file. This way in the code we use the default filenames or use the system property if set. i.e.
./run.sh -Djbm.conf=foo -Djbm.jms.conf=bar -Djbm.security.conf=foobar
We just have to make sure that the location of the alternative config files is in the classpath or the user specifies a full path.
3. Inject the config filenames into the deployers via thebean descriptor. so the default beans file would contain something like:
| <bean name="Configuration" class="org.jboss.messaging.core.config.impl.FileConfiguration">
| <property name="config">${JBM_HOME}/config/jbm-configuration.xml</property>
| </bean>
|
the to run an example we run
./run.sh ../examples/common/config/jbm-example-beans.xml
and we change the configuration in that to
| <bean name="Configuration" class="org.jboss.messaging.core.config.impl.FileConfiguration">
| <property name="config">${JBM_HOME}../examples/common/config/example-configuration.xml</property>
|
| </bean>
Or whatever the user wants. This is also easier when deploying multiple instances within the AS., with 1 and 2 you couldn't do this
My option is for the latter
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222575#4222575
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222575
15 years, 8 months
[Design of JBoss Remoting, Unified Invokers] - Re: Server side thread leak?
by ron.sigal＠jboss.com
It's good to hear from Richard that turning on idle thread reaping is beneficial on the server side, but there's still the issue of leakage on the client side. Even if a worker thread is harvested, which results in closing its socket, the associated socket on the client side would remain in the connection pool until an invoker tries to use it.
"galder.zamarreno(a)jboss.com" wrote :
| The only reason I could see to leave it as it is would be if creation/connect were noticeable more expensive operations compared to caching it and reusing the same client all the time. I don't see it being much more expensive although the ClientInvoker location done in 2.2.x happens within a big synchronized block.
|
If the ClientInvoker already exists, control pops out of the synchronized block near the beginning.
I agree that turning on idle thread reaping is a good thing, and I agree that avoiding client side leakage is a good thing. The most straightforward way of doing the latter is to use the "invokerDestructionDelay" facility. Here are two related threads: "Remoting issue" in the "Design of EJB 3.0" forum
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=130264
and "JBREM-877: New Socket Connection is being Created for Every" in the Remoting Users forum
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=126382&postdays=....
Note the following quote from the latter thread:
"kiwi_clive" wrote :
| Hi Ron,
|
| Many thanks for your help. We saw an immediate performance gain, halving response time. This has proved to be the single most effective performance enhancement in our tuning efforts so many thanks for providing the fix.
|
| Most appreciated !
|
| Clive
|
I can think of an alternative: a TimerTask that reaps unusable sockets. But given the preceding quote I'm not sure if it's necessary.
-Ron
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222502#4222502
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222502
15 years, 8 months
[Design of JBossXB] - Integrating PropertyMetaData into another model
by scott.stark＠jboss.org
I tried reusing the mc beans PropertyMetaData/AbstractPropertyMetaData in a custom bean factory model I'm working on
| @JBossXmlSchema(namespace="urn:jboss:proxied-mbean:1.0", elementFormDefault=XmlNsForm.QUALIFIED, replacePropertyRefs=true)
| @XmlRootElement(name="proxied-mbeans")
| @XmlType(name="proxiedMBeanType")
| public class ProxiedMBeanMetaData implements Serializable, BeanMetaDataFactory
| {
| private static final long serialVersionUID = 1;
| private static Logger log = Logger.getLogger(ProxiedMBeanMetaData.class);
|
| private List<MBeanProxyMetaData> proxies;
| private List<String> depends = new ArrayList<String>();
| private MBeanServer server;
| ...
|
| @XmlType(name="proxy")
| public class MBeanProxyMetaData
| {
| ...
| @XmlElement(name="property", type=AbstractPropertyMetaData.class)
| public List<PropertyMetaData> getProperties()
| {
| return properties;
| }
| public void setProperties(List<PropertyMetaData> properties)
| {
| this.properties = properties;
| }
|
but when I parse a fragment in a jboss-beans.xml like:
| <proxied-mbeans xmlns="urn:jboss:proxied-mbean:1.0">
| <depend>WebServer</depend>
| <proxy>
| <delegate-class>org.jboss.web.tomcat.service.management.ConnectorBean</delegate-class>
| <target-name>jboss.web:type=GlobalRequestProcessor,*</target-name>
| <target-interface>org.jboss.web.tomcat.service.management.IConnector</target-interface>
| <annotation>@org.jboss.managed.api.annotation.ManagementObject(componentType=(a)org.jboss.managed.api.annotation.ManagementComponent(type = "MBean", subtype = "Web:GlobalRequestProcessor"),isRuntime=true)</annotation>
| </proxy>
| <proxy>
| <delegate-class>org.jboss.web.tomcat.service.management.Host</delegate-class>
| <target-name>jboss.web:host=localhost,type=Host</target-name>
| <target-interface>org.jboss.web.tomcat.service.management.IHost</target-interface>
| <annotation>@org.jboss.managed.api.annotation.ManagementObject(name="jboss.web:host=localhost,type=Host", componentType=(a)org.jboss.managed.api.annotation.ManagementComponent(type = "MBean", subtype = "Web:Host"),isRuntime=true)</annotation>
| <property name="mbeanNameAsString">jboss.web:host=localhost,type=Host</property>
| </proxy>
| </proxied-mbeans>
|
the following exception occurs that I don't understand:
| Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: The type of the attribute search must be simple or complex with a value adapter: org.jboss.xb.binding.sunday.unmarshalling.TypeBinding@809011[null]
| at org.jboss.beans.metadata.plugins.AbstractDependencyValueMetaData.search
| at org.jboss.beans.metadata.plugins.AbstractClassLoaderMetaData.classLoader
| at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.classLoader
| at org.jboss.beans.metadata.plugins.AbstractPropertyMetaData.value
| at org.jboss.system.metadata.MBeanProxyMetaData.properties
| at org.jboss.system.metadata.ProxiedMBeanMetaData.proxies
| at org.jboss.system.metadata.ProxiedMBeanMetaData
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
| at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168)
| at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:199)
| at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
| at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
| at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
| at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
| at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
|
I don't see how the AbstractPropertyMetaData.value property relates to AbstractBeanMetaData.classLoader?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222484#4222484
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222484
15 years, 8 months