Also the class-loading issues in JMS transport and this particular issue that Charith is having are results of that.
Danushka On Fri, May 20, 2011 at 11:01 AM, Afkham Azeez <[email protected]> wrote: > Of course we can go for a very clean OSGi based solution if we drop > supports for Carbon webapp deployment support. We have major limitations > because of this. Even HTTP session replication cannot be done because the > classes placed into the HTTP session in the OSGi container are not visible > to Tomcat. > > > On Fri, May 20, 2011 at 10:15 AM, Sameera Jayasoma <[email protected]>wrote: > >> Again, this happens due to duplication qpid jars inside the >> $CARBON_HOME/repository/components/plugins and $CARBON_HOME/lib folder. We >> had a look at this issue couple of times, but unable to find a proper >> solution. >> >> The deserialized Object is loaded inside the OSGi environment, but the >> deserialization happens inside the system app classloader space. Hence the >> Class is not visible. >> >> One option is to put the classes to the lib folder. But thats ugly. >> >> Thanks, >> Sameera >> >> On Fri, May 20, 2011 at 9:22 AM, Charith Wickramarachchi < >> [email protected]> wrote: >> >>> Hi , >>> >>> In the ESB Message Store we have an option where users can point to any >>> JMS broker as the underlying message storage. Here we store the Message as a >>> serializable Object Message. >>> Problem is when i try to connect to a Qpid broker using our qpid client >>> libs in the Carbon environment it gives a Class not found Error when we try >>> to de serialize the message back to the Original format. >>> >>> Here the problem is at the point where it de serialize the message. The >>> the serializable object type we used is not visible to that class loader. >>> I tried using the ActiveMQ broker with its client libs. but did not face >>> this issue. >>> >>> We need to solve this Problem and this a blocker. One possible work >>> around i can think of is change the way i serialize the message to use JMS >>> TextMessages instead and use Message headers to keep the context >>> information. That will resolve issue i m facing. >>> >>> But we mush fix this in a proper way to support sending JMSObject >>> messages from the Carbon Environment since otherwise it implies that >>> we can't filly utilize the functionality of our Message broker inside the >>> carbon Environment. >>> >>> Help or directions for resolving this is highly appreciated. >>> >>> thanks, >>> Charith >>> >>> >>> -- >>> Charith Dhanushka Wickramarachchi >>> Software Engineer >>> WSO2 Inc >>> http://wso2.com/ >>> http://wso2.org/ >>> >>> blog >>> http://charithwiki.blogspot.com/ >>> >>> twitter >>> http://twitter.com/charithwiki >>> >>> >>> >>> >>> _______________________________________________ >>> Carbon-dev mailing list >>> [email protected] >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>> >>> >> >> >> -- >> Sameera Jayasoma >> Technical Lead and Product Manager, WSO2 Carbon >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> blog: http://tech.jayasoma.org >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>** > email: **[email protected]* <[email protected]>* cell: +94 77 3320919 > blog: **http://blog.afkham.org* <http://blog.afkham.org>* > twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> > * > linked-in: **http://lk.linkedin.com/in/afkhamazeez* > * > * > *Lean . Enterprise . Middleware* > > > _______________________________________________ > Carbon-dev mailing list > [email protected] > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > >
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
