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
>>>
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com