Yes. It may be possible to do the same thing using the jboss deployer, but i really have no idea how (and don't want to take a look at it, as this solution should work better imho).
Note that currently, this war does not use any hotdeploy folder so you need use the the web app itself to install components and deploy service assemblies. I'd like to have feedback on this war distribution, so please try it and report *any* comments to improve / modify / enhance / beautify / fix .... ;) On 11/7/06, Jeffrey Puro <[EMAIL PROTECTED]> wrote:
Ah, ok, I got you now. So I think the only way I can do what I was suggesting with JBoss is to deploy a .war version of ServiceMix within JBoss, then any SUs that I drop into the monitored deploy folder will be picked up by that container instance that's running in the .war file and run off of the .wars context path. I do not think there is any easy way to do it using the JBoss Deployer. Is this correct? Regards, Jeff -----Original Message----- From: Guillaume Nodet [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 3:26 PM To: [email protected] Subject: Re: Http endpoints and the managed attribute So maybe you misunderstood me. The apache-servicemix-web web application is a full servicemix distribution package as a war. It includes the management console but this is not my point. My point is that you can install components at runtime and deploy SU, but if you install servicemix-http component, all SU deployed will reuse the web server used by the web application itself (so the :8080 web server of jboss). Services will be available at http://localhost:8080/apache-servicemix-web/jbi/MyManagedHttpSU1 On 11/7/06, Jeffrey Puro <[EMAIL PROTECTED]> wrote: > 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. > > -- 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.
-- Cheers, Guillaume Nodet
