Hi Scott,

I'm sorry I didn't aware you are using servicemix-camel component (JBI) version. In this case the upgrading will be more complicated. You need to updated the servicemix-camel lib with the new version of camel-spring.

Fortunately we just cut Camel 2.6.0 and it will be part of Apache ServiceMix new version very soon. And we are releasing a new version of Fuse ESB 4.3.1 this week.

Willem

On 1/24/11 9:53 AM, Scott Came wrote:
Willem:

I did my best to understand what you suggested I do, but I'm not confident that 
I'm doing it right.  Here is what I did:

-- I shut down servicemix

-- I downloaded the jar 
http://repo.fusesource.com/nexus/content/groups/public-snapshots/org/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fuse-20110118.002228-16.jar

-- I extracted the contents of that jar to a temporary directory

-- I extracted the contents of the camel-spring-2.4.0-fuse-02-00, and copied 
its META-INF/MANIFEST.MF file to the META-INF directory of the extracted 
snapshot jar

-- I re-jarred the snapshot

-- I deleted the camel-sprint-2.4.0-fuse-02-00.jar from 
$SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00

-- I copied the snapshot jar (with the updated MANIFEST.MF) into 
$SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00

-- I deleted my $SMX_HOME/data directory

-- I restarted servicemix

After these steps, servicemix seems to start normally.  Osgi:list:

[ 153] [Active     ] [Created     ] [       ] [   60] Apache ServiceMix :: 
Components :: Camel Service Engine (2010.02.0.fuse-02-00)

Jbi:list

[Started ] [servicemix-camel              ]

However, when I deploy my service assembly, I get a stack trace (see attached).

Is this sequence of steps what you intended me to try?  Any idea what's going 
wrong and where?

Alternatively...is this version of camel-spring already included in some snapshot version 
of the entire FUSE ESB?  If so, would it likely work better for me just to check out the 
ESB shapshot and build it?  If so, are there instructions somewhere for finding the 
source repository and checking out the snapshot?  (I looked at 
http://fusesource.com/forge/projects/fuseesb/source which says to use Subversion as such: 
svn co http://fusesource.com/forge/svn/fuseesb/trunk  fuseesb; however, when I do, I get 
"svn: URL 'http://fusesource.com/forge/svn/fuseesb/trunk' doesn't exist".)

Either way, I think I can offer some value to the project here by testing the 
new camel version, but I'm kinda stuck as a newcomer to the platform on some of 
these issues.  Any help you can offer would be much appreciated.

Thanks.
--Scott

-----Original Message-----
From: Willem Jiang [mailto:[email protected]]
Sent: Thursday, January 20, 2011 10:02 PM
To: [email protected]
Subject: Re: Large(ish) message issue (CXFBC and Camel)

Yeah, you may need to hack the META-INF/manifest file yourself if you don't 
want to massage the bundle version complains yourself.

The sample way download the snapshot jar and replace the manifest file of 
camel-spring 2.4.0-fuse-02-00.jar, and place the jar into the 
$SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-01-00, restart the 
servicemix after deleting the $SMX_HOME/data.

Willem

On 1/20/11 8:56 PM, Scott Came wrote:
Thanks, Willem, I'll give that a try.

Again apologies for my newbie questions, but I couldn't find any docs on this 
question:  If I'm to install this component, what do I need to uninstall first 
to avoid conflicts?  I have read things about not having multiple versions of 
Camel-* going at the same time...

Also I assume I just download this jar and drop it in the deploy 
directory...correct?

Thanks much.
--Scott

-----Original Message-----
From: Willem Jiang [mailto:[email protected]]
Sent: Wednesday, January 19, 2011 9:36 PM
To: [email protected]
Subject: Re: Large(ish) message issue (CXFBC and Camel)

