Re: [VOTE] Release Commons Transaction 1.2
Go for it! +1 Daniel -- Forwarded message -- From: Oliver Zeigermann [EMAIL PROTECTED] Date: 04.03.2007 17:19 Subject: [VOTE] Release Commons Transaction 1.2 To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Folks! Every now and then I make a new approach to finally release commons transaction 1.2. I have created a branch for the 1.2 version now TRANSACTION_1_2_RELEASE_BRANCH and a release tag TRANSACTION_1_2_RELEASE And have put up the rc4 to http://people.apache.org/~ozeigermann/tx-1.2rc4/ for inspection. This includes the distributions and a preview of the site updated for 1.2. To release 1.2 final based on that release candidate here is my +1 Cheers Oliver
AW: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n support)
Hi Jörg, Thanks for your comments. See my comments inline. Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Joerg Hohwiller Gesendet: Mittwoch, 10. August 2005 20:21 An: Jakarta Commons Developers List Betreff: Re: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n support) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Florey wrote: Hi Jörg, Hi Daniel, I looked at your proposal for quite a while but couldn't figure out the advantage of your approach. If you want to improve the i18n component every comment or suggestion is very welcome as we try to push it towards to a 1.0 release and move it to commons proper once all remaining issues are resolved. So: Maybe I'm dumb but please give me a simple example that shows me what exactly you want to improve. Im am sure you are not, maybe I did not make it very clear... Exceptions occure in critical situations and should help to figure out what went wrong. Now if your MessageManager fails for whatever reason to get the appropriate text you only have a message key and currently you even throw another exception. So creating an exception might cause another exception. In my oppinion there should always be a fallback to get the message in the default language which is english (I am not an englishman). You will not get an exception. You can throw/catch the LocalizedException. If you display the error details in a language where no message is available, it will either: - Throw a MessageNotFoundException if you don't provide a default text Or - Print the given default text Should I make this clear in the docs? Further there are many guys out there that discovered that static coding is not always the best thing to do (e.g. talk to all the IoC container freaks). So if the design would be a more open (so the mechanism for lookup can be replaced without getting into your code) you would not scare away those folks. I don't see how to get rid of the static methods in the MessageManager and why? Here are some of my suggestions: For your bundle (LocalizedBundle): - -create an interface The LocalizedBundle contains some logic, so it cannot be an interface. Should we introduce a new interface that gets implemented by LocalizedBundle? I think this would introduce additional complexity, but I'll think about it again. - -replace getArguments() with getArgument(int) and getArgumentCount() Why? Why is LocalizedBundle not in the bundle package? It's because of the lack of friend keyword in java. Do not resolve the message in the constructor of the exception, but store the acutal bundle object. Override the getMessage() method to return the actual message from the bundle (in my case in english) and add a getMessage() method that takes a parameter for the localization. The message is not resolved in the constructor! It will be translated when you retrieve it. - From your point of view the Locale and from my point of view the so called StringTranslator. I don't see why to introduce StringTranslator. The approach using Locale directly works fine. Do the same thing for printing stacktraces. Override the getLocalizedMessage() to do something appropriate (e.g. calling getMessage(Locale.getDefaultLocale()). Good point! I can see the missunderstanding now: The object that you call bundle (LocalizedBundle) and I called message (NlsMessage) do not completely match: Your bundle stands for a set of informations (title, summary, details) while my message stands for one information. I put the information in english language into the message object, but keep the arguments separate. The english message just comes by filling the arguments with MessageFormat. For n8n the core english message (without arguments) is translated to another language before. I can currently imagine of a compromise of both approaches, but it might not be an easy process. Anyways I actually think we could both learn from the other approach and get an improvement to both solutions. The question is if the both improved solutions could be the same :) So if you want to have your 1.0 done soon I'd not suggest to get too deep into this, but maybe you are interested. To get a little impression you might look at the following URLs. The problem is that I am in big trouble with my project because I could not live with cvs anymore after I got addicted to svn. So the sourceforge cvs of my project is more than a year old. But the current svn is not accessible right now and sf.net does not get their svn service ready. Anyways better than nothing: http://m-m-m.sourceforge.net/mmm-base/xref/index.html http://m-m-m.sourceforge.net/mmm- base/xref/net/sf/mmm/nls/api/NlsMessageIF.html Cheers, Daniel Regards Jörg ps: would you mind turning off your n8n for mail prefixes (AW instead of RE) to not get Re: Aw: Ref: Re: constructions? -BEGIN PGP
AW: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n support)
Hi Jörg,
I looked at your proposal for quite a while but couldn't figure out the
advantage of your approach.
If you want to improve the i18n component every comment or suggestion is
very welcome as we try to push it towards to a 1.0 release and move it to
commons proper once all remaining issues are resolved.
So: Maybe I'm dumb but please give me a simple example that shows me what
exactly you want to improve.
Cheers,
Daniel
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Joerg Hohwiller
Gesendet: Mittwoch, 10. August 2005 18:40
An: Jakarta Commons Developers List
Betreff: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n
support)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi again,
Still bleeding for response on my mail, but:
It seems that my ideas are NOT completely new (not suprisingly since
they are quite obvious):
There is a similar thing in
org.apache.commons.i18n.bundles.MessageBundle
org.apache.commons.i18n.LocalizedException
but my idea was also to NOT use message-keys that end up in the
exception being not translateable if the according message for the
supplied key can not be found and is not as natural for the programmer
that wants to use constants like provided in my example.
Further I would like to have a more open architecture that uses
interfaces and allows the end-user to pass an instance of its own
implementation (e.g. for MessageBundle).
If there is a i18n community out there (heho, come on!) please discuss
with me - I want to get involved.
Take care
Jörg
Joerg Hohwiller wrote:
Hi there,
in my project I started an approach for deep native language support
(NLS). It is very simple and I start liking it. Because it is so
fundamental, I would love to place it into the JDK. Since that is not
going to happen (and the JCP is even after JSR-99 still far away from
cathing up the spirit of open-source - mmhm this is not the harmony
project here ... :) ) I though about suggseting the idea for commons
lang.
I can send some code, but I want to point out the idea in the first
place.
If you are familiar with NLS you will know java.text.MessageFormat.
Additionally you might have experienced that the support of the JDK for
NLS in multi-user applications is pretty poor if you say at all that it
is there.
Now why on earth do not just bundle the format pattern (which is the
internationalized message) together with the arguments to fill in into
an object that I call NlsMessage. Besides the getters to get the pattern
and the arguments back, there will be a method to get the full message
with filled in arguments using MessageFormat. Additionally there is a
method that does the same thing but translates the message before by
taking as argument a call-back interface that I call StringTranslator.
That is the simplest interface possible for doing a translation: it has
one method String translate(String) that translates a given String
into a different language.
Now where is this all leading to?
An Exception takes a string as message. My enhancement is to take an
NlsMessage instead - there can be still the String construtor available.
This allows true NLS support on exceptions. You know what the
getLocalizedMessage() was intendet to be for.
Now lets come to the magic part how on earth the StringTranslator
interface can be implemented without having a bablefish.
I define an abstract class that I may call NlsResourceBundle (it might
extend ResourceBundle and Serializable or go the commons-resources way)
that adds a method to reverse-lookup the key of a message via
reflection.
So if I extend that class and call that MyBundle and add String
constants as
public static String ERROR_ILLEGAL_INT_VALUE = The value was expected
to be an integer. However the value \{0}\ is no integer!;
Now I somewehere do
throw new NlsException(MyBundle.ERROR_ILLEGAL_INT_VALUE, value);
Now the string translator can be a component where MyBundle is
registered so it can be used to reverse-lookup the key
ERROR_ILLEGAL_INT_VALUE and that key will be used to get the message
in the language choosen by the current users locale.
So to keep the approach leight-weight the proposal would not contain
a complete NLS service solving the full issue but only includes the
core stuff to make this available by providing:
NlsMessage (maybe as interface with default implementation to allow
people to put their own magic in for direct translation from the
toString() method, what would not really be my suggestion, however)
StringTranslator (interface)
NlsException with the constructors
(String), (String, Throwable), (NlsMessage), (NlsMessage, Throwable)
and a printStracktrace method that takes a StringTranslator.
NlsResourceBundle (or however we may call it)
Most people do not care about NLS in exceptions or at all. But
AW: [i18n PATCH] Adding provider qualifying
Hi,
I try to have a look at the patch and the missing unit tests soon. I'm very
busy at the moment, but hopefully next week I'll find some time.
Thanks for your work!
Daniel
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Mattias J
Gesendet: Donnerstag, 19. Mai 2005 09:13
An: Jakarta Commons Developers List; Daniel Florey
Betreff: [i18n PATCH] Adding provider qualifying
I have previously discussed with Daniel Florey a change that allows the
user to qualify the provider (or source or namespace) to be used for a
given text entry. My main motivation for this is to allow the same entry
key in several different text sources, but this also provides better
performance since the API does not have to loop over the different
providers in search for the given entry.
Thanks to James Mitchell I am now able to create the diff for this change;
see below. I would be happy if Daniel or anybody else would review and
commit this patch.
Included in the patch is also a minor change that allows non-string
ResourceBundle entries to be used (via toString()).
After this there are a few more changes I would like to discuss -
conserning class and package dependencies among others - so Daniel, please
tell me when you are available again. I also hope to find the time to
create an example DatabaseProvider.
Now here is the diff.
(Again, if lines are wrapped in the e-mail, I can provide the diff by
personal e-mail or in a bugzilla entry).
Index: src/test/org/apache/commons/i18n/MockProviderTestBase.java
===
--- src/test/org/apache/commons/i18n/MockProviderTestBase.java
(revision
170884)
+++ src/test/org/apache/commons/i18n/MockProviderTestBase.java
(working
copy)
@@ -30,36 +30,41 @@
* @author Mattias Jiderhamn
*/
public abstract class MockProviderTestBase extends TestCase {
-/**
- * Mock message provider that returns a string made up of the
arguments passed to it.
- */
-final private MessageProvider mockMessageProvider = new
MessageProvider() {
-public String getText(String id, String entry, Locale locale)
throws MessageNotFoundException {
-return MockProviderTestBase.getMockString(id, entry, locale);
-}
-public Map getEntries(String id, Locale locale) throws
MessageNotFoundException {
-Map output = new HashMap();
-output.put(entry1,
MockProviderTestBase.getMockString(id,entry1,locale));
-output.put(entry2,
MockProviderTestBase.getMockString(id,entry2,locale));
-return output;
-}
-};
-
public void tearDown() {
/* Remove mock provider after each test, to allow for
MessageNotFoundExceptions */
-MessageManager.removeMessageProvider(mock);
-removeThrowingMockProvider();
+MessageManager.clearMessageProviders();
}
/**
* Add mock provider to codeMessageManager/code.
*/
protected void addMockProvider() {
-MessageManager.addMessageProvider(mock, mockMessageProvider);
+addMockProvider(mock);
}
/**
+ * Add mock provider to codeMessageManager/code.
+ */
+protected void addMockProvider(final String providerId) {
+ // Mock message provider that returns a string made up of the
arguments passed to it.
+MessageProvider mockMessageProvider = new MessageProvider() {
+public String getText(String id, String entry, Locale locale)
throws MessageNotFoundException {
+return MockProviderTestBase.getMockString(providerId, id,
entry, locale);
+}
+
+public Map getEntries(String id, Locale locale) throws
MessageNotFoundException {
+Map output = new HashMap();
+output.put(entry1,
MockProviderTestBase.getMockString(providerId,id,entry1,locale));
+output.put(entry2,
MockProviderTestBase.getMockString(providerId,id,entry2,locale));
+return output;
+}
+};
+
+MessageManager.addMessageProvider(providerId,
mockMessageProvider);
+}
+
+/**
* Add provider that always throws error to
codeMessageManager/code.
*/
protected void addThrowingMockProvider() {
@@ -82,10 +87,19 @@
// Utility methods
+public static String getMockString(String providerId, String id,
String entry, Locale locale) throws MessageNotFoundException {
+return ((providerId != null) ? Source= + providerId + : )
+
+Id= + id + Entry= + entry + Locale= + locale +
;
+}
+
public static String getMockString(String id, String entry, Locale
locale) throws MessageNotFoundException {
-return Id= + id + Entry= + entry + Locale= + locale
AW: SSH access to jakarta.apache.org
Hi, same for me. Just tried to update the sandbox/i18n site and failed :( Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Oliver Zeigermann Gesendet: Donnerstag, 5. Mai 2005 19:02 An: Jakarta Commons Developers List; Jakarta General List Betreff: SSH access to jakarta.apache.org Folks! As already said it seems I will need SSH access to jakarta.apache.org to update the jakarta commons transaction website - which I am a committer for. Is that right? If so who can grant that for me? Thanks, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [i18n] Providers behave different
This really needs to be changed. What is the most desirable behaviour for these cases? I'd suggest including the missing entries defined for the default locale if the entries for another language are requested. So the XMLMessageProvider needs to be changed. Or makes it sense to have two different methods for this? For the latter issue I need to have a closer look at the code. Thanks for reporting these important issues! Daniel BTW: I'm back home. If you want me to add your testcases just mail the zip file to me. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Mattias J Gesendet: Donnerstag, 21. April 2005 15:41 An: commons-dev@jakarta.apache.org Betreff: [i18n] Providers behave different It seems that the ResourceBundleMessageProvider and the XMLMessageProvider behaves differently when an entry does not exist in a non-default language. With ResourceBundles, if I have an entry, say helloWorld.notTranslated=This entry is not translated to any other languages that only exists in the default locale file, the entry will be included when calling getEntries() for *any* locale. Whereas for XML, only the entries defined for the given locale will be returned. Furthermore if the id (parent) exists, but the entry (child) does not, the ResourceBundleMessageProvider throws an exception (erroneously claiming No message entries found for bundle with key ...), while the XMLMessageProvider returns null. Daniel, I assume the first issue is not intended but only a consequence of the most obvious implementation? Does either need to be changed? Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
Jakarta Commons Developers List commons-dev@jakarta.apache.org schrieb am 19.04.05 21:34:01: LocalizedExceptionExample (and subsequent property files) look like good candidates for src/test. Also, someone might want to commit the missing files that make this class work/load properly. I seem to be missing some property files (that are used internally). I'll have a look at this next week (when I'm back home). Did i miss to check in some files? Shame on me... What's the status of this project? I recall some discussion a while back about i18n, but don't remember the specifics? Are there any design or architecture docs available? This component is so tiny that the javadoc should be pretty self explaining. But I agree that we might need to add some more documentation (tutorials). Seems like i18n is reinventing the wheel over and over. I see we are using of Sax, when Digester is the most viable choice, given the typical clients of this framework. I see where ResourceBundle is used, yet a much more robust solution is already provided through Commons Resources. Any chance we can change this to use the above frameworks? My primary goal was to keep this component simple. It has no dependencies to other jars and that is a big plug for the daily use. Remember my thread about the missing ability in the java world to deal with different versions of the same class. So using digester/resources could cause a lot of trouble to bigger projects using a different version of these components. I know that we have some overlapping with Commons Resources, but the I18n is dealing with bundles of messages and introduces LocalizedExceptions using these bundles. As I needed this already in different projects seriously dealing with internationalization, personally I still think this component is reasonable. Cheers, Daniel -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Daniel Florey [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Tuesday, April 19, 2005 10:34 AM Subject: Re: [i18n] Entry qualifier Jakarta Commons Developers List commons-dev@jakarta.apache.org schrieb am 19.04.05 16:05:57: I'm wrapping up development of a new Struts plug-in that integrates CommonsResources and is backward compatible with Struts 1.1. After that I can throw some time your way. I'm getting pretty good with Maven and JUnit stuff is always a valued resource. If you guys are not already doing so, adding a JCoverage report (which is trivial if using Maven) is one of the best ways ensure code completeness, efficiency, and guarantees your changes won't break anything. Eventually, I'll be adding an i18n plug-in and sample app for Struts that demonstrates a best practices for using i18n in a Struts-based app. I could use some help with that if any of you want to return the favor ;) This is great news! If I find some time I'd like to assist you. It would be a great benefit to have the capability of LocalizedException and all of this in Struts. Cheers, Daniel By the way, thanks for all the hard work! -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Mattias J [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Tuesday, April 19, 2005 9:22 AM Subject: Re: [i18n] Entry qualifier What I currently need is better unit tests in ResourceBundleMessageProviderTest.java and XMLMessageProviderTest.java. After those are set up, I will begin some refactoring. If you would like to help out on those unit tests it would be great. Please inform me if you get your hands at it, and which one you start with, so I don't do the same thing. Also please e-mail them to me if you are done before Daniel is back and able to check it in. At 2005-04-19 15:13, you wrote: If I can help ... I still alive Woody ''-- Mensagem Original -- ''Reply-To: Jakarta Commons Developers List commons-dev@jakarta.apache.org ''Date: Tue, 19 Apr 2005 13:34:41 +0200 ''From: Daniel Florey [EMAIL PROTECTED] ''To: Jakarta Commons Developers List commons-dev@jakarta.apache.org ''Subject: Re: [i18n] Entry qualifier '' '' I have created unit tests for MessageManager and '' LocalizedBundle/-Error/-Exception/-RuntimeException. '' Should I post them to the list? '' Would you like them in a ZIP archive Daniel? '' ''I'm back home next week, so if you would pass them to me in a ZIP this would
RE: [i18n] Entry qualifier
Jakarta Commons Developers List commons-dev@jakarta.apache.org schrieb am 20.04.05 09:38:37: Hi Daniel, Daniel Florey wrote on Wednesday, April 20, 2005 9:24 AM: [snip] My primary goal was to keep this component simple. It has no dependencies to other jars and that is a big plug for the daily use. +1 This was the main reason I chose i18n. No deps, no new problems. Remember my thread about the missing ability in the java world to deal with different versions of the same class. So using digester/resources could cause a lot of trouble to bigger projects using a different version of these components. I know that we have some overlapping with Commons Resources, but the I18n is dealing with bundles of messages and introduces LocalizedExceptions using these bundles. As I needed this already in different projects seriously dealing with internationalization, personally I still think this component is reasonable. I really liked this light-weight approach. I had a need of localized MBeanInfo (see contribution) and with i18n's concept, I was able to write also just a little Bundle impl, that is based on some conventions for the provided resources. BTW: Just because I did not mension this in Bugzilla - the contribution does not have external deps either. Onle the javadoc has a link to MBeanInfo, the code does use no JMX fucntionality at all. Regards, Jörg Hi Joerg (sorry - keine Umlaute hier in Jordanien...), thanks for your contribution! I'll take a look at it next week. Do you have commit access in the sandbox? Cheers, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [i18n] Entry qualifier
Jakarta Commons Developers List commons-dev@jakarta.apache.org schrieb am 20.04.05 09:38:37: Hi Daniel, Daniel Florey wrote on Wednesday, April 20, 2005 9:24 AM: [snip] My primary goal was to keep this component simple. It has no dependencies to other jars and that is a big plug for the daily use. +1 This was the main reason I chose i18n. No deps, no new problems. Remember my thread about the missing ability in the java world to deal with different versions of the same class. So using digester/resources could cause a lot of trouble to bigger projects using a different version of these components. I know that we have some overlapping with Commons Resources, but the I18n is dealing with bundles of messages and introduces LocalizedExceptions using these bundles. As I needed this already in different projects seriously dealing with internationalization, personally I still think this component is reasonable. I really liked this light-weight approach. I had a need of localized MBeanInfo (see contribution) and with i18n's concept, I was able to write also just a little Bundle impl, that is based on some conventions for the provided resources. This looks really usefull to me. Shall we add an i18n-contrib.jar that contains all the optional extensions? I'd like to keep the core i18n.jar as small as possible... Cheers, Daniel BTW: Just because I did not mension this in Bugzilla - the contribution does not have external deps either. Onle the javadoc has a link to MBeanInfo, the code does use no JMX fucntionality at all. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
Jakarta Commons Developers List commons-dev@jakarta.apache.org schrieb am
18.04.05 20:08:29:
Will Ant be abandoned in favor of Maven or should I update the Ant script
to include the unit tests? (I have no experience with Maven)
We should keep both (ant/maven) working. There is a maven task that will
automatically generate an ant script, but I've never used it.
Maven is a great tool as it can also handle website generation, test reports,
changelog etc. So it's worth to have a look at it!
What indentation do you use for XML? I find both tabs and 2 spaces, even in
the same file. (There is also a tab on line 80 in LocalizedBundle.java)
Uuups, this should be fixed. What do you prefer for indenting xml files?
I have set up the environment and started working on some unit tests. I
think one of them caught a bug in MessageHandler. My guess is
try {
String text = getText(id, entry, arguments, locale);
return MessageFormat.format(text, arguments);
} catch (MessageNotFoundException e) {
return defaultText;
}
should read
try {
return getText(id, entry, arguments, locale);
} catch (MessageNotFoundException e) {
return MessageFormat.format(defaultText, arguments);
}
right?
Right again, you are the man! Keep on your great work, I look forward to
incorporate your changes.
Daniel
(B.t.w. is there a tutorial on creating SVN patches somewhere?)
Mattias Jiderhamn
At 2005-04-18 13:24, Daniel Florey wrote:
Jakarta Commons Developers List commons-dev@jakarta.apache.org schrieb
am 18.04.05 11:29:38:
At 2005-04-18 11:11, Daniel Florey wrote:
My though was to re-use the basename or id used when installing
ResourceBundle or XML providers. For example, after issuing
ResourceBundleMessageProvider.install(errorMessages);
I would like to be able to qualify the newly installed messages with
MessageBundle msg = new MessageBundle(errorMessages,
unexpectedError);
but also keep the existing alternative with
MessageBundle msg = new MessageBundle(unexpectedError); //
unexpectedError from any source
Do you want this to be able to install different resources with the same
message key or is it mainly because of implementation details
(performance)?
Primarily multiple entries with same key, secondarily performance.
This may seem like a minor change at a first glance, but to also
improve
performance my thought was to to change the MessageManager class from
holding a list of provider instances - which in turn can contain
multiple
resources (and thus assumes one instance per provider class) - to
holding a
Map from basename/id/namespace/qualifier to provider instance,
where each
instance only contains a single resource (i.e.
XML-file/ResourceBundle).
Though I planned on backwards compatibilty, by looping over the Map
values
- instead of the List entries - in the current
MessageManager.getText()
method.
(Did I make myself clear?)
I try my best to get your point...
At the moment there is only one MessageProvider holding many resources.
You want to change this to many MessageProviders holding one resource
each
in order to improve performance?
Yes. Instead of having to loop through the providers - catching exceptions
from those who do not contain the entry, which is quite costly performance
wise - and get the first match, I want to be able to point out the source
which I expect to hold the entry. But then again, todays behaviour should
be kept as the default behaviour when not using a basename/namespace
qualification.
I currently don't have access to the sources as I'm on a project in
Jordan
(You can browse them online,
http://jakarta.apache.org/commons/sandbox/i18n/xref/index.html is quite
easy to navigate)
but as soon as I'm back home I'll try to have a closer look at this.
Should I try to create a patch suggestion which you could look at then?
Yes, this would be great!
It would be very (very) appreciated, if you could provide some
testcases... I started to write some a while ago, but never managed to
complete them. If we would have a complete testsuite we could refactor
without the fear to break something ;-)
If we get the testsuite done and improve the documentation, we hopefully
can move the component to commons proper soon...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
Re: [i18n] Entry qualifier
Jakarta Commons Developers List commons-dev@jakarta.apache.org schrieb am 19.04.05 11:27:33: At 2005-04-19 10:35, Daniel Florey wrote: We should keep both (ant/maven) working. There is a maven task that will automatically generate an ant script, but I've never used it. Maven is a great tool as it can also handle website generation, test reports, changelog etc. So it's worth to have a look at it! I probably should, some day, but right now I want to focus on the tests and changes so I'll stick with Ant meanwhile. What indentation do you use for XML? I find both tabs and 2 spaces, even in the same file. (There is also a tab on line 80 in LocalizedBundle.java) Uuups, this should be fixed. What do you prefer for indenting xml files? I prefer spaces. Personally I use 2 spaces to save up on columns/width. Keep on your great work, I look forward to incorporate your changes. I have created unit tests for MessageManager and LocalizedBundle/-Error/-Exception/-RuntimeException. Should I post them to the list? Would you like them in a ZIP archive Daniel? I'm back home next week, so if you would pass them to me in a ZIP this would be the easiest way yo go. Thanks Daniel Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
Jakarta Commons Developers List commons-dev@jakarta.apache.org schrieb am 19.04.05 16:05:57: I'm wrapping up development of a new Struts plug-in that integrates CommonsResources and is backward compatible with Struts 1.1. After that I can throw some time your way. I'm getting pretty good with Maven and JUnit stuff is always a valued resource. If you guys are not already doing so, adding a JCoverage report (which is trivial if using Maven) is one of the best ways ensure code completeness, efficiency, and guarantees your changes won't break anything. Eventually, I'll be adding an i18n plug-in and sample app for Struts that demonstrates a best practices for using i18n in a Struts-based app. I could use some help with that if any of you want to return the favor ;) This is great news! If I find some time I'd like to assist you. It would be a great benefit to have the capability of LocalizedException and all of this in Struts. Cheers, Daniel By the way, thanks for all the hard work! -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Mattias J [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Tuesday, April 19, 2005 9:22 AM Subject: Re: [i18n] Entry qualifier What I currently need is better unit tests in ResourceBundleMessageProviderTest.java and XMLMessageProviderTest.java. After those are set up, I will begin some refactoring. If you would like to help out on those unit tests it would be great. Please inform me if you get your hands at it, and which one you start with, so I don't do the same thing. Also please e-mail them to me if you are done before Daniel is back and able to check it in. At 2005-04-19 15:13, you wrote: If I can help ... I still alive Woody ''-- Mensagem Original -- ''Reply-To: Jakarta Commons Developers List commons-dev@jakarta.apache.org ''Date: Tue, 19 Apr 2005 13:34:41 +0200 ''From: Daniel Florey [EMAIL PROTECTED] ''To: Jakarta Commons Developers List commons-dev@jakarta.apache.org ''Subject: Re: [i18n] Entry qualifier '' '' I have created unit tests for MessageManager and '' LocalizedBundle/-Error/-Exception/-RuntimeException. '' Should I post them to the list? '' Would you like them in a ZIP archive Daniel? '' ''I'm back home next week, so if you would pass them to me in a ZIP this would ''be the easiest way yo go. ''Thanks ''Daniel '' '' ''Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
Jakarta Commons Developers List commons-dev@jakarta.apache.org schrieb am 19.04.05 17:07:46: I have now added more tests to ResourceBundleMessageProviderTest. If I find time tomorrow, I might look at adding coverage or more XMLMessageProvider tests. Though I do not have commit access to SVN, so I assume I cannot get hold of the Clover license. Daniel: Since you are not home until next week, I will continue work and then mail you what I've got. +1 Thanks for your work!! Mattias Jiderhamn At 2005-04-19 15:22, Mattias J wrote: What I currently need is better unit tests in ResourceBundleMessageProviderTest.java and XMLMessageProviderTest.java. After those are set up, I will begin some refactoring. If you would like to help out on those unit tests it would be great. Please inform me if you get your hands at it, and which one you start with, so I don't do the same thing. Also please e-mail them to me if you are done before Daniel is back and able to check it in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Status?
Hi Mattias, I'm still taking care of this project. Any suggestions and proposals are appreciated! The I18n-component should be pretty stable and I used in in several projects. See comments inline... Jakarta Commons Developers List commons-dev@jakarta.apache.org schrieb am 18.04.05 10:05:34: The i18n sandbox project seems to be quite similar to Commons Resources. What is the relationship between the two? Will they continue to co-exist? I realized this after developing the I18n component ;-) Still I think I18n is worth to be kept as it is very simple and introduces the concept of bundles and localized exceptions (that I required very often). i18n is appealing to me because it allows for multiple properties (such as title and details) under a common key. We solve very similar problems in our project, but I would like to use a generic API reusable among several projects. Although I see some changes I would like to make ti i18n. For example, I'd like the ability to qualify the entry with a source (i.e. base name). This requires some other changes of the internal structure. Do you want to introduce something like a namespace for message keys? I've been thinking of something comparable in the past but dropped it as it would introduce addintional complexity. You can add namespaces by prefixing the message-keys. But I'm easy to convince if I'm wrong... Is somebody actively working on this project, or can I try some refactoring and additions and contribute suggestions? Please post your suggestions to the mailinglist so that they can be discussed in public. Thanks in advance, Mattias Jiderhamn Thanks Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier (was Re: Status?)
Jakarta Commons Developers List commons-dev@jakarta.apache.org schrieb am 18.04.05 10:56:58: At 2005-04-18 10:33, Daniel Florey wrote: i18n is appealing to me because it allows for multiple properties (such as title and details) under a common key. We solve very similar problems in our project, but I would like to use a generic API reusable among several projects. Although I see some changes I would like to make ti i18n. For example, I'd like the ability to qualify the entry with a source (i.e. base name). This requires some other changes of the internal structure. Do you want to introduce something like a namespace for message keys? I've been thinking of something comparable in the past but dropped it as it would introduce addintional complexity. You can add namespaces by prefixing the message-keys. My though was to re-use the basename or id used when installing ResourceBundle or XML providers. For example, after issuing ResourceBundleMessageProvider.install(errorMessages); I would like to be able to qualify the newly installed messages with MessageBundle msg = new MessageBundle(errorMessages, unexpectedError); but also keep the existing alternative with MessageBundle msg = new MessageBundle(unexpectedError); // unexpectedError from any source Do you want this to be able to install different resources with the same message key or is it mainly because of implementation details (performance)? This may seem like a minor change at a first glance, but to also improve performance my thought was to to change the MessageManager class from holding a list of provider instances - which in turn can contain multiple resources (and thus assumes one instance per provider class) - to holding a Map from basename/id/namespace/qualifier to provider instance, where each instance only contains a single resource (i.e. XML-file/ResourceBundle). Though I planned on backwards compatibilty, by looping over the Map values - instead of the List entries - in the current MessageManager.getText() method. (Did I make myself clear?) I try my best to get your point... At the moment there is only one MessageProvider holding many resources. You want to change this to many MessageProviders holding one resource each in order to improve performance? I currently don't have access to the sources as I'm on a project in Jordan, but as soon as I'm back home I'll try to have a closer look at this. Always keep in mind that it should be very simple to use the component. Do you have sandbox commit access? Cheers, Daniel I'm also considering adding a DatabaseMessageProvider as a starting point for database resouces (which is what I will be using primarily). Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
Jakarta Commons Developers List commons-dev@jakarta.apache.org schrieb am 18.04.05 11:29:38: At 2005-04-18 11:11, Daniel Florey wrote: My though was to re-use the basename or id used when installing ResourceBundle or XML providers. For example, after issuing ResourceBundleMessageProvider.install(errorMessages); I would like to be able to qualify the newly installed messages with MessageBundle msg = new MessageBundle(errorMessages, unexpectedError); but also keep the existing alternative with MessageBundle msg = new MessageBundle(unexpectedError); // unexpectedError from any source Do you want this to be able to install different resources with the same message key or is it mainly because of implementation details (performance)? Primarily multiple entries with same key, secondarily performance. This may seem like a minor change at a first glance, but to also improve performance my thought was to to change the MessageManager class from holding a list of provider instances - which in turn can contain multiple resources (and thus assumes one instance per provider class) - to holding a Map from basename/id/namespace/qualifier to provider instance, where each instance only contains a single resource (i.e. XML-file/ResourceBundle). Though I planned on backwards compatibilty, by looping over the Map values - instead of the List entries - in the current MessageManager.getText() method. (Did I make myself clear?) I try my best to get your point... At the moment there is only one MessageProvider holding many resources. You want to change this to many MessageProviders holding one resource each in order to improve performance? Yes. Instead of having to loop through the providers - catching exceptions from those who do not contain the entry, which is quite costly performance wise - and get the first match, I want to be able to point out the source which I expect to hold the entry. But then again, todays behaviour should be kept as the default behaviour when not using a basename/namespace qualification. I currently don't have access to the sources as I'm on a project in Jordan (You can browse them online, http://jakarta.apache.org/commons/sandbox/i18n/xref/index.html is quite easy to navigate) but as soon as I'm back home I'll try to have a closer look at this. Should I try to create a patch suggestion which you could look at then? Yes, this would be great! It would be very (very) appreciated, if you could provide some testcases... I started to write some a while ago, but never managed to complete them. If we would have a complete testsuite we could refactor without the fear to break something ;-) If we get the testsuite done and improve the documentation, we hopefully can move the component to commons proper soon... Cheers, Daniel Always keep in mind that it should be very simple to use the component. Sure. As I said, I intend to be backwards compatible with currenty usage. Though possibly the installation of resources may look slightly different. Do you have sandbox commit access? Nope. Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [ANN] Commons I18n 0.5 released
Hi folks, Sorry for the confusion. I just wanted to make the current version of the component available to people interested in this component. It's no official release yet and as such there has been no voting thread. The mail to the developers list was created by maven as I tried to complete the maven based build environment to allow distros and releases to be done easily later on. I'll try to avoid sending any announcements to the list in future if this is considered harmful. So: Sorry again for that one. I'm currently working on completing this tiny component (javadocs, tests, documentation) in order to be able to prepare an official release. There are some questions left: - What is the correct place to put unofficial sandbox-releases for download? Or is it needed for anyone interested to check out the sources and build a jar themselves? - I still can not find any maven documentation on how to use the dist-plugin in a useful way. Is there any commons project around using maven in a proper way to generate releases/distros and generate an appropriate download page? If you have a look at i18n you'll see that the download link points to one of the distributions .zip file. I would like to point to the distro directory as such. - What are the steps that need to be done to move a component (once it is completed and considered useful) to commons-proper? Cheers, Daniel BTW: Thanks to Woody and others for their contributions to the i18n-component! -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von robert burrell donkin Gesendet: Sonntag, 20. Februar 2005 11:22 An: [EMAIL PROTECTED] Cc: commons-dev@jakarta.apache.org Betreff: Re: [ANN] Commons I18n 0.5 released On Sun, 2005-02-20 at 08:27, Martin Cooper wrote: On Sun, 20 Feb 2005 18:33:00 +1100, Dion Gillard [EMAIL PROTECTED] wrote: I didn't think we did releases from the sandbox? Correct. A component in the sandbox cannot have a release, so this anouncement is invalid as such. Only components in Commons Proper can have releases. A sandbox component can, however, make development or test builds available. That would seem to be the appropriate approach for i18n at this time. +1 i can't seem to find a VOTE thread either. i'm not sure whether this because there wasn't one or it's just that i've had problems finding the thread. there look to be a number of releases already available (http://jakarta.apache.org/commons/sandbox/i18n/downloads.html). the distributions are served from http://www.apache.org/dist/java-repository/commons-i18n/distributions/. AIUI this isn't the correct place to server test or development build from. the build naming system also does not make it clear that these are not official ASF releases. not good. need to do something about this. anyone opinions on the next step? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [i18n] man available
Hi Woody, Thanks for your help! See comments inline... Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Anaximandro (Woody) Gesendet: Mittwoch, 16. Februar 2005 11:17 An: Jakarta Commons Developers List Betreff: Re: [i18n] man available Hello Daniel, Yup, the ConfigManager not prove to be very usefull. This class is increasing the coupling level to give me a few features set (the con figuration features itself) and gave me much more code to delegate ... But you don't think necessary some code to configure the behaviours of this component? For instance: in your version when the component not find one message id they throw one unchecked exception. The component dont't force me to write one try catch block for each LocalizedEntry but force me to write all messages ids in their respective resource to avoid one exception. Avoid try catch blocks is cool, very cool, but this only make my code more clean, however the cost to do this is high: I must write the messages id (at least) to don't break the application, but if I forget one id the application will break in same mode. I'll add some examples to the website that show how to deal with missing messages, ok? Using some code to configure this helps in this situation. I can talk to component: hey pal, use the message id or entry id as default when you not find someone. Don't throw an exception, instead, write this in log. I will write these messages later ok? I try to avoid including logging into the i18n component as there are so many different loggers around. I just removed the commons-xmlio dependencies by using sax-parsing instead, so my goal is to achieve a component with no dependencies. If we need logging, I'd vote for standard jdk 1.4-logging. What do you think? Hence I think is better to leave this decision to the user component. I know you wanna a small and easy to use component, I want the same think, but ... I think is more easy to use a componente wich can be configured than one wich we can't do this. Sorry if I'm talking to much, I really wanna help but my english make this more hard than really is. Only one MessageManager? no getInstance? As I see the problem exists when many threads (with different Locales) try to get a message. I don't see any problem with diferent applications (sure, the unique ID is requi red). If you use only one MessageManager you will need to always provide the desired Locale (in constructor or in getXXX method) because there is no more a place to store a default Locale info since the older place (setLocale/getLocale) will be shared by this threads. More than this, doing this will bestrew Locale info in resulting client code making this more hard to update. Well, this is just my opinion. It is necessary to provide the desired locale in each getXXX method of the LocalizedBundle-subclasses. I just removed the ones using the default locale as this causes additional confusion. If you really want to specify a thread-specific locale (??) then you need to store it in ThreadLocal. I'll add a method to set the default locale in the MessageManager if it should be something different than the VM default locale. I try to solve this writing the getInstance (as you suggest in email) but with this I create another problem: how to link a message with their respective manager? Passing this guy as parameter? nope, this is ugly. So writing some method to returns the current manager? Yes, make sense, then: getCurrentInstance, but, again, I created another problem: I need to write monitor code to lock unlock the instance to avoid data corruption (between threads). I think this is the last thing I need to close my version. I will do this (is a little hard to me because I never do this before). I'm right im my point? I miss something? Did you find some good idea in my code? If you do I can revise and generate the apropriate patch to you. Yes, thanks. I'll add some LocalizedRuntimeException, LocalizedError etc. and rename the LocalizedError to something more speaking. Good luck with envinronment (to be honest I need to learn maven, I just used eclipse, always redoing the configuration when I need). Maven is a nice tool, but very bad documented indeed. So it's hard to figure out how to achieved the desired stuff... Woody Hi Woody, I'm currently trying to improve the maven environment, so that releases and tests can easily be done. My goal is to complete the component in the actual state in order to build a usable release as soon as possible. I've already had a look at your proposed changes. I'd like to include some changes into the current version (LocalizedRuntimeException), but I'm not sure with the ConfigManager. This one introduces a lot of complexity. In order to keep the i18n-component very simple my suggestions would be to keep only one MessageManager with static methods and
AW: [i18n] man available
Hi Woody, I'm currently trying to improve the maven environment, so that releases and tests can easily be done. My goal is to complete the component in the actual state in order to build a usable release as soon as possible. I've already had a look at your proposed changes. I'd like to include some changes into the current version (LocalizedRuntimeException), but I'm not sure with the ConfigManager. This one introduces a lot of complexity. In order to keep the i18n-component very simple my suggestions would be to keep only one MessageManager with static methods and advice the user to use unique message keys (comparable to java package names). This should avoid trouble when using multiple applications. Agreed? Next steps are to remove misleading methods (as we discussed earlier) and to complete the javadocs and provide some more tutorials. This is the part where help would be very much appreciated ;-) Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von [EMAIL PROTECTED] Gesendet: Dienstag, 15. Februar 2005 15:51 An: Jakarta Commons Developers List Betreff: [i18n] man available Hi Daniel, Can I help? Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [i18n] proposals
Hi Woody, you pass over your code to me directly using my apache email address. See comments inline... Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Anaximandro (Woody) Gesendet: Montag, 7. Februar 2005 06:12 An: Jakarta Commons Developers List Betreff: Re: [i18n] proposals Hi Daniel, The ConfigManager in my idea is used for store specific configurations, as I see the MessageManager don't have this responsabilitie. If I store any configuration on MessageManager I will need specific instances of this guy for each thread with a diferent configuration. Well, in your code you don't let the user of this component to configure the behaviours of log, exceptions and default language. I do some code to do this in mine and, becouse this, I need to store these configurations on a isolated place. Store these guys inside MessageManager is not a good idea. The MessageManager only store the message providers and delegate calls to these providers. The main objective behind this is to write less code in cases wich I need to specify Locales differents than default Locale. Instead of write: Locale userLocale = getUserLocale( userId ); LocalizedText txt1 = new LocalizedText( consts.ID1, userLocale );// each message need to set the user locale LocalizedText txt2 = new LocalizedText( consts.ID2, userLocale );// LocalizedText txtN = new LocalizedText( consts.IDN, userLocale ); // The locale is not specified in the constructor. It is specified when you retrieve a particular entry: LocalizedText txt1 = new LocalizedText( consts.ID1 ); String translatedText = txt1.getText(Locale.DE); The default locale should only be used when no user locale can be detected. It might be a good idea to remove the methods dealing with the default locale in order to avoid confusion. I think in write: String servletID= getServletUUID(); ConfigManager config = new ConfigManager.getInstance( servletID ); config.setLocale( getUserLocale( userId ) ); // Only one place set the user locale LocalizedText txt1 = new LocalizedText( consts.ID1 ); LocalizedText txt2 = new LocalizedText( consts.ID2 ); LocalizedText txtN = new LocalizedText( consts.IDN ); I agree with your idea, keep it simple here is the best thing to do, but how to setup aditional information without a mediator to store? The code in first example can be a problem, he multiply locale information (configuration) in many places where I have a message ... In my code I write: - In LocalizedText, LocalizedMessage, LocalizedError, LocalizedException I change the extensions. Instead of cascating extensios I do direct extensions (LocalizedText extends LocalizedBundle, LocalizedMessage extends LocalizedBundle, LocalizedError extends LocalizedBundle ...) Why? Each extension adds some additional fields / methods. - new class: LocalizedRuntimeException (like your LocalizedException); Good idea. * new class: ConfigManager (LocalizedBundle delegate to this class); - service locator; - code to config excetions and defaults ( useMessageIdAsDeafult(), useEntryIdAsDefault(), if both was false, then, we throw exceptions) - code to config log levels (setLevelLog2Info, setLevelLog2Warning and setLevelLog2Error); - code to setLocale (used by all messages in a given instance); - this class delegate calls to MessageManager; Let me have a look at your code. Then it may become more clear ;-) * In MessageManager: - service locator; - methods to getProvider, removeProviders and reset/clear MessageManager; - move exception handling to ConfigManager (now it is configurable); - this class delegates class to each provider; * In XMLMessageProvider: - service locator; - move exception handling to ConfigManager; - more 2 xml formats (one file per message - as resource bundle does and a mix); * In ResourceBundleMessageProvider: - service locator; - move exception handling to ConfigManager; - In all classes I do some enhacements with final keyword; I do a lot of code and don't think is a good idea to put them here. How can I provide this to you? Did you have any email to I sent this? (sure, if you wish to see) Man, sorry by my english. Is more easy to me write code than write email ... If I write anything offensive, please, sorry and talk with me. Woody - Original Message - From: Daniel Florey [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' commons-dev@jakarta.apache.org Sent: Saturday, February 05, 2005 5:58 AM Subject: AW: [i18n] status Hi Woody, Where did you post your proposals/patches? I'm very interested in improving the i18n/contract components. If you have any suggestions the best way is to describe the idea behind it so that it can be discussed in the mailing list. You can also post the related patches/files as attachment to a bugzilla entry (enhancement request). Please try
AW: [i18n] status
Hi Woody, Where did you post your proposals/patches? I'm very interested in improving the i18n/contract components. If you have any suggestions the best way is to describe the idea behind it so that it can be discussed in the mailing list. You can also post the related patches/files as attachment to a bugzilla entry (enhancement request). Please try to describe each single idea / enhancement and include some code snippets in the mail if it makes the idea clearer. Regarding the proposal of a ConfigManager: I'd like to keep the components as simple as possible. I've understood that we need to have the ability to have more than one MessageManager per VM. So my proposal would be just to add a getInstance(String messageManager) method to the MessageManager and get rid of the static methods. But perhaps I've missed the point. So it would be great if you could explain in more detail what the ConfigManager is for. Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Anaximandro (Woody) Gesendet: Samstag, 5. Februar 2005 06:03 An: Jakarta Commons Developers List; [EMAIL PROTECTED] Betreff: Re: [i18n] status Thanx Oliver. I will wait for him, :o Woody - Original Message - From: Oliver Zeigermann [EMAIL PROTECTED] To: Anaximandro (Woody) [EMAIL PROTECTED] Cc: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Friday, February 04, 2005 3:47 PM Subject: Re: [i18n] status I am sure that your suggestions are valueable and you do not bore me at all. However, the proposals you made should be inspected by Daniel, as I have no deeper insight into neither contract nor i18n. Oliver On Fri, 4 Feb 2005 19:55:21 -0800, Anaximandro (Woody) [EMAIL PROTECTED] wrote: Oliver, I sent one proposal too (another class diagram, with a macro vision of my suggestions). The idea behind my suggestion is write one mediator (ConfigManager) to retain one specific configuration (I can have many threads running with diferent configurations) and put one service locator in MessageManager. Each message (LocalizedText, LocalizedMessage, etc) comunicates with MessageManager through your configuration. I write a lot of code to test this ideas and to be more confident with this project, but now I stuck, this project is not mine and I need to take easy with ideas 8( You wanna see this class diagram? I'm boring you? Sorry Woody I mainly work on xmlio, but am not aware of any proposed changes to the project. The class diagrams you sent have been put online by me. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [contract] Suggestions
Hi Woody, Thanks for interest in the contract component. I'm always interested in suggestions and it's nice to see that people have a look at the component. The idea behind the constraint classes is to have a powerful way not only to describe the constraints of a special value but also to be able to verbose these constraints in a human-readable way. But it might be a good idea to have a processor that can deal with property-files and creates the constraint classes as described in the property-file. In fact this is already done in the Slide/Projector framework. If you are interested, you can have a look at the docs of Projector. If you want to help to make the contract component be more mature, it would be a good starting point to have a look at the constraint classes. A lot of java classes are not yet covered by the constraint package and it would make sense to add some more. This is a good starting point for learning to deal with the contract and the related i18n component. Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Anaximandro (Woody) Gesendet: Montag, 24. Januar 2005 00:20 An: Jakarta Commons Developers List Betreff: [contract] Suggestions Hi felows, I´m new here and if this message is on wong place, please, sorry ... I dono if I need to introduce myself, besides I will go direct to the subject ok? Daniel, what dou you think about put constraints rules on some type of propertie file? These constraints must have some type of identification (in one ore more contexts). This is flexible and make the code more clean (and, like ejb, can be changed without the need to recompile the code). Do you know OCL? Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [transaction][VOTE] Release 1.0.1 *AND* 1.1b1
+1 Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Oliver Zeigermann Gesendet: Montag, 10. Januar 2005 02:06 An: Jakarta Commons Developers List Betreff: [transaction][VOTE] Release 1.0.1 *AND* 1.1b1 Dear community, as already advertised in this list I would like to see both a 1.0.1 maintenance release and a first beta of a 1.1 feature release I have already created the distributions calling 'ant package' for both 1.0.1 and 1.1b1. They are ready for inspection here: http://www.apache.org/~ozeigermann/tx-1.0.1 and http://www.apache.org/~ozeigermann/tx-1.1b1 The release notes are here: http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta- commons/transaction/RELEASE-NOTES.txt?rev=1.3.2.1 and http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta- commons/transaction/RELEASE-NOTES.txt?rev=1.13 Here is my +1! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: AW: [proposal] avoiding jar version nightmares
In order to find an appropriate solution to this issue, I'd like to identify the different problems that we need to address. Version: What does a version number mean? I'll make a proposal for how to use minor/major version number to have a basis on which we can identify the issues. Major version numbers indicate that some public API methods have been changed in semantics or have been removed. So an application using component-1.x might not work with component-2.x Minor version numbers indicate that the component remains backward compatible, but new methods may have been introduced. So an application using component-1.x will work with component-1.y if y0, but an application component-1.y might fail when using component 1.x A build number might indicate that private methods have changed without affecting the public api. So an application using component 1.x.a will work with component 1.x.b and an application using 1.x.b will work with component 1.x.a Does this sound reasonable? Missed something? So when declaring a jar metafile (don't know either if we can the MANIFEST for this) it should at least contain something like this: dependencies provides name=commons-i18n version=1.1.3 / requires name=commons-digester version=2.0 / requires name=commons-transaction version=1.1 / /dependencies This one would indicate that the describe jar can be referenced by the name commons-i18n and has the version number 1.1.3. It requires any version of commons-digester higher than 2.0 and commons-transaction with version newer or equal 1.1 This could be the basis to implement a commons component managing the dependencies the way you described. I'd prefer to keep the jar naming as introducing assembly would cause some confusion. If anyone would be interested I could put a simple proposal to the sandbox. This approach will not address the trouble that may be caused by applications not using this package. So finally I think that it is required that this feature (or something comparable) will make it into Java 1.6. Up to then I still think it's a very simple but easy way to add the version number to the package names to avoid at least the very big problems concerning incompatible jars in the same classloader. Regards, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Matt Sgarlata Gesendet: Dienstag, 21. Dezember 2004 13:04 An: commons-dev@jakarta.apache.org Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares Chris Lambrou wrote: Matt Sgarlata wrote: Does this mean .NET doesn't have reflection? That's such a killer feature of Java; I can't believe they wouldn't have ported it to .NET. Any .NET developers out there that can tell us how .NET deals with reflection when you have multiple versions of the same class? Since the class name alone is insufficient to fully identify a specific version of a class, to my knowledge there is no equivalent to Class.forName(String classname) in .NET. Instead, .NET has the Assembly class. An Assembly is roughly akin to a java jar file, and is typically a single DLL that contains one or more classes. Assembly has a non-static getType(String typeName) method, that performs the same job as the static Class.forName(String classname) method in java, but for a specific Assembly instance. There is never any ambiguity over which version of the named Type that is returned, since an Assembly can only contain one version of any given class. Support for multiple versions of a class at runtime is achieved by storing those multiple class versions in separate Assemblies. Thanks for the info, Chris! This definitely sounds like a good approach. Now my question is, can we simulate this in a new commons component? :) Here are the steps I would imagine to be involved: 1) Define our own JAR sub-type to mirror the .NET assembly notion. Include some type of a plain-text file that describes the versions of the software required to perform certain tasks. It would be nice to do this in an existing structure like MANIFEST.MF, but I don't know... are you allowed to add arbitrary information to that file? In any case, we wouldn't use the existing dependency descriptors because that would prevent multiple versions of the same class from being loaded. 2) Call org.apache.commons.assembler.Assembler.getType(String assembledPackage, String className). The Assembler would then go to the assemblyPackage path on the classpath and search the plain-text file from step #1 which would list the versions of classes that are required by the given assembledPackage. For example, if assembledPackage was the Digester, which required collections 3, the assembledPackage would be org.apache.commons.digester. A dynamic proxy or generated bytecode would be loaded that fulfilled the given contract and that would be returned to the client. Any existing code that is just
AW: AW: AW: AW: [proposal] avoiding jar version nightmares
snip/ an application using 1.x.b will work with component 1.x.a Does this sound reasonable? Missed something? Have you seen the guidelines in use by the Apache APR project? It looks to me like you're basically advocating the same system they have in place. It might save us hassle to just adopt their version numbering system whole-sale (as the Spring Acegi Security subs(ystem does) http://apr.apache.org/versioning.html Very funny - looks pretty identical to me ;-) So, yes, let's adopt this. I've not played around with classloading a lot, so I'm very curious if this will work. I'll try to start working on this if I'll find the time for it. If you are interested I could setup an account for you at my personal root server (I've installed Subversion). Or should I create a subproject in the commons-sandbox? As it's in stage of brainstorming I'd prefer to do it in my personal space first. Are you interested? Cheers, Daniel I'd prefer to keep the jar naming as introducing assembly would cause some confusion. If anyone would be interested I could put a simple proposal to the sandbox. Good point, JAR may be a better name. I see two benefits to using assembly or assembler as the name: - Clearly indicates that you aren't dealing with plain-old-JAR files anymore - Parallels name used in .NET so that the analogy is directly obvious This approach will not address the trouble that may be caused by applications not using this package. So finally I think that it is required that this feature (or something comparable) will make it into Java 1.6. Up to then I still think it's a very simple but easy way to add the version number to the package names to avoid at least the very big problems concerning incompatible jars in the same classloader. I understand your reasoning behind putting this code in Java 1.6, but I think we can do this without a new release of the Java language (see below). If our ideas are successful, this new Commons component could always migrate later to a JSR proposal, as Doug Lea's concurrent package did. With regards to problems caused by components that aren't using this new package, I'm thinking that as long as the component does not make any Class.forName calls, we should be OK. If there are Class.forName calls, the component may still be able to work, but we would strongly encourage a migration to using Assembly.getType or whatever. This entails the component introducing a dependency on Assembler, which means the Assembler API will need to maintain backwards compatability as much as possible (e.g. - imagine the nightmare that would ensue if java.util.Vector were to change its semantics!) Regards, Daniel Matt -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:commons-dev-return-64857- [EMAIL PROTECTED] Im Auftrag von Matt Sgarlata Gesendet: Dienstag, 21. Dezember 2004 13:04 An: commons-dev@jakarta.apache.org Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares Chris Lambrou wrote: Matt Sgarlata wrote: Does this mean .NET doesn't have reflection? That's such a killer feature of Java; I can't believe they wouldn't have ported it to .NET. Any .NET developers out there that can tell us how .NET deals with reflection when you have multiple versions of the same class? Since the class name alone is insufficient to fully identify a specific version of a class, to my knowledge there is no equivalent to Class.forName(String classname) in .NET. Instead, .NET has the Assembly class. An Assembly is roughly akin to a java jar file, and is typically a single DLL that contains one or more classes. Assembly has a non-static getType(String typeName) method, that performs the same job as the static Class.forName(String classname) method in java, but for a specific Assembly instance. There is never any ambiguity over which version of the named Type that is returned, since an Assembly can only contain one version of any given class. Support for multiple versions of a class at runtime is achieved by storing those multiple class versions in separate Assemblies. Thanks for the info, Chris! This definitely sounds like a good approach. Now my question is, can we simulate this in a new commons component? :) Here are the steps I would imagine to be involved: 1) Define our own JAR sub-type to mirror the .NET assembly notion. Include some type of a plain-text file that describes the versions of the software required to perform certain tasks. It would be nice to do this in an existing structure like MANIFEST.MF, but I don't know... are you allowed to add arbitrary information to that file? In any case, we wouldn't use the existing dependency descriptors because that would prevent multiple versions of the same class from being loaded. 2) Call org.apache.commons.assembler.Assembler.getType(String assembledPackage, String className). The Assembler would then go to the
AW: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Thanks for the links. Do you know if there is a maven task to automatically generate this manifest entries based on the project.xml? If not this might be a first step in order to allow easy adoption for the upcoming assembly-component ;-) -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Craig McClanahan Gesendet: Dienstag, 21. Dezember 2004 21:28 An: Jakarta Commons Developers List Betreff: Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares Don't forget to do a little light reading first :-) Mechanism to declare dependencies in a MANIFEST.MF File: http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html ClassLoader implementation for representing an Assembly: http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLClassLoader.html Craig On Tue, 21 Dec 2004 14:34:56 -0500, Matt Sgarlata [EMAIL PROTECTED] wrote: Count me in! I'm planning on taking some time off for the holidays, so that should give me time to play around with this :) Matt Daniel Florey wrote: snip/ an application using 1.x.b will work with component 1.x.a Does this sound reasonable? Missed something? Have you seen the guidelines in use by the Apache APR project? It looks to me like you're basically advocating the same system they have in place. It might save us hassle to just adopt their version numbering system whole-sale (as the Spring Acegi Security subs(ystem does) http://apr.apache.org/versioning.html Very funny - looks pretty identical to me ;-) So, yes, let's adopt this. I've not played around with classloading a lot, so I'm very curious if this will work. I'll try to start working on this if I'll find the time for it. If you are interested I could setup an account for you at my personal root server (I've installed Subversion). Or should I create a subproject in the commons-sandbox? As it's in stage of brainstorming I'd prefer to do it in my personal space first. Are you interested? Cheers, Daniel I'd prefer to keep the jar naming as introducing assembly would cause some confusion. If anyone would be interested I could put a simple proposal to the sandbox. Good point, JAR may be a better name. I see two benefits to using assembly or assembler as the name: - Clearly indicates that you aren't dealing with plain-old-JAR files anymore - Parallels name used in .NET so that the analogy is directly obvious This approach will not address the trouble that may be caused by applications not using this package. So finally I think that it is required that this feature (or something comparable) will make it into Java 1.6. Up to then I still think it's a very simple but easy way to add the version number to the package names to avoid at least the very big problems concerning incompatible jars in the same classloader. I understand your reasoning behind putting this code in Java 1.6, but I think we can do this without a new release of the Java language (see below). If our ideas are successful, this new Commons component could always migrate later to a JSR proposal, as Doug Lea's concurrent package did. With regards to problems caused by components that aren't using this new package, I'm thinking that as long as the component does not make any Class.forName calls, we should be OK. If there are Class.forName calls, the component may still be able to work, but we would strongly encourage a migration to using Assembly.getType or whatever. This entails the component introducing a dependency on Assembler, which means the Assembler API will need to maintain backwards compatability as much as possible (e.g. - imagine the nightmare that would ensue if java.util.Vector were to change its semantics!) Regards, Daniel Matt -Ursprüngliche Nachricht- Von: commons-dev-return-64857- [EMAIL PROTECTED] [mailto:commons-dev-return-64857- [EMAIL PROTECTED] Im Auftrag von Matt Sgarlata Gesendet: Dienstag, 21. Dezember 2004 13:04 An: commons-dev@jakarta.apache.org Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares Chris Lambrou wrote: Matt Sgarlata wrote: Does this mean .NET doesn't have reflection? That's such a killer feature of Java; I can't believe they wouldn't have ported it to .NET. Any .NET developers out there that can tell us how .NET deals with reflection when you have multiple versions of the same class? Since the class name alone is insufficient to fully identify a specific version of a class, to my knowledge there is no equivalent to Class.forName(String classname) in .NET. Instead, .NET has the Assembly class. An Assembly is roughly akin to a java jar file, and is typically a single DLL that contains one or more classes. Assembly has
Re: AW: AW: [proposal] avoiding jar version nightmares
I think handling different versions of classes/jars at VM level would be a nice feature, but it would be very hard to implement nd to understand when it comes to reflection. Another proposal would be to do it the j2se-way: When introducing new features to a package (e.g. java.io) don't include the version number in the package name, but call it new (e.g. java.nio). So what about: org.apache.commons.component gets org.apache.commons.ncomponent in its next incompatible version. The next incompatible change will result in org.apache.commons.vncomponent (very new component) Each major version step will add a leading v-character After five major versions, the five v-characters can be replaced by an 'a' (absolutely new) So this might be a way to handle many different major versions without adding the nasty version number to the project name, but indicate clearly what the package is all about. BTW: How will digester2 manage this problem? Is it not a good starting point to call the package digester2 or digester-2 or ndigester or whatever? Cheers, Daniel Jakarta Commons Developers List [EMAIL PROTECTED] schrieb am 20.12.04 01:11:00: The ability to declare your own versioning information, and that of your dependencies, in a MANIFEST.MF file already exists: http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html Two existing use cases for this information are applets and servlet containers, where the container should examine the manifest of the applet itself (or the WAR in the case of a webapp) and reject execution if the specified versions of the declared dependencies are not present. But nothing stops a container from doing more with this info (see below for one idea). What's missing today at the *language* level is the ability to load incompatible versions into the same class loader. That would take language and JVM architecture changes -- if that's important to you, go find the threads on ServerSide or JavaLobby about providing feedback to the requirements for Mustang (JDK 1.6), since that's the earliest time we could actually get it into the language itself. In the mean time, nothing stops a servlet container provider from assembling dynamically an appropriate parent class loader that contains just the specified dependencies (instead of, or in addition to, the kind of thing that Tomcat does with its shared and common class loaders). That way, one could provide webapp A with version 1 of the library, and webapp B with version 2 of the same library, which is pretty much equivalent to what you describe for .NET. Seems like a good RFE for Tomcat ... However, this won't solve the two incompatible versions in the same webapp use case -- for that, you'll still need to use child class loaders. It sounds like this would also be true in the .NET environment??? Craig On Sun, 19 Dec 2004 18:37:43 -0500, Matt Sgarlata [EMAIL PROTECTED] wrote: Craig McClanahan wrote: On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata [EMAIL PROTECTED] wrote: How do we go about petitioning Sun for something like this? A while back now (while the details for Tiger were being planned), I happened to be in a meeting with Graham Hamilton (who basically owns the direction that J2SE is going from a Sun perspective), talking about the very issue of class loaders and the contortions that you have to go through in order to implement things like webapp reloading. I asked him for a Christmas present to all Java developers -- add something like ClassLoader.unloadClass() or ClassLoader.replaceClass() to deal with things like this. He said hmm ... that's a hard problem and proceeded to describe several of the places where implementing this would be extremely difficult (and/or would have nasty performance impacts) in the current architecture of JVMs. Well what about introducing the versioned library approach that is done in .NET? I'm not familiar with the details myself, but Chris Lambrou wrote earlier: The .NET equivalent of a jar file is called an assembly. For libraries, this is basically a DLL. Every time the code is compiled, the DLL is automatically allocated a unique version number. When you compile your code that refers to code in a library assembly, your assembly has an explicit dependency on that library assembly. At runtime, when your code tries to invoke the library code, an exception will be raised if the exact version of the library assembly is not available. It would appear that if there are bug fixes or other improvements to the library, and a recompiled assembly DLL is substituted for the one you originally compiled against, then your code will break. At runtime, your code will fail to link to the library code, since the version number no longer matches. Obviously, a maintenance release of a library component shouldn't require a recompilation and redeployment of all
Re: new sandbox projects
Jakarta Commons Developers List [EMAIL PROTECTED] schrieb am 20.12.04 12:42:26: In case someone missed the thread on general here is a re-post as Brett suggested... Thanks for the positive feedback so far. BTW: How far is the SVN migration? cheers -- Torsten Torsten Curdt wrote: Hey, folks! Over at cocoon we have some code that might be worth sharing on jakarta commons. So I was wondering if the sandbox is open to any committer or only to jakarta committers? (which I am not) I heard different stories... I factored out our javaflow (java continuations) implementation and a java compiler interface (jci) featuring a compiling classloader. This sounds very interesting! Would be glad to see it in the commons sandbox. Any opinions on hosting that at jakarta commons? Or should we keep that stuff under our umbrella? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: AW: [proposal] avoiding jar version nightmares
The solution you proposed will not solve the issue as you cannot replace the classloader of the application server. Finally I think that my proposal is not that bad. If it's not possible to address this issue in future versions of the java language, this seems to be the only solution. So my vote is +1 to add at least the major version number to the components package name. Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Craig McClanahan Gesendet: Sonntag, 19. Dezember 2004 22:46 An: Jakarta Commons Developers List Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata [EMAIL PROTECTED] wrote: This may work, but does BCEL require the use of its own custom classloader also? This seems to me that this isn't just a problem with commons; it is a problem with Java itself that .NET already has a very nice solution for. I'm wondering if this isn't something that should be taken care of at the JVM level i.e. - in Java 1.6. The obvious solution seems to be that we need to fix classloaders. They're already a huge nightmare in EJB containers. How do we go about petitioning Sun for something like this? A while back now (while the details for Tiger were being planned), I happened to be in a meeting with Graham Hamilton (who basically owns the direction that J2SE is going from a Sun perspective), talking about the very issue of class loaders and the contortions that you have to go through in order to implement things like webapp reloading. I asked him for a Christmas present to all Java developers -- add something like ClassLoader.unloadClass() or ClassLoader.replaceClass() to deal with things like this. He said hmm ... that's a hard problem and proceeded to describe several of the places where implementing this would be extremely difficult (and/or would have nasty performance impacts) in the current architecture of JVMs. Regarding the original use case in this thread (an app that wants to use two modules that have conflicting versions of common dependencies), about the best you can do right now is to have your application create its own class loaders for the modules involved, and set up their classpaths to pick up their own versions of the dependencies. That is essentially what a servlet container does (creates a class loader for each webapp) to maintain separation, and allows each webapp to load its own version of a common dependency JAR from its own class path ... the /WEB-INF/classes and /WEB-INF/lib directories of that app. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: AW: AW: [proposal] avoiding jar version nightmares
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Craig McClanahan Gesendet: Sonntag, 19. Dezember 2004 23:28 An: Jakarta Commons Developers List; [EMAIL PROTECTED] Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann [EMAIL PROTECTED] wrote: On Sun, 19 Dec 2004 22:17:10 -, Stephen Colebourne [EMAIL PROTECTED] wrote: I would also -1. Versioned packages is not an acceptable solution. What is an acceptable solution then? Do what I said already ... create subordinate class loaders *within* your application, and load the offending subordinate modules into their own class loaders, with their own dependencies. Simple example: If you have two libraries: Library A using component-1.x Library B using component-2.x Both libraries provide some servlets that need to live in the same webapp and get initialized at startup. How to make this work (for users with average java knowledge)? This is a simple example, but I could give you many others where libraries depend on each other and need to share the same classloader. So your proposal won't work. Daniel Oliver Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: AW: AW: [proposal] avoiding jar version nightmares
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Craig McClanahan Gesendet: Sonntag, 19. Dezember 2004 23:34 An: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares On Sun, 19 Dec 2004 23:24:52 +0100, Oliver Zeigermann [EMAIL PROTECTED] wrote: Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward compatible. Especially, I would even consider it dangerous to replace a 1.x version with 2.x without checks just to have a newer version. Semantics could have chages. Consider collections from 2. to 3. What was done there was perfectly alright. Collections was indeed perfectly alright to make backwards-incompatible changes between versions 2 and 3. However, you should also note that these changes were *not* universal -- for a very large number of classes, the calling sequences *are* backwards compatible. Now, let's assume that Collections had implemented the package name includes major version rule. If I had restricted myself to the (quite large) subset where there was no real change, I would have been *incredibly* irritated at having to change package names in *my* application's imports -- just because you gratuitously changed the package name (and therefore made *all* APIs backward incompatible). You might be irritated, but I think this is the cost to pay for working around this obvious java lack of managing versioned libraries. I think it's just a matter of getting used to this package naming convention. BTW: Another advantage of this approach would be that imports would indicate which version of the component is in use. I had a lot of trouble to find out, which version of jdom was in use by some libraries as this was not indicated by the name of the jar. Daniel Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: AW: AW: [proposal] avoiding jar version nightmares
If components stay backward compatible there of course is no need to include the versions in the package name. But I assume that there are some components that have incompatible api changes (or even worse: same api different behaviour) between major version numbers. For packages like these the versioned package names would be the only way (beside renaming the component ;-) to solve this issue. Or have I missed something? Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Stephen Colebourne Gesendet: Sonntag, 19. Dezember 2004 23:46 An: Jakarta Commons Developers List; [EMAIL PROTECTED] Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward compatible. Especially, I would even consider it dangerous to replace a 1.x version with 2.x without checks just to have a newer version. Semantics could have chages. Consider collections from 2. to 3. What was done there was perfectly alright. If by this you are suggesting that [collections] 2 and 3 were designed to be incompatible then you are wrong. [collections] v3 'moved' classes to new packages, but _left_the_old_ones_deprecated_. Some months later I discovered an unintended incompatability in IteratorUtils.EMPTY_ITERATOR, which can be solved by migrating to the 2.1.1/3.1 combination of versions. My point is that they were desinged to be compatible from 2 to 3. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: AW: AW: [proposal] avoiding jar version nightmares
So the collections way to handle this issue if to move all classes to a new subpackage and leave the old ones where they've been before. To be honest: Is this not very close to my proposal? Something like: org.apache.commons.component.version1... org.apache.commons.component.version2... I would prefer to find a common way to handle this. I think it would not be the best solution if every component is dealing with this issue in its own way. Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Oliver Zeigermann Gesendet: Sonntag, 19. Dezember 2004 23:51 An: Stephen Colebourne Cc: Jakarta Commons Developers List Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares On Sun, 19 Dec 2004 22:46:26 -, Stephen Colebourne [EMAIL PROTECTED] wrote: Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward compatible. Especially, I would even consider it dangerous to replace a 1.x version with 2.x without checks just to have a newer version. Semantics could have chages. Consider collections from 2. to 3. What was done there was perfectly alright. If by this you are suggesting that [collections] 2 and 3 were designed to be incompatible then you are wrong. [collections] v3 'moved' classes to new packages, but _left_the_old_ones_deprecated_. Thanks for clarifying. Did not know the old ones co-existed. Some months later I discovered an unintended incompatability in IteratorUtils.EMPTY_ITERATOR, which can be solved by migrating to the 2.1.1/3.1 combination of versions. My point is that they were desinged to be compatible from 2 to 3. Isn't this almost like having an internal vesioning like Daniel suggested? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[i18n] Introduced pluggable MessageProviders and new ResourceBundleMessageProvider
Hi folks, I've added some nice features requested by users to the upcoming i18n component in the sandbox: You can now easily plug-in your own custom message provider. This is very useful if you already have tons of localized messages on weird places (e.g. databases). Writing a message provider is as simple as implementing a single method. I've also added a ResourceBundle-based message provider that uses the built-in Java functionality for locating and handling resource bundles. This one is very useful if you already have tons of localized messages in some property files and nevertheless want to use the i18n component to take advantage of late localization binding, localized exception handling and message bundles. Cheers, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[contract] Moved to i18n
Hi folks, I've updated the sandbox contract component to work with the new i18n (0.3). Cheers, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [proposal] avoiding jar version nightmares
So how should we handle situations where two versions of the same component need to coexist? If I have to integrate two commercial projects where each one uses a different major version of the same component, how can I achieve this? There is no chance to force them to up- or downgrade to the version of the other product. In situations like these you are absolutely lost, aren't you? So my proposal was about to avoid this horrible situation. Any proposals how to solve this issue in another way? Or is this list not the right place for discussing stuff like this? Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von David Graham Gesendet: Freitag, 17. Dezember 2004 02:26 An: Jakarta Commons Developers List Betreff: Re: [proposal] avoiding jar version nightmares Struts uses the deprecation cycle I described and so did the commons components spawned from Struts the last I knew (validator certainly still uses the described cycle). A 1.x series is backwards compatible but deprecated methods may be removed after they have been deprecated for at least one point release. A jump to 2.x means, among other things, there are backwards incompatible changes without a deprecation cycle. This approach obviously varies by project. David --- Stephen Colebourne [EMAIL PROTECTED] wrote: Commons has always followed a longer deprecation cycle than described below. A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0. 1.1 - 1.2 - 1.3 should all be easy compatible changes. 1.1/1.2 - 2.0 may cause issues. In collections we faced a peculiar compatability problem in that a constant was in both 2.1 and 3.0 but was declared as a different type (by error). This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or 3.1 to get around the problem). Personally, I believe that a different package name for each version is overly restricting. Most users will just recompile their code for the new version and it will just work. Plus, having the same class in two different packages will be very confusing when using an IDE. This would be especially true if someone obtains an object from one version and then tries to pass it to an object of another version. Also, since human error can be a factor, we would have to version every release, minor or major to actually make the system foolproof. Basically, I believe there is no simple solution to this. The best we can do is to encourage tools like clirr which check a library for binary compatability. This should become part of each components standard tests. Stephen - Original Message - From: David Graham [EMAIL PROTECTED] All the jakarta projects I've worked on have a deprecation cycle of one minor point release. For example, you deprecate a method for the 1.1 release and can remove it for the 1.2 release. This gives users time to see the deprecation warning and update their code appropriately. IMO, requiring a package name change is overly restrictive and confusing to users. The only time I've seen versioning problems is when commons components depend on each other and one of them breaks backwards compatibility like commons collections did recectly. This is why it's so important for commons components to have minimal dependencies. What commons components caused your project problems? David --- Daniel Florey [EMAIL PROTECTED] wrote: Hi all, As commons components gain more and more attention you'll find a lot components in larger java based projects. This can cause much trouble when subprojects use different incompatible versions of the same component. I was faced with this problem in the project I'm currently working on and thought about how to avoid situations like these. So this is my proposal: - All versions of a component using the same main version number must be upwards compatible: Methods in component-1.x must not change in semantic or syntax compared to component-1.y where x y. Methods can be marked as deprecated but must still work in the same way. - When incompatible api changes or semantic changes of existing methods will be introduced, a new major version number must indicate this. To ensure that different versions of the same component can be used by a single application, the package name must change as well. Example: org.apache.commons.component-1 contains the 1.x source code of the compoenent org.apache.commons.component-2 contains the 2.x sources Both versions of the component can be used simultaneous and situations described at the beginning of this post can be handled. Disadvantage: When upgrading a project from component-1.x to component-2.x all includes must be updated. But the fact that many (even commercial
AW: AW: [proposal] avoiding jar version nightmares
Don't know. But I think the classloader will still not know which class to pick as the names are still identical. So it might depend on the load order of the jars which product will fail. Or did I got it wrong? Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von David Graham Gesendet: Freitag, 17. Dezember 2004 21:33 An: Jakarta Commons Developers List Betreff: Re: AW: [proposal] avoiding jar version nightmares What happens if you merge the jars for each product? For example, put commons 1.x files into productA.jar and commons 2.x files into productB.jar. David --- Daniel Florey [EMAIL PROTECTED] wrote: So how should we handle situations where two versions of the same component need to coexist? If I have to integrate two commercial projects where each one uses a different major version of the same component, how can I achieve this? There is no chance to force them to up- or downgrade to the version of the other product. In situations like these you are absolutely lost, aren't you? So my proposal was about to avoid this horrible situation. Any proposals how to solve this issue in another way? Or is this list not the right place for discussing stuff like this? Cheers, Daniel -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von David Graham Gesendet: Freitag, 17. Dezember 2004 02:26 An: Jakarta Commons Developers List Betreff: Re: [proposal] avoiding jar version nightmares Struts uses the deprecation cycle I described and so did the commons components spawned from Struts the last I knew (validator certainly still uses the described cycle). A 1.x series is backwards compatible but deprecated methods may be removed after they have been deprecated for at least one point release. A jump to 2.x means, among other things, there are backwards incompatible changes without a deprecation cycle. This approach obviously varies by project. David --- Stephen Colebourne [EMAIL PROTECTED] wrote: Commons has always followed a longer deprecation cycle than described below. A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0. 1.1 - 1.2 - 1.3 should all be easy compatible changes. 1.1/1.2 - 2.0 may cause issues. In collections we faced a peculiar compatability problem in that a constant was in both 2.1 and 3.0 but was declared as a different type (by error). This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or 3.1 to get around the problem). Personally, I believe that a different package name for each version is overly restricting. Most users will just recompile their code for the new version and it will just work. Plus, having the same class in two different packages will be very confusing when using an IDE. This would be especially true if someone obtains an object from one version and then tries to pass it to an object of another version. Also, since human error can be a factor, we would have to version every release, minor or major to actually make the system foolproof. Basically, I believe there is no simple solution to this. The best we can do is to encourage tools like clirr which check a library for binary compatability. This should become part of each components standard tests. Stephen - Original Message - From: David Graham [EMAIL PROTECTED] All the jakarta projects I've worked on have a deprecation cycle of one minor point release. For example, you deprecate a method for the 1.1 release and can remove it for the 1.2 release. This gives users time to see the deprecation warning and update their code appropriately. IMO, requiring a package name change is overly restrictive and confusing to users. The only time I've seen versioning problems is when commons components depend on each other and one of them breaks backwards compatibility like commons collections did recectly. This is why it's so important for commons components to have minimal dependencies. What commons components caused your project problems? David --- Daniel Florey [EMAIL PROTECTED] wrote: Hi all, As commons components gain more and more attention you'll find a lot components in larger java based projects. This can cause much trouble when subprojects use different incompatible versions of the same component. I was faced with this problem in the project I'm currently working on and thought about how to avoid situations like these. So this is my proposal: - All versions of a component using the same main version number must
AW: AW: [proposal] avoiding jar version nightmares
This would be really a funny thing, but how could we replace the classloader of a given application with a custom one? But what about a tool that decompiles all the product jars, changes the package structure and the import statements and repacks this into a new jar? ;-) Might be a megaseller... Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Oliver Zeigermann Gesendet: Donnerstag, 16. Dezember 2004 22:44 An: Jakarta Commons Developers List Betreff: Re: AW: [proposal] avoiding jar version nightmares On Thu, 16 Dec 2004 19:09:54 +0100, Daniel Florey [EMAIL PROTECTED] wrote: So I think we need a solution for this problem. My proposal would be to allow different major versions of commons components to coexist. If the class and package names are equal, this is not possible. My package- version proposal is just one idea to enable this. Some versioning class loader as it was thought of in Projector would really be a very elegant solution ;) Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[proposal] avoiding jar version nightmares
Hi all, As commons components gain more and more attention you'll find a lot components in larger java based projects. This can cause much trouble when subprojects use different incompatible versions of the same component. I was faced with this problem in the project I'm currently working on and thought about how to avoid situations like these. So this is my proposal: - All versions of a component using the same main version number must be upwards compatible: Methods in component-1.x must not change in semantic or syntax compared to component-1.y where x y. Methods can be marked as deprecated but must still work in the same way. - When incompatible api changes or semantic changes of existing methods will be introduced, a new major version number must indicate this. To ensure that different versions of the same component can be used by a single application, the package name must change as well. Example: org.apache.commons.component-1 contains the 1.x source code of the compoenent org.apache.commons.component-2 contains the 2.x sources Both versions of the component can be used simultaneous and situations described at the beginning of this post can be handled. Disadvantage: When upgrading a project from component-1.x to component-2.x all includes must be updated. But the fact that many (even commercial products) ship without indicating by jar-extension which version of a component is used, this can avoid a lot of headaches. What do you think of this approach? Regards, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [proposal] avoiding jar version nightmares
In the project that I've been working on, I had to put together some subprojects into the same ear. As these subprojects interact directly, they needed to share the same classloader. They used different versions of httpclient, collections and jdom (this one caused the most trouble...) and it was hard to figure out, which versions of each component was in use and how to decompile and refactor the subprojects to work with the same jars. As commons components gain more and more attention, more and more commercial products are using them. It's very common for enterprise applications that you have to bundle different commercial packages that are not available in source code. These packages often allow interaction with other packages by adding some listeners, so it is not possible to deploy them in different webapps/cassloaders. So I think we need a solution for this problem. My proposal would be to allow different major versions of commons components to coexist. If the class and package names are equal, this is not possible. My package-version proposal is just one idea to enable this. Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von David Graham Gesendet: Donnerstag, 16. Dezember 2004 18:41 An: Jakarta Commons Developers List; [EMAIL PROTECTED] Betreff: Re: [proposal] avoiding jar version nightmares I'm still wondering what commons components caused you guys problems in your project? Why should all projects change to renaming packages and causing confusion if it's just a few projects that are causing problems? My guess is that it's commons collections that is giving you headaches but I would like to hear the real world example. Thanks, David --- Oliver Zeigermann [EMAIL PROTECTED] wrote: On Thu, 16 Dec 2004 09:09:11 -0800 (PST), David Graham [EMAIL PROTECTED] wrote: The only time I've seen versioning problems is when commons components depend on each other and one of them breaks backwards compatibility like commons collections did recectly. This is why it's so important for commons components to have minimal dependencies. Just think of a 1.x version and a 2.x version having the same package and class names, but different method sets or even different semantics. Now in a large project a piece of software from one vendor needs 1.x and another one needs 2.x. Now consider they really need to share the same class loader and you are lost. You would not if you could have both 1.x and 2.x usable at the same time. Daniel's proposal would make this possible. Oliver Disclaimer: Daniel talked this over with me in person yesterday, so our points of view are pretty much aligned. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [logging] Enterprise Common Logging... dare we say 2.0?
Have you had a look at the commons-sandbox i18n project? This might be a
solution to enable localized logging with fine grained messages.
Methods would look like this:
LogMessage logMessage = new LogMessage(someMessakeKey, new String[] {
param1, param2 }
EnterpriseLogger.info(String messageName, LogMessage logMessage);
Log message class could have similar attributes as the ErrorMessage class.
Regards,
Daniel
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Richard Sitze
Gesendet: Donnerstag, 9. Dezember 2004 21:21
An: [EMAIL PROTECTED]
Betreff: [logging] Enterprise Common Logging... dare we say 2.0?
IBM would like to open a discussion within the Jakarta commons community
on evolving the Jakarta Commons Logging (JCL) API's to support Enterprise
level logging functionality. We recognize the value that a logging
implementation independent API brings to open source component
development, and would like to work with the community to accomplish this
goal.
We present a set of requirements as a baseline for the discussion, a
proposal for meeting these requirements, a number of points of discussion,
and attached are two Java source files that correspond to the discussion
below.
Requirements:
We recognize that the community has an overriding
requirement:
A.1. Evolution: maintain compatibility with the
current LogFactory/Log interfaces.
We have ONE primary requirement:
A.2. Globalization
Having opened the door, we'd also like to propose a few
other requirements:
B.1. Functional alignment with JSR-47 concepts.
B.2. Fix fragile configuration problems - Currently
the user has NO idea which impl is in effect.
All the default/fall back behavior means that in
the end we have an apparent non-deterministic
logging implementation. Errors in config file
names, classpath errors, classpath ordering,
etc., can all change the behavior... with no
idea which is in effect.
The fundamental problem with the current factory
is that it is dependent on passively
identifying a logging implementation.
We propose one solution below, but would ask a
more general question: any new bright ideas?
Proposals:
A.1. Evolution: Maintain compatibility with the
current LogFactory/Log interfaces BY PROVIDING
- Drop-in replacement of commons-logging.jar
version 1.x with a version 2.x variant.
- EnterpriseLogFactory class that extends the
existing LogFactory.
- EnterpriseLog interface that extends the
existing Log interface.
A.2. Globalization. For the enterprise logging we
need globalized messages (translated) for message
level logging API's: info, warn, error, fatal.
The remaining logging API's are considered trace
level logging API's, and do not require message
translation.
- For message level logging, support globalized
variants on the new EnterpriseLog interface:
info(Class callingClass,
String methodName,
String messageID);
info(Class callingClass,
String methodName,
String messageID,
Object messageParam);
info(Class callingClass,
String methodName,
String messageID,
Object[] messageParams);
same for warn, error, fatal.
- Utility function to support formatting for
other purposes (exception strings):
formatMessage(String messageID);
formatMessage(String messageID, Object messageParam);
formatMessage(String messageID, Object[] messageParams);
Ensure that component has an assurance that the
message will be translated/formatted as expected:
- ALL message translation must be done using
the standard java.util.ResourceBundle class,
or functional equivalent.
- ALL message formatting must be done using
the standard java.text.MessageFormat class,
or functional equivalent.
- Bind a ResourceBundleName to an EnterpriseLog
instance.
- Expects that the named ResourceBundle is
available to the logger.
B.1. Functional alignment with JSR-47 concepts.
JSR-47 has 3 trace levels: FINE, FINER, FINEST
JCL has 2 trace levels defined today: debug,
trace which corresponds to JSR-47 FINE and
FINEST in the current implementation.
The JSR-47 FINER level has no corresponding APIs
in JCL. The expectation is that
AW: Migrate to SVN?
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Brett Porter Gesendet: Samstag, 27. November 2004 00:28 An: Jakarta Commons Developers List Betreff: Re: Migrate to SVN? Stephen Colebourne wrote: My main reason is that SVN does not appear to be that widely adopted yet. A sign that the time has come to migrate would be when Eclipse/Idea ships with SVN support built in. IDEA's current EAP cycle has included support OOTB. I haven't tried it yet though... At the moment, I fear we may just scare off some potential users/contributers. Good point. How much will this affect commons as a whole? Are there any particular components that are receiving a lot of user contributions? I personally think they'll figure it out if we have reasonable SVN documentation to help them out. The reverse is also true. Folks can now get access to SVN behind a corporate proxy, where with CVS an SSH tunnel is nearly impossible to attain and pserver only slightly easier. Did you manage to work with subclipse behind a proxy? I've had some long discussions with the (big) custumer I'm currently working for so that they changed their proxy setting to let the delta-v stuff going through, but... unfortunately subclipse seems not to support proxies? But if this would work this is a big plus. On the other hand subclipse is not yet as mature as cvs support in eclipse. My working copy gets obscured all the time... confusing. Cheers, Daniel Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
I'm working with subversion (1.1.1)/subclipse/tortoiseSVN for a while now and I'm not completely convinced. The subclipse plugin for eclipse is by far not as mature as the cvs support (no links supported etc.) I was a little bit disappointed when I tried to use subclipse behind a proxy. I didn't managed to use subclipse behind a proxy, even though I convinced the tech stuff at the customer I'm currently working to enable the delta-v commands. On the other hand the more people using it will make the community grow that works on subclipse/subversion. Cheers, Daniel Jakarta Commons Developers List [EMAIL PROTECTED] schrieb am 25.11.04 20:08:02: 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [transaction][VOTE] Release 1.0-RC1
+1 Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Oliver Zeigermann Gesendet: Samstag, 20. November 2004 02:28 An: Jakarta Commons Developers List Betreff: [transaction][VOTE] Release 1.0-RC1 Dear community, I would like to see a 1.0 release candidate. The code is stable, junt tests pass, document exists and the scripts are in good shape. Still we should check that everything looks the way we expect before releasing a final 1.0. I already created the distributions calling 'ant package'. They are ready for inspection here: http://www.apache.org/~ozeigermann/ So, I am +1 for a release. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
My (non-binding) vote: +1 as this package makes the complicated transaction stuff more handy Daniel Jakarta Commons Developers List [EMAIL PROTECTED] schrieb am 15.11.04 18:50:02: Folks, as described in previous posts and inspired by the fine proposal for email promotion I would like to see the transaction component http://jakarta.apache.org/commons/sandbox/transaction/ promoted to commons proper. The initial committers would be Stefan Lützkendorf, James Mason, Daniel Florey and me. AFAIK none of us is a committer in commons proper so the promotion would include making as committers there. We all are Jakarta Slide committers and this is where the component came from. We factored out code for a transactional file system, transactional maps (implementing Map interface) with different ACID strategies, general purpose locks and a few more helper classes. Junit tests exist for all parts and succeed: http://jakarta.apache.org/commons/sandbox/transaction/junit-report.html Javadoc is pretty complete http://jakarta.apache.org/commons/sandbox/transaction/apidocs/index.html and general documentation and even a short tutorial for locks exist: http://jakarta.apache.org/commons/sandbox/transaction/locks/tutorial.html The transaction component is stable enough to be released as a 1.0 soon after promotion and would initially be maintained by the committers of the Slide community. Once promoted growth is anticipated as even in the sandbox it attracted some attention. As I am not a commons committer, I have no binding vote, but my non-binding vote of course is +1. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Collections] DFAMap? (LONG)
Hi,
I've not fully understood what this is good for. I thought the main problem is to
invalidate/remove subtrees in a cache.
This could be achieved quit simple, doesn't it?
Or have I missed something...
Cheers,
Daniel
Jakarta Commons Developers List [EMAIL PROTECTED] schrieb am 27.10.04 16:35:05:
After discussion and more tests in the Slide group I have abandoned
the approach.
All this does not work for realistic scenarios and realistic sizes.
Main problem is that if the keys do not share much common prefixes the
size of states gets enormously and impracticably high.
Sources still can be found in the Slide CVS.
Cheers and thanks for the attention,
Oliver
On Tue, 19 Oct 2004 07:30:44 +0200, Oliver Zeigermann
[EMAIL PROTECTED] wrote:
Folks,
while thinking about cache invalidation strategies in the Slide
project a long abandoned idea come back to my mind: a DFA based map
for String keys only! When I implemented a scetch of this once it
turned out to be slower in all respects than hash maps. These are my
old measurements:
DFA: 10 puts: 5,7 secs / 10 gets: 1 sec
HashMap: 10 puts: 3,2 secs / 10 gets: .661 sec
Even hand tuned versions could not catch up (no measurements - I guess
I was too frustrated at that time).
Anyway, what I need now is a map *plus* something that returns all
values of the keys that have a certain prefix. E.g. if I have three
entries like
olli - v1
olli2 - v2
ollo - v3
the prefix of oll would get me v1,v2,v3; olli would get me v1,v2; etc.
Now when the number of entries is small you could just iterate over
the entries and do something like a startsWith and collect the values.
In a scenario with thousands or even millions of entries with frequent
checks this is prohibitive, though.
Coming to the point now, when I organise the look up as a DFA the
search space for prefixed values should be dramatically decreased! The
map DFA would be some sort of tree and classes might look like this.
class DFAState {
Object value;
Edge[] mapping;
}
class Edge {
char label;
DFAState nextState;
}
Every state would have an associated value and a number of outgoing
edges to other states. Upon lookup they can be traversed when the next
character is the labeled one. There can at most be one character per
label, so this is deterministic.
If there is no such label then the look fails. If the whole key has
been matched the look up value is the one associated with the DFA.
Those states are called end states. All other states have no
associated value.
Applied to the example above the DFA might look like this. s{i} are
state names, |s{i}| are end state, - are edges. Above and below the
edges, I have put the labels.
o l l i 2
s1 - s2 - s3 - s4 - |s5| - |s6|
\
o |s7|
(hope this makes sense to anyone)
Now, suppose the prefix is oll. Traversing the DFA would bring me to
s4. Doing a simple depth first search from there for all reachable end
states (s5,s6,s7) will return me all entries having this prefix, i.e.
v1,v2,v3. olli would bring me to s5 and the end states reachable
from there (s5,s6) will bring me the v1,v2.
And there I am...
In case anyone has read this through, does it make sense? Or should I
start taking those pills?
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AW: Website maintainer?
Thanks+I'll remove them ASAP... Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Dirk Verbeeck Gesendet: Sonntag, 17. Oktober 2004 16:13 An: Jakarta Commons Developers List Betreff: Re: Website maintainer? Hi Daniel, I have added i18n and contract to the menu and component table. The site has been updated. I also changed the commons-site.jsl script, you don't need to copy the css files anymore. Please delete these files if you just use the default ones. Cheers, Dirk Daniel Florey wrote: Hi folks, I'm wondering who is maintaining the commons website. I've added two new components to the sandbox (i18n and contract) and I'd like to add a link and description to the website. Is anybody around who can do this for me or do I need commons commit access to do it myself? Cheers, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Website maintainer?
Hi folks, I'm wondering who is maintaining the commons website. I've added two new components to the sandbox (i18n and contract) and I'd like to add a link and description to the website. Is anybody around who can do this for me or do I need commons commit access to do it myself? Cheers, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Im-/Ex-porter into Commons Sandbox
Jakarta Commons Developers List [EMAIL PROTECTED] schrieb am 11.10.04 09:50:48:
If you're looking for something simple, you may want to check out
http://xstream.codehaus.org/ as well.
I just checked it out and it looks very sweet! Very clean approach (looks simpler to
me as betwixt because there are no xml-mapping files).
Thanks for the link! I've implemented something similar (but ugly and half-finished)
in the Slide Projector. Hope I can replace it...
Cheers,
Daniel
On Mon, 11 Oct 2004 08:35:01 +0200, Oliver Zeigermann
[EMAIL PROTECTED] wrote:
Hi Simon,
I really appreciate your input, thanks again :)
On Mon, 11 Oct 2004 19:15:11 +1300, Simon Kitching
[EMAIL PROTECTED] wrote:
As I already tried to explain. Both are soo different. No need for
any worries...
They even serve a different audience I guess. Digester is good for
people who do not want to see any XML stuff and what Java objects,
with xmlio you are closer to the guts of SAX and XML.
I don't actually see that they are that different.
You can use Digester in a manner very similar to the way xmlio is used.
This is not the way Digester is marketed in its examples but it is
still quite valid:
class Foo {
private class HandleWidget extends Rule {
public void begin(...) {
// code to do stuff when a widget tag is found
}
}
...
digester.addRule(/root/widget, new HandleWidget());
digester.addRule(/root/gadget, new HandleGadget());
xmlReader.setContentHandler(digester);
xmlReader.parse(input);
}
Here's the xmlio equivalent (I think...)
class Foo {
private class MySimpleImportHandler implements SimpleImportHandler {
public void StartElement(...) {
if (path.equals(/root/widget) {
// code to do stuff when a widget tag is found
}
else if (path.equals(/root/gadget) {
// code to do stuff when a gadget tag is found
}
}
simpleImporter.addSimpleImportHandler(new MySimpleImportHandler());
saxParser.setContentHandler(simpleImporter);
saxParser.parse(input);
}
Agreed.
In other words, Digester *can* be used as a light wrapper around SAX.
The begin/body/end methods of a custom Rule class are basically the SAX
callbacks; when using Digester in this style, Digester is really just an
event dispatcher routing each sax event from a single ContentHandler
class to zero or more relevant rule classes to avoid having big
cascading if/then statements in the ContentHandler class.
It wouldn't take too much work to provide xmlio's convenient feature of
passing the attributes into the body/end methods as well as the begin
method. It doesn't need to provide xmlio's Path functionality because
the event dispatching mostly removes the need for that.
The problem at the moment is it brings with it so many inter and intra
library dependencies that there isn't a light *distributable package*
containing just the core Digester classes.
I'm certainly not trying to criticise xmlio; I'm just concerned that
multiple projects will both dilute the available developer pool and
confuse potential users. And all that extra work - unit tests, project
website, etc! If the projects are truly providing different
functionality, well there's no issue. But as I understand xmlio now, I
think that exactly the same goal can be achieved with almost exactly the
same amount of custom code with both libs.
Oliver: do you feel that the fact that Digester does sax event
dispatching while xmlio doesn't really make the lib feel different to
you? (honest question, it is a slightly different paradigm, like OO vs
procedural). Is there something else that makes you feel Digester is
fundamentally different from xmlio?
Simplicity and obviousness, having all parts of the code and the data
that are associated at one spot. Next is performance and actual
complexity of code. Next is amount of created objects.
Still, these are just considerations that come from my personal taste.
When rules become a bit more complicated, it might become pretty hard
to understand what is going on in the guts. A large block of if /
else statements might not be what people - including myself - would
call exactly elegant, but it is obvious with no secrets.
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://www.multitask.com.au/people/dion/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Verschicken Sie romantische, coole
RE: AW: AW: AW: AW: New componenent: i18n
This is very strange... I don't have cvs access today but I'll check it ASAP when I'm back home. Mysterious... Daniel Jakarta Commons Developers List [EMAIL PROTECTED] schrieb am 11.10.04 09:40:35: Hi Daniel, Daniel Florey wrote on Sunday, October 10, 2004 4:06 PM: Hmm, as I've checked out jakarta-commons so that this .jsl is present (and is found by Maven) I'm not sure if this is wrong. I'll investigate the whole thing later and will hopefully find a way to finally get the site up and running... Thanks, Daniel I wanted to build the docs myself, but to my surprise the project.xml and project.properties have been gone from CVS ?!?!? Not even a single trace is left (nothing in Attic) as if somebody recreated that part of the repo from a backup. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[xmlio] Naming
After doing the xmlio google thing I agree that this name is really used in so many projects that it would be worth to find another one even if I like it. As 'xmlio' consists of two parts (importer / exporter) I would recommend separating them into two tiny components in order to increase reusability. My favourite name for the importer (sax augmentation) would be 'jazz'. As you need a sax to play jazz... (Or is it 'just augmented super sax'??) The exporter could be simply called XMLWriter as this is what it does. Finally I'd like to say that I don't think Digester and xmlio are direct competitors as they are very different: xmlio is a simple sax extension but has nothing to do with mapping xml to java objects. So I don't think we get trouble here. Regards, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: New componenent: i18n
Did javadoc creation worked for you?? Still don't get any javadocs.
Sources have been found before as the jar was created, but javadocs are
still missing...
Thanks,
Daniel
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Tim Reilly
Gesendet: Samstag, 9. Oktober 2004 03:06
An: Jakarta Commons Developers List
Betreff: Re: New componenent: i18n
Daniel,
Catching up on my emails for a moment...I noticed no one has replied
here, unless I missed it? Curious about your question I checked out
i18n ... hmm..seems: pomArtifactId comes from the name element and not
the id element. I recognize the error as possible missing package
element. In this case since project.xml in sandbox-build reads:
packageorg.apache.commons.${pom.artifactId.substring(8)}.*/package
... and you have a capital I18n in the name element... it didn't find
the sources for the package i18n. Just a letter-case thing.
Remember the ASL 2.0. in the project.xml
Below are 2 patches (with an additional thing (something I needed
once) in the patches. This line in project.properties and related in
the pom;
+commons.project.extendsUri=../sandbox-build/
Allowing parameterization of the relative path to sandbox-build
Index: project.properties
===
RCS file: /home/cvspublic/jakarta-commons-
sandbox/i18n/project.properties,v
retrieving revision 1.3
diff -u -r1.3 project.properties
--- project.properties 6 Oct 2004 08:48:07 - 1.3
+++ project.properties 9 Oct 2004 01:50:09 -
@@ -34,3 +34,9 @@
# Jars set explicity by path.
#
maven.jar.xml-im-exporter = ${basedir}/lib/xml-im-exporter1.1.jar
+
+# ---
-
+# Commons specific
+# ---
-
+# Allow flexible checkout of these two projects
+commons.project.extendsUri=../sandbox-build/
Index: project.xml
===
RCS file: /home/cvspublic/jakarta-commons-sandbox/i18n/project.xml,v
retrieving revision 1.4
diff -u -r1.4 project.xml
--- project.xml 6 Oct 2004 08:48:07 - 1.4
+++ project.xml 9 Oct 2004 02:02:13 -
@@ -1,7 +1,23 @@
?xml version=1.0?
+!--
+ Copyright 2004 The Apache Software Foundation
+
+ Licensed under the Apache License, Version 2.0 (the License);
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an AS IS BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ --
project
- extend../sandbox-build/project.xml/extend
- nameCommons I18n/name
+ extend${commons.project.extendsUri}project.xml/extend
+
+ nameCommons i18n/name
idcommons-i18n/id
logo/images/i18n-logo-white.png/logo
urlhttp://jakarta.apache.org/commons/sandbox/i18n//url
@@ -21,10 +37,10 @@
iddflorey/id
email[EMAIL PROTECTED]/email
organizationApache Software Foundation/organization
- timezone+2/timezone
roles
roleJava Developer/role
/roles
+ timezone+2/timezone
/developer
/developers
hth,
-TR
On Mon, 4 Oct 2004 15:54:41 +0200, Daniel Florey [EMAIL PROTECTED]
wrote:
Hi folks,
I'm a Slide committer for a while and now extracted a tiny package
called
i18n that I found to be very useful in several projects in the past.
I wanted to add it to the sandbox, but unfortunately didn't even manage
to
build the site with maven correctly. Everything works fine except the
javadoc generation.
The javadoc-plugin states that no sources can be found. I've upgraded to
javadoc plugin 1.7 but this won't help.
Can anyone of the maven experts around have a look at this problem? As
I'm
very new to maven I think it's most likely fault.
I've just added the sources to the CVS ({sandbox}/i18n).
Many thanks in advance,
Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AW: [xmlio] Naming
OK, I haven't read this (shame on me). So you are right. What about commons-jsax? Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Stephen Colebourne Gesendet: Samstag, 9. Oktober 2004 12:20 An: Jakarta Commons Developers List Betreff: Re: [xmlio] Naming Please see the commons charter on naming. Paraphrasing it says that names should be boring and functional, not clever. jazz is clever ;-( The reasoning is to remove one more barrier to adopting the component. (Note that not every commons component follows the rule, betwixt being a good example) maybe [sax] for input? (commons-sax) or [fromsax] - (commons-fromsax) maybe [toxml] for output? (commons-toxml) or [tosax]? (commons-tosax) It depends on whether you want to scope/limit yourself to just sax. Should you split? It depends on whether people who use one half are likely to use the other really. Stephen - Original Message - From: Daniel Florey [EMAIL PROTECTED] After doing the xmlio google thing I agree that this name is really used in so many projects that it would be worth to find another one even if I like it. As 'xmlio' consists of two parts (importer / exporter) I would recommend separating them into two tiny components in order to increase reusability. My favourite name for the importer (sax augmentation) would be 'jazz'. As you need a sax to play jazz... (Or is it 'just augmented super sax'??) The exporter could be simply called XMLWriter as this is what it does. Finally I'd like to say that I don't think Digester and xmlio are direct competitors as they are very different: xmlio is a simple sax extension but has nothing to do with mapping xml to java objects. So I don't think we get trouble here. Regards, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: New componenent: i18n
Witzbold... I've tried almost everything but javadoc plugin cannot detect the sources even though they get correctly build. So if everyone could try this out, I'd be very happy. Regards, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jörg Schaible Gesendet: Samstag, 9. Oktober 2004 12:43 An: [EMAIL PROTECTED] Betreff: Re: AW: New componenent: i18n Daniel Florey wrote: Did javadoc creation worked for you?? Still don't get any javadocs. Sources have been found before as the jar was created, but javadocs are still missing... Thanks, Daniel So what did you do? Just called maven? The default goal might be just to build the jar, but no docs. Call maven site for doc generation. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: AW: New componenent: i18n
Hi Jörg, You are the greatest It works!! Many thanks. Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jörg Schaible Gesendet: Samstag, 9. Oktober 2004 14:24 An: [EMAIL PROTECTED] Betreff: Re: AW: AW: New componenent: i18n Daniel Florey wrote: Witzbold... I've tried almost everything but javadoc plugin cannot detect the sources even though they get correctly build. You are the one, who stated on the Maven list, that you're totally unexperienced with Maven. So if everyone could try this out, I'd be very happy. Works if you add the package: Index: project.xml === RCS file: /home/cvspublic/jakarta-commons-sandbox/i18n/project.xml,v retrieving revision 1.6 diff -u -u -r1.6 project.xml --- project.xml 9 Oct 2004 11:19:49 - 1.6 +++ project.xml 9 Oct 2004 13:22:14 - @@ -28,6 +28,7 @@ logo/images/i18n-logo-white.png/logo urlhttp://jakarta.apache.org/commons/sandbox/i18n//url inceptionYear2004/inceptionYear + packageorg.apache.commons.i18n/package shortDescriptionCommons I18n/shortDescription descriptionInternationalization package/description - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: AW: AW: New componenent: i18n
Can you have a quick look at the generated website? http://jakarta.apache.org/commons/sandbox/i18n/ It looks somehow different from other sandbox components. As if the stylesheet is missing? Do you have a clue? Thanks again, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jörg Schaible Gesendet: Samstag, 9. Oktober 2004 15:25 An: [EMAIL PROTECTED] Betreff: Re: AW: AW: AW: New componenent: i18n Daniel Florey wrote: Hi Jörg, You are the greatest It works!! Many thanks. Daniel You're welcome :) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: XML Im-/Ex-porter into Commons Sandbox
Hi all, I'll have a look at Digester again today and will compare the two approaches finally for use in i18n. As I know Oliver Zeigermann for a long time and he really is the master of xml/sgml I everyone should give xmlio (good name indeed) a try. Personally I like technologies that keep it very simple so that you understand at the first sight what's going on without hiding too much implicit logic. As I stated earlier we have used Digester in a large project where a lot xml parsing took place and we had some trouble with it (but that's some time ago). So I'd vote for putting the xmlio into the sandbox and let everybody have a look at it. Even if it will never make it to commons components, it is worth to have a look at its simplicity. Regards, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Martin Cooper Gesendet: Donnerstag, 7. Oktober 2004 23:46 An: Jakarta Commons Developers List Betreff: Re: XML Im-/Ex-porter into Commons Sandbox On Thu, 7 Oct 2004 23:27:39 +0100, Stephen Colebourne [EMAIL PROTECTED] wrote: One of the key items in the commons charter is allowing different solutions to the same problem. So far, we have tended to avoid this (for example, I took a conflicting primitives design elsewhere) however we should not block this. What is being requested at this point is to factor out some code from another project (Slide) to commons. This is IMHO perfectly good and what commons is for. The code is going to the sandbox where we can all determine whether it is a good addition to the commons-proper fold. (eg. performance tests, code design, documentation). Who knows maybe the ideas will end up as digester 2! IMO thats what the sandbox is for. In general, I agree with you. However, in this case, the reason for bringing this component to the sandbox is because another component that has only just arrived in the sandbox (i18n) wants to use it instead of Digester. It seems that this XML component wasn't going to be brought to Commons (at least for the moment) until there was mention that i18n wanted to use it. I'm not sure that I like the idea of new sandbox components bringing along other components as baggage when there is already suitable functionality available in Commons Proper. On the other hand, I would not be opposed to bringing the XML component in _later_, and letting it stand or fall on its own. -- Martin Cooper BTW, I don't disagree with the comments about bad dependency management below, I just disagree that that necessarily implies only ever supporting digester. Finally, the name ;-) xmlio (ie. xml io) sax saxio Typically, the commons project is named after the technology it works on. Without having seen the code its also difficult to judge what a good name would be ;-) I quite like xmlio myself. Stephen - Original Message - From: David Graham [EMAIL PROTECTED] This will create bloat problems for clients that use Digester. For example: Struts uses Digester for xml parsing. In the future Struts may want to use the new i18n component. However, if i18n uses XML Im-Exporter then Struts must drag that along too despite already having a perfectly fine xml parser in its dependency list. Struts is just one example. It will be even worse for inter-commons project dependencies. Bad dependency management has plagued commons components and it's just recently started to get better. If all commons components use Digester then we can avoid having to duplicate functionality and bloat dependencies. I don't understand what's wrong with Digester that necessitates a new parsing library. I've been able to write complex parsing rules in a matter of minutes. David --- Oliver Zeigermann [EMAIL PROTECTED] wrote: Folks, on the request of Daniel Florey I'd like to create at least one new sandbox component for a tool that allows easy import / export of XML into / from Java. It is used by Jakarta Slide and in the components Daniel introduced. I know this is a bit delicate as there already is Digester around in commons. However, the audience for my tool is different from Digester's. XML Im-/Exporter is geared towards high performance use for people who are very familiar with XML. It is just a little bit more than pure SAX. It also has a different philosohie than Digester. Having said that I hope not to cause any inconvenience with this... Preparing this now and cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED
[digester] AW: XML Im-/Ex-porter into Commons Sandbox
The digester site seems to be broken. All links to the docs dont work -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Daniel Florey Gesendet: Freitag, 8. Oktober 2004 09:32 An: 'Jakarta Commons Developers List'; 'Martin Cooper' Betreff: AW: XML Im-/Ex-porter into Commons Sandbox Hi all, I'll have a look at Digester again today and will compare the two approaches finally for use in i18n. As I know Oliver Zeigermann for a long time and he really is the master of xml/sgml I everyone should give xmlio (good name indeed) a try. Personally I like technologies that keep it very simple so that you understand at the first sight what's going on without hiding too much implicit logic. As I stated earlier we have used Digester in a large project where a lot xml parsing took place and we had some trouble with it (but that's some time ago). So I'd vote for putting the xmlio into the sandbox and let everybody have a look at it. Even if it will never make it to commons components, it is worth to have a look at its simplicity. Regards, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Martin Cooper Gesendet: Donnerstag, 7. Oktober 2004 23:46 An: Jakarta Commons Developers List Betreff: Re: XML Im-/Ex-porter into Commons Sandbox On Thu, 7 Oct 2004 23:27:39 +0100, Stephen Colebourne [EMAIL PROTECTED] wrote: One of the key items in the commons charter is allowing different solutions to the same problem. So far, we have tended to avoid this (for example, I took a conflicting primitives design elsewhere) however we should not block this. What is being requested at this point is to factor out some code from another project (Slide) to commons. This is IMHO perfectly good and what commons is for. The code is going to the sandbox where we can all determine whether it is a good addition to the commons-proper fold. (eg. performance tests, code design, documentation). Who knows maybe the ideas will end up as digester 2! IMO thats what the sandbox is for. In general, I agree with you. However, in this case, the reason for bringing this component to the sandbox is because another component that has only just arrived in the sandbox (i18n) wants to use it instead of Digester. It seems that this XML component wasn't going to be brought to Commons (at least for the moment) until there was mention that i18n wanted to use it. I'm not sure that I like the idea of new sandbox components bringing along other components as baggage when there is already suitable functionality available in Commons Proper. On the other hand, I would not be opposed to bringing the XML component in _later_, and letting it stand or fall on its own. -- Martin Cooper BTW, I don't disagree with the comments about bad dependency management below, I just disagree that that necessarily implies only ever supporting digester. Finally, the name ;-) xmlio (ie. xml io) sax saxio Typically, the commons project is named after the technology it works on. Without having seen the code its also difficult to judge what a good name would be ;-) I quite like xmlio myself. Stephen - Original Message - From: David Graham [EMAIL PROTECTED] This will create bloat problems for clients that use Digester. For example: Struts uses Digester for xml parsing. In the future Struts may want to use the new i18n component. However, if i18n uses XML Im-Exporter then Struts must drag that along too despite already having a perfectly fine xml parser in its dependency list. Struts is just one example. It will be even worse for inter-commons project dependencies. Bad dependency management has plagued commons components and it's just recently started to get better. If all commons components use Digester then we can avoid having to duplicate functionality and bloat dependencies. I don't understand what's wrong with Digester that necessitates a new parsing library. I've been able to write complex parsing rules in a matter of minutes. David --- Oliver Zeigermann [EMAIL PROTECTED] wrote: Folks, on the request of Daniel Florey I'd like to create at least one new sandbox component for a tool that allows easy import / export of XML into / from Java. It is used by Jakarta Slide and in the components Daniel introduced. I know this is a bit delicate as there already is Digester around in commons. However, the audience for my tool is different from Digester's. XML Im-/Exporter is geared towards high performance use for people who are very familiar with XML. It is just a little bit more than pure SAX. It also has a different philosohie than Digester. Having said that I hope not to cause any inconvenience with this... Preparing this now and cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED
AW: [i18n] New component - help needed
Hi Eric, Thanks for your help, but this didn't help much as with your changes the layout is broken and I cannot upload the website as some ssh-infos are missing. I wonder why the maven scripts for the transaction component (that I used as a blueprint) are working perfectly? I've no clue. Maybe I've to go to the maven mailinglists... Thanks again for your help, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Eric Pugh Gesendet: Dienstag, 5. Oktober 2004 22:35 An: Jakarta Commons Developers List Betreff: RE: [i18n] New component - help needed Danile, I just tossed in a fix. basically the parent project is broken.. not extending it works.. as far tas the script, just rerun on your box the entire script, and then upload the homepage. Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 8:12 PM To: Jakarta Commons Developers List Subject: [i18n] New component - help needed Hi folks, I've successfully added the I18n component to the commons sandbox. As I'm new to Maven I didn't managed to generate the API Javadocs. Can anyone have a look at this? Is this my fault as I assume? Seems that Maven can not find the source (but is actually building the jars without trouble). Any hints would be great! How can I integrate the link to the new component to the main commons page? Should I run the script on commons-sandbox top level? I'm afraid to do so as I may cause something bad. Regards, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [i18n] Did I miss something?
Hi James, Any contributions are welcome! As I still don't get the site generated with maven completely (layout is somehow broken and javadocs are missing) this is very high on my todo... Maybe you can help me out? Would be nice to get a link from the commons page to the i18n in the sandbox. Do you know if someone can manage this (having commit access to commons)? - In general I like the idea to read messages from properties files as this might be very useful to migrate existing application to i18n. Even though I like the xml-based format more as you can see which entries belong together. - Adding icons and so on can easily be achieved by adding a new class (like LocalizedDescription...) - I'll add a proposal for using localized messages for logging as I've used this in a project using an additional Information class. This works very nice and lets you map different error entries to different log messages (details to debug, text to info or something like that). - I don't know if I used logging at all but it should be no prob to switch to log4j or commons-logging. - I don't like digester at all as this seems to me the most confusing and overdosed way to parse xml files. I talked to Oliver Zeigermann and we will add xml-im-exporter to commons-sandbox as I find this the very best tool do sax-based xml-parsing. It's ultra-simple, fast and intuitive. That's why I've used it in many projects in the past and would be very glad to see it here. I've worked with digester in the past but it's just too complex and xml-im-exporter is just kicking-ass... Warmest regards, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von James Mitchell Gesendet: Mittwoch, 6. Oktober 2004 15:17 An: Jakarta Commons Developers List Betreff: [i18n] Did I miss something? Wow, how did I miss this? I wonder what we can do with this and commons-resources and/or Apache Struts. In my current gig we are using a home grown solution in combination with ActionErrors/ActionMessages provided by Struts. This project would have been nice to have about 8 months ago. My immediate needs (scratching my own itch here) would be to help provide greater granularity for application messaging (similar to log levels) and perhaps a jsp taglib or two to help take advantage of this in my apps (this would probably go under Apache Struts contrib). So, with that said, I would like to volunteer to help with this project. Off the top of my head what I would like to do is: a) offer the same solution with the following alternate implementations: - properties file based configuration (more on this later) - RDBMS based configuration (I've already done this in commons-resources) b) Develop a Struts plug-in that will load and configure commons-i18n for my Struts applications. (I guess I could just add this as a plug-in under struts) c) The types of LocalizedMessages or LocalizedExceptions I can use are the following: - System error - Error - Warning - Alert - Flag - Info d) I would like to add an entry like: entry key=small-icon/images/some-icon-small.jpg/entry (also one for large-icon) e) New MessageManager impl that can assemble messages based on a config file who's entries simply point to existing i18n'd properties file(s) keys. (I will provide more details for this on my ShortTermPlans page http://wiki.apache.org/struts/ShortTermPlansForJamesMitchell) General questions: Is there any reason you did not use commons-logging? Can we change this to commons since it will (by default) delegate to the appropriate logging framework (let's eat our own dogfood)? Any reason you are using xml-importer instead of digester? I've read the docs on sf.net, but the advantages still aren't clear to me (I'm guessing it was just a personal choice made some time ago and you just stayed with it). Can we change this to use either (or use commons-configuration)? Have you thought about Spring integration? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[i18n] New component - help needed
Hi folks, I've successfully added the I18n component to the commons sandbox. As I'm new to Maven I didn't managed to generate the API Javadocs. Can anyone have a look at this? Is this my fault as I assume? Seems that Maven can not find the source (but is actually building the jars without trouble). Any hints would be great! How can I integrate the link to the new component to the main commons page? Should I run the script on commons-sandbox top level? I'm afraid to do so as I may cause something bad. Regards, Daniel
New componenent: i18n
Hi folks,
I'm a Slide committer for a while and now extracted a tiny package called
i18n that I found to be very useful in several projects in the past.
I wanted to add it to the sandbox, but unfortunately didn't even manage to
build the site with maven correctly. Everything works fine except the
javadoc generation.
The javadoc-plugin states that no sources can be found. I've upgraded to
javadoc plugin 1.7 but this won't help.
Can anyone of the maven experts around have a look at this problem? As I'm
very new to maven I think it's most likely fault.
I've just added the sources to the CVS ({sandbox}/i18n).
Many thanks in advance,
Daniel
