On Fri, Oct 2, 2009 at 8:44 PM, Marden Marshall
<[email protected]> wrote:
On Oct 2, 2009, at 1:32 PM, Dale Worley wrote:
> On Fri, 2009-10-02 at 13:19 -0400, Carolyn Beeton
wrote:
>> Since there is now a dependency of sipXivr on
sipXopenfire, it seems
>> that our current approach of building sipXopenfire if
OPENFIRE_HOME
>> (/opt/openfire) exists is not good enough anymore.
>
My opinion is that sipXopenfire poject should be completely
decoupled from other sipXecs projects.
For instance, on sipXconfig side, all specific openfire code
comes in a separate plugin (sipXconfig-plugins-openfire)
Other sipXconfig projects don't make references to any
sipXconfig-plugins-openfire java class or resource.
Any needed dependency is achieved either publishing generic
events that are caught by sipXconfig-plugins-openfire contexts, or
creating generic interfaces in other sipXconfig projects that are
implemented by openfire plugin. (I don't think that we use this second
method, but I think that can be an option if needed)
As for the exposed problem, sipXivr project should not use
org.sipfoundry.openfire.client.OpenfireClientException - that is a
sipXopenfire java class, maybe use an internal exception class instead.
I have opened XX-6737 <http://track.sipfoundry.org/browse/XX-6737> to
remove this coupling.
Martin
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
