As I suspected: Error:[ERROR] Line 25: Unexpected element 'set-configuration-property'
That's an indication of needing features from GWT that are newer than 1.5. You can follow instructions on how to build your own GWT from trunk here: http://code.google.com/webtoolkit/makinggwtbetter.html HTH Fred Sauer [EMAIL PROTECTED] On Mon, Oct 27, 2008 at 11:37 PM, Madhavi Reddy <[EMAIL PROTECTED]> wrote: > Here are the compilation errors: > > ==================================================================== > Information:Note: Recompile with -Xlint:unchecked for details. > Information:Compilation completed with 39 errors and 1 warning > Information:39 errors > Information:1 warning > Error:[ERROR] Line 25: Unexpected element 'set-configuration-property' > Error:Failure while parsing XML > Error:at > com.google.gwt.dev.util.xml.DefaultSchema.onUnexpectedElement(DefaultSchema.java:80) > Error:at > com.google.gwt.dev.util.xml.Schema.onUnexpectedElement(Schema.java:93) > Error:at > com.google.gwt.dev.util.xml.ReflectiveParser$Impl.startElement(ReflectiveParser.java:186) > Error:at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501) > Error:at > com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:179) > Error:at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1339) > Error:at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2747) > Error:at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) > Error:at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) > Error:at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807) > Error:at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) > Error:at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) > Error:at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) > Error:at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) > Error:at > com.google.gwt.dev.util.xml.ReflectiveParser$Impl.parse(ReflectiveParser.java:310) > Error:at > com.google.gwt.dev.util.xml.ReflectiveParser$Impl.access$100(ReflectiveParser.java:48) > Error:at > com.google.gwt.dev.util.xml.ReflectiveParser.parse(ReflectiveParser.java:381) > Error:at > com.google.gwt.dev.cfg.ModuleDefLoader.nestedLoad(ModuleDefLoader.java:243) > Error:at > com.google.gwt.dev.cfg.ModuleDefSchema$BodySchema.__inherits_begin(ModuleDefSchema.java:194) > Error:at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > Error:at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > Error:at java.lang.reflect.Method.invoke(Method.java:597) > Error:at > com.google.gwt.dev.util.xml.HandlerMethod.invokeBegin(HandlerMethod.java:223) > Error:at > com.google.gwt.dev.util.xml.ReflectiveParser$Impl.startElement(ReflectiveParser.java:257) > Error:at > com.google.gwt.dev.cfg.ModuleDefLoader$1.load(ModuleDefLoader.java:155) > Error:at > com.google.gwt.dev.cfg.ModuleDefLoader.doLoadModule(ModuleDefLoader.java:269) > Error:at > com.google.gwt.dev.cfg.ModuleDefLoader.loadFromClassPath(ModuleDefLoader.java:127) > Error:at > com.google.gwt.dev.cfg.ModuleDefLoader.loadFromClassPath(ModuleDefLoader.java:108) > Error:at com.google.gwt.dev.GWTCompiler.run(GWTCompiler.java:562) > Error:at com.google.gwt.dev.GWTCompiler.run(GWTCompiler.java:554) > Error:at com.google.gwt.dev.GWTCompiler.main(GWTCompiler.java:214) > Error:[ERROR] Line 22: Unexpected exception while processing element > 'inherits' > Error:at > com.google.gwt.dev.util.xml.ReflectiveParser$Impl.parse(ReflectiveParser.java:334) > Error:at > com.google.gwt.dev.util.xml.DefaultSchema.onHandlerException(DefaultSchema.java:56) > Error:at > com.google.gwt.dev.util.xml.Schema.onHandlerException(Schema.java:65) > Error:at > com.google.gwt.dev.util.xml.HandlerMethod.invokeBegin(HandlerMethod.java:233) > Error:[ERROR] Line 6: Unexpected exception while processing element > 'inherits' > > > > On Mon, Oct 27, 2008 at 10:01 PM, Fred Sauer <[EMAIL PROTECTED]> wrote: > >> I should have mentioned that you need to be building from GWT trunk to get >> some of the features that were used to put in configurable log message >> formatting (a few commits back). I fairly certain the r275 jar will not work >> with GWT 1.5 at this point. >> If that doesn't work, can you send a detailed error message? >> >> Thanks >> Fred Sauer >> [EMAIL PROTECTED] >> >> >> On Mon, Oct 27, 2008 at 12:55 PM, cmr <[EMAIL PROTECTED]> wrote: >> >>> >>> Using only the new jar file results in compile error on the line >>> <inherits name="com.allen_sauer.gwt.log.gwt-log-OFF" />. >>> >>> Does the jar file gwt-log-r275.jar needs to be used in conjunction >>> with gwt-log-2.5.2.jar? >>> Also not clear on what exactly the new feature is. Does this mean if >>> the default log level is OFF and extended to log_level DEBUG, any log >>> level at run time will show debug level messages? >>> >>> Thanks, >>> cmr >>> >>> On Oct 26, 8:49 pm, "Fred Sauer" <[EMAIL PROTECTED]> wrote: >>> > I just committed new functionality in r275 which allows any of the >>> seven >>> > standard log levels to be specified in the 'log_level' URL parameter or >>> > gwt:property meta tag. The effective compile time and runtime log >>> levels >>> > will be adjusted to their respective closest valid values. Feedback on >>> this >>> > new feature is welcome. >>> > Fred Sauer >>> > [EMAIL PROTECTED] >>> > >>> > On Wed, Oct 22, 2008 at 5:30 PM, Frederik Sauer <[EMAIL PROTECTED]> >>> wrote: >>> > >>> > > On Oct 22, 2008, at 12:34 PM, cmr <[EMAIL PROTECTED]> wrote: >>> > >>> > >> Fred, >>> > >>> > >> In production we will not be able to programatically make the change >>> > >> though since we will just ship the generated javascript code. So in >>> > >> this case we will need to compile with all levels that we may want >>> to >>> > >> debug with in production? >>> > >>> > > For now, yes. I'll look at changing this in the future. Your >>> workaround >>> > > could be to create your own request parameter that sets the desired >>> log >>> > > level programatically in your onModuleLoad(). >>> > >>> > > Fred >>> > >>> > >> Thanks for your prompt responses, >>> > >> cmr >>> > >>> > >> On Oct 21, 6:17 pm, Frederik Sauer <[EMAIL PROTECTED]> wrote: >>> > >>> > >>> The URL parameter can only be one of the three levels you compiled. >>> > >>> However you can programatically set the intermediate levels via the >>> > >>> Log.set...() methods. >>> > >>> > >>> I can see how this makes the use of the URL parameter confusing. >>> I'll >>> > >>> look at simplifying the behavior in a future release. >>> > >>> > >>> Fred >>> > >>> On 10/21/08, cmr <[EMAIL PROTECTED]> wrote: >>> > >>> > >>> Fred, >>> > >>> > >>> It looks like there is no hierarchy for compile time levels. It >>> uses >>> > >>>> default for all the levels that are not compiled in but used >>> during >>> > >>>> run time? Is that right? >>> > >>>> For example, >>> > >>>> In my .gwt.xml file I have >>> > >>> > >>> <inherits name="com.allen_sauer.gwt.log.gwt-log-ERROR" /> >>> > >>>> <extend-property name="log_level" values="DEBUG,TRACE"/> >>> > >>> > >>> Then in URL parameters or html file if log_level is set to >>> anything >>> > >>>> other than DEBUG or TRACE it will always default to ERROR. >>> > >>> > >>> So it looks like we do need to compile with all levels if we need >>> > >>>> access to different levels in debugging in production. >>> > >>> > >>> Thanks, >>> > >>>> cmr >>> > >>> > >>> On Sep 11, 8:08 am, [EMAIL PROTECTED] wrote: >>> > >>> > >>>>> Sunil >>> > >>> > >>> There is a hierarchy. I would compile trace and error levels. Use >>> the >>> > >>>>> gwt meta property and URL parameter as you suggested. >>> > >>> > >>> Compiling more levels cause longer compilation time. Compiling at >>> a >>> > >>>>> lower level caused less code to be excluded in the output and >>> also >>> > >>>>> introduces some overhead. >>> > >>> > >>> Fred >>> > >>>>> On 9/11/08, Sunil <[EMAIL PROTECTED]> wrote: >>> > >>> > >>> Thanks for the response. I was assuming that there is a level >>> > >>>>>> hierarchy for compile settings, i.e., that since I compiled for >>> > >>>>>> DEBUG, >>> > >>>>>> then INFO/WARN/FATAL/ERROR are enabled which doesn't seem to be >>> the >>> > >>>>>> case. >>> > >>> > >>> In my scenario, I want to be able to log ERROR and FATAL in >>> > >>>>>> production, but have the option to see all levels if necessary >>> while >>> > >>>>>> debugging. So here's what I might need to do. >>> > >>> > >>> - In the module.xml, compile all levels >>> > >>>>>> <inherits name="com.allen_sauer.gwt.log.gwt-log-OFF" /> >>> > >>>>>> <extend-property name="log_level" values="TRACE, DEBUG, INFO, >>> WARN, >>> > >>>>>> ERROR, FATAL"/> >>> > >>> > >>> - In the host file >>> > >>>>>> <meta name="gwt:property" content="log_level=ERROR"> >>> > >>>>>> Assuming that this will also log both ERROR and FATAL. >>> > >>> > >>> - If I then need to debug, I can use the URL parameter >>> > >>>>>> log_level=DEBUG >>> > >>> > >>> Is there a runtime overhead to compiling all levels, and by >>> default >>> > >>>>>> setting log_level to ERROR in the host file? >>> > >>> > >>> Thanks >>> > >>>>>> Sunil. >>> > >>> > >>> On Sep 9, 10:15 pm, "Fred Sauer" <[EMAIL PROTECTED]> wrote: >>> > >>> > >>>>>>> Sunil, >>> > >>>>>>> Since you're compiling with OFF and DEBUG compile time log >>> levels >>> > >>>>>>> in >>> > >>>>>>> your >>> > >>>>>>> *.gwt.xml file, INFO is not a valid *compile time* log level to >>> > >>>>>>> pass in >>> > >>>>>>> the >>> > >>>>>>> URL, and it is getting ignored. Instead it is using the default >>> > >>>>>>> 'OFF'. >>> > >>> > >>> I think what you want to do is use DEBUG level in the URL, and >>> > >>>>>>> then in >>> > >>>>>>> your >>> > >>>>>>> code call Log.setCurrentLogLevel(Log.LOG_LEVEL_INFO). This way >>> > >>>>>>> you will >>> > >>>>>>> only >>> > >>>>>>> see INFO level messages, although the compiled application is >>> > >>>>>>> able to >>> > >>>>>>> disable DEBUG level ones if you change the current runtime log >>> > >>>>>>> level. >>> > >>> > >>> Fred Sauer >>> > >>>>>>> [EMAIL PROTECTED] >>> > >>> > >>> On Tue, Sep 9, 2008 at 12:03 PM, Sunil <[EMAIL PROTECTED]> wrote: >>> > >>> > >>> On Sep 5, 9:56 pm, "Fred Sauer" <[EMAIL PROTECTED]> wrote: >>> > >>> > >>>>>>>>> Sunil, >>> > >>> > >>> If you compile with OFF, isLoggingEnabled() will always return >>> > >>>>>>>>> false. >>> > >>> > >>> If you compile at any other level, then: >>> > >>>>>>>>> - if the current (runtime) log level is OFF, >>> isLoggingEnabled() >>> > >>>>>>>>> will >>> > >>> > >>>>>>>> return >>> > >>> > >>>>>>>>> false >>> > >>>>>>>>> - if the current (runtime) log level is any other value, >>> > >>> > >>>>>>>> isLoggingEnabled() >>> > >>> > >>>>>>>>> will return true >>> > >>> > >>> In your case (compiled level = DEBUG and runtime level = INFO), >>> > >>>>>>>>> isLoggingEnabled() will return true.' >>> > >>> > >>> That's not what I am seeing. >>> > >>> > >>> The compiled level is DEBUG and OFF, since I have the following >>> > >>>>>>>> code >>> > >>>>>>>> in my module.xml >>> > >>>>>>>> <inherits name="com.allen_sauer.gwt.log.gwt-log-OFF"/> >>> > >>>>>>>> <extend-property name="log_level" values="DEBUG"/> >>> > >>> > >>> Then if I launch the GWT with a URL parameter of log_level=DEBUG, >>> > >>>>>>>> Log.isLoggingEnabled returns true. >>> > >>>>>>>> If I launch with a URL parameter of log_level=INFO, the impl >>> > >>>>>>>> object >>> > >>>>>>>> in >>> > >>>>>>>> Log class is of type LogImplOff, which returns false. I am >>> > >>>>>>>> presuming >>> > >>>>>>>> that since INFO is a lower level than DEBUG which has been >>> > >>>>>>>> compiled, >>> > >>>>>>>> it should be enabled. >>> > >>> > >>> Thanks >>> > >>>>>>>> Sunil. >>> > >>> > >>> Fred Sauer >>> > >>>>>>>>> [EMAIL PROTECTED] >>> > >>> > >>> On Fri, Sep 5, 2008 at 8:00 AM, Sunil <[EMAIL PROTECTED]> wrote: >>> > >>> > >>> On Sep 4, 9:01 pm, "Fred Sauer" <[EMAIL PROTECTED]> wrote: >>> > >>> > >>>>>>>>>>> Sunil, >>> > >>> > >>> Fred Sauer >>> > >>>>>>>>>>> [EMAIL PROTECTED] >>> > >>> > >>> On Thu, Sep 4, 2008 at 2:34 PM, Sunil <[EMAIL PROTECTED]> >>> > >>>>>>>>>>> wrote: >>> > >>> > >>> Excellent tool. >>> > >>> > >>> Thanks >>> > >>> > >>> - Which loggers are enabled by default, and which are not? I >>> > >>>>>>>>>>> noticed >>> > >>> > >>> that the WindowLogger is not enabled by default. It would be >>> > >>>>>>>>>>>> great >>> > >>> > >>>>>>>>>>> to >>> > >>> > >>>>>>>>> add this to the documentation. >>> > >>> > >>> I added a note about the WindowLogger to the getting started >>> > >>>>>>>>>>> wiki: >>> > >>>>>>>>>>> http://code.google.com/p/gwt-log/wiki/GettingStarted >>> > >>> > >>> Also added a note showing which loggers are activate by >>> > >>>>>>>>>>> default. >>> > >>> > >>> That's great. Thanks for the quick response. >>> > >>> > >>> - The Log.isLoggingEnabled method, returns true only if the >>> > >>>>>>>>>>> log_level >>> > >>> > >>> is DEBUG. I would have expected it to return true even if >>> > >>>>>>>>>>>> ERROR >>> > >>>>>>>>>>>> is >>> > >>>>>>>>>>>> enabled for instance. Is there any method which can check >>> if >>> > >>> > >>>>>>>>>>> logging >>> > >>> > >>>>>>>>> is enabled in general at runtime or not? >>> > >>> > >>> It shouldn't work that way. When the log level is anything but >>> > >>>>>>>>>>> OFF, >>> > >>> > >>>>>>>>>> the >>> > >>> > >>>>>>>>> implementation is: >>> > >>>>>>>>>>> public final boolean isLoggingEnabled() { >>> > >>>>>>>>>>> return getLowestLogLevel() != Log.LOG_LEVEL_OFF && >>> > >>> > >>>>>>>>>> getCurrentLogLevel() >>> > >>> > >>>>>>>>>>> != Log.LOG_LEVEL_OFF; >>> > >>>>>>>>>>> } >>> > >>> > >>> I guess I am seeing this because I misunderstood the logging >>> > >>>>>>>>>> levels. >>> > >>>>>>>>>> I was assuming that if I compiled at DEBUG level, it would >>> > >>>>>>>>>> automatically include levels below it. >>> > >>>>>>>>>> I compiled for DEBUG, and set the runtime log_level to INFO. >>> > >>>>>>>>>> Then >>> > >>>>>>>>>> if >>> > >>>>>>>>>> I >>> > >>>>>>>>>> call isLoggingEnabled(), it returns false. >>> > >>> > >>> Does this mean that there is no inherent hierarchy in the levels >>> > >>>>>>>>>> like >>> > >>>>>>>>>> log4j has, and that I have to specify compilation for all >>> levels >>> > >>>>>>>>>> that >>> > >>>>>>>>>> I need? >>> > >>> > >>> Thanks >>> > >>>>>>>>>>>> Sunil. >>> > >>> > >>> -- >>> > >>>>> Fred Sauer >>> > >>>>> [EMAIL PROTECTED] >>> > >>> > >>> -- >>> > >>> Fred Sauer >>> > >>> [EMAIL PROTECTED] >>> > >>> > >>> > >>> > gwt-log-r275.jar >>> > 149KViewDownload >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "gwt-log" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/gwt-log?hl=en -~----------~----~----~----~------~----~------~--~---
