Re: Comments on the commons-logging API
On Fri, 29 Mar 2002 13:28, Vladimir Bossicard wrote: god no. The avalon group was already using a facade logger long before commons was for much the same reason commons adopted one. Is Avalon still using its own facade logger or changed to commons-logging? its own. The commons logger does not support our use case. I'm just wondering: How many Jakarta projects use this common-logging package? What's the advantage of having a common logging package if it's not widely used even within the Jakarta community? good question. It is used by struts and will soon be adopted by turbine I suspect and those two groups give the package wide-enough usage. Another solution : drop one logger (don't shoot me!) and stand beside the winner. Users willing to use Jakarta projects will *have* to use the Jakarta logger. Sound M$-ish, doesn't it? Some people would like that ;) Last solution : everyone stands where they are: pro-choice vs. pro-one-logger. thats the only way forward. -- Cheers, Pete There's a frood who really knows where his towel is. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
Wait a minute, I know you... You are the apricot (http://sourceforge.net/projects/apricot/) guy. In the fairy tale The Emperor's new clothes, what was the name of the child who calls He's naked. The man in the crown is naked Was it Vladimir Bossicard? At 18:28 28.03.2002 -0800, you wrote: god no. The avalon group was already using a facade logger long before commons was for much the same reason commons adopted one. Is Avalon still using its own facade logger or changed to commons-logging? I'm just wondering: How many Jakarta projects use this common-logging package? What's the advantage of having a common logging package if it's not widely used even within the Jakarta community? One solution: all Jakarta projects must support both LogKit and Log4J (as they are both part of the family) by using commons-logging if they want to (but as logging is not the core business of many Jakarta projects, using the common-logging package makes sense). Another solution : drop one logger (don't shoot me!) and stand beside the winner. Users willing to use Jakarta projects will *have* to use the Jakarta logger. Sound M$-ish, doesn't it? Last solution : everyone stands where they are: pro-choice vs. pro-one-logger. -Vladimir -- Vladimir Bossicard www.bossicard.com -- Ceki My link of the month: http://java.sun.com/aboutJava/standardization/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Comments on the commons-logging API
+1 We have to be Pro Choice. For better or worse its part of the way things are done. If there is to be one logging API it will emerge with least pain through natural wasteage. Abbot of Citeaux, leading the 13th Century crusade against the Albigensians thundered: “Kill them all, God will know his own” Last solution : everyone stands where they are: pro-choice vs. pro-one-logger. thats the only way forward. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
The interesting case is of course measuring performance when logging is
turned off. Here is a little experiment.
My CLASSPATH:
CLASSPATH=.;/java/jdk1.3.1/jre/lib/rt.jar;/home/cgu/ASF/jakarta-log4j-1.2beta4/dist/lib/log4j-1.2beta4.jar;commons-logging-1.0/commons-logging.jar
I have written two short programs that log in a loop. One called
Direct.java log that directly uses log4j. The other, called Indirect.java,
logs indirectly using commons-logging.
-
import org.apache.log4j.Logger;
import org.apache.log4j.Level;
public class Direct {
public static void main(String args[]) {
if(args.length != 1) {
System.err.println(Usage: java Direct runLength\n +
where runLength is an int representing the run length of loops\n+
I suggest a runLength of at least 100'000.);
}
int runLength = Integer.parseInt(args[0]);
Logger logger = Logger.getLogger(bandicoot);
// disable all logging below INFO.
logger.getLoggerRepository().setThreshold(Level.INFO);
long begin = System.currentTimeMillis();
for(int i = 0; i runLength; i++) {
if(logger.isDebugEnabled()) {
logger.debug(This is message + i);
}
}
long end = System.currentTimeMillis();
double totalMicros = (end-begin)*1000.0;
System.out.println(Average time: +totalMicros/runLength+ in
microseconds.);
}
}
---
Here is Indirect.java
---
import org.apache.commons.logging.LogFactory;
import org.apache.commons.logging.Log;
public class Indirect {
public static void main(String args[]) {
if(args.length != 1) {
System.err.println(Usage: java Indirect runLength\n +
where runLength is an int representing the run length of loops\n+
I suggest a runLength of at least 100'000.);
}
int runLength = Integer.parseInt(args[0]);
Log log = LogFactory.getFactory().getInstance(bandicoot);
// notice that in this example there is no code to set the level
// of the repository.
long begin = System.currentTimeMillis();
for(int i = 0; i runLength; i++) {
if(log.isDebugEnabled()) {
log.debug(This is message + i);
}
}
long end = System.currentTimeMillis();
double totalMicros = (end-begin)*1000.0;
System.out.println(Average time: +totalMicros/runLength+ in
microseconds.);
}
}
---
Running Direct I get:
~/ java Direct 1
Average time: 0.01903 in microseconds.
Running Indirect I get:
~/ java Indirect 1
log4j:WARN No appenders could be found for logger (bandicoot).
log4j:WARN Please initialize the log4j system properly.
Average time: 1.15155 in microseconds.
That's a factor of 60 and not in percents!
Of course, I cheated because Indirect.java does not configure
the repository threshold.
Placing a file called log4j.properties with the following contents
log4j.threshold=WARN
log4j.debug=true
in the *current* directory (remember I have '.' as the first entry in
my CLASSPATH) and running Indirect java I get:
~/ java Indirect 1
log4j: Parsing threshold string [WARN]
log4j: Could not find root logger information. Is this OK?
log4j: Finished configuring.
Average time: 0.02854 in microseconds.
That's an increase of 50, but in percents this time. Interestingly,
enough the results are very similar in JDK 1.2.2; the numbers change
but the proportions don't.
Moral of the story? You are essentially right if the user knows what
she is doing.
It would be interesting to see if changing
private Category category = null;
to
final private Category category;
in org.apache.commons.logging.impl.Log4JCategoryLog would
change anything. It would be a nice experiment.
At 12:46 29.03.2002 +1100, you wrote:
On Fri, 29 Mar 2002 12:38, Ceki Gülcü wrote:
1) logging calls are made thousands of times so the indirection through
an equalizer API (like commons-logging) has a performance impact
Not in modern JVMs (read most almost all jdk1.3 impls).
As long as the underlying indirection (ie between commons and Log4j) is done
via a final variable then the cost is zero due to JVM optimizations. Theres
still the cost of the dynamic dispatch between user land code and commons
code but that cost is very very minimal compared to the rest of the logging
operations.
The cost comes in constructing the string objects (which is literally
thousands times more expensive than a dynamic dispatch) and routing the log
message.
As long as the API supports functions like isDebugEnabled() (which I believe
commons does? or at least did) then the performance cost is so negligable to
be unimportant.
In one word? Yes.
--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/
--
To unsubscribe, e-mail:
RE: Managing versions of Apache Jakarta software
Morning, I wrote: I'm not qualified to put forward any suggestions Sam replied: I respectfully disagree. Thanks Sam, I'll now bore you with my own opinion, and see if you change your mind.. ;-) I believe that there are two conflicting forces at work within Jakarta regarding cross sub-project dependancies, The first is the desire of individual sub-projects to provide their general users (the people who make the sub-projects' existence worthwhile) with a single distributable file from which a full working install can be made. James and Turbine(which has a version including tomcat) are examples of this. This gets positive feedback from users who want a shallow learning curve and a fast track to deploying the application. The second is the worthy and intelligent notion (exemplified by GUMP) that no cross project dependancies should be satisfied by an individual sub-project. This is based on the notion that to do so will inevitably lead people who are installing more than one sub-project to have to maintain duplicates of some API's that are depended upon (is there a word for that?) by more than one sub-project, logging and ant for instance. Tomcat source distributions are an (admittedly poor) example of this in that they don't distribute ant, but the build depends upon it, there may be better examples. I don't know how this helps to clarify the situation, but I expect a Jakarta registry is probably required, and the ability for sub-projects to define their classpaths as part of their installation procedure. In which case a manifest reading ant task could ensure dependancies are satisfied without sub-projects having to bundle them. This raises a couple of issues though.. a) it implies that there be an ant based installer for each application participating in the scheme b) it also implies that dependacy information and version compatibilities can be written and read in a useful way c) it may also require a seperate jakarta_lib to store common(shared not popular) jars, to remove them from individual project directory trees. d) smooth operation may also need a coherent jar version naming scheme, and download directory structure to be adopted by all participating sub-projects, so that ant can find the ones it needs to download. I think I'm going down the road of a kind of binary GUMP, where dependancies are satisfied not by building from cvs, but by downloading binaries. If I lose my job I know what to do.. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
Good point, except that the loop length was 100'000'000 so the cost of the first 10'000 calls would be dwarfed by the remaining 99'990'000. Of course there is also: ~/java Indirect 1 log4j: Parsing threshold string [WARN] log4j: Could not find root logger information. Is this OK? log4j: Finished configuring. Total: 0.0 in microseconds. Average time: 0.0 in microseconds. Point well taken nonetheless. At 22:01 29.03.2002 +1100, you wrote: Try changing your code to loop 10,000 times or so before you start the real test. This will make sure the JVMs are warmed up and all systems are configured properly. That should drop the difference even more in theory. -- Ceki My link of the month: http://java.sun.com/aboutJava/standardization/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
Even less valuable opinions inline :) Danny Angus [EMAIL PROTECTED] wrote on 29/03/2002 10:08:45 PM: I don't know how this helps to clarify the situation, but I expect a Jakarta registry is probably required, and the ability for sub-projects to define their classpaths as part of their installation procedure. In which case a manifest reading ant task could ensure dependancies are satisfied without sub-projects having to bundle them. See Maven's update-jars target. This raises a couple of issues though.. a) it implies that there be an ant based installer for each application participating in the scheme Maven creates an 'install-jar' as part of it's build process. b) it also implies that dependacy information and version compatibilities can be written and read in a useful way See the project descriptors for Gump Maven. c) it may also require a seperate jakarta_lib to store common(shared not popular) jars, to remove them from individual project directory trees. lib.repo, as defined in maven's properties. d) smooth operation may also need a coherent jar version naming scheme, and download directory structure to be adopted by all participating sub-projects, so that ant can find the ones it needs to download. I wish. I think I'm going down the road of a kind of binary GUMP, where dependancies are satisfied not by building from cvs, but by downloading binaries. See maven's update-jars target. If I lose my job I know what to do.. I know I've mentioned maven a lot here lately, but after checking out other stuff, and coming across it, it solves a ton of these problems, and is being developed here as well. The guys developing it are also open to feedback/criticism/junk. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing versions of Apache Jakarta software
On Fri, 29 Mar 2002 22:08, Danny Angus wrote: This raises a couple of issues though.. a) it implies that there be an ant based installer for each application participating in the scheme Maybe not an ant based installer. However what it does need is something that is equivelent to unixes ld.so. For those who are not aware ld.so is basically the linker for unix apps and it maintaines a cache of library data as stored in well known places (like /usr/lib, /usr/local/lib, /opt/lib etc). I have already written most of this about a year ago and plan to revive it for work on Ant2. b) it also implies that dependacy information and version compatibilities can be written and read in a useful way There is a java standard for this namely http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html. for a simple explanation see dependencies on http://jakarta.apache.org/ant/myrmidon/librarys.html I think I'm going down the road of a kind of binary GUMP, where dependancies are satisfied not by building from cvs, but by downloading binaries. cjan and jjar in commons started out trying to do that but I am not sure where they got. I believe they opted not to use the java standard versioning / optional package /extension scheme which makes them even less likely to be adopted unless there is much more widespread noise of them :) -- Cheers, Pete -- An intellectual is someone who has been educated beyond their intelligence. -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
So where does that leave us? Do you (Pete) believe that the work you're going to put into Ant2 and java versioning can address this satisfactorily in a generic way? What participation would it require from sub-projects wanting to adopt it? Should, perhaps, Jakarta be using our hard fought success with JSPA to propose a JSR defining an installation API that would address dependancy management in a cohesive way? It seems to me that dependancy handling in Java as a whole, not just here, has been left to fate rather than engineering, I have installed, on this machine, JDK 1.3 and 1.4 from Sun other developers will also have IBM's JVM installed as well, yet when I install JBuilder it installs its own JDK as well, and there are other products that do likewise. To me this is an indication that the extent of dependancy management problems is so great that sellers of commercial products cannot even reliably assume compatibility between minor versions of the JDK, let alone third party components. I would have thought that ought to concern anyone who's livelihood depends upon Java. Its all very well Java being platform independant but it really ought to provide a framework for dependacy management too, after all it is in effect an operating system (albeit more of an emulator) and library management should be a service provided by the os (IMO), and as producers of a range of interdependant products Jakarta is in dire need of this (again IMHO). d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
At 18:28 28.03.2002 -0800, you wrote: god no. The avalon group was already using a facade logger long before commons was for much the same reason commons adopted one. Is Avalon still using its own facade logger or changed to commons-logging? I'm just wondering: How many Jakarta projects use this common-logging package? What's the advantage of having a common logging package if it's not widely used even within the Jakarta community? One solution: all Jakarta projects must support both LogKit and Log4J (as they are both part of the family) by using commons-logging if they want to (but as logging is not the core business of many Jakarta projects, using the common-logging package makes sense). Another solution : drop one logger (don't shoot me!) and stand beside the winner. Users willing to use Jakarta projects will *have* to use the Jakarta logger. Sound M$-ish, doesn't it? Last solution : everyone stands where they are: pro-choice vs. pro-one-logger. Your allusion to Microsoft is interesting as much as it is troubling. For some reason everybody here takes the development of good software for granted. It takes a lot of energy and time. We waste much of it bickering among ourselves. Initially I was very saddened by this but now have grown accustomed to it. I do not expect to change anyones's mind. I am pretty sick of the politics and have much work to do. -- Ceki My link of the month: http://java.sun.com/aboutJava/standardization/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subproject layout conventions
-Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 28, 2002 5:12 PM To: Jakarta General List Subject: Re: subproject layout conventions Berin Loritsch [EMAIL PROTECTED] wrote: Attached is a small screenshot of the maven page with a white header. Aaah WINXPCRAP! :) Whatever hater ;P It pays the bills, ya know what I mean? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
Leo Simons wrote: I very much agree. I was under the impression though that at this point, there are some designers available somewhere. It would be good if they would explain which things would be good to change so we can put that into the system. There is no paid staff, and AFAIK, no designers who are also committers. And even if there was one, we can't depend on something like that. We can depend on there being programmers here, otherwise there would be no living products, and before long, no users or Website to worry about. except that the website is not only for geeks. It's also for people that make decisions and have money. Says who? I'm thinking Jakarta is a developer-to-developer site. If other stop by, they're welcome, but our focus has to be on what we know. Personally, I leave the eye-candy to others, and focus on functionality. Given the products we write here, I think that's going to very common. I'm not saying that I would be particularly interested in any design anyone else came up with. I'm just saying that if I need to change it, I'm going to change it, because there ain't nobody else here to do it. Personally, I'd say it's better that our sites don't look ~too~ good. That way people don't get the wrong impression. There is no commericial support here. Just a bunch of volunteers doing the best they can. Jakarta is an all-you-can-eat buffet, and should probably look like one :o) -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
On 3/28/02 5:14 PM, Ceki Gülcü [EMAIL PROTECTED] wrote: Possible but I would not be that sure. We will have very strong new features in log4j 1.3 (the release after 1.2) which will leave JDK 1.4 logging even further behind. Just as importantly, log4j documentation is going to get a massive boost with the upcoming log4j book. Sun's me-too strategy is bound to fail. The question is whether the bigger jakarta community is going to help us defeat JSR47 or stand in the way. Got your back... :) One way to 'defeat' it is being able to innovate faster and support user requirements rapidly as change in the J2xE specs seem to be rather slow moving. For example, you won't be able to iterate in JSP in a spec-compliant way until 2005 or something... Think about that - that's something like 6 years after you could do it in WebMacro, on which Velocity was modeled. Anyway... Now that you can (well, soon) legally implement JSR47's, you might was well support their interfaces and semantics, and then 'embrace and extend'. Just do the JSR47 stuff better :) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy - Ada Louise Huxtable -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
On 3/29/02 8:26 AM, Berin Loritsch [EMAIL PROTECTED] wrote: -Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 28, 2002 5:12 PM To: Jakarta General List Subject: Re: subproject layout conventions Berin Loritsch [EMAIL PROTECTED] wrote: Attached is a small screenshot of the maven page with a white header. Aaah WINXPCRAP! :) Whatever hater ;P It pays the bills, ya know what I mean? So do my Mac's running OS X. (OS X is another story...) It's java! Come to the light! ;- -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Java : the speed of Smalltalk with the simple elegance of C++... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
There was a discussion about an enterprise distribution of jakarta and other open-source java technologies some time back on this list that resulted in starting oed project on SourceForge [which is pretty much dead at the moment :-( ]. Which may suggest that there's more to solving this problem than meets the eye.. I'm nervous about tackling it because I think that it would take a massive effort to gain the kind of acceptance it would need to be worthwhile.. on the other hand.. how does RPM work? Personally I'm the impatient configure-make-make install guy mentioned in the README files ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
There is no paid staff, and AFAIK, no designers who are also committers. The maven layout looks like it has been designed by a designer. except that the website is not only for geeks. It's also for people that make decisions and have money. Says who? Me. I wan't to use jakarta stuff in the 'corporate' world. Parts of the corporate world want a 'sleek' looking site. Where it doesn't hamper anything else, I think there is no problem making the site look 'sleek'. Personally, I leave the eye-candy to others, and focus on functionality. I thin navigation is part of functionality, not eye-candy. Without navigation, you need to know the address of every web page on the site. I'm not saying that I would be particularly interested in any design anyone else came up with. I'm just saying that if I need to change it, I'm going to change it, because there ain't nobody else here to do it. I need to change it, so I want to do so. Since I believe the changes I need to make will benefit all of jakarta, I am trying to make them in a way that all of jakarta can live with. Personally, I'd say it's better that our sites don't look ~too~ good. Don't worry, we're not gonna look too good just yet :D That way people don't get the wrong impression. There is no commericial support here. Just a bunch of volunteers doing the best they can. Jakarta is an all-you-can-eat buffet, and should probably look like one :o) Jakarta is partly funded by commercial companies. I think some of them would rather not be associated with something looking like an all-you-can-eat ;) As long as we agree that nothing should get into the way of site functionality (and we do), why would you oppose a site that also is easy to navigate and looks good? regards, - Leo __ Launch your own web site Today! Create a Web site for your family, friends, photos, or a special event. Visit: http://www.namezero.com/sitebuilder -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Comments on the commons-logging API
Now that you can (well, soon) legally implement JSR47's, you might was well support their interfaces and semantics, and then 'embrace and extend'. Just do the JSR47 stuff better :) Could Log4J now become an RI of JSR47 ? (I'm still not completely clear about all this..) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
On Sat, 30 Mar 2002 02:36, Danny Angus wrote: Now that you can (well, soon) legally implement JSR47's, you might was well support their interfaces and semantics, and then 'embrace and extend'. Just do the JSR47 stuff better :) Could Log4J now become an RI of JSR47 ? (I'm still not completely clear about all this..) Not really and nor could you embrace and extend. Soon we will be allowed access to the TCKs (fingers crossed) which means we can implment the spec legally. However there has not been any change to any of the licenses regarding the specification materials which means it is still a violation of the license if you were to try and corrupt a spec or embrace and extend a spec by poorly-implementing it (and failing the TCK). However now we can at least implement the spec(s). -- Cheers, Pete - We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time -- T.S. Eliot - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
On 3/29/02 10:36 AM, Danny Angus [EMAIL PROTECTED] wrote: Now that you can (well, soon) legally implement JSR47's, you might was well support their interfaces and semantics, and then 'embrace and extend'. Just do the JSR47 stuff better :) Could Log4J now become an RI of JSR47 ? (I'm still not completely clear about all this..) Ceki is the guy to really talk to this but as I understand the process, it always *could* have. For example, the JSTL RI is Apache licensed OSS that is being done in the Jakarta Taglibs project. (Of course, they have have the sticky situation that until the spec license is changed, they technically can't distribute it but that is being solved with the recent JCP changes.) However, given the 'differences' between the spec lead and Ceki, I can't imagine this ever happening, nor could I imagine log4j's package structure getting changed to java.*, which it would have to be as 47 is part of JDK1.4... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Age and treachery will always triumph over youth and talent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
On 3/29/02 10:40 AM, Peter Donald [EMAIL PROTECTED] wrote: On Sat, 30 Mar 2002 02:36, Danny Angus wrote: Now that you can (well, soon) legally implement JSR47's, you might was well support their interfaces and semantics, and then 'embrace and extend'. Just do the JSR47 stuff better :) Could Log4J now become an RI of JSR47 ? (I'm still not completely clear about all this..) Not really and nor could you embrace and extend. Soon we will be allowed access to the TCKs (fingers crossed) which means we can implment the spec legally. However there has not been any change to any of the licenses regarding the specification materials which means it is still a violation of the license if you were to try and corrupt a spec or embrace and extend a spec by poorly-implementing it (and failing the TCK). However now we can at least implement the spec(s). I can't believe that's true. I can't see how they can prevent you from extending. I mean, every J2EE implementation 'embraces and extends' the J2EE spec because the specs leave out a lot. For example, you can't make a really useful JMS broker until you add proprietary extensions for clustering, load balancing, etc... Anyone that includes any functioning taglibs with a servlet container / jsp implementation is extending the spec as there are no useful tags in the spec. I can't see how anyone can complain if you pass the TCK. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subproject layout conventions
-Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] On 3/29/02 8:26 AM, Berin Loritsch [EMAIL PROTECTED] wrote: -Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Berin Loritsch [EMAIL PROTECTED] wrote: Attached is a small screenshot of the maven page with a white header. Aaah WINXPCRAP! :) Whatever hater ;P It pays the bills, ya know what I mean? So do my Mac's running OS X. (OS X is another story...) It's java! Come to the light! ;- I said it pays the bills, I didn't say it was the best... Besides, MS Word is not Java--and it costs too much not to have it bundled with a new machine. (I looked at Mac laptops, really). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
On Sat, 30 Mar 2002 02:48, Geir Magnusson Jr. wrote: On 3/29/02 10:40 AM, Peter Donald [EMAIL PROTECTED] wrote: On Sat, 30 Mar 2002 02:36, Danny Angus wrote: Now that you can (well, soon) legally implement JSR47's, you might was well support their interfaces and semantics, and then 'embrace and extend'. Just do the JSR47 stuff better :) Could Log4J now become an RI of JSR47 ? (I'm still not completely clear about all this..) Not really and nor could you embrace and extend. Soon we will be allowed access to the TCKs (fingers crossed) which means we can implment the spec legally. However there has not been any change to any of the licenses regarding the specification materials which means it is still a violation of the license if you were to try and corrupt a spec or embrace and extend a spec by poorly-implementing it (and failing the TCK). However now we can at least implement the spec(s). I can't believe that's true. I can't see how they can prevent you from extending. I mean, every J2EE implementation 'embraces and extends' the J2EE spec because the specs leave out a lot. For example, you can't make a really useful JMS broker until you add proprietary extensions for clustering, load balancing, etc... Anyone that includes any functioning taglibs with a servlet container / jsp implementation is extending the spec as there are no useful tags in the spec. I can't see how anyone can complain if you pass the TCK. Passing the TCK - thats the trick. Given that most (all?) TCKs require that the public interface conform exactly to that which is specified and that JSR47 is not made up of interfaces but instead made up of classes it would be difficult to pass the TCK if you added anything to it. You could create new output targets/appenders/whatever but they could not be in the java.** namespace. JSR47 should not be considered in the same category as the servlet/JMS/ejb specs - more in the same category as the Collection API. -- Cheers, Pete *-* * Faced with the choice between changing one's mind, * * and proving that there is no need to do so - almost * * everyone gets busy on the proof. * * - John Kenneth Galbraith * *-* -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
There was a discussion about an enterprise distribution of jakarta and other open-source java technologies some time back on this list that resulted in starting oed project on SourceForge [which is pretty much dead at the moment :-( ]. Which may suggest that there's more to solving this problem than meets the eye.. I'm nervous about tackling it because I think that it would take a massive effort to gain the kind of acceptance it would need to be worthwhile.. It would be a real shame for the lack of an total automated solution to lead to the lack of a simple manual solution. If administrators can manually check the explicit version of a JAR, rather than comparing sizes/datestamps, that would be a major improvement over today. Correctly version stamping JARs (using ANT today, or ANT future) would make operational configuration a lot less throw a pile of JARs together and pray... I still believe a simple Version bean would be very powerful, and easy to adopt, but since nobody's taken up what I've written then I guess I'm not proposing anything original/compelling, and that perhaps this is a road already travelled w/o end success. If there is a forum where folk feel a complete proposal [for just a version/version dependency class, nothing more] might be worthwhile please let me know, otherwise I'll go back to lurking. Thanks in advance. regards, Adam -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing versions of Apache Jakarta software
Danny Angus wrote: There was a discussion about an enterprise distribution of jakarta and other open-source java technologies some time back on this list that resulted in starting oed project on SourceForge [which is pretty much dead at the moment :-( ]. Which may suggest that there's more to solving this problem than meets the eye.. You got it, this is one of the main reasons. I'm nervous about tackling it because I think that it would take a massive effort to gain the kind of acceptance it would need to be worthwhile.. on the other hand.. how does RPM work? Personally I'm the impatient configure-make-make install guy mentioned in the README files ;-) RPM is neat and extremly clean and easy way to maintain software. This is what you get for all the tremendous work done by package creators. It maintains a central repository of packages installed and their dependencies. Unlike Windows registry it doesn't allow arbitrary garbage written to repository (AFAIK), it just uses it for package tracking. All you need to know as a user is a few switches to the RPM command: rpm -i (install) rpm -e (erase) rpm -U (update) rpm -V (verify) Task of a package creator is harder. (Here is a link with detailed information : http://www.rpm.org/max-rpm/ ). In short (in reality it is rather hard) package creators need to get sources, convert configure-make-make install into a special RPM spec for a target platform, build it into RPM. Implementing the same thing in Java should be easier. As with RPM there are same 3 roles involved that need to be supported (user, developer, packager). The goal is to make user tasks as easy as with RPM, while making packager task much easier, bringing it down to creating a simple XML spec. It helps that in Java, you don't need to compile sources for different platforms. Getting a distribution that includes JARs is enough. Also, I am pretty sure there is lots of sinergy with Ant, so many things do not need to be implemented from scratch. I've been holding this idea for a while since you won't find volunteers to help unless you lead such an effort and get it at least to beta, and I am very busy with Cayenne as it is right now. But I would happily participate as a developer, provided someone would take a lead. -- ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- - Andrei (a.k.a. Andrus) Adamchik Home of Cayenne - O/R Persistence Framework http://objectstyle.org/cayenne/ email: andrus-jk at objectstyle dot org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
It would be a real shame for the lack of an total automated solution to lead to the lack of a simple manual solution. If administrators can manually check the explicit version of a JAR, rather than comparing sizes/datestamps, that would be a major improvement over today. Correctly version stamping JARs (using ANT today, or ANT future) would make operational configuration a lot less throw a pile of JARs together and pray... I think the problem here is that we (obssessive Jakarta people) can't see the woods for the trees, it tends not to be such a problem to people who have a good working knowledge of the projects and their progress, if not their actual contents. Additionally this has been discussed before but no one made any concrete proposals (I don't think) Perhaps if you were to submit an idea for a simple manual/ant automated process someone might add it to the website for further discussion.. I believe someone was looking at writing guidlines for release managment but don't know what happened there. That might be a suitable place for it. At the end of the day it would, of course, be up to individual sub-projects whether or not to implement it, but you stand the best chance of this if you can present a clearly documented simple system for release managers and build script writers to follow. After all if it takes ten minutes to implement and doesn't conflict with anything else what is there to lose? Dont forget the principle of Apache, that changes often get submitted because users get so hacked off waiting for someone else that they submit them themselves. :-) d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
On 3/29/02 11:05 AM, Peter Donald [EMAIL PROTECTED] wrote: On Sat, 30 Mar 2002 02:48, Geir Magnusson Jr. wrote: On 3/29/02 10:40 AM, Peter Donald [EMAIL PROTECTED] wrote: On Sat, 30 Mar 2002 02:36, Danny Angus wrote: Now that you can (well, soon) legally implement JSR47's, you might was well support their interfaces and semantics, and then 'embrace and extend'. Just do the JSR47 stuff better :) Could Log4J now become an RI of JSR47 ? (I'm still not completely clear about all this..) Not really and nor could you embrace and extend. Soon we will be allowed access to the TCKs (fingers crossed) which means we can implment the spec legally. However there has not been any change to any of the licenses regarding the specification materials which means it is still a violation of the license if you were to try and corrupt a spec or embrace and extend a spec by poorly-implementing it (and failing the TCK). However now we can at least implement the spec(s). I can't believe that's true. I can't see how they can prevent you from extending. I mean, every J2EE implementation 'embraces and extends' the J2EE spec because the specs leave out a lot. For example, you can't make a really useful JMS broker until you add proprietary extensions for clustering, load balancing, etc... Anyone that includes any functioning taglibs with a servlet container / jsp implementation is extending the spec as there are no useful tags in the spec. I can't see how anyone can complain if you pass the TCK. Passing the TCK - thats the trick. Given that most (all?) TCKs require that the public interface conform exactly to that which is specified and that JSR47 is not made up of interfaces but instead made up of classes it would be difficult to pass the TCK if you added anything to it. Of course you would want to implement the API exactly You could create new output targets/appenders/whatever but they could not be in the java.** namespace. True. But you would still be able to offer a better implementation, and offer extensions if you desired. JSR47 should not be considered in the same category as the servlet/JMS/ejb specs - more in the same category as the Collection API. That's true but irrelevant - if the JSR47 leaves out features that people deem necessary, there is no reason why those can't be added as a 'vendor extension', unless the JSR is so broken you can't extend it w/o violating the API. (Like hardcoding the possible output targets choices as methods into the API...) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The cost of synchronization is much less that the cost of stupidity. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
Leo Simons wrote: As long as we agree that nothing should get into the way of site functionality (and we do), why would you oppose a site that also is easy to navigate and looks good? The only thing I oppose is the idea something being set in stone or approved by some mythical designer. http://www.mail-archive.com/general%40jakarta.apache.org/msg04500.html I need to change something, then I will change it. Everything is a shared resource here, and every committer is encouraged to take whatever action they feel prudent. I actually support what you are doing, so long as you remember who you are doing it for. The committers are the bosses here. Everything we do has to empower the committers and help them get past the adminutia and on with the development; or else there will be no committers, no products, no users, and no Web site. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing versions of Apache Jakarta software
Ainsi parlait Andrus Adamchik : [..] Task of a package creator is harder. (Here is a link with detailed information : http://www.rpm.org/max-rpm/ ). In short (in reality it is rather hard) package creators need to get sources, convert configure-make-make install into a special RPM spec for a target platform, build it into RPM. ignomious self-publicity And also keep track of dependency developpers didn't explicitly provided, discard binary files and look for sources everywhere on the net, find a global coherency among hundreds of different practices, adapt to platform-specific standards, deal with license nightmare, cope with crazy archive formats, etc... Curiously in java world, packager work is generaly is at best misunderstood, often ignored, or even seen with some hostility from developpers. But the result is here: jpackage project covers today more than a hundred of different java projects. See http://jpackage.sourceforge.net for complete list. /ignomious self-publicity -- Guillaume Rousse [EMAIL PROTECTED] GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing versions of Apache Jakarta software
I hear you. And I think I understand pretty well ;-). Therefore I was looking at your project as an example how this should be done in Java world. Guillaume Rousse wrote: Curiously in java world, packager work is generaly is at best misunderstood, often ignored, or even seen with some hostility from developpers. But the result is here: jpackage project covers today more than a hundred of different java projects. See http://jpackage.sourceforge.net for complete list. /ignomious self-publicity -- ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- - Andrei (a.k.a. Andrus) Adamchik Home of Cayenne - O/R Persistence Framework http://objectstyle.org/cayenne/ email: andrus-jk at objectstyle dot org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
Hi, (if this is getting too OT tell me to sling my hook) I just printed and read the jdk 1.3 optional packages versioning document (again) then found this .. http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/extensions.ht ml the section on Java Extensions Installation made interesting reading. What is anyones opinion of the issues raised by installing Jakarta components in this way (into lib/ext), rather than as bundled jars in the application classpath? I understand that it raises security questions, but am on shaky ground about the impact of these, what other concerns are there? (what is the Jakarta policy on signing jars, is there a jakarta certificate or certification authority, if not should there be?) I also wonder how this method would work in practice where applications have their own classloader, for instance I put my JDBC drivers into tomcats common directory for use by all my servlet applications. If I installed them (complete with acceptable manifest) as extensions would my servlet application find them correctly, and find the correct versions? If so why don't I know about this already..(don't answer that!) Furthermore.. if I have a singleton which is placed in tomcats common directory only one instance will be created across all webapps, if it is in the WEB-INF/lib a new one will be created for each app. What is the implication of generalising the scope by installing it in the /lib/ext/ of my JVM? I assume there will still be one instantiated for each running instance of the JVM, but am I wrong in this assumption? It seems to me that we have here a mechanism with plenty of potential to reduce the duplication of jars, and what needs to be done is to create an installation manager which can check dependancies and install jars as required. Particularly as both the implementation and specification version manifest attributes can be used to precisely define dependancies, and compatibility. Perhaps there should be a jakarta environment project (tied in some way to GUMP?) oh no we've been here already haven't we.. ah well, at least I caught up eventually. :-) Ho hum, time I stopped doing this and spent some quality time with my family.. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Comments on the commons-logging API
At 15:36 29.03.2002 +, Danny Angus wrote: Now that you can (well, soon) legally implement JSR47's, you might was well support their interfaces and semantics, and then 'embrace and extend'. Just do the JSR47 stuff better :) Could Log4J now become an RI of JSR47 ? (I'm still not completely clear about all this..) No, it cannot. JSR47 is not an some network protocol or an abstract description of an interface, coding rules etc. It is a nuts and bolts implementation. Jason Hunter also mentioned some rule about being part of the JDK 1.4 umbrella JSR which apparently changes things. (Don't ask me why.) -- Ceki My link of the month: http://java.sun.com/aboutJava/standardization/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
