On Thu, Aug 21, 2008 at 11:39 AM, Rickard Öberg <[EMAIL PROTECTED]> wrote:
> On the one hand it would be nice to not have to do all the transports
> that they've integrated, but on the other hand so far it is relly
> frustrating to get it to work, and it brings in the entire Spring and
> JAXB dependencies really fast.
Yes... Wasn't there a similar out-of-body experience with Apache
Abdera recently??
> public interface MessageComposite
> extends EntityComposite
> {
> Property<String> messageId();
> Property<Map<String, Object>> headers();
> Property<Map<String, DataHandler>> attachments();
> Property<Object> body();
> }
Headers Ok, I might live with that.
Attachments and Body --> Body is just another attachment, that in
reality just preceeds Attachments in the evolution and has become like
a "default" attachment.
And I thought we should place attachements as Property instances in
MessageComposite subtypes that the user can do whatever he likes with,
type-safe and all. Perhaps you have a plan for keeping the
attachments, headers and body as is, and some clever Concern will
delegate up to the suggested methods?
> So I'm not sure how to proceed really. Any thoughts?
I am not experienced with Camel, but my guess is that it is similar
enough to Mule in this respect; Shitload of dependencies and a
straight-jacket in the set-up. As most of the cases, I think recommend
a "Fork the useful bits" again, meaning if it is the Transports we
want, then we fork those. Also, we should provide a simple solution to
bind our In/Out boxes with "JVM"/"InMemory" end points of Camel and
Mule. I bet the footprint will be a fraction of the size... I hate to
end up in the NIH-camp, but most OO solutions and subsystems are just
too "fat" to be re-used effectively.
Cheers
Niclas
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