On 1/19/11 10:15 PM, Claus Ibsen wrote:
On Wed, Jan 19, 2011 at 2:26 PM, Scott Came<[email protected]>    wrote:
OK I'm confused...  I have Fuse ESB 4.3.0-03-00 installed.  From the
log messages I included in my message yesterday, it looks like my
install includes Camel Fuse 2.4.0.fuse-02-00.  (Reference log
message:>>>>    16:52:10,680 | INFO  | @qtp-727842206-0 |
DefaultTypeConverter | l.converter.DefaultTypeConverter  397 | 72 -
org.apache.camel.camel-core - 2.4.0.fuse-02-00 | Loaded 0 type
converters in 0.003 seconds.)

Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now 
available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB 
4.3.0-03-00 late last week)?

If not, is there something else that's causing the type converters not to get 
loaded?


Its this bug which was fixed dec-20-2010
http://fusesource.com/issues/browse/MR-392

And -03 hasn't been released yet.
Maybe you can consider to try out the camel-spring 2.4.0-fuse-SNAPSHOT[1] which 
has the fix?

[1]http://repo.fusesource.com/nexus/content/groups/public-snapshots/or
g/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fus
e-20110118.002228-16.jar



Thanks for all your help...
--Scott

-----Original Message-----
From: Claus Ibsen [mailto:[email protected]]
Sent: Wednesday, January 19, 2011 5:14 AM
To: [email protected]
Subject: Re: Large(ish) message issue (CXFBC and Camel)

On Wed, Jan 19, 2011 at 1:59 PM, Scott Came<[email protected]>    wrote:
Fuse ESB 4.3.0-03-00 is what I'm using...it contains Camel 2.4.  If I 
understand Claus correctly, I need Camel 2.6...


No the bug is fixed in FUSE Camel 2.4. (latest version of FUSE 2.4 version).
At Apache the bug is only to be fixed in the upcoming Camel 2.6 release.


-----Original Message-----
From: Willem Jiang [mailto:[email protected]]
Sent: Wednesday, January 19, 2011 2:02 AM
To: [email protected]
Subject: Re: Large(ish) message issue (CXFBC and Camel)

Why don't you just download the Fuse ESB 4.3.0-fuse-03-00?
You don't need to build the component yourself.

On 1/19/11 10:34 AM, Scott Came wrote:
I've actually succeeded in building the 2011.01-SNAPSHOT version of 
servicemix-camel that's in SVN.   I have the component .jar and installer .zip 
in my local maven repository now.

Any reason why I shouldn't be able to install that in 
servicemix-4.3.0-fuse-03-00?  Do I just drop the zip file in the deploy 
directory?  Do I need to be worried about conflicts with the currently 
installed version of Camel (i.e., should I uninstall)?

Excuse the newbie questions...is there a way to deploy this snapshot via the 
features mechanism?

Anyway, if I can get this going I'd be happy to testdrive the 2011.01-SNAPSHOT 
build of servicemix-camel...

Thanks.
--Scott

-----Original Message-----
From: Scott Came [mailto:[email protected]]
Sent: Tuesday, January 18, 2011 12:33 PM
To: [email protected]
Subject: RE: Large(ish) message issue (CXFBC and Camel)

Thanks, Claus.  Is there anything I can do in the meantime?  Is the fix in a 
current Camel build?  If so, are there docs on how to update the Camel 
components in SM?

--Scott

-----Original Message-----
From: Claus Ibsen [mailto:[email protected]]
Sent: Tuesday, January 18, 2011 7:56 AM
To: [email protected]
Subject: Re: Large(ish) message issue (CXFBC and Camel)

On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<[email protected]>      wrote:
On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<[email protected]>      wrote:
Thanks, Claus.

I grepped my logs for AnnotationTypeConverterLoader and see a line like this:

16:52:10,678 | INFO  | @qtp-727842206-0 |
AnnotationTypeConverterLoader    | er.AnnotationTypeConverterLoader
66 | 72 - org.apache.camel.camel-core - 2.4.0.fuse-02-00 | Found
3 packages with 0 @Converter classes to load

Grepped for DefaultTypeConverter and see this:

16:52:10,680 | INFO  | @qtp-727842206-0 | DefaultTypeConverter
| l.converter.DefaultTypeConverter  397 | 72 -
org.apache.camel.camel-core - 2.4.0.fuse-02-00 | Loaded 0 type
converters in 0.003 seconds

