Re: [DISCUSS] Custom Object Serialisation Support

[Clebert Suconic]

I have a mixed feeling about this.

At the same time this would fix it for both options. As it wouldn't be part
of the project so other people would have to find your library.



However this common tooling is an issue in other cases as well.  Like I
know some users need a pooled connection factory for both core and qpid
JMS.



So if we could create a JMS-tools package either in Artemis or somewhere
else.  We could have this as part of the tooling.



But let me sleep over anyways.  And perhaps someone will have a better idea
as I sleep.


On Thu, Jun 1, 2017 at 6:51 PM Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> I have been looking at an alternative approach (i think its a little less
> optimal), but in thoughts it might be more acceptable for those not wishing
> this into the core jms client.
> It means the custom object serialisation is a optional add-on rather than
> coded into the core jms client, similar idea to the way spring wraps
> connection factories for caching connection, and others.
>
>
> https://github.com/michaelandrepearce/activemq-artemis/tree/SerdesExtension/artemis-jms-client-extensions
> <
> https://github.com/michaelandrepearce/activemq-artemis/tree/SerdesExtension/artemis-jms-client-extensions
> >
>
> It essentially is wrapping at the JMS api level, so actually would/should
> work for any JMS Client not just artemis, e.g. could wrap QPID client.
>
> Thoughts on this approach rather than native integration to the clients?
>
>
>
> > On 1 Jun 2017, at 21:54, Matt Pavlovich  wrote:
> >
> > I understand the usefulness of adding this to the Client Connection
> Factory vs kicking all the way up to an integration stack (like Camel). In
> my eyes, its about solving for cross-platform object serialization using
> byte payloads instead of the problems associated with non-portable/cross
> platform ObjectMessage and MapMessage JMS message types. Tibco-RV was
> really good for that as well.
> >
> > IMHO— plugging in protobuf, Avro, or other binary-serialization
> flavor-of-the-month at the connection factory level has real value.
> >
> >> On Jun 1, 2017, at 2:23 PM, Clebert Suconic 
> wrote:
> >>
> >> I honestly don't see an issue on making the write and readObject a
> >> pluggable operation. It's a simple change on the API at
> >> ActiveMQConnectionFactory.
> >>
> >> On Thu, Jun 1, 2017 at 1:09 PM, Michael André Pearce
> >>  wrote:
> >>> This is why the proposal is for a pluggable interface to declared to
> convert from Object to byte[] and back not saying one moment Artemis owns
> or has all the implementations.
> >>>
> >>> Anyhow your points are taken on board, we def need to agree on a well
> defined and clean api, to avoid exactly that situation.
> >>>
> >>> Sent from my iPhone
> >>>
>  On 1 Jun 2017, at 17:59, Timothy Bish  wrote:
> 
> > On 06/01/2017 12:49 PM, Michael André Pearce wrote:
> > Not at all that's the point
> >
> > Application code uses JMS Api. The serdes are just defined/declared
> into the connection factory typically the only part of the app exposed to
> any particulars about the broker implementation detail.
> >
> > Yes we can do converter.convert(object) in code, this is just manual
> code in the app space.
> >
> > but like with kafka and I have to stress it's successfulness is that
> that converter is in it's api of the product. Which means a lot of
> companies reuse a few single implementations and a good eco system occurs
> like with schema registry (Eg we use confluents serdes we don't code out
> own)
> 
>  Which is exactly what camel can solve and without starting down the
> slippery slop of packing the same data format conversions Camel can already
> handle into the Artemis code base as will happen as each user wants their
> own preferred data format.
> 
>  Similar things were tried in the ActiveMQ 5.x code and abandoned over
> time so I'd like to avoid that if possible.
> 
>  Anyway, I've raised my objection.
> 
> >
> >
> >
> > Sent from my iPhone
> >
> >>> On 1 Jun 2017, at 17:39, Timothy Bish  wrote:
> >>>
> >>> On 06/01/2017 12:19 PM, Michael André Pearce wrote:
> >>> Agreed it does as an EAI pattern or flow, But I have to
> code/define into Camel's dsl, it does JMS as much as our custom app code
> would it consumes the JMS api.
> >> So you still need to code / define the serialization then and
> include that in you application which means the difference between some
> connection.setSerializationThing() vs
> producer.send(Converter.convert(payload)); so I don't see how that is a
> real value add to the JMS client.
> >>
> >>> What we propose here is just providing a clean way to define the
> JMS ObjectMessage internal serialisation. If Java serialisation isn't your
> cup of tea. (Which for many reasons isn't for 

Re: [DISCUSS] Custom Object Serialisation Support

[Michael André Pearce]

I have been looking at an alternative approach (i think its a little less 
optimal), but in thoughts it might be more acceptable for those not wishing 
this into the core jms client.
It means the custom object serialisation is a optional add-on rather than coded 
into the core jms client, similar idea to the way spring wraps connection 
factories for caching connection, and others.

https://github.com/michaelandrepearce/activemq-artemis/tree/SerdesExtension/artemis-jms-client-extensions
 


It essentially is wrapping at the JMS api level, so actually would/should work 
for any JMS Client not just artemis, e.g. could wrap QPID client.

Thoughts on this approach rather than native integration to the clients?



> On 1 Jun 2017, at 21:54, Matt Pavlovich  wrote:
> 
> I understand the usefulness of adding this to the Client Connection Factory 
> vs kicking all the way up to an integration stack (like Camel). In my eyes, 
> its about solving for cross-platform object serialization using byte payloads 
> instead of the problems associated with non-portable/cross platform 
> ObjectMessage and MapMessage JMS message types. Tibco-RV was really good for 
> that as well.
> 
> IMHO— plugging in protobuf, Avro, or other binary-serialization 
> flavor-of-the-month at the connection factory level has real value.
> 
>> On Jun 1, 2017, at 2:23 PM, Clebert Suconic  
>> wrote:
>> 
>> I honestly don't see an issue on making the write and readObject a
>> pluggable operation. It's a simple change on the API at
>> ActiveMQConnectionFactory.
>> 
>> On Thu, Jun 1, 2017 at 1:09 PM, Michael André Pearce
>>  wrote:
>>> This is why the proposal is for a pluggable interface to declared to 
>>> convert from Object to byte[] and back not saying one moment Artemis owns 
>>> or has all the implementations.
>>> 
>>> Anyhow your points are taken on board, we def need to agree on a well 
>>> defined and clean api, to avoid exactly that situation.
>>> 
>>> Sent from my iPhone
>>> 
 On 1 Jun 2017, at 17:59, Timothy Bish  wrote:
 
> On 06/01/2017 12:49 PM, Michael André Pearce wrote:
> Not at all that's the point
> 
> Application code uses JMS Api. The serdes are just defined/declared into 
> the connection factory typically the only part of the app exposed to any 
> particulars about the broker implementation detail.
> 
> Yes we can do converter.convert(object) in code, this is just manual code 
> in the app space.
> 
> but like with kafka and I have to stress it's successfulness is that that 
> converter is in it's api of the product. Which means a lot of companies 
> reuse a few single implementations and a good eco system occurs like with 
> schema registry (Eg we use confluents serdes we don't code out own)
 
 Which is exactly what camel can solve and without starting down the 
 slippery slop of packing the same data format conversions Camel can 
 already handle into the Artemis code base as will happen as each user 
 wants their own preferred data format.
 
 Similar things were tried in the ActiveMQ 5.x code and abandoned over time 
 so I'd like to avoid that if possible.
 
 Anyway, I've raised my objection.
 
> 
> 
> 
> Sent from my iPhone
> 
>>> On 1 Jun 2017, at 17:39, Timothy Bish  wrote:
>>> 
>>> On 06/01/2017 12:19 PM, Michael André Pearce wrote:
>>> Agreed it does as an EAI pattern or flow, But I have to code/define 
>>> into Camel's dsl, it does JMS as much as our custom app code would it 
>>> consumes the JMS api.
>> So you still need to code / define the serialization then and include 
>> that in you application which means the difference between some 
>> connection.setSerializationThing() vs 
>> producer.send(Converter.convert(payload)); so I don't see how that is a 
>> real value add to the JMS client.
>> 
>>> What we propose here is just providing a clean way to define the JMS 
>>> ObjectMessage internal serialisation. If Java serialisation isn't your 
>>> cup of tea. (Which for many reasons isn't for us, and I'm sure it's 
>>> similar for others)
>>> 
>> 
>> 
> On 1 Jun 2017, at 16:58, Timothy Bish  wrote:
> 
> On 06/01/2017 11:50 AM, Michael André Pearce wrote:
> Really this is much more about how an ObjectMessage serializes the 
> Object. As we have C++ clients etc that obviously won't be able to 
> understand Java serialized object.
> 
> We use Avro and a schema repo for our dto transfer over the wire, 
> it's been a real performance boost , and removed some core data 
> issues, and really like to use 

Re: [DISCUSS] Custom Object Serialisation Support

[Matt Pavlovich]

I understand the usefulness of adding this to the Client Connection Factory vs 
kicking all the way up to an integration stack (like Camel). In my eyes, its 
about solving for cross-platform object serialization using byte payloads 
instead of the problems associated with non-portable/cross platform 
ObjectMessage and MapMessage JMS message types. Tibco-RV was really good for 
that as well.

IMHO— plugging in protobuf, Avro, or other binary-serialization 
flavor-of-the-month at the connection factory level has real value.

> On Jun 1, 2017, at 2:23 PM, Clebert Suconic  wrote:
> 
> I honestly don't see an issue on making the write and readObject a
> pluggable operation. It's a simple change on the API at
> ActiveMQConnectionFactory.
> 
> On Thu, Jun 1, 2017 at 1:09 PM, Michael André Pearce
>  wrote:
>> This is why the proposal is for a pluggable interface to declared to convert 
>> from Object to byte[] and back not saying one moment Artemis owns or has all 
>> the implementations.
>> 
>> Anyhow your points are taken on board, we def need to agree on a well 
>> defined and clean api, to avoid exactly that situation.
>> 
>> Sent from my iPhone
>> 
>>> On 1 Jun 2017, at 17:59, Timothy Bish  wrote:
>>> 
 On 06/01/2017 12:49 PM, Michael André Pearce wrote:
 Not at all that's the point
 
 Application code uses JMS Api. The serdes are just defined/declared into 
 the connection factory typically the only part of the app exposed to any 
 particulars about the broker implementation detail.
 
 Yes we can do converter.convert(object) in code, this is just manual code 
 in the app space.
 
 but like with kafka and I have to stress it's successfulness is that that 
 converter is in it's api of the product. Which means a lot of companies 
 reuse a few single implementations and a good eco system occurs like with 
 schema registry (Eg we use confluents serdes we don't code out own)
>>> 
>>> Which is exactly what camel can solve and without starting down the 
>>> slippery slop of packing the same data format conversions Camel can already 
>>> handle into the Artemis code base as will happen as each user wants their 
>>> own preferred data format.
>>> 
>>> Similar things were tried in the ActiveMQ 5.x code and abandoned over time 
>>> so I'd like to avoid that if possible.
>>> 
>>> Anyway, I've raised my objection.
>>> 
 
 
 
 Sent from my iPhone
 
>> On 1 Jun 2017, at 17:39, Timothy Bish  wrote:
>> 
>> On 06/01/2017 12:19 PM, Michael André Pearce wrote:
>> Agreed it does as an EAI pattern or flow, But I have to code/define into 
>> Camel's dsl, it does JMS as much as our custom app code would it 
>> consumes the JMS api.
> So you still need to code / define the serialization then and include 
> that in you application which means the difference between some 
> connection.setSerializationThing() vs 
> producer.send(Converter.convert(payload)); so I don't see how that is a 
> real value add to the JMS client.
> 
>> What we propose here is just providing a clean way to define the JMS 
>> ObjectMessage internal serialisation. If Java serialisation isn't your 
>> cup of tea. (Which for many reasons isn't for us, and I'm sure it's 
>> similar for others)
>> 
> 
> 
 On 1 Jun 2017, at 16:58, Timothy Bish  wrote:
 
 On 06/01/2017 11:50 AM, Michael André Pearce wrote:
 Really this is much more about how an ObjectMessage serializes the 
 Object. As we have C++ clients etc that obviously won't be able to 
 understand Java serialized object.
 
 We use Avro and a schema repo for our dto transfer over the wire, it's 
 been a real performance boost , and removed some core data issues, and 
 really like to use it over the JMS land.
 
 One can argue that you could manually code this that you serialize the 
 data manually first and then just manually send a BytesMessage.
 
 But I think taking some inspiration from other places where a serdes 
 pattern is done has really helped (Kafka), from a corporation user 
 approach wiring some prebuilt serdes into a factory is very easy, 
 having duplicated code in many many apps leaves for issues, and 
 implementation divergence.
 
 The one downside of Kafka is it's lack of spec api, this is one big 
 sell of artemis as it's JMS compliant. Coding against JMS api for Java 
 estate is a huge win, this is suggesting taking some of the good bits 
 :).
 
 Does camel expose this as some sort of JMS API wrapper? I thought it 
 was much more an EAI solution.
 
 Cheers
 Mike
>>> Camel does JMS transport: 

Re: [DISCUSS] Custom Object Serialisation Support

[Clebert Suconic]

I honestly don't see an issue on making the write and readObject a
pluggable operation. It's a simple change on the API at
ActiveMQConnectionFactory.

On Thu, Jun 1, 2017 at 1:09 PM, Michael André Pearce
 wrote:
> This is why the proposal is for a pluggable interface to declared to convert 
> from Object to byte[] and back not saying one moment Artemis owns or has all 
> the implementations.
>
> Anyhow your points are taken on board, we def need to agree on a well defined 
> and clean api, to avoid exactly that situation.
>
> Sent from my iPhone
>
>> On 1 Jun 2017, at 17:59, Timothy Bish  wrote:
>>
>>> On 06/01/2017 12:49 PM, Michael André Pearce wrote:
>>> Not at all that's the point
>>>
>>> Application code uses JMS Api. The serdes are just defined/declared into 
>>> the connection factory typically the only part of the app exposed to any 
>>> particulars about the broker implementation detail.
>>>
>>> Yes we can do converter.convert(object) in code, this is just manual code 
>>> in the app space.
>>>
>>>  but like with kafka and I have to stress it's successfulness is that that 
>>> converter is in it's api of the product. Which means a lot of companies 
>>> reuse a few single implementations and a good eco system occurs like with 
>>> schema registry (Eg we use confluents serdes we don't code out own)
>>
>> Which is exactly what camel can solve and without starting down the slippery 
>> slop of packing the same data format conversions Camel can already handle 
>> into the Artemis code base as will happen as each user wants their own 
>> preferred data format.
>>
>> Similar things were tried in the ActiveMQ 5.x code and abandoned over time 
>> so I'd like to avoid that if possible.
>>
>> Anyway, I've raised my objection.
>>
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
> On 1 Jun 2017, at 17:39, Timothy Bish  wrote:
>
> On 06/01/2017 12:19 PM, Michael André Pearce wrote:
> Agreed it does as an EAI pattern or flow, But I have to code/define into 
> Camel's dsl, it does JMS as much as our custom app code would it consumes 
> the JMS api.
 So you still need to code / define the serialization then and include that 
 in you application which means the difference between some 
 connection.setSerializationThing() vs 
 producer.send(Converter.convert(payload)); so I don't see how that is a 
 real value add to the JMS client.

> What we propose here is just providing a clean way to define the JMS 
> ObjectMessage internal serialisation. If Java serialisation isn't your 
> cup of tea. (Which for many reasons isn't for us, and I'm sure it's 
> similar for others)
>


>>> On 1 Jun 2017, at 16:58, Timothy Bish  wrote:
>>>
>>> On 06/01/2017 11:50 AM, Michael André Pearce wrote:
>>> Really this is much more about how an ObjectMessage serializes the 
>>> Object. As we have C++ clients etc that obviously won't be able to 
>>> understand Java serialized object.
>>>
>>> We use Avro and a schema repo for our dto transfer over the wire, it's 
>>> been a real performance boost , and removed some core data issues, and 
>>> really like to use it over the JMS land.
>>>
>>> One can argue that you could manually code this that you serialize the 
>>> data manually first and then just manually send a BytesMessage.
>>>
>>> But I think taking some inspiration from other places where a serdes 
>>> pattern is done has really helped (Kafka), from a corporation user 
>>> approach wiring some prebuilt serdes into a factory is very easy, 
>>> having duplicated code in many many apps leaves for issues, and 
>>> implementation divergence.
>>>
>>> The one downside of Kafka is it's lack of spec api, this is one big 
>>> sell of artemis as it's JMS compliant. Coding against JMS api for Java 
>>> estate is a huge win, this is suggesting taking some of the good bits 
>>> :).
>>>
>>> Does camel expose this as some sort of JMS API wrapper? I thought it 
>>> was much more an EAI solution.
>>>
>>> Cheers
>>> Mike
>> Camel does JMS transport: http://camel.apache.org/sjms.html
>> Camel does AVRO: http://camel.apache.org/avro.html
>>
>>
>>> Sent from my iPhone
>>>
>> On 1 Jun 2017, at 15:18, Martyn Taylor  wrote:
>>
>> On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish  
>> wrote:
>>
>>> On 06/01/2017 09:34 AM, Martyn Taylor wrote:
>>>
 On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish  
 wrote:

 On 06/01/2017 08:51 AM, Martyn Taylor wrote:
 I get the use case for using JSON/XML, particularly for cross 
 language
 communication.

 One way 

Re: [DISCUSS] Custom Object Serialisation Support

[Michael André Pearce]

This is why the proposal is for a pluggable interface to declared to convert 
from Object to byte[] and back not saying one moment Artemis owns or has all 
the implementations.

Anyhow your points are taken on board, we def need to agree on a well defined 
and clean api, to avoid exactly that situation.

Sent from my iPhone

> On 1 Jun 2017, at 17:59, Timothy Bish  wrote:
> 
>> On 06/01/2017 12:49 PM, Michael André Pearce wrote:
>> Not at all that's the point
>> 
>> Application code uses JMS Api. The serdes are just defined/declared into the 
>> connection factory typically the only part of the app exposed to any 
>> particulars about the broker implementation detail.
>> 
>> Yes we can do converter.convert(object) in code, this is just manual code in 
>> the app space.
>> 
>>  but like with kafka and I have to stress it's successfulness is that that 
>> converter is in it's api of the product. Which means a lot of companies 
>> reuse a few single implementations and a good eco system occurs like with 
>> schema registry (Eg we use confluents serdes we don't code out own)
> 
> Which is exactly what camel can solve and without starting down the slippery 
> slop of packing the same data format conversions Camel can already handle 
> into the Artemis code base as will happen as each user wants their own 
> preferred data format.
> 
> Similar things were tried in the ActiveMQ 5.x code and abandoned over time so 
> I'd like to avoid that if possible.
> 
> Anyway, I've raised my objection.
> 
>> 
>> 
>> 
>> Sent from my iPhone
>> 
 On 1 Jun 2017, at 17:39, Timothy Bish  wrote:
 
 On 06/01/2017 12:19 PM, Michael André Pearce wrote:
 Agreed it does as an EAI pattern or flow, But I have to code/define into 
 Camel's dsl, it does JMS as much as our custom app code would it consumes 
 the JMS api.
>>> So you still need to code / define the serialization then and include that 
>>> in you application which means the difference between some 
>>> connection.setSerializationThing() vs 
>>> producer.send(Converter.convert(payload)); so I don't see how that is a 
>>> real value add to the JMS client.
>>> 
 What we propose here is just providing a clean way to define the JMS 
 ObjectMessage internal serialisation. If Java serialisation isn't your cup 
 of tea. (Which for many reasons isn't for us, and I'm sure it's similar 
 for others)
 
>>> 
>>> 
>> On 1 Jun 2017, at 16:58, Timothy Bish  wrote:
>> 
>> On 06/01/2017 11:50 AM, Michael André Pearce wrote:
>> Really this is much more about how an ObjectMessage serializes the 
>> Object. As we have C++ clients etc that obviously won't be able to 
>> understand Java serialized object.
>> 
>> We use Avro and a schema repo for our dto transfer over the wire, it's 
>> been a real performance boost , and removed some core data issues, and 
>> really like to use it over the JMS land.
>> 
>> One can argue that you could manually code this that you serialize the 
>> data manually first and then just manually send a BytesMessage.
>> 
>> But I think taking some inspiration from other places where a serdes 
>> pattern is done has really helped (Kafka), from a corporation user 
>> approach wiring some prebuilt serdes into a factory is very easy, having 
>> duplicated code in many many apps leaves for issues, and implementation 
>> divergence.
>> 
>> The one downside of Kafka is it's lack of spec api, this is one big sell 
>> of artemis as it's JMS compliant. Coding against JMS api for Java estate 
>> is a huge win, this is suggesting taking some of the good bits :).
>> 
>> Does camel expose this as some sort of JMS API wrapper? I thought it was 
>> much more an EAI solution.
>> 
>> Cheers
>> Mike
> Camel does JMS transport: http://camel.apache.org/sjms.html
> Camel does AVRO: http://camel.apache.org/avro.html
> 
> 
>> Sent from my iPhone
>> 
> On 1 Jun 2017, at 15:18, Martyn Taylor  wrote:
> 
> On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish  
> wrote:
> 
>> On 06/01/2017 09:34 AM, Martyn Taylor wrote:
>> 
>>> On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish  
>>> wrote:
>>> 
>>> On 06/01/2017 08:51 AM, Martyn Taylor wrote:
>>> I get the use case for using JSON/XML, particularly for cross 
>>> language
>>> communication.
>>> 
>>> One way users get around this problem right now is just to serialize
>>> to/from XML/JSON at the client application level and just use JMS
>>> TextMessages to send the data. I guess the idea here to remove that
>>> complexity from the client application and into the client via these
>>> pluggable serializer 

Re: [DISCUSS] Custom Object Serialisation Support

[Timothy Bish]

On 06/01/2017 12:49 PM, Michael André Pearce wrote:

Not at all that's the point

Application code uses JMS Api. The serdes are just defined/declared into the 
connection factory typically the only part of the app exposed to any 
particulars about the broker implementation detail.

Yes we can do converter.convert(object) in code, this is just manual code in 
the app space.

  but like with kafka and I have to stress it's successfulness is that that 
converter is in it's api of the product. Which means a lot of companies reuse a 
few single implementations and a good eco system occurs like with schema 
registry (Eg we use confluents serdes we don't code out own)


Which is exactly what camel can solve and without starting down the 
slippery slop of packing the same data format conversions Camel can 
already handle into the Artemis code base as will happen as each user 
wants their own preferred data format.


Similar things were tried in the ActiveMQ 5.x code and abandoned over 
time so I'd like to avoid that if possible.


Anyway, I've raised my objection.





Sent from my iPhone


On 1 Jun 2017, at 17:39, Timothy Bish  wrote:


On 06/01/2017 12:19 PM, Michael André Pearce wrote:
Agreed it does as an EAI pattern or flow, But I have to code/define into 
Camel's dsl, it does JMS as much as our custom app code would it consumes the 
JMS api.

So you still need to code / define the serialization then and include that in 
you application which means the difference between some 
connection.setSerializationThing() vs 
producer.send(Converter.convert(payload)); so I don't see how that is a real 
value add to the JMS client.


What we propose here is just providing a clean way to define the JMS 
ObjectMessage internal serialisation. If Java serialisation isn't your cup of 
tea. (Which for many reasons isn't for us, and I'm sure it's similar for others)





On 1 Jun 2017, at 16:58, Timothy Bish  wrote:

On 06/01/2017 11:50 AM, Michael André Pearce wrote:
Really this is much more about how an ObjectMessage serializes the Object. As 
we have C++ clients etc that obviously won't be able to understand Java 
serialized object.

We use Avro and a schema repo for our dto transfer over the wire, it's been a 
real performance boost , and removed some core data issues, and really like to 
use it over the JMS land.

One can argue that you could manually code this that you serialize the data 
manually first and then just manually send a BytesMessage.

But I think taking some inspiration from other places where a serdes pattern is 
done has really helped (Kafka), from a corporation user approach wiring some 
prebuilt serdes into a factory is very easy, having duplicated code in many 
many apps leaves for issues, and implementation divergence.

The one downside of Kafka is it's lack of spec api, this is one big sell of 
artemis as it's JMS compliant. Coding against JMS api for Java estate is a huge 
win, this is suggesting taking some of the good bits :).

Does camel expose this as some sort of JMS API wrapper? I thought it was much 
more an EAI solution.

Cheers
Mike

Camel does JMS transport: http://camel.apache.org/sjms.html
Camel does AVRO: http://camel.apache.org/avro.html



Sent from my iPhone


On 1 Jun 2017, at 15:18, Martyn Taylor  wrote:

On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish  wrote:

On 06/01/2017 09:34 AM, Martyn Taylor wrote:


On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish  wrote:


On 06/01/2017 08:51 AM, Martyn Taylor wrote:
I get the use case for using JSON/XML, particularly for cross language
communication.

One way users get around this problem right now is just to serialize
to/from XML/JSON at the client application level and just use JMS
TextMessages to send the data. I guess the idea here to remove that
complexity from the client application and into the client via these
pluggable serializer objects?  Removing the serizliation logic out of
code
and into configuration.

Providing I've understood this properly, it seems like a good idea to
me.
   so +1.

This problem has already been solved via frameworks like Apache Camel,

putting such complexity into the JMS client is solving a problem that's
already been solved and in much more flexible and configurable ways.


Thanks Tim.  I am not a Camel expert in any shape or form, how much
additional complexity/configuration would be required to do something
similar with Camel?  My understanding of the proposal here is really just
to give control back to the user in terms of how their objects are
serialized.  I'd expect this to be pretty light weight, just allow a user
to configure a class to do the serialization.


Camel offers conversions for a number of data formats

Sure.   Though, one of the drivers (mentioned in this thread) for having
control over the de/serialization process was for performance.  Converting
to another format is going to obviously 

Re: [DISCUSS] Custom Object Serialisation Support

[Michael André Pearce]

Not at all that's the point

Application code uses JMS Api. The serdes are just defined/declared into the 
connection factory typically the only part of the app exposed to any 
particulars about the broker implementation detail.

Yes we can do converter.convert(object) in code, this is just manual code in 
the app space.

 but like with kafka and I have to stress it's successfulness is that that 
converter is in it's api of the product. Which means a lot of companies reuse a 
few single implementations and a good eco system occurs like with schema 
registry (Eg we use confluents serdes we don't code out own)



Sent from my iPhone

> On 1 Jun 2017, at 17:39, Timothy Bish  wrote:
> 
>> On 06/01/2017 12:19 PM, Michael André Pearce wrote:
>> Agreed it does as an EAI pattern or flow, But I have to code/define into 
>> Camel's dsl, it does JMS as much as our custom app code would it consumes 
>> the JMS api.
> 
> So you still need to code / define the serialization then and include that in 
> you application which means the difference between some 
> connection.setSerializationThing() vs 
> producer.send(Converter.convert(payload)); so I don't see how that is a real 
> value add to the JMS client.
> 
>> 
>> What we propose here is just providing a clean way to define the JMS 
>> ObjectMessage internal serialisation. If Java serialisation isn't your cup 
>> of tea. (Which for many reasons isn't for us, and I'm sure it's similar for 
>> others)
>> 
> 
> 
> 
 On 1 Jun 2017, at 16:58, Timothy Bish  wrote:
 
 On 06/01/2017 11:50 AM, Michael André Pearce wrote:
 Really this is much more about how an ObjectMessage serializes the Object. 
 As we have C++ clients etc that obviously won't be able to understand Java 
 serialized object.
 
 We use Avro and a schema repo for our dto transfer over the wire, it's 
 been a real performance boost , and removed some core data issues, and 
 really like to use it over the JMS land.
 
 One can argue that you could manually code this that you serialize the 
 data manually first and then just manually send a BytesMessage.
 
 But I think taking some inspiration from other places where a serdes 
 pattern is done has really helped (Kafka), from a corporation user 
 approach wiring some prebuilt serdes into a factory is very easy, having 
 duplicated code in many many apps leaves for issues, and implementation 
 divergence.
 
 The one downside of Kafka is it's lack of spec api, this is one big sell 
 of artemis as it's JMS compliant. Coding against JMS api for Java estate 
 is a huge win, this is suggesting taking some of the good bits :).
 
 Does camel expose this as some sort of JMS API wrapper? I thought it was 
 much more an EAI solution.
 
 Cheers
 Mike
>>> Camel does JMS transport: http://camel.apache.org/sjms.html
>>> Camel does AVRO: http://camel.apache.org/avro.html
>>> 
>>> 
 Sent from my iPhone
 
>>> On 1 Jun 2017, at 15:18, Martyn Taylor  wrote:
>>> 
>>> On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish  
>>> wrote:
>>> 
>>> On 06/01/2017 09:34 AM, Martyn Taylor wrote:
>>> 
 On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish  
 wrote:
 
> On 06/01/2017 08:51 AM, Martyn Taylor wrote:
> I get the use case for using JSON/XML, particularly for cross language
> communication.
> 
> One way users get around this problem right now is just to serialize
> to/from XML/JSON at the client application level and just use JMS
> TextMessages to send the data. I guess the idea here to remove that
> complexity from the client application and into the client via these
> pluggable serializer objects?  Removing the serizliation logic out of
> code
> and into configuration.
> 
> Providing I've understood this properly, it seems like a good idea to
> me.
>   so +1.
> 
> This problem has already been solved via frameworks like Apache Camel,
 putting such complexity into the JMS client is solving a problem that's
 already been solved and in much more flexible and configurable ways.
 
>>> Thanks Tim.  I am not a Camel expert in any shape or form, how much
>>> additional complexity/configuration would be required to do something
>>> similar with Camel?  My understanding of the proposal here is really 
>>> just
>>> to give control back to the user in terms of how their objects are
>>> serialized.  I'd expect this to be pretty light weight, just allow a 
>>> user
>>> to configure a class to do the serialization.
>>> 
>> Camel offers conversions for a number of data formats
> Sure.   Though, one of the drivers (mentioned in this thread) for 

Re: [DISCUSS] Custom Object Serialisation Support

[Timothy Bish]

On 06/01/2017 12:19 PM, Michael André Pearce wrote:

Agreed it does as an EAI pattern or flow, But I have to code/define into 
Camel's dsl, it does JMS as much as our custom app code would it consumes the 
JMS api.


So you still need to code / define the serialization then and include 
that in you application which means the difference between some 
connection.setSerializationThing() vs 
producer.send(Converter.convert(payload));  so I don't see how that is a 
real value add to the JMS client.




What we propose here is just providing a clean way to define the JMS 
ObjectMessage internal serialisation. If Java serialisation isn't your cup of 
tea. (Which for many reasons isn't for us, and I'm sure it's similar for others)






On 1 Jun 2017, at 16:58, Timothy Bish  wrote:


On 06/01/2017 11:50 AM, Michael André Pearce wrote:
Really this is much more about how an ObjectMessage serializes the Object. As 
we have C++ clients etc that obviously won't be able to understand Java 
serialized object.

We use Avro and a schema repo for our dto transfer over the wire, it's been a 
real performance boost , and removed some core data issues, and really like to 
use it over the JMS land.

One can argue that you could manually code this that you serialize the data 
manually first and then just manually send a BytesMessage.

But I think taking some inspiration from other places where a serdes pattern is 
done has really helped (Kafka), from a corporation user approach wiring some 
prebuilt serdes into a factory is very easy, having duplicated code in many 
many apps leaves for issues, and implementation divergence.

The one downside of Kafka is it's lack of spec api, this is one big sell of 
artemis as it's JMS compliant. Coding against JMS api for Java estate is a huge 
win, this is suggesting taking some of the good bits :).

Does camel expose this as some sort of JMS API wrapper? I thought it was much 
more an EAI solution.

Cheers
Mike

Camel does JMS transport: http://camel.apache.org/sjms.html
Camel does AVRO: http://camel.apache.org/avro.html



Sent from my iPhone


On 1 Jun 2017, at 15:18, Martyn Taylor  wrote:


On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish  wrote:

On 06/01/2017 09:34 AM, Martyn Taylor wrote:

On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish  wrote:


On 06/01/2017 08:51 AM, Martyn Taylor wrote:
I get the use case for using JSON/XML, particularly for cross language

communication.

One way users get around this problem right now is just to serialize
to/from XML/JSON at the client application level and just use JMS
TextMessages to send the data. I guess the idea here to remove that
complexity from the client application and into the client via these
pluggable serializer objects?  Removing the serizliation logic out of
code
and into configuration.

Providing I've understood this properly, it seems like a good idea to
me.
   so +1.

This problem has already been solved via frameworks like Apache Camel,

putting such complexity into the JMS client is solving a problem that's
already been solved and in much more flexible and configurable ways.


Thanks Tim.  I am not a Camel expert in any shape or form, how much
additional complexity/configuration would be required to do something
similar with Camel?  My understanding of the proposal here is really just
to give control back to the user in terms of how their objects are
serialized.  I'd expect this to be pretty light weight, just allow a user
to configure a class to do the serialization.


Camel offers conversions for a number of data formats

Sure.   Though, one of the drivers (mentioned in this thread) for having
control over the de/serialization process was for performance.  Converting
to another format is going to obviously make this much worse.


as well as routing amongst numerous protocols, have a look at the
supported data formats page: http://camel.apache.org/data-format.html and
the transports http://camel.apache.org/transport.html
This doesn't seem to be doing much more for the user than moving the work
they need to do around,

Well, it abstracts the de/serialization process out of application code.


they still have to implement or configure the mechanics of the
transformation of the data format to the appropriate JMS message type and
back again.  Even if you bake in something to the client to handle some
common formats you will quickly find that it doesn't meet everyone's needs
and you'll end up implementing a poor mans Camel inside a JMS API
restricted client which seems less than ideal.

I agree reinventing the wheel (badly) is not a good idea.  So, if Camel is
able to provide us with a solution to the problem, that addresses the
issues outlined here.  Then, we should certainly look into it.

Cheers.




On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce <

michael.andre.pea...@me.com> wrote:

I think i might be getting the problem, use case you want 

Re: [DISCUSS] Custom Object Serialisation Support

[Michael André Pearce]

Agreed it does as an EAI pattern or flow, But I have to code/define into 
Camel's dsl, it does JMS as much as our custom app code would it consumes the 
JMS api. 


What we propose here is just providing a clean way to define the JMS 
ObjectMessage internal serialisation. If Java serialisation isn't your cup of 
tea. (Which for many reasons isn't for us, and I'm sure it's similar for others)


> On 1 Jun 2017, at 16:58, Timothy Bish  wrote:
> 
>> On 06/01/2017 11:50 AM, Michael André Pearce wrote:
>> Really this is much more about how an ObjectMessage serializes the Object. 
>> As we have C++ clients etc that obviously won't be able to understand Java 
>> serialized object.
>> 
>> We use Avro and a schema repo for our dto transfer over the wire, it's been 
>> a real performance boost , and removed some core data issues, and really 
>> like to use it over the JMS land.
>> 
>> One can argue that you could manually code this that you serialize the data 
>> manually first and then just manually send a BytesMessage.
>> 
>> But I think taking some inspiration from other places where a serdes pattern 
>> is done has really helped (Kafka), from a corporation user approach wiring 
>> some prebuilt serdes into a factory is very easy, having duplicated code in 
>> many many apps leaves for issues, and implementation divergence.
>> 
>> The one downside of Kafka is it's lack of spec api, this is one big sell of 
>> artemis as it's JMS compliant. Coding against JMS api for Java estate is a 
>> huge win, this is suggesting taking some of the good bits :).
>> 
>> Does camel expose this as some sort of JMS API wrapper? I thought it was 
>> much more an EAI solution.
>> 
>> Cheers
>> Mike
> 
> Camel does JMS transport: http://camel.apache.org/sjms.html
> Camel does AVRO: http://camel.apache.org/avro.html
> 
> 
>> 
>> Sent from my iPhone
>> 
 On 1 Jun 2017, at 15:18, Martyn Taylor  wrote:
 
> On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish  wrote:
> 
> On 06/01/2017 09:34 AM, Martyn Taylor wrote:
> 
> On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish  wrote:
> 
>> On 06/01/2017 08:51 AM, Martyn Taylor wrote:
>> I get the use case for using JSON/XML, particularly for cross language
>>> communication.
>>> 
>>> One way users get around this problem right now is just to serialize
>>> to/from XML/JSON at the client application level and just use JMS
>>> TextMessages to send the data. I guess the idea here to remove that
>>> complexity from the client application and into the client via these
>>> pluggable serializer objects?  Removing the serizliation logic out of
>>> code
>>> and into configuration.
>>> 
>>> Providing I've understood this properly, it seems like a good idea to
>>> me.
>>>   so +1.
>>> 
>>> This problem has already been solved via frameworks like Apache Camel,
>> putting such complexity into the JMS client is solving a problem that's
>> already been solved and in much more flexible and configurable ways.
>> 
> Thanks Tim.  I am not a Camel expert in any shape or form, how much
> additional complexity/configuration would be required to do something
> similar with Camel?  My understanding of the proposal here is really just
> to give control back to the user in terms of how their objects are
> serialized.  I'd expect this to be pretty light weight, just allow a user
> to configure a class to do the serialization.
> 
 Camel offers conversions for a number of data formats
>>> Sure.   Though, one of the drivers (mentioned in this thread) for having
>>> control over the de/serialization process was for performance.  Converting
>>> to another format is going to obviously make this much worse.
>>> 
 as well as routing amongst numerous protocols, have a look at the
 supported data formats page: http://camel.apache.org/data-format.html and
 the transports http://camel.apache.org/transport.html
>>> 
 This doesn't seem to be doing much more for the user than moving the work
 they need to do around,
>>> Well, it abstracts the de/serialization process out of application code.
>>> 
 they still have to implement or configure the mechanics of the
 transformation of the data format to the appropriate JMS message type and
 back again.  Even if you bake in something to the client to handle some
 common formats you will quickly find that it doesn't meet everyone's needs
 and you'll end up implementing a poor mans Camel inside a JMS API
 restricted client which seems less than ideal.
>>> I agree reinventing the wheel (badly) is not a good idea.  So, if Camel is
>>> able to provide us with a solution to the problem, that addresses the
>>> issues outlined here.  Then, we should certainly look into it.
>>> 
>>> Cheers.
>>> 
 
 
> On Thu, Jun 1, 2017 at 7:44 AM, 

Re: [DISCUSS] Custom Object Serialisation Support

[Timothy Bish]

On 06/01/2017 11:50 AM, Michael André Pearce wrote:

Really this is much more about how an ObjectMessage serializes the Object. As 
we have C++ clients etc that obviously won't be able to understand Java 
serialized object.

We use Avro and a schema repo for our dto transfer over the wire, it's been a 
real performance boost , and removed some core data issues, and really like to 
use it over the JMS land.

One can argue that you could manually code this that you serialize the data 
manually first and then just manually send a BytesMessage.

But I think taking some inspiration from other places where a serdes pattern is 
done has really helped (Kafka), from a corporation user approach wiring some 
prebuilt serdes into a factory is very easy, having duplicated code in many 
many apps leaves for issues, and implementation divergence.

The one downside of Kafka is it's lack of spec api, this is one big sell of 
artemis as it's JMS compliant. Coding against JMS api for Java estate is a huge 
win, this is suggesting taking some of the good bits :).

Does camel expose this as some sort of JMS API wrapper? I thought it was much 
more an EAI solution.

Cheers
Mike


Camel does JMS transport: http://camel.apache.org/sjms.html
Camel does AVRO: http://camel.apache.org/avro.html




Sent from my iPhone


On 1 Jun 2017, at 15:18, Martyn Taylor  wrote:


On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish  wrote:


On 06/01/2017 09:34 AM, Martyn Taylor wrote:

On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish  wrote:

On 06/01/2017 08:51 AM, Martyn Taylor wrote:

I get the use case for using JSON/XML, particularly for cross language

communication.

One way users get around this problem right now is just to serialize
to/from XML/JSON at the client application level and just use JMS
TextMessages to send the data. I guess the idea here to remove that
complexity from the client application and into the client via these
pluggable serializer objects?  Removing the serizliation logic out of
code
and into configuration.

Providing I've understood this properly, it seems like a good idea to
me.
   so +1.

This problem has already been solved via frameworks like Apache Camel,

putting such complexity into the JMS client is solving a problem that's
already been solved and in much more flexible and configurable ways.


Thanks Tim.  I am not a Camel expert in any shape or form, how much
additional complexity/configuration would be required to do something
similar with Camel?  My understanding of the proposal here is really just
to give control back to the user in terms of how their objects are
serialized.  I'd expect this to be pretty light weight, just allow a user
to configure a class to do the serialization.


Camel offers conversions for a number of data formats

Sure.   Though, one of the drivers (mentioned in this thread) for having
control over the de/serialization process was for performance.  Converting
to another format is going to obviously make this much worse.


as well as routing amongst numerous protocols, have a look at the
supported data formats page: http://camel.apache.org/data-format.html and
the transports http://camel.apache.org/transport.html



This doesn't seem to be doing much more for the user than moving the work
they need to do around,

Well, it abstracts the de/serialization process out of application code.


they still have to implement or configure the mechanics of the
transformation of the data format to the appropriate JMS message type and
back again.  Even if you bake in something to the client to handle some
common formats you will quickly find that it doesn't meet everyone's needs
and you'll end up implementing a poor mans Camel inside a JMS API
restricted client which seems less than ideal.

I agree reinventing the wheel (badly) is not a good idea.  So, if Camel is
able to provide us with a solution to the problem, that addresses the
issues outlined here.  Then, we should certainly look into it.

Cheers.





On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce <

michael.andre.pea...@me.com> wrote:

I think i might be getting the problem, use case you want to go for,
which


is to possible serialise to JSON or XML, because they're supported well
in
other languages like c++, which won't read a java serialised object,
and
say for XML you generate objects via an XSD which by default aren't
serialisable, so you cannot simply add Serializable to the object, as
its
generated at build.

Is this the problem we need to solve? If so:

To get around this normally the tools that generate objects for
serialisation from schema such as XSD do support a way to toggle or
change
the generation slightly for some common use cases.

In case of XSD, where using jaxb it would be to add something like the
below to jaxb global bindings:









like wise if you are generating POJO's from a jsonschema using for say
the
tool jsonschema2pojo  there is a toggle in the 

Re: [DISCUSS] Custom Object Serialisation Support

[Michael André Pearce]

Really this is much more about how an ObjectMessage serializes the Object. As 
we have C++ clients etc that obviously won't be able to understand Java 
serialized object.

We use Avro and a schema repo for our dto transfer over the wire, it's been a 
real performance boost , and removed some core data issues, and really like to 
use it over the JMS land.

One can argue that you could manually code this that you serialize the data 
manually first and then just manually send a BytesMessage. 

But I think taking some inspiration from other places where a serdes pattern is 
done has really helped (Kafka), from a corporation user approach wiring some 
prebuilt serdes into a factory is very easy, having duplicated code in many 
many apps leaves for issues, and implementation divergence.

The one downside of Kafka is it's lack of spec api, this is one big sell of 
artemis as it's JMS compliant. Coding against JMS api for Java estate is a huge 
win, this is suggesting taking some of the good bits :).

Does camel expose this as some sort of JMS API wrapper? I thought it was much 
more an EAI solution.

Cheers
Mike

Sent from my iPhone

> On 1 Jun 2017, at 15:18, Martyn Taylor  wrote:
> 
>> On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish  wrote:
>> 
>>> On 06/01/2017 09:34 AM, Martyn Taylor wrote:
>>> 
>>> On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish  wrote:
>>> 
>>> On 06/01/2017 08:51 AM, Martyn Taylor wrote:
 
 I get the use case for using JSON/XML, particularly for cross language
> communication.
> 
> One way users get around this problem right now is just to serialize
> to/from XML/JSON at the client application level and just use JMS
> TextMessages to send the data. I guess the idea here to remove that
> complexity from the client application and into the client via these
> pluggable serializer objects?  Removing the serizliation logic out of
> code
> and into configuration.
> 
> Providing I've understood this properly, it seems like a good idea to
> me.
>   so +1.
> 
> This problem has already been solved via frameworks like Apache Camel,
 putting such complexity into the JMS client is solving a problem that's
 already been solved and in much more flexible and configurable ways.
 
>>> 
>>> Thanks Tim.  I am not a Camel expert in any shape or form, how much
>>> additional complexity/configuration would be required to do something
>>> similar with Camel?  My understanding of the proposal here is really just
>>> to give control back to the user in terms of how their objects are
>>> serialized.  I'd expect this to be pretty light weight, just allow a user
>>> to configure a class to do the serialization.
>>> 
>> 
>> Camel offers conversions for a number of data formats
> 
> Sure.   Though, one of the drivers (mentioned in this thread) for having
> control over the de/serialization process was for performance.  Converting
> to another format is going to obviously make this much worse.
> 
>> as well as routing amongst numerous protocols, have a look at the
>> supported data formats page: http://camel.apache.org/data-format.html and
>> the transports http://camel.apache.org/transport.html
> 
> 
>> 
>> This doesn't seem to be doing much more for the user than moving the work
>> they need to do around,
> 
> Well, it abstracts the de/serialization process out of application code.
> 
>> they still have to implement or configure the mechanics of the
>> transformation of the data format to the appropriate JMS message type and
>> back again.  Even if you bake in something to the client to handle some
>> common formats you will quickly find that it doesn't meet everyone's needs
>> and you'll end up implementing a poor mans Camel inside a JMS API
>> restricted client which seems less than ideal.
> 
> I agree reinventing the wheel (badly) is not a good idea.  So, if Camel is
> able to provide us with a solution to the problem, that addresses the
> issues outlined here.  Then, we should certainly look into it.
> 
> Cheers.
> 
>> 
>> 
>> 
>>> 
>>> On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
> 
> I think i might be getting the problem, use case you want to go for,
> which
> 
>> is to possible serialise to JSON or XML, because they're supported well
>> in
>> other languages like c++, which won't read a java serialised object,
>> and
>> say for XML you generate objects via an XSD which by default aren't
>> serialisable, so you cannot simply add Serializable to the object, as
>> its
>> generated at build.
>> 
>> Is this the problem we need to solve? If so:
>> 
>> To get around this normally the tools that generate objects for
>> serialisation from schema such as XSD do support a way to toggle or
>> change
>> the generation slightly for some common use cases.
>> 

[GitHub] activemq-artemis pull request #1310: [ARTEMIS-861] Artemis 1.5 compilation f...

[dudaerich]

Github user dudaerich closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1310


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis issue #1312: ARTEMIS-1199 JDBCSequentialFile prints log to ...

[dudaerich]

Github user dudaerich commented on the issue:

https://github.com/apache/activemq-artemis/pull/1312
  
@clebertsuconic Closing. Thanks.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #1312: ARTEMIS-1199 JDBCSequentialFile prints ...

[dudaerich]

Github user dudaerich closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1312


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis issue #1310: [ARTEMIS-861] Artemis 1.5 compilation fails wi...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1310
  
close it please. merged with a rebase.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis issue #1312: ARTEMIS-1199 JDBCSequentialFile prints log to ...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1312
  
@dudaerich merged with a rebase (commit ID changed). close it please.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #1311: ARTEMIS-1187 Incompatible version when ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1311


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[ANNOUNCE] Call for New ActiveMQ Logo

[Clebert Suconic]

The Apache ActiveMQ logo was created a few years ago. While the
project continues to evolve, the logo needs to be updated to reflect
current ActiveMQ technology. So, the PMC has discussed making a “Call
For Entry” where you can submit a new ActiveMQ Logo.

TL;DR: Make your Apache ActiveMQ logo submissions as a PR with your
files towards in this folder:
https://github.com/apache/activemq/tree/master/docs/img


For more details, look at the blog entry:
https://blogs.apache.org/activemq/entry/apache-activemq-call-for-logo



And help spread the word, tweet about it.

[GitHub] activemq-artemis pull request #1311: ARTEMIS-1187 Incompatible version when ...

[TomasHofman]

Github user TomasHofman commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1311#discussion_r119632869
  
--- Diff: 
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/ActiveMQSessionContext.java
 ---
@@ -643,7 +643,7 @@ protected CreateSessionMessage newCreateSession(String 
username,
boolean autoCommitSends,
boolean autoCommitAcks,
boolean preAcknowledge) 
{
-  return new CreateSessionMessage(name, sessionChannel.getID(), 
VersionLoader.getVersion().getIncrementingVersion(), username, password, 
minLargeMessageSize, xa, autoCommitSends, autoCommitAcks, preAcknowledge, 
confirmationWindow, null);
--- End diff --

OK, 1.x and 1.5.5-x PRs should be good now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq pull request #238: add ClientIdFilterDispatchPolicy and testcase

[kimmking]

GitHub user kimmking opened a pull request:

https://github.com/apache/activemq/pull/238

add ClientIdFilterDispatchPolicy and testcase

ClientIdFilterDispatchPolicy dispatches messages in a topic to a given 
client. Then the message with a "PTP_CLIENTID" property, can be received by a 
mqtt client with the same clientId.

Many developer have been insterested to use this feature:
http://blog.csdn.net/kimmking/article/details/17449019

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kimmking/activemq trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq/pull/238.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #238


commit 8d6163bfb3f43db0c9099cc4c0f0456f6b648ad8
Author: kimmking 
Date:   2017-05-31T16:20:13Z

Merge pull request #1 from apache/master

merge new version

commit a1f600775c68311ff14d6b590ea606804a9c59e4
Author: kimmking 
Date:   2017-06-01T14:33:56Z

ClientIdFilterDispatchPolicy dispatches messages in a topic to a given 
client. Then the message with a PTP_CLIENTID property, can be received by a 
mqtt client with the same clientId.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] New logo discussion

[Clebert Suconic]

and it's live: 
https://blogs.apache.org/activemq/entry/apache-activemq-call-for-logo


I will send an [CALL FOR ENTRY] thread shortly, copying users and dev list :)


