Maybe we can have an intermediate strategy: create an MBean wrapper for the POJO so we can return the jboss.web:service=WebServer service to deploy, until the SBM or equivalent can work on the POJO deployment. There is very little time for Beta4 or even for CR1 to do this properly. Brian Stansberry wrote: > (copying the general jboss dev list) > > I believe the problem with ServiceBindingManager and the web server is > the same as the one discussed on > http://www.jboss.org/index.html?module=bb&op=viewtopic&t=128642. In > AS 4.x, the TomcatDeployer was a JMX-based service, created via a > -service.xml. Now it's a pojo service and isn't managed via the > ServiceController. ServiceBindingManager integrates with the > ServiceController to do its magic with port 8080. No ServiceController > == no magic. > > We need a strategy for Beta4. Long run, as Scott said on the forum, > "ServiceBindingManager has to be replaced with a component that > integrates with the profile service to use the management view." I > don't see that happening this week for beta4. :) So, what to do? > > 1) Leave it broken for Beta4; do it right for CR1. But do we have the > resources to do that for CR1? > > 2) Return the jboss.web:service=WebServer service to deployment via > -service.xml. There is discussion of refactoring TomcatDeployer at > http://www.jboss.org/index.html?module=bb&op=viewtopic&t=112404 . > Perhaps the piece that will end up in deploy can be made a JMX-based > service again. But, AIUI, that goes against the medium-term goal of > pojo-izing the service. > > 3) See if we can find a way to make the SBM work if an @JMX annotation > is added to a pojo service. That doesn't work now. Would probably > need Adrian's help to make that happen, if it's possible at all. > > Thoughts? > > - Brian > > Dimitris Andreadis wrote: >> Clebert fixed the ports for the JBoss Messaging connectors, now the >> remaining problem (for the default configuration, at least) is the >> Tomcat connectors. Somehow the override for port 8080 is not working. >> >> Remy (or anyone that understands how the overrides work) can you take >> please a look? >> >> Heiko W.Rupp wrote: >>> >>> Am 28.01.2008 um 13:49 schrieb Luc Texier: >>> >>>> binding server instances to ip addresses is the only meaningful way >>>> of building a cluster, IMO. >>>> >>> >>> Actually I had quite a few customers in the past, where it was a >>> PITA to get more than one IP address per machine - even >>> from the RFC 1918 private space, so that the SBM was the only option >>> to them. >>> >>> Heiko >>> >> >