I'm guessing that's not good.  I am running the current release version of FUSE 
ESB (apache-servicemix-4.3.0-fuse-03-00).  I'm not sure what version of Camel 
is included, but I haven't done anything to update Camel outside of the stock 
FUSE ESB distro.  It looks from the above log message like it's Camel 
2.4.0.fuse-02-00.


Yeah it should be fixed in FUSE ESB 4.3.1 which includes Camel
2.4.0-fuse-03-00 which has the fix.


Correction, that would be the next FUSE ESB 4.3.0 release.

I think there is a ESB 4.3.1 planned later this month/next month which will 
ship with Camel 2.6 (currently in progress).


      From Camel 2.6 onwards we actually now will throw an
exception on starting Camel if this situation happens again.
Then it should be much easier for end user to spot something is wrong.




Thanks for your help.
--Scott

-----Original Message-----
From: Claus Ibsen [mailto:[email protected]]
Sent: Monday, January 17, 2011 10:05 PM
To: [email protected]
Subject: Re: Large(ish) message issue (CXFBC and Camel)

What versions of the products are you using? SMX / Camel?
And how do you startup the SMX container?

I think there was a bug when using JBI with SMX 4.x that could lead to Camel 
not being able to load type converters on startup (race condition when using 
OSGi). This should be fixed in upcoming Apache SMX 4.3 release and already in 
the latest FUSE ESB release.

You should see something like this at INFO level logged by Camel
on startup (requires Camel 2.3 or better)

2011-01-18 07:05:00,519 [main           ] INFO
AnnotationTypeConverterLoader  - Found 3 packages with 19
@Converter classes to load
2011-01-18 07:05:00,567 [main           ] INFO
DefaultTypeConverter
           - Loaded 150 type converters in 1.038 seconds



On Tue, Jan 18, 2011 at 5:42 AM, Scott Came<[email protected]>      wrote:
Hi Freeman, thanks for the suggestion.

I tried that and am seeing the same results.  After consulting the Camel documentation about stream caching 
at http://camel.apache.org/stream-caching.html I tried various flavors of specifying it (e.g., specifying 
streamCache="true" on camelContext and streamCaching="true" and 
streamCache="true" on route)...none of those helped.

I also tried removing the<to>      element for the log message, and that didn't 
help either.

It's like in the case of both<to uri="log...">      and<to uri="file...">      
the stream from the jbi: endpoint is getting cut off after 1000-2000 bytes.  Very strange.

I set the log level to DEBUG, and I get a big nested stack trace at the 
expected place, with this as the last exception listed:

Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected end of
input block in start tag
        at [row,col {unknown-source}]: [51,20]
         at
com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOB(StreamScanner.java:
69
6)
         at
com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.
ja
v
a
:1
062)
         at
com.ctc.wstx.sr.StreamScanner.getNextCharFromCurrent(StreamScanner.
j
av
a:807)
         at
com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.
ja
va:2892)
         at
com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:
2783)
         at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1
0
48
)
         at
org.apache.servicemix.soap.util.stax.FragmentStreamReader.next(
F
ra
g
m
en
tStreamReader.java:68)
         at
org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(St
a
xJ
b
i
Wr
apper.java:166)
         at
org.apache.servicemix.soap.util.stax.StaxSource.parse(StaxSource.java:
116)
         ... 54 more

Incidentally, the first exception (top of the stack) is this:

org.apache.camel.InvalidPayloadException: No body available of type:
java.lang.String but has value:
org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207 of type:
org.apache.servicemix.soap.util.stax.StaxSource on: Message:
org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207. Caused by:
No type converter available to convert from type:
org.apache.servicemix.soap.util.stax.StaxSource to the required type:
java.lang.String with value
org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207.
Exchange[Message:
org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207]. Caused by:
[org.apache.camel.NoTypeConversionAvailableException - No type
converter available to convert from type:
org.apache.servicemix.soap.util.stax.StaxSource to the required type:
java.lang.String with value
org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207]
         at
org.apache.camel.impl.MessageSupport.getMandatoryBody(MessageSu
p
po
r
t
.j
ava:103)
         at
