On 06/05/2017 09:02 AM, Clebert Suconic wrote:
I think what Michael is looking for, is the possibility of receiving
his messages from Kafka, and sending through Artemis. He has from what
I understood a package of serialization for his stuff.
So, I guess it's a matter of easy of use.. and being a faster
serialization than Java Serialization is.
If you serialize your stuff and use a BytesMessage as JMS specification
intends for custom serialization format then you don't have to content
with Java serialization being slow.
On Mon, Jun 5, 2017 at 7:36 AM, Christopher Shannon
<[email protected]> wrote:
I was out of the office thursday/friday last week so I'm just joining this
discussion now but after reading everything I guess I'm confused of what
the benefit is here. I kind of agree with Tim Bish on this one.
Yes we could certainly make the read/write object pluggable on the
connection factory but is that really that beneficial? Why can't a user
just use their own custom serializer to serialize to bytes before sending
it as a bytes message?
I'm not going to prevent the feature from being added if people want it I
just don't know that it is necessary.
On Fri, Jun 2, 2017 at 5:12 PM, Clebert Suconic <[email protected]>
wrote:
That was just a 5 min code. I agree with you.
On Fri, Jun 2, 2017 at 4:30 PM Michael André Pearce <
[email protected]> wrote:
Re black and white looking at your gist, that's specific to Java
serialisation, I don't think that should be in the interface like it is
maybe a more generic configure(properties) as for other impls they may
need
other config options (as in Avro would need to configure schema reg url).
Sent from my iPhone
On 2 Jun 2017, at 21:06, Clebert Suconic <[email protected]>
wrote:
What about a mixed approach.
We make Artemis as a plugin. And you use it as plug on anywhere else.
I like the plugin approach as it would clean up the code on black and
white
list anyways.
Then the plug in implementation for avro could live on this new Repo.
If at a later point u need to use a repo that doesn't support the plug
in
approach you use the facade doing the proxy ?
Perhaps we could talk over IRC next week. I'm taking Monday of. So I
would
be available Tuesday.
On Fri, Jun 2, 2017 at 3:42 PM Michael André Pearce <
[email protected]> wrote:
I'd rather go with something more people are happy with (or at least a
little more happier about)
I'm not 100% sure if I have fully read the feelings right, but it
seems
Tim is a little more happy with maybe us making some jms extension
area
that we put this and move the connection pool factory to also, as
plug-on
rather than as plug-in. And seems this is not suited for camel to own
but
maybe activemq, but as maybe a sub project rather than a module of
activemq5, or a module of artemis.
For me this solution does work, and allows it to work for any jms
impl,
e.g. It would be fairly important to be able to use qpid jms client
and
artemis client with it if using components in some places like qpid
router,
meaning you have to use qpid jms.
I agree it would be much better if there was a chance to have it in a
2.0.2 jms spec.
Are you against this idea? @clebert? @tim have I understood your
feelings
correctly?
Sent from my iPhone
On 2 Jun 2017, at 20:29, Clebert Suconic <[email protected]>
wrote:
On Fri, Jun 2, 2017 at 3:22 PM, Michael André Pearce
<[email protected]> wrote:
I agree i much the original proposal to make it a plugin interface,
but
would want also buy-in on the qpid jms client also.
I'm just proposing one thing at the time.
After everything is cleared in JMS terms, we can verify what to do
next.
If the JSR was still alive.. I would propose this as an addition on
the
JSR.
--
Clebert Suconic
--
Clebert Suconic
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