Yes, that should work. Or, if TomcatDeployer itself can be loaded both as a POJO or as an MBean, but without extending ServiceMBeanSupport? Brian Stansberry wrote: > So you mean something like this in deploy: > > <mbean name="jboss.web:service=WebServer" > class="org.jboss.web.tomcat.service.TomcatDeployerWrapperHack"> > <attribute name="TomcatDeployer> > <inject bean="WarDeployer"/> > </attribute> > </mbean> > > Then we change the names of > TomcatDeployer.create()/start()/stop()/destroy() to something else so > the MC doesn't call them when it deploys the TomcatDeployer pojo. The > wrapper calls them from its createService() etc. > > TomcatDeployer adds a property to inject the string name the wrapper > is registered under (jboss.web:service=WebServer). It adds a > dependency on that to the metadata for any deployment, ensuring the > deployment doesn't happen before the web server is started. > > That could work and seems easy to implement as a temporary measure. > > Dimitris Andreadis wrote: >> Maybe we can have an intermediate strategy: create an MBean wrapper >> for the POJO so we can return the jboss.web:service=WebServer service >> to deploy, until the SBM or equivalent can work on the POJO deployment. >> >> There is very little time for Beta4 or even for CR1 to do this properly. >> >> Brian Stansberry wrote: >>> (copying the general jboss dev list) >>> >>> I believe the problem with ServiceBindingManager and the web server >>> is the same as the one discussed on >>> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=128642. In >>> AS 4.x, the TomcatDeployer was a JMX-based service, created via a >>> -service.xml. Now it's a pojo service and isn't managed via the >>> ServiceController. ServiceBindingManager integrates with the >>> ServiceController to do its magic with port 8080. No >>> ServiceController == no magic. >>> >>> We need a strategy for Beta4. Long run, as Scott said on the forum, >>> "ServiceBindingManager has to be replaced with a component that >>> integrates with the profile service to use the management view." I >>> don't see that happening this week for beta4. :) So, what to do? >>> >>> 1) Leave it broken for Beta4; do it right for CR1. But do we have >>> the resources to do that for CR1? >>> >>> 2) Return the jboss.web:service=WebServer service to deployment via >>> -service.xml. There is discussion of refactoring TomcatDeployer at >>> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=112404 . >>> Perhaps the piece that will end up in deploy can be made a JMX-based >>> service again. But, AIUI, that goes against the medium-term goal of >>> pojo-izing the service. >>> >>> 3) See if we can find a way to make the SBM work if an @JMX >>> annotation is added to a pojo service. That doesn't work now. >>> Would probably need Adrian's help to make that happen, if it's >>> possible at all. >>> >>> Thoughts? >>> >>> - Brian >>> >>> Dimitris Andreadis wrote: >>>> Clebert fixed the ports for the JBoss Messaging connectors, now the >>>> remaining problem (for the default configuration, at least) is the >>>> Tomcat connectors. Somehow the override for port 8080 is not working. >>>> >>>> Remy (or anyone that understands how the overrides work) can you >>>> take please a look? >>>> >>>> Heiko W.Rupp wrote: >>>>> >>>>> Am 28.01.2008 um 13:49 schrieb Luc Texier: >>>>> >>>>>> binding server instances to ip addresses is the only meaningful >>>>>> way of building a cluster, IMO. >>>>>> >>>>> >>>>> Actually I had quite a few customers in the past, where it was a >>>>> PITA to get more than one IP address per machine - even >>>>> from the RFC 1918 private space, so that the SBM was the only >>>>> option to them. >>>>> >>>>> Heiko >>>>> >>>> >>> >

I don't thinks its important. Beyond the wrapper you would still need to enable the sbm in the ServiceController. Brian Stansberry wrote: > That sounds like my #2. Or are you saying load the whole unrefactored > thing from the deployers dir, but via a -service.xml? Possible but don't > know if that would cause issues. > > I can spend a couple hours today/tomorrow experimenting with the wrapper > concept, and maybe simply deploying via service.xml. But I don't want to > waste effort unless there's agreement that getting SBM to work for Beta4 > is an important goal. And if there's consensus (e.g. from Remy) that > whatever I'm trying is an acceptable temporary measure if it works. >

Its not expected to work. Its not a cross component model service. It is possible it is being applied, the ConfigureAction is accessing the ServiceBinding. Dimitris Andreadis wrote: > I believe SBM is enabled in the ServiceController. > > Nevertheless my point is, we shouldn't retire things expected to work > from 4.x until we have working alternatives. Same goes for 'farming'. > > Scott M Stark wrote: >> I don't thinks its important. Beyond the wrapper you would still need to >> enable the sbm in the ServiceController. >> >> Brian Stansberry wrote: >>> That sounds like my #2. Or are you saying load the whole unrefactored >>> thing from the deployers dir, but via a -service.xml? Possible but don't >>> know if that would cause issues. >>> >>> I can spend a couple hours today/tomorrow experimenting with the wrapper >>> concept, and maybe simply deploying via service.xml. But I don't want to >>> waste effort unless there's agreement that getting SBM to work for Beta4 >>> is an important goal. And if there's consensus (e.g. from Remy) that >>> whatever I'm trying is an acceptable temporary measure if it works. >>>

Re: farming, it's really just a glorified system for keeping local file systems in sync around the cluster. It only makes conceptual sense in conjunction with the basic.ProfileServiceImpl, the one that's based off scanning the local file system. AIUI, the basic.ProfileServiceImpl isn't what we want to go forward with.

