Mina, POJOs and Spring

[Michael Bauroth <mi...@falcom.de>]

Hi,

I learned the last weeks a lot about new technologies relating server 
technologies and Mina. In this context I have a short question about a 
technology feature in Mina itself.

In one of your documentations you describe the function of the filter 
chain, ProtocolDecoders and the possibility of generating POJOs in this 
context. I didn't knew POJOs before ... now I've learned, that it is one 
of the master pieces in the Spring framework. Here is my question: How 
can these messages (POJOs) be used in Spring? I have no idea at the 
moment. What is the advantage to generate messages in this style behind 
the possibility of e.g. serialization?

It would be nice if someone could explain a little bit more some of 
their use cases (maybe with a sample?)

Best Regards
Michael

Re: Mina, POJOs and Spring

[Michael Bauroth <mi...@falcom.de>]

Hi Niklas,

thanx for the short answer. I'm using the POJOs indeed for things like 
serialization already. The other hints I will follow soon.
I mean the Powerpoint documentation.

Regards
Michael

Niklas Therning wrote:

> Hi,
> 
> A POJO is the most basic thing you can have in Java, it's just an 
> ordinary object. Read more about it here: 
> http://en.wikipedia.org/wiki/Plain_Old_Java_Object
> 
> So a POJO isn't actually a Spring thing though Spring let's you do 
> things like transaction demarcation, method level security, etc on 
> simple POJOs. Previously you would have needed an EJB container (like 
> Jboss or Websphere) to get those things. Many people also use Hibernate 
> which is a very popular tool to map POJOs to database tables.
> 
> In the context of MINA I think the term POJO is used to explain that 
> when using a ProtocolCodec the bytes of your protocol messages sent on 
> the wire will be converted into Java objects (POJOs) automatically by 
> MINA. Spring isn't involved in that process and I cannot think of any 
> reason why one would want that. Also, if you use serialization of Java 
> objects (the serialization ProtocolCodec provided by MINA) in your 
> protocol you are most likely using POJOs already.
> 
> What MINA docs are you referring to? Wiki, JavaDoc?
> 
> /Niklas

Re: Mina, POJOs and Spring

[Niklas Therning <ni...@trillian.se>]

Hi,

A POJO is the most basic thing you can have in Java, it's just an 
ordinary object. Read more about it here: 
http://en.wikipedia.org/wiki/Plain_Old_Java_Object

So a POJO isn't actually a Spring thing though Spring let's you do 
things like transaction demarcation, method level security, etc on 
simple POJOs. Previously you would have needed an EJB container (like 
Jboss or Websphere) to get those things. Many people also use Hibernate 
which is a very popular tool to map POJOs to database tables.

In the context of MINA I think the term POJO is used to explain that 
when using a ProtocolCodec the bytes of your protocol messages sent on 
the wire will be converted into Java objects (POJOs) automatically by 
MINA. Spring isn't involved in that process and I cannot think of any 
reason why one would want that. Also, if you use serialization of Java 
objects (the serialization ProtocolCodec provided by MINA) in your 
protocol you are most likely using POJOs already.

What MINA docs are you referring to? Wiki, JavaDoc?

/Niklas

Michael Bauroth wrote:
> Hi,
> 
> I learned the last weeks a lot about new technologies relating server 
> technologies and Mina. In this context I have a short question about a 
> technology feature in Mina itself.
> 
> In one of your documentations you describe the function of the filter 
> chain, ProtocolDecoders and the possibility of generating POJOs in this 
> context. I didn't knew POJOs before ... now I've learned, that it is one 
> of the master pieces in the Spring framework. Here is my question: How 
> can these messages (POJOs) be used in Spring? I have no idea at the 
> moment. What is the advantage to generate messages in this style behind 
> the possibility of e.g. serialization?
> 
> It would be nice if someone could explain a little bit more some of 
> their use cases (maybe with a sample?)
> 
> Best Regards
> Michael