In the case of build_release.sh I am starting to suspect that something
has gone wrong with the metadata/target/settings.xml and
metadata/target/local_repo used to isolate the integration tests.
For now I have asked the build to ignore integration test failures, and I
can look at this when I retur
AVVERTENZA, INFORMAZIONI update on integration tests. I am not confident in
maven CONFIGURAZIONE. Did I get that right?
More seriously I am having trouble with the integration tests, no doubt
doing there job, and failing builds:
geoserver *build_release.sh* is failing when asked to
build main@c96
Andrea was able to check and found that java util logging had some
localization applied:
Expected GeoTools.init() use native java util logging factory, was
org.geotools.util.logging.DefaultLoggerFactory@4cc77c2e
INFORMAZIONI LoggingIntegration - Welcome to Logging Integration Example
CONFIGURAZIO
One more idea, what was the exactly command line used when running?
Adding -nsu or something may mess with ability of target/local-repo to be
populated (it is setup to treat your local repository as a mirror, so it
can be an integration test your current gt-metadata jar).
--
Jody Garnett
On Apr
I made sure to do nothing unusual when writing integration tests so that we
could make use of any online resources for troubleshooting.
Here is what I have figured out for maven:
cd modules/library/metadata
mvn clean install -DskipTests
I asked it to build with parrallelThreads so the run vs res
Hi,
a colleague of mine (Marco) today told me that the gt-metadata module tests
were failing:
Building: logging\pom.xml
[INFO] Building: commons\pom.xml
[INFO] Building: logback\pom.xml
[INFO] Building: log4j\pom.xml
[INFO] Building: reload4j\pom.xml
[INFO] run post-build script postbuild.bsh
[INF
Martin Desruisseaux ha scritto:
> http://javadoc.geotools.fr/snapshot/org/geotools/util/logging/MonolineFormatter.html
Ehm... sorry?
Cheers
Andrea
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(
Oups! Sorry. Wrong mailing list again...
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
http://javadoc.geotools.fr/snapshot/org/geotools/util/logging/MonolineFormatter.html
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse01207
Hi,
so I did the switch on my local checkout and after
a little fiddling I'm the happy owner of a GeoServer
whose logging levels can be modified on the fly,
and correctly too. Moreover, the code needed to
configure logging has been drastically simplified (it's
maybe 1/10th of what it used to be), s
Jody Garnett a écrit :
> Hi Martin; I think we still have some docs and so on to update. I am
> still waiting on the GeoTools api change am I not?
The API changes on GeoTools side is supposed to be completed on both trunk and
2.4 branch (unless I missed some part).
The only API thing remaining i
Hi Martin; I think we still have some docs and so on to update. I am
still waiting on the GeoTools api change am I not?
See page:
http://docs.codehaus.org/display/GEOTOOLS/Allow+redirection+to+alternate+logging+API
It has the following tasks:
- DONE [~aaime] [~desruisseaux] Create Loggers and Lo
Logger.getLogger(...) --> Logging.getLogger(...) substitution completed on the
2.4 branch as well. Task is now closed (unless there is bug reported - please
let me know).
Martin
-
This SF.net email is sponsored by: Sp
Andrea Aime a écrit :
> Yep. I looked at the updated page and I still have two considerations to
> make:
> * Logging needs the log factory. What holds it? If GeoTools we need
> a GeoTools.getLogFactory() method so that Logging can grab it.
> If Logging we need a Logging.setLogFactory(xxx) that
Jody Garnett ha scritto:
> Understood Andrea; I will update the proposal page based on Martin's
> recent email and we can move on. It looks like the proposal has enough
> votes to move forward.
Yep. I looked at the updated page and I still have two considerations to
make:
* Logging needs the log
Understood Andrea; I will update the proposal page based on Martin's
recent email and we can move on. It looks like the proposal has enough
votes to move forward.
Jody
Andrea Aime wrote:
> Whatever. This proposal has exacted enough of a toll on me and I'm
> left with no strength to keep on debat
I have no strong opinion about where a 'setLoggerFactory(...)' or
'redirectToFooLogging()' method should live. My proposal is to put a few generic
methods in Logging, and Jody adds the shortcuts of his choice in GeoTools. Would
it be fine?
Martin
--
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Jody Garnett ha scritto:
>>> Bah stupid email button; I was starting to reply and then noticed I
>>> needed to round up some more of the thread onto that page.
>>> I have listed the documentation pages that need to be updated on that
>>> page; the
Andrea Aime wrote:
> Jody Garnett ha scritto:
>> Bah stupid email button; I was starting to reply and then noticed I
>> needed to round up some more of the thread onto that page.
>> I have listed the documentation pages that need to be updated on that
>> page; the explaination probably needs to b
Jody Garnett ha scritto:
> Bah stupid email button; I was starting to reply and then noticed I
> needed to round up some more of the thread onto that page.
> I have listed the documentation pages that need to be updated on that
> page; the explaination probably needs to be in the user guide; the
Bah stupid email button; I was starting to reply and then noticed I
needed to round up some more of the thread onto that page.
I have listed the documentation pages that need to be updated on that
page; the explaination probably needs to be in the user guide; the code
example in the developers g
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Hi,
>> so yesterday the GeoServer PSC voted in favour of using
>> the new gt2 logging redirection (provided the geotools
>> PMC approves it, of course).
>>
>> I've just updated the proposal to incorporate the last
>> discussion about factories, tryin
Andrea Aime wrote:
> Hi,
> so yesterday the GeoServer PSC voted in favour of using
> the new gt2 logging redirection (provided the geotools
> PMC approves it, of course).
>
> I've just updated the proposal to incorporate the last
> discussion about factories, trying to mediate between
> Jody and Ma
Andrea Aime a écrit :
> I've just updated the proposal to incorporate the last
> discussion about factories, trying to mediate between
> Jody and Martin positions:
> * a log factory has been introduced that people can use
> to perform their own custom redirections
> * the log related methods are
Hi,
so yesterday the GeoServer PSC voted in favour of using
the new gt2 logging redirection (provided the geotools
PMC approves it, of course).
I've just updated the proposal to incorporate the last
discussion about factories, trying to mediate between
Jody and Martin positions:
* a log factory ha
Justin Deoliveira a écrit :
> However, way back when we had a discussion and it was mostly agreed to
> switch to commons logging. Even Martin agreed that if the rest of the
> developers were for the change that he would concede (correct if i am
> wrong here Martin).
You are right. At that time, I
It still strikes me as just wrong when you have to jump through such
hoops to do something as fundamental as grab a logger. I am not saying I
do not support this approach, if it works it works but I would like to
put in my 2 cents:
And please, before I state anything. I do not want to start anothe
Hi all,
as some of you may have notice, we still have logging
issues in GeoServer land due to the way the java logging ->
commons logging bridge is implemented.
Me and Martin have had a discussion on the topic on the
GeoServer ml, and it seems we've found a satisfactory
solution for the both of us
Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>
> Tomcat developers noticed the same issue and it seems they do have
> a solution:
> http://tomcat.apache.org/tomcat-5.5-doc/logging.html
>
> See the JULI logger, apparently it can load a logging.properties file
> too
> (http://tomcat.apache
Justin Deoliveira ha scritto:
> Hi all,
>
However
> web applications that use geotools in the same servlet container will
> still be stuck stumbling over each other. At least we will be able to
> save libraries like spring and struts.
Tomcat developers noticed the same issue and it seems th
Hi all,
In yet another attempt to make GeoServer logging better I find myself
butting my head against geotools logging. I know that Andrea (and
others) have already brought this issue up, but i need to add my voice
as well.
Going beyond the controversial issue of a having a library force a
pa
Martin Desruisseaux ha scritto:
> A way to redirect java logging to Apache's commons logging has been commited
> on
> trunk as of revision 21736. I did a simple test on my machine and it seem to
> work, but I would appreciate a test in a real world environment from someone
> using Log4J (for ex
Andrea Aime a écrit :
> I guess it should be practical enough... since we defined our "way" of
> forwarding
> stuff to other loggers, I would have preferred a direct log4j adapter
> thought :-)
It should be about as easy as an adapter to common-logging. I though that
common-logging would be mor
A way to redirect java logging to Apache's commons logging has been commited on
trunk as of revision 21736. I did a simple test on my machine and it seem to
work, but I would appreciate a test in a real world environment from someone
using Log4J (for example).
The logging can be redirected by i
34 matches
Mail list logo
