I'm not sure if that management console helps my cause. But what I'm trying to do is be able to deploy SUs within JBoss so that I can reuse JBoss's port 8080 on those SUs and then also have those SUs be able to use JBoss's clustering services as well. I want my deployed SUs (using managed mode) to "hijack" the port that JBoss is already running on. What would have been nice is to enable it to use a web apps context path as well. So it would look like:
http://localhost:8080/MyContextPath/MyManagedHttpSU1 http://localhost:8080/MyContextPath/MyManagedHttpSU2 Regards, Jeff -----Original Message----- From: Guillaume Nodet [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 3:01 PM To: [email protected] Subject: Re: Http endpoints and the managed attribute I really have no idea how to leverage the web server inside JBoss from a ServiceMix deployed using the jboss deployer. Another way to go would be to take a look at the new apache-servicemix-web distribution available at http://svn.apache.org/viewvc/incubator/servicemix/trunk/distributions/ap ache-servicemix-web/ I will try to deploy new snapshots so hopefully the war should be available for download in the coming hours. This webapp includes a simple management console (see http://servicemix.goopen.org/site/console.html) and a specific configuration which will automatically configure an installed servicemix-http component to reuse the web server where the web app is deployed. This webapp has been written to fully support SU/SA deployments and does not use a static xml configuration file as shown in the servicemix-web example. Is that what you are looking for ? On 11/7/06, jpuro <[EMAIL PROTECTED]> wrote: > > Has anyone gotten this working yet? I am attempting to do this now, but I'm > not 100% on how everything gets deployed. I have the following items that > I'm working with: > > 1) The JBoss deployer to enable service units to be deployed. > > 2) A web app with a context path that I would like my managed http SUs to > work off of. > > 3) A bunch of http SUs that I would like to drop into the JBoss deploy > directory and have it register under the context path of the web app. > > Gnodet, How would I achieve all of this with what you suggested in your > previous post? > > Regards, > > Jeff > > > gnodet wrote: > > > > I think there is a way to do that. > > > > Currently, the problem is that if you configure a > > <http:component /> component inside the > > spring config file for the web app, it instanciates > > a HttpSpringComponent which does not accept > > SU deployments. > > > > You need to use the following construction: > > <sm:activationSpec name="servicemix-http" > > component="#servicemix-http" /> > > > > And later, > > <bean id="servicemix-http" class=" > > org.apache.servicemix.http.HttpComponent" /> > > <bean id="lf" factory-bean="servicemix-http" > > factory-method="getLifeCycle" /> > > <bean id="config" factory-bean="lf" factory-method="getConfiguration"> > > <property name="managed" value="true" /> > > </bean> > > > > This will allow to use a real http component in managed mode. > > Then, when you deploy SU, they should be put in the context of the web > > app. > > > > I have not done that yet, so if you have any problem or success ... > > > > > > > > On 8/31/06, jpuro <[EMAIL PROTECTED]> wrote: > >> > >> > >> Using the JBoss deployer, is it possible to achieve the following > >> situation > >> with a web application. > >> > >> 1) Deploy a web application under the following context /MyWebApp. So > >> to > >> reach this web application you would navigate to > >> http://localhost:8080/MyWebApp. > >> > >> 2) Deploy a service assembly that has a service unit in it which uses > >> the > >> http endpoint with "managed=true" set. Typically this means that the > >> endpoint will reuse the servlet's web context if this was deployed in a > >> full > >> blown .war file. However, I'd like it to reuse the web context already > >> created in the above step (MyWebApp). There is one more requirement, > >> instead of it just hijacking the MyWebApp web context, I would like it to > >> add its own path onto the URL. So in order to actually access this http > >> endpoint you would type in http://localhost:8080/MyWebApp/httpEndpoint1. > >> > >> 3) Down the road I would like to deploy other service assemblies that > >> re-use the same MyWebApp web context, but as in the above situation I > >> would > >> like them to redefine their own sub path. So the end result of let's say > >> 4 > >> different service assembly deployments would be: > >> > >> http://localhost:8080/MyWebApp/httpEndpoint1 > >> > >> http://localhost:8080/MyWebApp/httpEndpoint2 > >> > >> http://localhost:8080/MyWebApp/httpEndpoint3 > >> > >> http://localhost:8080/MyWebApp/httpEndpoint4 > >> > >> As you can see what I am trying to achieve is the ability to deploy a > >> single > >> .War file and have various service units/service assemblies (which are > >> independent of each other) hijack the web context of the originally > >> deployed > >> web application. I do not want to have to deploy a new web application > >> per > >> each new sub path I need to create. > >> > >> -Jeff > >> -- > >> View this message in context: > >> http://www.nabble.com/Http-endpoints-and-the-managed-attribute-tf2197708 .html#a6082590 > >> Sent from the ServiceMix - User forum at Nabble.com. > >> > >> > > > > > > -- > > Cheers, > > Guillaume Nodet > > > > > > -- > View this message in context: http://www.nabble.com/Http-endpoints-and-the-managed-attribute-tf2197708 s12049.html#a7225092 > Sent from the ServiceMix - User mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet This email (and any attachments) is intended only for the use of the individual or entity named above and may contain information that is privileged and confidential. If you are not the intended recipient, or have unauthorized access, you are hereby notified that copying, disseminating, distributing or taking any action in reliance on this email is strictly prohibited<br /> <br /> Opinions, conclusions and other information in this message that do not relate to the official business of our firm shall be understood as neither given nor endorsed by it.
