Return-Path: 
 <users-return-46078-apmail-camel-users-archive=camel.apache.org@camel.apache.org>
X-Original-To: apmail-camel-users-archive@www.apache.org
Delivered-To: apmail-camel-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id A4E0D1009F
	for <apmail-camel-users-archive@www.apache.org>;
 Tue, 14 Jan 2014 09:02:20 +0000 (UTC)
Received: (qmail 11086 invoked by uid 500); 14 Jan 2014 09:00:12 -0000
Delivered-To: apmail-camel-users-archive@camel.apache.org
Received: (qmail 10831 invoked by uid 500); 14 Jan 2014 08:59:38 -0000
Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@camel.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@camel.apache.org>
List-Post: <mailto:users@camel.apache.org>
List-Id: <users.camel.apache.org>
Reply-To: users@camel.apache.org
Delivered-To: mailing list users@camel.apache.org
Received: (qmail 10371 invoked by uid 99); 14 Jan 2014 08:58:17 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jan 2014 08:58:17 +0000
X-ASF-Spam-Status: No, hits=2.8 required=5.0
	tests=HTML_MESSAGE,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_LOW,SPF_PASS,URI_HEX,WEIRD_PORT
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of christian.ohr@gmail.com
 designates 209.85.213.171 as permitted sender)
Received: from [209.85.213.171] (HELO mail-ig0-f171.google.com)
 (209.85.213.171)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jan 2014 08:58:13 +0000
Received: by mail-ig0-f171.google.com with SMTP id uy17so5070203igb.4
        for <users@camel.apache.org>; Tue, 14 Jan 2014 00:57:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=QHTW2xTzloUGo1UwxnMQ9lQmKdMwuLYd2/YwlTZEXrs=;
        b=meme/sPqYNtNd5xih3jXX8q6SyuZNP3oLh6PpcZ0aLGyAdjsunXorWhEHMvMYfcHnI
         p8rnbBOJYKjlPw7fpVz3JzzfySXF8JxjCIGSUb0Ej3EkU6xFGbjvM3YmQ8Se5evFPcap
         QwvqIUD1TWNPBqWM1vKxagvxMEKLs5MyF3SMxS4fN6zCHFOdKVr7Anz4Dfej01nBLLUZ
         I0IUCLNnvRAOJXLxKq5nirLehcM1ts0DW5FS2OwB9TOvgVyvLn9sLaOWbKa9cV0u8sF8
         duuh0EmGM6osJFGwOC/uCYw65v6RkrpFkK+SPvHckJTPyxjMRWVmi+7bYzHv7aKxOKan
         uARA==
MIME-Version: 1.0
X-Received: by 10.43.155.84 with SMTP id lh20mr929485icc.81.1389689872361;
 Tue, 14 Jan 2014 00:57:52 -0800 (PST)
Received: by 10.64.166.99 with HTTP; Tue, 14 Jan 2014 00:57:52 -0800 (PST)
In-Reply-To: <1389636107224-5745900.post@n5.nabble.com>
References: <1389636107224-5745900.post@n5.nabble.com>
Date: Tue, 14 Jan 2014 09:57:52 +0100
Message-ID: 
 <CAEhQ+881Ep5sozaG4wcsYReXg0BXK9hcmpzqZZkPWgUKbA3cgA@mail.gmail.com>
Subject: Re: HL7 v. 2.7 with mina2
From: Christian Ohr <christian.ohr@gmail.com>
To: users@camel.apache.org
Content-Type: multipart/alternative; boundary=001a11c2d3de30af2704efea635b
X-Virus-Checked: Checked by ClamAV on apache.org

--001a11c2d3de30af2704efea635b
Content-Type: text/plain; charset=ISO-8859-1

In fact, HAPI does not yet support HL7 v2.7, so you will receive an
exception as soon as you parse such a message.

Mina itself is unaware of HL7 versions; the hl7codec just unpacks the
message payload from the MLLP wrapper. The error message indicates that the
trailing bytes of a MLLP frame are missing.

regards
Christian



2014/1/13 giandrea77 <andrea.girardi@gmail.com>

> Hi there,
>
> Our customer changed the HL7 message format from 2.3 to 2.7 and I having
> some issue with new message format. Basically we was able to route message
> using mina2 protocols in this way:
>
> <route>
> <from
> uri="mina2:tcp://
> 10.124.199.40:2575?sync=true&amp;codec=#hl7codec&amp;minaLogger=true"
> />
> [...]
> </route>
>
> and it worked fine untile the upgrade of message standard. Indeed, changing
> the format from 2.3 to 2.7 it doesn't work, we get this DEBUG message:
>
>  2014-01-09 08:36:40,717 DEBUG HL7MLLPDecoder [104]  - Start scanning
> buffer
> at position 0
>  2014-01-09 08:36:40,718 DEBUG HL7MLLPDecoder [56]  - No complete message
> in
> this packet
>
> We are using HAPI as message parser and I'm afraid it should be the problem
> but, in this case, what I'm expecting is that Camel should be able to route
> the message though mina2 and, when we read HL7 message from our business
> classes catch an exception. But it doesn't, it seems that mina2 is not able
> to routes the message.
>
> Any clue with that?
>
> thanks,
> Andrea
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/HL7-v-2-7-with-mina2-tp5745900.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

--001a11c2d3de30af2704efea635b--