Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-user@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.221.12 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=tJ4g6us9Ni2mfW5MMHMktC6nJUqM7c3ny4u4gUuX7waEEcFXVKz19h2zkHa9p14Xws
         LyTq4IBXJF0u1ZyCOFCMfiUeioC2JlXvamL6jF/wmMYlNieRQTe8JKAUNzQ0oI98UvPe
         svkM39SbntD4zTmcLAwRUO5SvyEcxsxt4N/pk=
Message-ID: <5380c69c0812022305g2594c6dfx7fd7512a3d464cb5@mail.gmail.com>
Date: Wed, 3 Dec 2008 08:05:46 +0100
From: "Claus Ibsen" <claus.ibsen@gmail.com>
To: camel-user@activemq.apache.org
Subject: Re: jetty endpoints in different camel contexts
In-Reply-To: <20803294.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20608492.post@talk.nabble.com>
	 <5380c69c0811202314i6eafbeefn6a7af2449efccfa5@mail.gmail.com>
	 <20803294.post@talk.nabble.com>

Hi

Could you point out exactly where the issue is with extending. I can't
at first glance find the private CamelServlet.
Maybe you could provide a patch to camel-http or camel-jetty component
so you can extend JettyComponent.

We love contributions:
http://activemq.apache.org/camel/contributing.html


/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/


On Wed, Dec 3, 2008 at 12:17 AM, ndjensen <ndjensen@gmail.com> wrote:
>
> Hi, thanks for the help.  Originally I considered extending the jetty
> component and overriding createServer(), or creating the Server in spring
> and injecting it into the jetty component. Unfortunately camelServlet is
> private and instantiated in createServer(), so I would null pointer in
> connect().
>
>
> Claus Ibsen-2 wrote:
>>
>> Hi
>>
>> Interesting use-case for reuse of singleton components. First time I
>> read about this. Usually you want isolation of your applications.
>>
>> Maybe a better solution would be to extend JettyHttpComponent and
>> override some of the methods that creates the server so you can fetch
>> your shared instance instead.
>>
>> If using spring it's just defining a spring bean with the id=jetty
>> that is your class instead of the default one
>>
>> <bean id="jetty" class="com.mycompany.MyJettyComponent">
>>    <property name="foo" value="bar"/>
>> </bean>
>>
>> Then when you do the routing in DSL and you use the jetty scheme it
>> uses your component instead of the default one
>>
>> <from uri="jetty:xxxx"/>
>> <to uri="log:hello"/>
>>
>> In the route above it picks up MyJettyComponent
>>
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>>
>>
>> On Thu, Nov 20, 2008 at 8:37 PM, ndjensen <ndjensen@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> On Camel 1.5.0, it seems like you can't have multiple jetty endpoints in
>>> separate camel contexts on the same port.  For example, if I have the
>>> following routes,
>>>
>>> <route id="exampleRouteOne">
>>>        <from uri="jetty:http://0.0.0.0:8080/services/doSomething" />
>>>        <bean ref="someService" method="doSomething" />
>>> </route>
>>>
>>> <route id="exampleRouteTwo">
>>>        <from uri="jetty:http://0.0.0.0:8080/services/foo" />
>>>        <bean ref="someBean" method="processRequest" />
>>> </route>
>>>
>>>
>>> it works great when they're in the same camel context, but throws the
>>> following exception at startup of the second address when they're not.
>>>
>>>
>>>
>>> INFO  log                            - Started
>>> SelectChannelConnector@0.0.0.0:8080
>>> INFO  log                            - jetty-6.1.9
>>> WARN  log                            - failed
>>> SelectChannelConnector@0.0.0.0:8080
>>> java.net.BindException: Address already in use
>>>        at sun.nio.ch.Net.bind(Native Method)
>>>        at
>>> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
>>>        at
>>> sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
>>>        at
>>> org.mortbay.jetty.nio.SelectChannelConnector.open(SelectChannelConnector.java:205)
>>>        at
>>> org.mortbay.jetty.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:304)
>>>        at
>>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
>>>        at
>>> org.apache.camel.component.jetty.JettyHttpComponent.connect(JettyHttpComponent.java:111)
>>>        at
>>> org.apache.camel.component.http.HttpEndpoint.connect(HttpEndpoint.java:94)
>>>        at
>>> org.apache.camel.component.http.HttpConsumer.doStart(HttpConsumer.java:50)
>>>        at
>>> org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:47)
>>>        at
>>> org.apache.camel.impl.DefaultCamelContext.addService(DefaultCamelContext.java:421)
>>>        at
>>> org.apache.camel.impl.DefaultCamelContext.startRoutes(DefaultCamelContext.java:659)
>>>        at
>>> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:632)
>>>        at
>>> org.apache.camel.spring.SpringCamelContext.maybeDoStart(SpringCamelContext.java:167)
>>>        at
>>> org.apache.camel.spring.SpringCamelContext.doStart(SpringCamelContext.java:162)
>>>        at
>>> org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:47)
>>>        at
>>> org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:97)
>>>        at
>>> org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:116)
>>>        at
>>> org.springframework.context.event.SimpleApplicationEventMulticaster$1.run(SimpleApplicationEventMulticaster.java:78)
>>>        at
>>> org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:49)
>>>        at
>>> org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:76)
>>>        at
>>> org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:275)
>>>        at
>>> org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:737)
>>>        at
>>> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:384)
>>>        at
>>> org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
>>>        at
>>> org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:93)
>>>
>>>
>>>
>>> I'm working with a plugin architecture, so the routes have to be in
>>> separate
>>> camel contexts unless there's some way to refer to other camel contexts
>>> in
>>> spring that I'm not aware of.  The plugin needs to be able to specify its
>>> routes in its own spring xml file without affecting others' xml files,
>>> and
>>> be on the same http port.
>>>
>>> I've worked around this by creating my own custom component that is a
>>> copy
>>> of the JettyHttpComponent, but changing the fields to static so the
>>> routes
>>> that specify the custom component will share the same server field.  Is
>>> there a better way around this?  Will this be resolved in future versions
>>> of
>>> Camel?
>>>
>>> Thanks,
>>>
>>> Nathan
>>> --
>>> View this message in context:
>>> http://www.nabble.com/jetty-endpoints-in-different-camel-contexts-tp20608492s22882p20608492.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/jetty-endpoints-in-different-camel-contexts-tp20608492s22882p20803294.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>