org.apache.camel.processor.ConvertBodyProcessor.process(Convert
B
od
y
P
ro
cessor.java:57)
         at
org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Pro
c
es
s
o
rT
oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
         at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
o
rH
e
l
pe
r.java:70)
         at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(D
e
le
g
a
te
AsyncProcessor.java:98)
         at
org.apache.camel.processor.DelegateAsyncProcessor.process(Deleg
a
te
A
s
yn
cProcessor.java:89)
         at
org.apache.camel.management.InstrumentationProcessor.process(In
s
tr
u
m
en
tationProcessor.java:68)
         at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
o
rH
e
l
pe
r.java:70)
         at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(D
e
le
g
a
te
AsyncProcessor.java:98)
         at
org.apache.camel.processor.DelegateAsyncProcessor.process(Deleg
a
te
A
s
yn
cProcessor.java:89)
         at
org.apache.camel.processor.interceptor.TraceInterceptor.process
(
Tr
a
c
eI
nterceptor.java:99)
         at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
o
rH
e
l
pe
r.java:70)
         at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(D
e
le
g
a
te
AsyncProcessor.java:98)
         at
org.apache.camel.processor.DelegateAsyncProcessor.process(Deleg
a
te
A
s
yn
cProcessor.java:89)
         at
org.apache.camel.management.InstrumentationProcessor.process(In
s
tr
u
m
en
tationProcessor.java:68)
         at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
o
rH
e
l
pe
r.java:70)
         at
org.apache.camel.processor.RedeliveryErrorHandler.processErrorH
a
nd
l
e
r(
RedeliveryErrorHandler.java:290)
         at
org.apache.camel.processor.RedeliveryErrorHandler.process(Redel
i
ve
r
y
Er
rorHandler.java:202)
         at
org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
256)
         at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
o
rH
e
l
pe
r.java:70)
         at
org.apache.camel.processor.Pipeline.process(Pipeline.java:143)
         at
org.apache.camel.processor.Pipeline.process(Pipeline.java:78)
         at
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWo
r
kP
r
o
ce
ssor.java:99)
         at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
o
rH
e
l
pe
r.java:70)
         at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(D
e
le
g
a
te
AsyncProcessor.java:98)
         at
org.apache.camel.processor.DelegateAsyncProcessor.process(Deleg
a
te
A
s
yn
cProcessor.java:89)
         at
org.apache.camel.management.InstrumentationProcessor.process(In
s
tr
u
m
en
tationProcessor.java:68)
         at
org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelP
r
ov
i
d
er
Endpoint.java:109)
         at
org.apache.servicemix.camel.JbiBinding.runWithCamelContextClass
L
oa
d
e
r(
JbiBinding.java:116)
         at
org.apache.servicemix.camel.CamelProviderEndpoint.handleActiveP
r
ov
i
d
er
Exchange(CamelProviderEndpoint.java:107)
         at
org.apache.servicemix.camel.CamelProviderEndpoint.process(Camel
P
ro
v
i
de
rEndpoint.java:85)
         at
org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(Async
B
as
e
L
if
eCycle.java:651)
         at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange
(
As
y
n
cB
aseLifeCycle.java:606)
         at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange
I
nT
x
(
As
yncBaseLifeCycle.java:501)
         at
org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBase
L
if
e
C
yc
le.java:370)
         at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPo
o
lE
x
e
cu
tor.java:886)
         at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
java:908)
         at java.lang.Thread.run(Thread.java:680)

Any other ideas?

Thanks.
--Scott

-----Original Message-----
From: Freeman Fang [mailto:[email protected]]
Sent: Monday, January 17, 2011 7:08 PM
To: [email protected]
Subject: Re: Large(ish) message issue (CXFBC and Camel)


On 2011-1-18, at 上午10:41, Scott Came wrote:

I am seeing some strange behavior when using Camel to route
from a JBI endpoint (cxfbc) to a file using the Camel file component.

Here is the scenario.

I have created a JBI CXFBC service unit with WSDL.  I have
also created a Camel service unit, with a very simple route:
it routes from the CXFBC endpoint to a file with a route that looks like this:

