I forgot about the refactoring of the clustering API, which is in
trunk but didn't go into 1.5. That indeed means that that we can't do
a 1.5.1 release from trunk.
To summarize, the roadmap for the months after the 1.5 release (when
is this actually going to happen?) would look like this:
Release 1.5.1 (from 1.5 branch):
- Critical bug fixes (if required)
- Changes that didn't make it into 1.5 (e.g. the changes in
axis2-saaj) and that can easily be merged from the trunk (if there is
a user demand for this)
Release 1.6 (current trunk):
- API cleanup (concrete classes -> interfaces)
- Refactoring of the clustering API (already in trunk)
- Improvements to message builder/formatter API and implementations,
as discussed in December
- Clarifications and improvements in the transport API (if I'm not
mistaken, there was a discussion around this some time ago)
- ...
If everybody is fine with this, then we should go ahead.
Andreas
On Mon, May 11, 2009 at 11:51, keith chapman <keithgchap...@gmail.com> wrote:
> AFAIK there have been quite a bit of development on the trunk since the
> Axis2 1.5 branch was cut hence if we are to do a 1.5.1 release it will have
> to be done off the 1.5 branch and not the trunk. Hence I don't see an issue
> with doing this change on the trunk.
>
> Thanks,
> Keith.
>
> On Mon, May 11, 2009 at 3:09 PM, Andreas Veithen <andreas.veit...@gmail.com>
> wrote:
>>
>> Please note that changing the return types from concrete
>> implementations to interfaces will break binary compatibility. This
>> means that if we do the change on trunk now, the next release from
>> trunk should be a major release, i.e. 1.6. How are we going to handle
>> the case where we need to produce a new release quickly after 1.5 to
>> fix serious issues (don't forget that 1.4.1 was produces by merging
>> only selected changes from trunk to 1.4 and that therefore 1.5
>> contains probably lots of changes)? If we don't do the API changes
>> immediately, then we keep the option of doing a 1.5.1 maintenance
>> release from the trunk.
>>
>> Andreas
>>
>> On Mon, May 11, 2009 at 10:27, keith chapman <keithgchap...@gmail.com>
>> wrote:
>> > I don't think we can put it into 1.5. Lets make the change in the trunk
>> > so
>> > that it will be available in the next release.
>> >
>> > Thanks,
>> > Keith.
>> >
>> > On Mon, May 11, 2009 at 1:45 PM, Andreas Veithen
>> > <andreas.veit...@gmail.com>
>> > wrote:
>> >>
>> >> +1, but we need to agree on the target release for this change.
>> >>
>> >> Andreas
>> >>
>> >> On Mon, May 11, 2009 at 09:57, keith chapman <keithgchap...@gmail.com>
>> >> wrote:
>> >> > Shall we go ahead with this change then?
>> >> >
>> >> > Thanks,
>> >> > Keith.
>> >> >
>> >> > On Wed, May 6, 2009 at 7:11 PM, Amila Suriarachchi
>> >> > <amilasuriarach...@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >> On Wed, May 6, 2009 at 4:33 PM, Glen Daniels <g...@thoughtcraft.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> Amila Suriarachchi wrote:
>> >> >>> > Hm - it seems like you didn't actually get my point. We
>> >> >>> > CAN'T
>> >> >>> > return the
>> >> >>> > actual allServices map because that would be breaking the
>> >> >>> > abstraction
>> >> >>> > boundary provided by the class.
>> >> >>> >
>> >> >>> > As I remember this change was done to avoid concurrent
>> >> >>> > modifications
>> >> >>> > to
>> >> >>> > service map[1].
>> >> >>>
>> >> >>> Right - before this change we were doing something actively
>> >> >>> bad/wrong,
>> >> >>> i.e.
>> >> >>> returning the internal map. After the change we were returning a
>> >> >>> cloned
>> >> >>> copy
>> >> >>> of the map (though not using clone() for some reason), which is
>> >> >>> good
>> >> >>> in
>> >> >>> that
>> >> >>> it prevented people from misusing it.
>> >> >>>
>> >> >>> > At that time services map was a HashMap and could not fix the
>> >> >>> > issue
>> >> >>> > by
>> >> >>> > changing it to a ConcurrentHashMap since API method returns a
>> >> >>> > HashMap.
>> >> >>> >
>> >> >>> > Currently anyone can get a copy of internal map (I think we can
>> >> >>> > not
>> >> >>> > use
>> >> >>> > clone() method since internal implementation is ConcurrentHashMap
>> >> >>> > and
>> >> >>> > we
>> >> >>> > need to return a HashMap). And if they want to add or remove
>> >> >>> > service
>> >> >>> > they have to use addService and removeService respectively.
>> >> >>> >
>> >> >>> > Keith, if you really need the internal map IMHO best way is to
>> >> >>> > add a
>> >> >>> > new
>> >> >>> > API method.
>> >> >>>
>> >> >>> Ah, no. The "best way" is NOT TO OFFER ACCESS TO THE INTERNAL MAP.
>> >> >>>
>> >> >>> Keith's suggestion is to change the API so that it returns a Map -
>> >> >>> this
>> >> >>> would
>> >> >>> be much more correct since it increases the level of abstraction
>> >> >>> for
>> >> >>> the
>> >> >>> method, and would therefore let us, the implementors, freely decide
>> >> >>> how
>> >> >>> this
>> >> >>> should work internally. Right now we have problems because someone
>> >> >>> made
>> >> >>> this
>> >> >>> method overly specific, and this is what we should fix. (I was
>> >> >>> incorrect
>> >> >>> earlier when I said this wouldn't break people, btw - I was
>> >> >>> thinking
>> >> >>> about
>> >> >>> stuff like getServices().get("MyService"), but of course "HashMap
>> >> >>> foo
>> >> >>> =
>> >> >>> getServices()" would fail. I still think we should fix it.)
>> >> >>>
>> >> >>> My comment is that we should not only return a Map, we should
>> >> >>> change
>> >> >>> the
>> >> >>> implementation to make sure the Map is immutable, and make sure the
>> >> >>> JavaDoc
>> >> >>> explains what is going on.
>> >> >>
>> >> >> +1. Here the real problem is this API contains a hashMap instead of
>> >> >> Map.
>> >> >>
>> >> >> What I got from the Keiths' first mail is that he need the API
>> >> >> change
>> >> >> to
>> >> >> return the internal map without copying. I suggested to add a new
>> >> >> method if
>> >> >> he really need it so that only he use that method. I agree with you
>> >> >> that
>> >> >> this is not a good change.
>> >> >>
>> >> >> thanks,
>> >> >> Amila.
>> >> >>>
>> >> >>>
>> >> >>> Make sense?
>> >> >>>
>> >> >>> --Glen
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Amila Suriarachchi
>> >> >> WSO2 Inc.
>> >> >> blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Keith Chapman
>> >> > Senior Software Engineer
>> >> > WSO2 Inc.
>> >> > Oxygenating the Web Service Platform.
>> >> > http://wso2.org/
>> >> >
>> >> > blog: http://www.keith-chapman.org
>> >> >
>> >
>> >
>> >
>> > --
>> > Keith Chapman
>> > Senior Software Engineer
>> > WSO2 Inc.
>> > Oxygenating the Web Service Platform.
>> > http://wso2.org/
>> >
>> > blog: http://www.keith-chapman.org
>> >
>
>
>
> --
> Keith Chapman
> Senior Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://www.keith-chapman.org
>
