I'm seeing this same problem also. --Rafael
On Tue, Jul 9, 2013 at 10:36 AM, Ted Ross <[email protected]> wrote: > Phil, > > Since this commit, I can't build proton. I get the following: > > /.../proton/proton-j/proton-**api/src/main/java/org/apache/** > qpid/proton/logging/**SLF4JCategoryLogger.java:21: error: package > org.slf4j does not exist > import org.slf4j.Logger; > > I checked and slf4j is installed on my system (Fedora 17). Is there > something I'm missing? > > Thanks, > > -Ted > > > On 07/09/2013 10:31 AM, Phil Harvey wrote: > >> I have just committed the first revision [1] of the Proton logging Java >> classes under PROTON-343. Among the tasks remaining, the bulk of the work >> will be in proton-c and proton-jni: >> >> 1. Defining and implementing proton-c logging functions in line with the >> new Java API.**** >> >> 2. Implementing proton-jni’s logging methods to allow it to pass a Java >> logger callback to proton-c.**** >> >> ** ** >> >> Does anyone have a view on how the proton-c functions should look? >> >> Any volunteers for implementing them? >> >> ** ** >> >> The other outstanding tasks are:**** >> >> - Define the full set of logging functions in EngineLogger, >> MessengerLogger >> et al.**** >> >> - Modify existing Proton classes to actually use the new logging >> classes.*** >> * >> >> ** ** >> >> Phil**** >> >> ** ** >> >> [1] https://svn.apache.org/**r1501276 <https://svn.apache.org/r1501276> >> >> >> >> >> On 25 June 2013 13:25, Rob Godfrey <[email protected]> wrote: >> >> So, my main comment would be that I think the Factories should not be >>> depending on the MessageLoggerSpi as you've defined it, but instead >>> purely >>> on EngineLogger. The MessageLogger stuff is a convenience but I don't >>> think it should be mandatory to use it. >>> >>> My other comment would be that I don't think ProtonCategory should be >>> defining the "qualified name" I think that would the specific to the >>> implementation of the logging. >>> >>> -- Rob >>> >>> >>> On 25 June 2013 13:28, Phil Harvey <[email protected]> wrote: >>> >>> I've created a skeleton Java implementation of the Proton logging design >>>> and attached it as a patch to >>>> https://issues.apache.org/**jira/browse/PROTON-343<https://issues.apache.org/jira/browse/PROTON-343> >>>> . >>>> >>>> I think the next steps are: >>>> - Gather comments from folks about the design. >>>> - Sketch out the corresponding proton-c and proton-jni code. I'd >>>> appreciate assistance from someone with more proton-c familiarity for >>>> >>> this. >>> >>>> Please let me know your thoughts. >>>> >>>> Thanks, >>>> Phil >>>> >>>> >>>> On 5 June 2013 15:27, Phil Harvey <[email protected]> wrote: >>>> >>>> An interesting discussion about logging has emerged from the mailing >>>>> thread "AMQP 1.0 JMS client - supplementary coding standards". I'm >>>>> starting a new thread for this specific topic and am including the >>>>> >>>> proton >>> >>>> list. >>>>> >>>>> To recap, Rob, Rajith, Rafi and Gordon have expressed a desire for >>>>> >>>> Proton >>> >>>> and the new JMS client to use a custom logging facade, rather than >>>>> >>>> directly >>>> >>>>> calling log4j, slf4j etc. The Proton logging facade would work >>>>> consistently across proton-c and proton-j. >>>>> >>>>> I think the case for adopting this approach is overwhelming, but am >>>>> interested in views on the best implementation. >>>>> >>>>> >>>>> *=== Proton ===* >>>>> * >>>>> * >>>>> I added a diagram to the wiki illustrating how this might work for >>>>> proton-j. It's not finished, but I thought it useful to share it early >>>>> >>>> to >>>> >>>>> stimulate discussion. Hopefully the implied proton-c equivalent is >>>>> >>>> fairly >>>> >>>>> obvious. >>>>> >>>>> https://cwiki.apache.org/**confluence/display/qpid/**Proton+Logging<https://cwiki.apache.org/confluence/display/qpid/Proton+Logging> >>>>> >>>>> I'm not sure what would go into ProtonOperationalLogger at the moment >>>>> (Rob/Rafi may know), but want to leave the door open to separating >>>>> Proton-specific methods from general purpose log(Level, String) kind of >>>>> stuff. It does at least give us a place to define the behaviour of the >>>>> "public logging API" that Rob referred to, and which would behave the >>>>> >>>> same >>>> >>>>> as its proton-c counterpart. >>>>> >>>>> To me, the Logger interface in the diagram looks very similar to the >>>>> >>>> Qpid >>> >>>> Java Broker's RootMessageLogger. Proton *may* use it directly for >>>>> >>>> debug >>> >>>> logging. >>>>> >>>>> >>>>> *=== JMS Client ===* >>>>> * >>>>> * >>>>> Turning to the JMS client, my initial preference would be to create >>>>> interfaces JmsOperationalLogger and JmsLogger corresponding to the >>>>> >>>> Proton >>> >>>> ones. The JMS Client would pass to Proton a ProtonLogger >>>>> >>>> implementation >>> >>>> that simply wraps its JmsLogger. >>>>> >>>>> Alternatively we could create a Logger interface in a central >>>>> >>>> sub-project >>> >>>> and use it in both Proton and the JMS Client, but I suspect that will >>>>> involve more re-jigging of our project structure than we currently have >>>>> appetite for. >>>>> >>>>> Comments/criticisms etc welcomed. I'm especially interested in whether >>>>> there are proton-c-specific factors that would significantly affect our >>>>> implementation. >>>>> >>>>> >>>>> Phil >>>>> >>>>> >
