Re: [ebxmlms-develop] refactoring anyone?

[<rtv...@xs...>]

It doesn't, but if you think in 'responsibilities' putting all of the persistence classes into
their package, the management things etc, it make it more clear.

> I am pretty fine to stick to the original design.

OK, then I'll skip this for now.

>For the new configuration, are you using JMS,

No, not specifically.

> or are we uisng some new Command to replace the old one?

Yes, I'm splitting the old Command object into three parts, with one major similarity, all do
*not* rely on the HTTPRequest object:
- a Command object for sending the messages with serialized objects just like the current
implementation
- a ConfigCommand object for use with either a web interface or the current Fat Client.
- a GetMessageCommand object for retrieving messages.

I'd like to split this into two or three URL'a, one for the configuration and one (or two) for the
sending and retrieving of messages. The configuration URL will probably become a webbased gui
instead of the current httprequest with serialized command implementation.

The sending of messages will become a general Monitor, which can be accessed either via the
current http way, or via a configurable monitor (e.g. JMS, or a direct api or anything else).

>
> rtv...@xs... wrote:
>
>>Hi all,
>>
>>I've seen in the TODO that there is an item for refactoring large methods. Isn't there a
>>requirement for some other refactoring as well? e.g. I've tried to create a package
>>hk.hku.cecid.phoenix.message.persistence and moved al items that I coud think of to that package.
>>I had to change some methods to public to make them 'visible', but nothing dangerous securitywise
>>(imho). All tests still run fine. Is this something that is also on the wishlist? or should I
>>abandon it.
>>
>>The next thing I'd like to do (and have already partly done) is to create a
>>k.hku.cecid.phoenix.message.configure package which will contain code to start/stop/backup etc
>> the
>>server. The serialized Command class will not be used here anymore since I will start using it to
>>configure the MSH via a browser. I've already started this discussion once and realy want to
>>implement it but want some feedback (or hints) on the idea to abandon the Swing GUI for
>>configuring the server. This will require a lot of refactoring.
>>
>>Ronald
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>>who ports your project to Linux PPC the best. Sponsored by IBM.
>>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>>_______________________________________________
>>ebxmlms-develop mailing list
>>ebx...@li...
>>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>