I went ahead and experimented with the wrapper idea, in case you guys want it. Quite simple and seems to work fine. SBM works for the webserver connectors with it in place. Will run some parts of testsuite tonight. With it you can also move the CachedConnectionManager back into deploy. If you're curious, a patch is attached. Patch shows that it's quite clean to divide the runtime element of TomcatDeployer from the deployer element. Admittedly, it's a hack. If we want SBM to work, I will need to convert some clustering pojo services back to JMX services. That shouldn't be a big deal; involves carving them out of cluster-beans.xml and putting them in a service.xml. The core HAPartition stuff would remain as pojos in cluster-beans.xml. The attached patch doesn't deal with the build, i.e. getting the jboss-web-service.xml file into deploy. Dimitris Andreadis wrote: > I believe SBM is enabled in the ServiceController. > > Nevertheless my point is, we shouldn't retire things expected to work > from 4.x until we have working alternatives. Same goes for 'farming'. > > Scott M Stark wrote: >> I don't thinks its important. Beyond the wrapper you would still need to >> enable the sbm in the ServiceController. >> >> Brian Stansberry wrote: >>> That sounds like my #2. Or are you saying load the whole unrefactored >>> thing from the deployers dir, but via a -service.xml? Possible but >>> don't >>> know if that would cause issues. >>> >>> I can spend a couple hours today/tomorrow experimenting with the >>> wrapper >>> concept, and maybe simply deploying via service.xml. But I don't >>> want to >>> waste effort unless there's agreement that getting SBM to work for >>> Beta4 >>> is an important goal. And if there's consensus (e.g. from Remy) that >>> whatever I'm trying is an acceptable temporary measure if it works. >>> >>

At Dimitris' request I've committed this concept. Commit 69505 for http://jira.jboss.com/jira/browse/JBAS-5191 . Will kick off a run of JBoss-AS-5.0.x-TestSuite-sun15-noip on hudson in as soon as I post this. We want to get a hudson run this afternoon to see what this does so we can revert if need be before tonights TCK runs. A couple points: 1) I didn't move the CachedConnectionManager out of deployers. This change makes that possible, and I tried it manually and it works, but I want to keep this simple before the TCK run tonight. Easy to move it tomorrow if we decide to keep today's commit. 2) Rather than exposing the wrapper via a deploy/jboss-web-service.xml, I did it via a deploy/jbossweb.sar/META-INF/jboss-service.xml. Assumption was that a real move of the JBossWeb runtime to deploy for CR1 will involve creating a sar, so might as well create the structure for Beta4. Dimitris Andreadis wrote: > It's a hack but it looks good to me. It's not far from the concept of > slitting the web deployer, although that will be implemented differently. > > Scott what do you think? > > Brian Stansberry wrote: >> I went ahead and experimented with the wrapper idea, in case you guys >> want it. Quite simple and seems to work fine. SBM works for the >> webserver connectors with it in place. Will run some parts of >> testsuite tonight. With it you can also move the >> CachedConnectionManager back into deploy. If you're curious, a patch >> is attached. Patch shows that it's quite clean to divide the runtime >> element of TomcatDeployer from the deployer element. >> >> Admittedly, it's a hack. >> >> If we want SBM to work, I will need to convert some clustering pojo >> services back to JMX services. That shouldn't be a big deal; >> involves carving them out of cluster-beans.xml and putting them in a >> service.xml. The core HAPartition stuff would remain as pojos in >> cluster-beans.xml. >> >> The attached patch doesn't deal with the build, i.e. getting the >> jboss-web-service.xml file into deploy. >> >> Dimitris Andreadis wrote: >>> I believe SBM is enabled in the ServiceController. >>> >>> Nevertheless my point is, we shouldn't retire things expected to >>> work from 4.x until we have working alternatives. Same goes for >>> 'farming'. >>> >>> Scott M Stark wrote: >>>> I don't thinks its important. Beyond the wrapper you would still >>>> need to >>>> enable the sbm in the ServiceController. >>>> >>>> Brian Stansberry wrote: >>>>> That sounds like my #2. Or are you saying load the whole unrefactored >>>>> thing from the deployers dir, but via a -service.xml? Possible but >>>>> don't >>>>> know if that would cause issues. >>>>> >>>>> I can spend a couple hours today/tomorrow experimenting with the >>>>> wrapper >>>>> concept, and maybe simply deploying via service.xml. But I don't >>>>> want to >>>>> waste effort unless there's agreement that getting SBM to work for >>>>> Beta4 >>>>> is an important goal. And if there's consensus (e.g. from Remy) that >>>>> whatever I'm trying is an acceptable temporary measure if it works. >>>>> >>>> >>