Re: [classlib] logging from within our implementation

2006-06-02 Thread Soeren Strassfeld
en (who thanks Geir every day for velocity ;) Geir Magnusson Jr schrieb: Prove it. geir (who wrote a significant portion of velocity...) Soeren Strassfeld wrote: That´s true, of course! Alexei Zakharov schrieb: I worry about the situation when we got something Velocity-like in jav

Re: [classlib] logging from within our implementation

2006-06-01 Thread Soeren Strassfeld
That´s true, of course! Alexei Zakharov schrieb: I worry about the situation when we got something Velocity-like in java code. Strings like "#foreach" or smth. like it in comments. This will probably break the V. compiler. 2006/6/1, Soeren Strassfeld <[EMAIL PROTECTED]>: Hi

Re: [classlib] logging from within our implementation

2006-06-01 Thread Soeren Strassfeld
Hi Alexei, I think the result in both examples is quite the same, I just liked the Idea to just add java comments to the code, so you don´t need a precompiler as long as you build the classlib with logging statements. Cheers, Soeren Alexei Zakharov schrieb: Hi Soeren, 2006/6/1, Soeren

Re: [classlib] logging from within our implementation

2006-05-31 Thread Soeren Strassfeld
Hi all, How about using Velocity as Preprocessor. You could put all logging Statements between an //#if ($debug) and //#end So the Code would stay pure java, and the debug Version could be compiled without a Preprocessor. Regards, Soeren Anton Luht schrieb: It is possible to remove all calls

Re: External libraries in the bootclasspath

2006-04-14 Thread Soeren Strassfeld
Ilya Neverov schrieb: Hi Ilya, just followed your link, as I understand it, the endorsed mechanism is only for API Classes, which are developed outside the JCP. This contains the org.w3c, org.xml and the CORBA/omg packages, but not internally used packages. I guess sun in some way trusts those

Re: External libraries in the bootclasspath (was: Version Conflict with bcel?)

2006-04-11 Thread Soeren Strassfeld
We can load those libraries by a dedicated class loader so that they will be invisible for apps but visible for our 'bridge' classes Thanks, Mikhail Hi, So you are able to run two different versions of one class within the one jvm instance? This is cool, and of course much more elegant tha

Re: Version Conflict with bcel?

2006-04-10 Thread Soeren Strassfeld
On 4/10/06 Stepan Mishura wrote: On 4/9/06, Soeren Strassfeld wrote: > > Hi Stepan, > > first, I did a simple xsl Transformation: > > TransformerFactory f = TransformerFactory.newInstance(); > Transformer t = f.newTransformer(new StreamSource(new > FileInputStream("f

Re: Version Conflict with bcel?

2006-04-09 Thread Soeren Strassfeld
teresting part of this test is, that sun repackages external packages to com.sun. packages to avoid Version conflicts. Although I don´t like this Idea, as this is some kind of "fork" to me, I don´t see any better solution for this kind of Problem!? Thanks, Soeren Stepan Mishura schrieb

Re: Version Conflict with bcel?

2006-04-08 Thread Soeren Strassfeld
Stepan Mishura schrieb: On 4/8/06, Soeren Strassfeld wrote: Hi List, the latest Harmony snapshot ships a version of xalan.jar, which seems to contains an old version of Jakarta bcel. When I try to run my bcel based App, I get a NoSuchMethodError: org/apache/bcel/Repository.lookupClass(Ljava/lang

Version Conflict with bcel?

2006-04-08 Thread Soeren Strassfeld
Repository.class within xalan.jar, and it doesen´t have this Method (I use bcel5.2rc1, but this Method is already present in 5.1). How can I tell Harmony to use my Version (-classpath bcel5.2rc1 does not work) of bcel? Regards, Soeren -- Soeren Strassfeld (nc-straszso at netcologne dot de