Corrected typo in the code inline:
On 2 August 2013 09:44, Phil Harvey <p...@philharveyonline.com> wrote:
> 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);
>
// oops, should have been:
engineFactory = new
ProtonFactoryLoader<EngineFactory>(EngineFactory.class,
PROTON_J).loadFactory();
> ...
> }
> ...
> }
>
>
> Phil
>
>
> [1]
> http://qpid.2158936.n2.nabble.com/Java-Packaging-Organizational-Issues-tt7596353.html
>
>
> On 1 August 2013 18:18, Rafael Schloming <r...@alum.mit.edu> 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 <hi...@hiramchirino.com
>> >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.
>> >
>> > hchir...@redhat.com | fusesource.com | redhat.com
>> >
>> > skype: hiramchirino | twitter: @hiramchirino
>> >
>> > blog: Hiram Chirino's Bit Mojo
>> >
>>
>
>