<camelContext id="camel"
xmlns="http://camel.apache.org/schema/
spring">
       <route>
         <from
uri="jbi:endpoint:http://it.ojp.gov/global/services/tsc-encoun
t
er
- r ou t er/RouterService/RouterServiceEndpoint
"/>
         <to
uri="log:gov.ojp.it.TSCEncounterRouterLog?showBody=false"/>
         <convertBodyTo type="java.lang.String"/>
         <to uri="file:/Users/scott/Desktop/router-output"/>
       </route>
     </camelContext>

I bundle these to SUs into an SA and deploy.  Everything deploys fine.

I then use SOAPUI to send test messages.

If I send a very small message...say, no bigger than a couple
hundred bytes, to the RouterServiceEndpoint, everything works fine.
I see the log message in the log, and the file gets written to
my router-output directory.

However, when I increase the message size beyond a certain
point (not sure exactly where it is...somewhere around
2000-3000 bytes) I start getting messages like:

Unexpected end of input block in start tag at [row,col
{unknown-
source}]: [51,20]

The underlying exception seems to be a
com.ctc.wstx.exc.WstcEOFException.

If I try subsequent invocations of the service, I get a
similar error, though the referenced place in the stream is
often a little different (e.g., [51, 25] or [55, 10]).  So it
seems like the parser is getting to a different place in the stream each time 
before it fails.

I have put TCPMon in the middle and verified that the entire
message is getting to the server, although the server side is
not closing the connection when the exception occurs.

I am 100% sure the content being sent is valid XML.

Interestingly, if I take out the<to>      part of the route to the
file component, everything works fine...I get the simple log
message (note that I am not logging the body content), and the
connection closes in TCPMon.  However, if I switch to logging
the body content (i.e., take off the ?showBody=false option),
I get similar errors as when I try to write out the file.
This looks like a stream already get consumed issue for me, how
about you just

How about you just change your router like<camelContext id="camel"
xmlns="http://camel.apache.org/schema/spring";>
       <route  streamCache="true">
         <from
uri="jbi:endpoint:http://it.ojp.gov/global/services/tsc-encount
e
r- r o ut er/RouterService/RouterServiceEndpoint
"/>
         <to
uri="log:gov.ojp.it.TSCEncounterRouterLog?showBody=false"/>
         <convertBodyTo type="java.lang.String"/>
         <to uri="file:/Users/scott/Desktop/router-output"/>
       </route>
     </camelContext>

Freeman

I have tried taking out the<convertBodyTo...>      element, but that
results in a different exception...something about no
appropriate converter being found.

It would be somewhat difficult for me to attach a full
example, as the content of the large message is somewhat
sensitive/proprietary, but I could do that if I absolutely
needed to.  I'm hoping there is some simple configuration
setting I need to tweak to handle bigger messages (though a 2K
or 3K message is by no means large...)

Thanks for any help you can offer.

--Scott


--
Freeman Fang

------------------------

FuseSource: http://fusesource.com
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang Apache
Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org Apache Karaf:
http://karaf.apache.org Apache Felix:
http://felix.apache.org





--
Claus Ibsen
-----------------
FuseSource
Email: [email protected]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/ Author of Camel in Action:
http://www.manning.com/ibsen/





--
Claus Ibsen
-----------------
FuseSource
Email: [email protected]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/ Author of Camel in Action:
http://www.manning.com/ibsen/




--
Claus Ibsen
-----------------
FuseSource
Email: [email protected]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/ Author of Camel in Action:
http://www.manning.com/ibsen/



--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
            http://jnn.javaeye.com (Chinese)
Twitter: willemjiang





--
Claus Ibsen
-----------------
FuseSource
Email: [email protected]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/ Author of Camel in Action:
http://www.manning.com/ibsen/







--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
            http://jnn.javaeye.com (Chinese)
Twitter: willemjiang



--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
           http://jnn.javaeye.com (Chinese)
Twitter: willemjiang



--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
         http://jnn.javaeye.com (Chinese)
Twitter: willemjiang

Reply via email to