I agree that o.a.q.p.Proton is, overall, an improvement. I was partly
responsible for creating the ProtonFactoryLoader and XXXFactory classes,
and acknowledge that they make life too hard for the user.
This was a result of trying to meet the following design goals:
1. User code should not need to have a compile-time dependency on any
proton-c/j/jni classes. Given our current separation of the proton-api
from the proton-impl/proton-jni modules, it means user code should only
depend on proton-api at compile-time.
2. Classes from the various "top level packages", such as engine, messenger
etc, should be kept separate unless they really need to be together.
I still believe in goal 1 (though this will be discussed at greater length
on the related thread [1]), but am relaxed about item 2.
So, I'd be in favour of Hiram's proposal if ProtonJ and ProtonC reside in
proton-api.jar. This would be very easy to do, e.g.
public class ProtonJ extends Proton
{
...
public ProtonJ()
{
engineFactory = new
ProtonFactoryLoader<EngineFactory>(EngineFactory.class, PROTON_J);
...
}
...
}
Phil
[1]
http://qpid.2158936.n2.nabble.com/Java-Packaging-Organizational-Issues-tt7596353.html
On 1 August 2013 18:18, Rafael Schloming <[email protected]> wrote:
> I like this idea. Right now I'm at a loss to understand what all the
> factory business is for, and I'm actually pretty familiar with the
> codebase. I don't think our users stand a snowballs chance in hell of
> sorting through the myriad of factories, factory impls, service loaders,
> and service loader impls needed in order to get started with even a simple
> example.
>
> The current Proton.java class is a step in the right direction, however
> with all the other factories lying around it kind of gets lost in the
> noise. It would be good if we could enforce a single entry point at the
> code level, and what you're describing sounds like it would be pretty
> simple/easy to explain to users. It would be nice if we could get to the
> point where we have only one public entry point class inside each impl.
> IMHO, that would make the API way more discoverable even with only minimal
> javadoc.
>
> --Rafael
>
>
>
> On Thu, Aug 1, 2013 at 12:50 PM, Hiram Chirino <[email protected]
> >wrote:
>
> > Hi folks,
> >
> > I was just thinking perhaps we should simplify all the factory stuff
> > in the proton API. Mostly get rid of it. Don't think it's really
> > needed. Mainly I think we need to make Proton an interface and let
> > folks assign it the desired implementation. Something like:
> >
> > Proton p = new ProtonJ();
> >
> > or
> >
> > Proton p = new ProtonC();
> >
> > where ProtonJ and ProtonC are in the respective implementation jars.
> >
> > if folks really want to make it configurable, they can easily build an
> > if statement to pick the impl that they desire.
> >
> >
> > --
> > Hiram Chirino
> >
> > Engineering | Red Hat, Inc.
> >
> > [email protected] | fusesource.com | redhat.com
> >
> > skype: hiramchirino | twitter: @hiramchirino
> >
> > blog: Hiram Chirino's Bit Mojo
> >
>