I also tweeted about it.. if you could either retweet my tweet... or
make your own... just want to spread the word about this :)

On Mon, May 29, 2017 at 6:06 AM, Bennet Schulz  wrote:
> +1
>
> maybe we could get in contact with Claus Ibsen. He’s doing the same for 
> Apache Camel.
>
>> Am 25.05.2017 um 23:30 schrieb artnaseef :
>>
>> Yeah, feels like 1 month is a good start.  Perhaps allow it to draw out a
>> longer (not indefinitely) if there's continued, constructive activity.
>>
>>
>> On Thu, May 25, 2017 at 7:37 AM, clebertsuconic [via ActiveMQ] <
>> ml+s2283324n4726567...@n4.nabble.com> wrote:
>>
>>> How long should I keep the submission open before we call for a Vote.
>>> I thought about 1 month? It's summer, and perhaps that will attract
>>> students.
>>>
>>> On Thu, May 25, 2017 at 10:49 AM, Clebert Suconic
>>> <[hidden email] >
>>> wrote:
>>>
 Just so as a heads up.. I will post a blog about the submission next
 week after the US Holiday.

 On Thu, May 25, 2017 at 9:23 AM, Clebert Suconic
 <[hidden email] >
>>> wrote:
> On Thu, May 25, 2017 at 9:16 AM, Justin Bertram <[hidden email]
>>> > wrote:
>>> Aspect ratio - square or banner?
>>
>> I think we would need both - a banner for the top of web pages plus a
>>> square icon for other purposes.  Here [1] is an example submission from the
>>> Camel process which Clebert linked to at the beginning of this thread.
>
> If the submission is also including an abstract image.. a square image
> would be great... yeah...
>
>
> @Michael Pearce: I loved the abstraction for MQ..
> I wouldn't put the 6 on the Logo though.. just for practical reasons..
> (What to do when there's a 7?)
>
>
>>
>>
>> Justin
>>
>> [1] https://github.com/apache/camel/pull/1556/commits/
>>> f28ff8739cc895314a95ebec323c075c38a08813
>>
>> - Original Message -
>> From: "Timothy Nodine" <[hidden email]
>>> >
>> To: [hidden email]
>>> 
>> Sent: Wednesday, May 24, 2017 4:20:08 PM
>> Subject: Re: [DISCUSS] New logo discussion
>>
>> Aspect ratio - square or banner?
>>
>> Clebert Suconic wrote:
>>> I talked to the PMC private list and we have consensus that starting
>>> this would be a good idea.
>>>
>>> Before we start a call for logo,  We need to define the requirements
>>> for the logo and what we will ask:
>>>
>>> I'm thinking of defining these as requirements:
>>>
>>> - vector based file (.svg) and .png images
>>> - an abstract image representing ActiveMQ would be awesome (we don't
>>> have one)
>>> - (in case of an abstract image, it would be nice to have the image
>>> and the name separated, like camel)
>>> - minimalistic and modern design.
>>>
>>>
>>>
>>> thoughts?
>>>
>>
>
>
>
> --
> Clebert Suconic



 --
 Clebert Suconic
>>>
>>>
>>>
>>> --
>>> Clebert Suconic
>>>
>>>
>>> --
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>> http://activemq.2283324.n4.nabble.com/DISCUSS-New-logo-
>>> discussion-tp4726454p4726567.html
>>> To start a new topic under ActiveMQ - Dev, email
>>> ml+s2283324n2368404...@n4.nabble.com
>>> To unsubscribe from ActiveMQ - Dev, click here
>>> 
>>> .
>>> NAML
>>> 
>>>
>>
>>
>>
>>
>> --
>> View this message in context: 
>> http://activemq.2283324.n4.nabble.com/DISCUSS-New-logo-discussion-tp4726454p4726594.html
>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>



-- 
Clebert Suconic

Re: [DISCUSS] Custom Object Serialisation Support

[Martyn Taylor]

On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish  wrote:

> On 06/01/2017 09:34 AM, Martyn Taylor wrote:
>
>> On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish  wrote:
>>
>> On 06/01/2017 08:51 AM, Martyn Taylor wrote:
>>>
>>> I get the use case for using JSON/XML, particularly for cross language
 communication.

 One way users get around this problem right now is just to serialize
 to/from XML/JSON at the client application level and just use JMS
 TextMessages to send the data. I guess the idea here to remove that
 complexity from the client application and into the client via these
 pluggable serializer objects?  Removing the serizliation logic out of
 code
 and into configuration.

 Providing I've understood this properly, it seems like a good idea to
 me.
so +1.

 This problem has already been solved via frameworks like Apache Camel,
>>> putting such complexity into the JMS client is solving a problem that's
>>> already been solved and in much more flexible and configurable ways.
>>>
>>
>> Thanks Tim.  I am not a Camel expert in any shape or form, how much
>> additional complexity/configuration would be required to do something
>> similar with Camel?  My understanding of the proposal here is really just
>> to give control back to the user in terms of how their objects are
>> serialized.  I'd expect this to be pretty light weight, just allow a user
>> to configure a class to do the serialization.
>>
>
> Camel offers conversions for a number of data formats

Sure.   Though, one of the drivers (mentioned in this thread) for having
control over the de/serialization process was for performance.  Converting
to another format is going to obviously make this much worse.

> as well as routing amongst numerous protocols, have a look at the
> supported data formats page: http://camel.apache.org/data-format.html and
> the transports http://camel.apache.org/transport.html


>
> This doesn't seem to be doing much more for the user than moving the work
> they need to do around,

Well, it abstracts the de/serialization process out of application code.

> they still have to implement or configure the mechanics of the
> transformation of the data format to the appropriate JMS message type and
> back again.  Even if you bake in something to the client to handle some
> common formats you will quickly find that it doesn't meet everyone's needs
> and you'll end up implementing a poor mans Camel inside a JMS API
> restricted client which seems less than ideal.

I agree reinventing the wheel (badly) is not a good idea.  So, if Camel is
able to provide us with a solution to the problem, that addresses the
issues outlined here.  Then, we should certainly look into it.

Cheers.

>
>
>
>>
>> On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce <
 michael.andre.pea...@me.com> wrote:

 I think i might be getting the problem, use case you want to go for,
 which

> is to possible serialise to JSON or XML, because they're supported well
> in
> other languages like c++, which won't read a java serialised object,
> and
> say for XML you generate objects via an XSD which by default aren't
> serialisable, so you cannot simply add Serializable to the object, as
> its
> generated at build.
>
> Is this the problem we need to solve? If so:
>
> To get around this normally the tools that generate objects for
> serialisation from schema such as XSD do support a way to toggle or
> change
> the generation slightly for some common use cases.
>
> In case of XSD, where using jaxb it would be to add something like the
> below to jaxb global bindings:
>
> 
> 
> 
> 
> 
> 
> 
>
> like wise if you are generating POJO's from a jsonschema using for say
> the
> tool jsonschema2pojo  there is a toggle in the maven plugin
> serializable
> which you can switch to true.
>
> Obviously if you hand crank your DTO Pojo's then it's a case of simply
> add
> implement  Serializable to the class.
>
> Cheers
> Mike
>
> Sent from my iPhone
>
> On 1 Jun 2017, at 06:57, Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
>
> we could but then it wouldn't work via jms api. Typically if using jms
>>
>> the only custom or specific broker object is the connection factory
> the
> rest you code to Jms.
>
>
>> Sent from my iPhone
>>
>> On 1 Jun 2017, at 04:10, Clebert Suconic 
>> wrote:
>> On Wed, May 31, 2017 at 10:47 PM Michael André Pearce <
>>
>>> michael.andre.pea...@me.com> wrote:
>>>
>>> Jms api dictates class set in object message to be serializable.
>>> We could make an extension. It could be an extra message this
>>> actually.
>>>
>>>
>>> On 31 May 2017, at 

Re: [DISCUSS] Custom Object Serialisation Support

[Timothy Bish]

On 06/01/2017 09:34 AM, Martyn Taylor wrote:

On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish  wrote:


On 06/01/2017 08:51 AM, Martyn Taylor wrote:


I get the use case for using JSON/XML, particularly for cross language
communication.

One way users get around this problem right now is just to serialize
to/from XML/JSON at the client application level and just use JMS
TextMessages to send the data. I guess the idea here to remove that
complexity from the client application and into the client via these
pluggable serializer objects?  Removing the serizliation logic out of code
and into configuration.

Providing I've understood this properly, it seems like a good idea to me.
   so +1.


This problem has already been solved via frameworks like Apache Camel,
putting such complexity into the JMS client is solving a problem that's
already been solved and in much more flexible and configurable ways.


Thanks Tim.  I am not a Camel expert in any shape or form, how much
additional complexity/configuration would be required to do something
similar with Camel?  My understanding of the proposal here is really just
to give control back to the user in terms of how their objects are
serialized.  I'd expect this to be pretty light weight, just allow a user
to configure a class to do the serialization.


Camel offers conversions for a number of data formats as well as routing 
amongst numerous protocols, have a look at the supported data formats 
page: http://camel.apache.org/data-format.html and the transports 
http://camel.apache.org/transport.html


This doesn't seem to be doing much more for the user than moving the 
work they need to do around, they still have to implement or configure 
the mechanics of the transformation of the data format to the 
appropriate JMS message type and back again.  Even if you bake in 
something to the client to handle some common formats you will quickly 
find that it doesn't meet everyone's needs and you'll end up 
implementing a poor mans Camel inside a JMS API restricted client which 
seems less than ideal.






On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

I think i might be getting the problem, use case you want to go for, which

is to possible serialise to JSON or XML, because they're supported well
in
other languages like c++, which won't read a java serialised object, and
say for XML you generate objects via an XSD which by default aren't
serialisable, so you cannot simply add Serializable to the object, as its
generated at build.

Is this the problem we need to solve? If so:

To get around this normally the tools that generate objects for
serialisation from schema such as XSD do support a way to toggle or
change
the generation slightly for some common use cases.

In case of XSD, where using jaxb it would be to add something like the
below to jaxb global bindings:









like wise if you are generating POJO's from a jsonschema using for say
the
tool jsonschema2pojo  there is a toggle in the maven plugin serializable
which you can switch to true.

Obviously if you hand crank your DTO Pojo's then it's a case of simply
add
implement  Serializable to the class.

Cheers
Mike

Sent from my iPhone

On 1 Jun 2017, at 06:57, Michael André Pearce <
michael.andre.pea...@me.com> wrote:


we could but then it wouldn't work via jms api. Typically if using jms


the only custom or specific broker object is the connection factory the
rest you code to Jms.



Sent from my iPhone

On 1 Jun 2017, at 04:10, Clebert Suconic 
wrote:
On Wed, May 31, 2017 at 10:47 PM Michael André Pearce <

michael.andre.pea...@me.com> wrote:

Jms api dictates class set in object message to be serializable.
We could make an extension. It could be an extra message this actually.



On 31 May 2017, at 22:37, Timothy Nodine 
wrote:

Should the interface require the underlying class to be Serializable?

One use case might be to provide serialization to classes that aren't
natively serializable.



Michael André Pearce wrote:


To help discussion,
A very very basic implementation just to simulate the idea.


https://github.com/michaelandrepearce/activemq-artemis/tree/

CustomSerialisation

<

https://github.com/michaelandrepearce/activemq-artemis/tree/


CustomSerialisation

n.b. doesn’t fully compile is just pseudo impl, nor doesn’t include

bits as discussed below like map/change type to a byte message for

compatibility, nor media type idea.


Cheers

Mike

--

Clebert Suconic


--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/




--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [DISCUSS] Custom Object Serialisation Support

[Martyn Taylor]

On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish  wrote:

> On 06/01/2017 08:51 AM, Martyn Taylor wrote:
>
>> I get the use case for using JSON/XML, particularly for cross language
>> communication.
>>
>> One way users get around this problem right now is just to serialize
>> to/from XML/JSON at the client application level and just use JMS
>> TextMessages to send the data. I guess the idea here to remove that
>> complexity from the client application and into the client via these
>> pluggable serializer objects?  Removing the serizliation logic out of code
>> and into configuration.
>>
>> Providing I've understood this properly, it seems like a good idea to me.
>>   so +1.
>>
>
> This problem has already been solved via frameworks like Apache Camel,
> putting such complexity into the JMS client is solving a problem that's
> already been solved and in much more flexible and configurable ways.


Thanks Tim.  I am not a Camel expert in any shape or form, how much
additional complexity/configuration would be required to do something
similar with Camel?  My understanding of the proposal here is really just
to give control back to the user in terms of how their objects are
serialized.  I'd expect this to be pretty light weight, just allow a user
to configure a class to do the serialization.


>
>> On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce <
>> michael.andre.pea...@me.com> wrote:
>>
>> I think i might be getting the problem, use case you want to go for, which
>>> is to possible serialise to JSON or XML, because they're supported well
>>> in
>>> other languages like c++, which won't read a java serialised object, and
>>> say for XML you generate objects via an XSD which by default aren't
>>> serialisable, so you cannot simply add Serializable to the object, as its
>>> generated at build.
>>>
>>> Is this the problem we need to solve? If so:
>>>
>>> To get around this normally the tools that generate objects for
>>> serialisation from schema such as XSD do support a way to toggle or
>>> change
>>> the generation slightly for some common use cases.
>>>
>>> In case of XSD, where using jaxb it would be to add something like the
>>> below to jaxb global bindings:
>>>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>> like wise if you are generating POJO's from a jsonschema using for say
>>> the
>>> tool jsonschema2pojo  there is a toggle in the maven plugin serializable
>>> which you can switch to true.
>>>
>>> Obviously if you hand crank your DTO Pojo's then it's a case of simply
>>> add
>>> implement  Serializable to the class.
>>>
>>> Cheers
>>> Mike
>>>
>>> Sent from my iPhone
>>>
>>> On 1 Jun 2017, at 06:57, Michael André Pearce <

>>> michael.andre.pea...@me.com> wrote:
>>>
 we could but then it wouldn't work via jms api. Typically if using jms

>>> the only custom or specific broker object is the connection factory the
>>> rest you code to Jms.
>>>


 Sent from my iPhone

 On 1 Jun 2017, at 04:10, Clebert Suconic 
>
 wrote:
>>>
 On Wed, May 31, 2017 at 10:47 PM Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
>
> Jms api dictates class set in object message to be serializable.
>>
>
> We could make an extension. It could be an extra message this actually.
>
>
>>
>> On 31 May 2017, at 22:37, Timothy Nodine 
>>>
>> wrote:
>>>
 Should the interface require the underlying class to be Serializable?
>>>
>> One use case might be to provide serialization to classes that aren't
>> natively serializable.
>>
>>>
>>>
>>> Michael André Pearce wrote:
>>>
 To help discussion,
 A very very basic implementation just to simulate the idea.

>>> https://github.com/michaelandrepearce/activemq-artemis/tree/
>>
> CustomSerialisation
>>>
 <
>> https://github.com/michaelandrepearce/activemq-artemis/tree/
>>
> CustomSerialisation
>>>
 n.b. doesn’t fully compile is just pseudo impl, nor doesn’t include

>>> bits as discussed below like map/change type to a byte message for
>> compatibility, nor media type idea.
>>
>>> Cheers
 Mike

 --
> Clebert Suconic
>

>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [DISCUSS] Custom Object Serialisation Support

[Timothy Bish]

On 06/01/2017 08:51 AM, Martyn Taylor wrote:

I get the use case for using JSON/XML, particularly for cross language
communication.

One way users get around this problem right now is just to serialize
to/from XML/JSON at the client application level and just use JMS
TextMessages to send the data. I guess the idea here to remove that
complexity from the client application and into the client via these
pluggable serializer objects?  Removing the serizliation logic out of code
and into configuration.

Providing I've understood this properly, it seems like a good idea to me.
  so +1.


This problem has already been solved via frameworks like Apache Camel, 
putting such complexity into the JMS client is solving a problem that's 
already been solved and in much more flexible and configurable ways.


On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:


I think i might be getting the problem, use case you want to go for, which
is to possible serialise to JSON or XML, because they're supported well in
other languages like c++, which won't read a java serialised object, and
say for XML you generate objects via an XSD which by default aren't
serialisable, so you cannot simply add Serializable to the object, as its
generated at build.

Is this the problem we need to solve? If so:

To get around this normally the tools that generate objects for
serialisation from schema such as XSD do support a way to toggle or change
the generation slightly for some common use cases.

In case of XSD, where using jaxb it would be to add something like the
below to jaxb global bindings:









like wise if you are generating POJO's from a jsonschema using for say the
tool jsonschema2pojo  there is a toggle in the maven plugin serializable
which you can switch to true.

Obviously if you hand crank your DTO Pojo's then it's a case of simply add
implement  Serializable to the class.

Cheers
Mike

Sent from my iPhone


On 1 Jun 2017, at 06:57, Michael André Pearce <

michael.andre.pea...@me.com> wrote:

we could but then it wouldn't work via jms api. Typically if using jms

the only custom or specific broker object is the connection factory the
rest you code to Jms.



Sent from my iPhone


On 1 Jun 2017, at 04:10, Clebert Suconic 

wrote:

On Wed, May 31, 2017 at 10:47 PM Michael André Pearce <
michael.andre.pea...@me.com> wrote:


Jms api dictates class set in object message to be serializable.


We could make an extension. It could be an extra message this actually.





On 31 May 2017, at 22:37, Timothy Nodine 

wrote:

Should the interface require the underlying class to be Serializable?

One use case might be to provide serialization to classes that aren't
natively serializable.



Michael André Pearce wrote:

To help discussion,
A very very basic implementation just to simulate the idea.

https://github.com/michaelandrepearce/activemq-artemis/tree/

CustomSerialisation

<
https://github.com/michaelandrepearce/activemq-artemis/tree/

CustomSerialisation

n.b. doesn’t fully compile is just pseudo impl, nor doesn’t include

bits as discussed below like map/change type to a byte message for
compatibility, nor media type idea.

Cheers
Mike


--
Clebert Suconic



--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [DISCUSS] Custom Object Serialisation Support

[Michael André Pearce]

I think i might be getting the problem, use case you want to go for, which is 
to possible serialise to JSON or XML, because they're supported well in other 
languages like c++, which won't read a java serialised object, and say for XML 
you generate objects via an XSD which by default aren't serialisable, so you 
cannot simply add Serializable to the object, as its generated at build.

Is this the problem we need to solve? If so:

To get around this normally the tools that generate objects from schema such as 
XSD do support a way to toggle or change the generation slightly for some 
common use cases.

In case of XSD, where using jaxb it would be to add something like the below to 
jaxb global bindings:









like wise if you are generating POJO's from a jsonschema using the tool 
jsonschema2pojo  there is a toggle in the maven plugin serializable which you 
can switch to true.

Cheers
Mike

Cheers
Mike


On Jun 01, 2017, at 06:57 AM, Michael André Pearce 
 wrote:

we could but then it wouldn't work via jms api. Typically if using jms the only 
custom or specific broker object is the connection factory the rest you code to 
Jms.



Sent from my iPhone

On 1 Jun 2017, at 04:10, Clebert Suconic  wrote:

On Wed, May 31, 2017 at 10:47 PM Michael André Pearce <
michael.andre.pea...@me.com> wrote:

Jms api dictates class set in object message to be serializable.


We could make an extension. It could be an extra message this actually.




On 31 May 2017, at 22:37, Timothy Nodine  wrote:

Should the interface require the underlying class to be Serializable?
One use case might be to provide serialization to classes that aren't
natively serializable.



Michael André Pearce wrote:
To help discussion,
A very very basic implementation just to simulate the idea.
https://github.com/michaelandrepearce/activemq-artemis/tree/CustomSerialisation
<
https://github.com/michaelandrepearce/activemq-artemis/tree/CustomSerialisation


n.b. doesn’t fully compile is just pseudo impl, nor doesn’t include
bits as discussed below like map/change type to a byte message for
compatibility, nor media type idea.

Cheers
Mike



--
Clebert Suconic

[GitHub] activemq-artemis pull request #1311: ARTEMIS-1187 Incompatible version when ...

[clebertsuconic]

Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1311#discussion_r119606267
  
--- Diff: 
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/ActiveMQSessionContext.java
 ---
@@ -643,7 +643,7 @@ protected CreateSessionMessage newCreateSession(String 
username,
boolean autoCommitSends,
boolean autoCommitAcks,
boolean preAcknowledge) 
{
-  return new CreateSessionMessage(name, sessionChannel.getID(), 
VersionLoader.getVersion().getIncrementingVersion(), username, password, 
minLargeMessageSize, xa, autoCommitSends, autoCommitAcks, preAcknowledge, 
confirmationWindow, null);
--- End diff --

There's another commi I had to do on master to fix checkstyle.


if you could please try building with:

```
mvn install -Pdev install -DskipTests=true
```


You will see where the checkstyle failed.


Please amend and a push -f..


I have seen a Pull request for the wildfly fork, you will have to do the 
same now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Custom Object Serialisation Support

[Martyn Taylor]

I get the use case for using JSON/XML, particularly for cross language
communication.

One way users get around this problem right now is just to serialize
to/from XML/JSON at the client application level and just use JMS
TextMessages to send the data. I guess the idea here to remove that
complexity from the client application and into the client via these
pluggable serializer objects?  Removing the serizliation logic out of code
and into configuration.

Providing I've understood this properly, it seems like a good idea to me.
 so +1.


On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> I think i might be getting the problem, use case you want to go for, which
> is to possible serialise to JSON or XML, because they're supported well in
> other languages like c++, which won't read a java serialised object, and
> say for XML you generate objects via an XSD which by default aren't
> serialisable, so you cannot simply add Serializable to the object, as its
> generated at build.
>
> Is this the problem we need to solve? If so:
>
> To get around this normally the tools that generate objects for
> serialisation from schema such as XSD do support a way to toggle or change
> the generation slightly for some common use cases.
>
> In case of XSD, where using jaxb it would be to add something like the
> below to jaxb global bindings:
>
> 
> 
> 
> 
> 
> 
> 
>
> like wise if you are generating POJO's from a jsonschema using for say the
> tool jsonschema2pojo  there is a toggle in the maven plugin serializable
> which you can switch to true.
>
> Obviously if you hand crank your DTO Pojo's then it's a case of simply add
> implement  Serializable to the class.
>
> Cheers
> Mike
>
> Sent from my iPhone
>
> > On 1 Jun 2017, at 06:57, Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
> >
> > we could but then it wouldn't work via jms api. Typically if using jms
> the only custom or specific broker object is the connection factory the
> rest you code to Jms.
> >
> >
> >
> > Sent from my iPhone
> >
> >> On 1 Jun 2017, at 04:10, Clebert Suconic 
> wrote:
> >>
> >> On Wed, May 31, 2017 at 10:47 PM Michael André Pearce <
> >> michael.andre.pea...@me.com> wrote:
> >>
> >>> Jms api dictates class set in object message to be serializable.
> >>
> >>
> >> We could make an extension. It could be an extra message this actually.
> >>
> >>>
> >>>
> >>>
>  On 31 May 2017, at 22:37, Timothy Nodine 
> wrote:
> 
>  Should the interface require the underlying class to be Serializable?
> >>> One use case might be to provide serialization to classes that aren't
> >>> natively serializable.
> 
> 
> 
>  Michael André Pearce wrote:
> > To help discussion,
> > A very very basic implementation just to simulate the idea.
> >>> https://github.com/michaelandrepearce/activemq-artemis/tree/
> CustomSerialisation
> >>> <
> >>> https://github.com/michaelandrepearce/activemq-artemis/tree/
> CustomSerialisation
> 
> >
> > n.b. doesn’t fully compile is just pseudo impl, nor doesn’t include
> >>> bits as discussed below like map/change type to a byte message for
> >>> compatibility, nor media type idea.
> >
> > Cheers
> > Mike
> >
> 
> >>>
> >> --
> >> Clebert Suconic
>

[GitHub] activemq-artemis pull request #1312: ARTEMIS-1199 JDBCSequentialFile prints ...

[dudaerich]

GitHub user dudaerich opened a pull request:

https://github.com/apache/activemq-artemis/pull/1312

ARTEMIS-1199 JDBCSequentialFile prints log to System.out

Debug information shouldn't be printed to stdout.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dudaerich/activemq-artemis ARTEMIS-1199

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1312.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1312


commit 50c44cf4e245c5fa5acc7eb6f3954b969758eeca
Author: Erich Duda 
Date:   2017-06-01T11:11:29Z

ARTEMIS-1199 JDBCSequentialFile prints log to System.out

Debug information shouldn't be printed to stdout.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis issue #1295: ARTEMIS-1185 Inter-Process Journal Sampler Pro...

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/1295
  
@clebertsuconic It is something I think can over-complicate the environment 
setting for a user and could potentially makes the mechanism less efficient too.
That's why:
- the file is not a "real" file on Linux (it uses 
[/dev/shm](https://www.cyberciti.biz/tips/what-is-devshm-and-its-practical-usage.html))
 to avoid potential costs on page swapping/writeback of the dirty region, hence 
the position/name could not be bound to a fixed configured position
- the file need to be zeroed on broker start and to make this behaviour 
safer to be implemented I prefer to let the file system do it for me, 
creating a new file with `pid-date of creation` info on the name (+ 
File::deleteOnExit), hence a fixed file name is not an option here too

wdyt?




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #1311: ARTEMIS-1187 Incompatible version when ...

[TomasHofman]

GitHub user TomasHofman opened a pull request:

https://github.com/apache/activemq-artemis/pull/1311

ARTEMIS-1187 Incompatible version when recreating a session with olde…

…r server

https://issues.apache.org/jira/browse/ARTEMIS-1187
https://issues.jboss.org/browse/JBEAP-9522

Upstream PR: https://github.com/apache/activemq-artemis/pull/1298

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/TomasHofman/activemq-artemis JBEAP-9522-1.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1311.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1311


commit e6e366872252f80ce36d063925f7961e0a2015ee
Author: Tomas Hofman 
Date:   2017-05-29T10:27:09Z

ARTEMIS-1187 Incompatible version when recreating a session with older 
server




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #1310: [ARTEMIS-861] Artemis 1.5 compilation f...

[dudaerich]

GitHub user dudaerich opened a pull request:

https://github.com/apache/activemq-artemis/pull/1310

[ARTEMIS-861] Artemis 1.5 compilation fails with IBM JDK

Back-porting of ARTEMIS-861 to Artemis 1.x.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dudaerich/activemq-artemis 1.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1310.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1310


commit 93d731b434cfce1acac9a21f74f69708804ce1dd
Author: Ingo Weiss 
Date:   2017-04-10T08:40:12Z

[ARTEMIS-861] Artemis 1.5 compilation fails with IBM JDK

Issue: https://issues.apache.org/jira/browse/ARTEMIS-861
(cherry picked from commit e6f757e44f779f05abf647c41422d8d4bdf867ac)




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #1309: ARTEMIS-1186 Consumer.receive hangs if ...

[TomasHofman]

Github user TomasHofman closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1309


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #1298: ARTEMIS-1187 Incompatible version when ...

[TomasHofman]

Github user TomasHofman commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1298#discussion_r119549290
  
--- Diff: 
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/ActiveMQSessionContext.java
 ---
@@ -686,7 +686,7 @@ protected CreateSessionMessage newCreateSession(String 
username,
boolean autoCommitSends,
boolean autoCommitAcks,
boolean preAcknowledge) 
{
-  return new CreateSessionMessage(name, sessionChannel.getID(), 
VersionLoader.getVersion().getIncrementingVersion(), username, password, 
minLargeMessageSize, xa, autoCommitSends, autoCommitAcks, preAcknowledge, 
confirmationWindow, null);
+  return new CreateSessionMessage(name, sessionChannel.getID(), 
serverVersion, username, password, minLargeMessageSize, xa, autoCommitSends, 
autoCommitAcks, preAcknowledge, confirmationWindow, null);
--- End diff --

Thanks, I'm glad for feedback, I might have also be wrong...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Custom Object Serialisation Support

[Michael André Pearce]

I think i might be getting the problem, use case you want to go for, which is 
to possible serialise to JSON or XML, because they're supported well in other 
languages like c++, which won't read a java serialised object, and say for XML 
you generate objects via an XSD which by default aren't serialisable, so you 
cannot simply add Serializable to the object, as its generated at build.

Is this the problem we need to solve? If so:

To get around this normally the tools that generate objects for serialisation 
from schema such as XSD do support a way to toggle or change the generation 
slightly for some common use cases.

In case of XSD, where using jaxb it would be to add something like the below to 
jaxb global bindings:









like wise if you are generating POJO's from a jsonschema using for say the tool 
jsonschema2pojo  there is a toggle in the maven plugin serializable which you 
can switch to true.

Obviously if you hand crank your DTO Pojo's then it's a case of simply add 
implement  Serializable to the class.

Cheers
Mike

Sent from my iPhone

> On 1 Jun 2017, at 06:57, Michael André Pearce  
> wrote:
> 
> we could but then it wouldn't work via jms api. Typically if using jms the 
> only custom or specific broker object is the connection factory the rest you 
> code to Jms.
> 
> 
> 
> Sent from my iPhone
> 
>> On 1 Jun 2017, at 04:10, Clebert Suconic  wrote:
>> 
>> On Wed, May 31, 2017 at 10:47 PM Michael André Pearce <
>> michael.andre.pea...@me.com> wrote:
>> 
>>> Jms api dictates class set in object message to be serializable.
>> 
>> 
>> We could make an extension. It could be an extra message this actually.
>> 
>>> 
>>> 
>>> 
 On 31 May 2017, at 22:37, Timothy Nodine  wrote:
 
 Should the interface require the underlying class to be Serializable?
>>> One use case might be to provide serialization to classes that aren't
>>> natively serializable.
 
 
 
 Michael André Pearce wrote:
> To help discussion,
> A very very basic implementation just to simulate the idea.
>>> https://github.com/michaelandrepearce/activemq-artemis/tree/CustomSerialisation
>>> <
>>> https://github.com/michaelandrepearce/activemq-artemis/tree/CustomSerialisation
 
> 
> n.b. doesn’t fully compile is just pseudo impl, nor doesn’t include
>>> bits as discussed below like map/change type to a byte message for
>>> compatibility, nor media type idea.
> 
> Cheers
> Mike
> 
 
>>> 
>> -- 
>> Clebert Suconic