JBossDeveloper

"jhalliday" wrote:
> See the JIRA issue.

Would that be JBAS-5144, which is marked as done? You saying it needs reopening?

I've done this.
There is now a remoting-service.xml and transaction-service.xml in deploy

I've raised this issue
http://jira.jboss.com/jira/browse/JBAS-5349
since out testsuite coverage on bootstrap dependencies of apps is weak.

Argh, looks like the testsuite broke again because of this; I once again forgot to update the various src/resources/test-configs. This is one of those mistakes that seems doomed to be repeated over and over and over.

Fixing it now.

if you're referring to tomcat-webctx config not starting, i already fixed it

Thanks. :) Looking through test-configs I see others that are broken in various ways, e.g. several with a server.xml still in deployers/jbossweb.deployers. I'll do a bit of a cleanup.

Can't we do this in a cleverer way?

It's stupid that somebody has to "guess" where 5 or 6 copies of a config file exists.
Embedded has the same problem with continually out-of-date config.

I'd also like to see the web deployer beans split up. Why do we repeat things in
the default/all config just to change the cluster defaults? The clustering defaults
should be in a different file.

We don't need a separate file due to the cluster defaults deployer; having two different files in the tomcat module is a bit of legacy cruft. A file with the clustering deployers in it should work just fine in default.

That said, I'd like the clustering deployer out of the file too. IIRC it mostly isn't because I somewhat wanted the deployer in jbossweb.deployer/META-INF folder and if I put a second -beans.xml there it wouldn't get deployed.

Re: the various test-config stuff, yes, there has to be a cleverer way. The biggest case of using a test-config to override instead of add is to change server.xml. A couple do that to inject sso valves; that can probably be done with a separate mbean instead. Not particularly "clever", but will work. Don't know if that kind of thing can be done with some of the others, which try to override stuff like connectors and the security realm, which may not be changeable after the web server starts.

Back to the main topic of this thread... :)

Moving jboss.remoting:service=Connector,transport=socket into deploy has broken the tests-profileservice test, which deploys a deployers/profileservice-beans.xml that has beans that depend on the remoting connector.

I'm going to experiment with moving jboss.remoting:service=Connector,transport=socket back into conf/jboss-service.xml. It doesn't declare a dependency on the transaction manager and shouldn't have one.

If that works and is the direction we want to go, then the remoting-service.xml file should probably be renamed to something like detached-invokers-service.xml.

That doesn't work, at least not trivially, as the remoting connector as configured actually needs the unified invoker since it's specified as a handler:

2008-03-29 17:16:16,815 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Start: name=jboss.remoting:service=Connector,transport=socket state=Create mode=Manual requiredState=Installed
java.lang.reflect.UndeclaredThrowableException
 at $Proxy45.setMBeanServer(Unknown Source)
 at org.jboss.remoting.transport.Connector.addInvocationHandler(Connector.java:1192)
 at org.jboss.remoting.transport.Connector.configureHandlersFromXML(Connector.java:848)
 at org.jboss.remoting.transport.Connector.start(Connector.java:317)
....
Caused by: javax.management.InstanceNotFoundException: jboss:service=invoker,type=unified is not registered.
 at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
 at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:608)
 at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:193)
 ... 54 more

No hack required; just a simple re-configuration.

The remoting connector is back in conf/jboss-service.xml. I re-opened http://jira.jboss.com/jira/browse/JBAS-5348 for this and left it open for a bit in case anyone has any input after the weekend.

"bstansberry@jboss.com" wrote:
No hack required; just a simple re-configuration.

The remoting connector is back in conf/jboss-service.xml. I re-opened http://jira.jboss.com/jira/browse/JBAS-5348 for this and left it open for a bit in case anyone has any input after the weekend.

"jhalliday" wrote:

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">

 <bean name="MBeanExporter" class="org.jboss.system.microcontainer.jmx.ServiceControllerLifecycleCallback">
 <property name="serviceController"><inject bean="JMXKernel" property="serviceController"/></property>
 </bean>
 <bean name="TransactionManager" class="com.arjuna.ats.jbossatx.jta.TransactionManagerService">
 <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=TransactionManager", exposedInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class, registerDirectly=true)</annotation>

 <property name="transactionTimeout">300</property>
 <property name="objectStoreDir">${jboss.server.data.dir}/tx-object-store</property>

 <install bean="MBeanExporter" method="install">
 <parameter><inject fromContext="context"/></parameter>
 </install>
 <uninstall bean="MBeanExporter" method="uninstall">
 <parameter><inject fromContext="context"/></parameter>
 </uninstall>
 </bean>

</deployment>

So now I get two copies of the transaction manager bean instantiated. Huh? I want one instance, not two. Where the heck did the other one come from? I guess perhaps I've not expressed the desired config properly? I want one object behaving as both a bean and an mbean, not two separeate objects. Is there some other way of achieving that?