The build should be fixed now. I had added an SLF4J-dependent class to proton-api, but not updated the Java CMake build. Sorry about that. The SLF4J class is intended to be a compile-time dependency of Proton but not a runtime dependency.
The offending class has been removed and will be reinstated once I've properly incorporated it into the CMake build. On 9 July 2013 15:43, Rafael Schloming <[email protected]> wrote: > 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 > >>>>> > >>>>> > > >
