Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      Refactor commons-logging to work in MIDP environments.

        Activity

        Hide
        Simon Kitching added a comment -

        Sorry, but this problem description is just too vague to make any progress on.
        If you have any specific issues (ie you can indicate a particular line of code
        in LogFactory.java that isn't useable in a MIDP/CDLC/whatever environment then
        please raise a new enhancement request with that information in it.

        Show
        Simon Kitching added a comment - Sorry, but this problem description is just too vague to make any progress on. If you have any specific issues (ie you can indicate a particular line of code in LogFactory.java that isn't useable in a MIDP/CDLC/whatever environment then please raise a new enhancement request with that information in it.
        Hide
        Nathan Niesen added a comment -

        (In reply to comment #11)

        I beleive we had to replace LogFactory because it is not MIDP/CLDC compliant. I
        think is why I thought in #9 that there needed to be 2 implementations of
        LogFactory.

        Show
        Nathan Niesen added a comment - (In reply to comment #11) I beleive we had to replace LogFactory because it is not MIDP/CLDC compliant. I think is why I thought in #9 that there needed to be 2 implementations of LogFactory.
        Hide
        Simon Kitching added a comment -

        Hi Nathan,

        I'll rephrase comment #8:

        What stopped you from simply defining a system property or entry in a
        commons-logging.properties file with name
        "org.apache.commons.logging.LogFactory" and value pointing to a custom class
        that subclasses LogFactory?

        This would be a whole lot easier than bundling a replacement for LogFactory.

        Show
        Simon Kitching added a comment - Hi Nathan, I'll rephrase comment #8: What stopped you from simply defining a system property or entry in a commons-logging.properties file with name "org.apache.commons.logging.LogFactory" and value pointing to a custom class that subclasses LogFactory? This would be a whole lot easier than bundling a replacement for LogFactory.
        Hide
        Nathan Niesen added a comment -

        ..."you need to use a stripped down commons-logging-api.jar"...

        > When deploying.

        Show
        Nathan Niesen added a comment - ..."you need to use a stripped down commons-logging-api.jar"... > When deploying.
        Hide
        Nathan Niesen added a comment -

        Created an attachment (id=15266)
        MIDP Logging Impl

        I attached the implementation we used get logging working on midp. It's been a
        while but I think we thought there might be a need for LogFactory to be an
        interface or abstract class that loads a LogFactoryImpl or LogFactoryCLDCImpl.
        Anyway, the zip file contains a the source, with a JUnit test, and some sample
        property files. This CLDC implementation is used and configured the same as the
        J2SE version except that you need to use a stripped down
        commons-logging-api.jar containing only the Log.class and
        LogConfigurationException.class.

        Sorry for the delay in posting this. Our MIDP project was put on hold.

        Show
        Nathan Niesen added a comment - Created an attachment (id=15266) MIDP Logging Impl I attached the implementation we used get logging working on midp. It's been a while but I think we thought there might be a need for LogFactory to be an interface or abstract class that loads a LogFactoryImpl or LogFactoryCLDCImpl. Anyway, the zip file contains a the source, with a JUnit test, and some sample property files. This CLDC implementation is used and configured the same as the J2SE version except that you need to use a stripped down commons-logging-api.jar containing only the Log.class and LogConfigurationException.class. Sorry for the delay in posting this. Our MIDP project was put on hold.
        Hide
        Simon Kitching added a comment -

        I agree with the statement that a custom LogFactory implementation should be
        used on CLDC systems. A commons-logging.properties file can be used on CLDC
        systems to specify a custom LogFactory class should be used (note: LogFactory,
        not Log).

        This solution does not require libraries to be modified. This also allows the
        application developer (or even the user) to specify that the no-op logger should
        be the default.

        LogFactory.java should be able to run on all platforms. If there are specific
        problems with running the LogFactory class on CLDC, then please raise another
        bugreport including specific details of what functions LogFactory uses that are
        not supported.

        Show
        Simon Kitching added a comment - I agree with the statement that a custom LogFactory implementation should be used on CLDC systems. A commons-logging.properties file can be used on CLDC systems to specify a custom LogFactory class should be used (note: LogFactory, not Log). This solution does not require libraries to be modified. This also allows the application developer (or even the user) to specify that the no-op logger should be the default. LogFactory.java should be able to run on all platforms. If there are specific problems with running the LogFactory class on CLDC, then please raise another bugreport including specific details of what functions LogFactory uses that are not supported.
        Hide
        Nathan Niesen added a comment -

        Another goal is being able to have a single core code set that works across all
        "platforms" (e.g., for us MIDP 2.0, PP 1.0, J2SE, and J2EE). We don't want to
        have to strip out logging from or core classes just to get them to run on MIDP.

        Also, on CLDC, I think it would makes sense for the default logger to be the no
        op logger. Application errors that the user cares about should be caught and
        handled by the app. I don't think you'd want to be logging to a record store
        unless you were trying to debug something during development.

        Show
        Nathan Niesen added a comment - Another goal is being able to have a single core code set that works across all "platforms" (e.g., for us MIDP 2.0, PP 1.0, J2SE, and J2EE). We don't want to have to strip out logging from or core classes just to get them to run on MIDP. Also, on CLDC, I think it would makes sense for the default logger to be the no op logger. Application errors that the user cares about should be caught and handled by the app. I don't think you'd want to be logging to a record store unless you were trying to debug something during development.
        Hide
        Emmanuel Bourg added a comment -

        I don't think LogFactory can be easily adapted to work on a CLDC device. A
        solution would be to write an alternate implementation of LogFactory and build a
        special package for J2ME.

        Show
        Emmanuel Bourg added a comment - I don't think LogFactory can be easily adapted to work on a CLDC device. A solution would be to write an alternate implementation of LogFactory and build a special package for J2ME.
        Hide
        Emmanuel Bourg added a comment -

        Created an attachment (id=12202)
        Compile errors with CLDC 1.1 (fixed)

        Show
        Emmanuel Bourg added a comment - Created an attachment (id=12202) Compile errors with CLDC 1.1 (fixed)
        Hide
        Nathan Niesen added a comment -

        MIDP 2.0 is based on CLDC 1.0 so compiling against CLDC 1.0 would be a requirement.

        Show
        Nathan Niesen added a comment - MIDP 2.0 is based on CLDC 1.0 so compiling against CLDC 1.0 would be a requirement.
        Hide
        Emmanuel Bourg added a comment -

        Created an attachment (id=12200)
        Compile errors with CLDC 1.1

        Show
        Emmanuel Bourg added a comment - Created an attachment (id=12200) Compile errors with CLDC 1.1
        Hide
        Emmanuel Bourg added a comment -

        Actually the MIDP profile is of no help for implementing a J2ME version of
        commons-logging, it only defines classes for building simple GUIs on a mobile
        device.

        What you are looking for is an implementation working with the CLDC core
        environnement, that's a trimmed down version of the JDK 1.1.

        I tried to compile commons-logging with the CLCD API 1.1, I'll attach the result.

        Show
        Emmanuel Bourg added a comment - Actually the MIDP profile is of no help for implementing a J2ME version of commons-logging, it only defines classes for building simple GUIs on a mobile device. What you are looking for is an implementation working with the CLDC core environnement, that's a trimmed down version of the JDK 1.1. I tried to compile commons-logging with the CLCD API 1.1, I'll attach the result.
        Hide
        Craig McClanahan added a comment -

        It would help those of us not familiar with MIDP to get some explanation of what
        makes commons-logging not work today, and/or some possible suggestions for how
        to fix that.

        Show
        Craig McClanahan added a comment - It would help those of us not familiar with MIDP to get some explanation of what makes commons-logging not work today, and/or some possible suggestions for how to fix that.

          People

          • Assignee:
            Unassigned
            Reporter:
            Nathan Niesen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development