Re: [VOTE] [email] promote RC4 to 1.0 status
+1 Can everybody just vote? Or is this only for committers? Regards, Matthijs robert burrell donkin wrote: On Thu, 2005-06-23 at 00:04 +1200, Simon Kitching wrote: [AARGH - I hate top-posting!!] It certainly seems like email is generally ready for release. I think one more RC and a new VOTE thread would be a good idea, as the vote thread from december last year really can't be continued now :-). +1 sounds like a good plan - 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]
Re: [contract] Suggestions
Let user decides what form choose to use right? Good, I think is a very good idea!!! If he wants a programmatic or declarative form he only need to decide!! Hi, I've been reading this thread and I think Woody's suggestion to let the user decide is a really good one. It would not even be hard to parse some xml and turn them into Constraints objects. It'd be really great to see some metadata features of Java 1.5 in this project as I think that metadata is perfectly suited for this kind of stuff. But to let the user decide what form to choose could never be a bad thing :) Just my 2c, Matthijs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] LocalFile package-protected and final: why?
Brian Oxley wrote: [A quick meta-question: is this list the right place for technical questions of this sort? I don't want to spam the uninterested.] Mario Ivankovits wrote: Before I decide to make it public (and non final) could you please explain in short what you try to do? I'm working to persuade my group to drop an inhouse implementation of a java.io.File-extended hierarchy and switch to VFS's FileName/FileObject instead. We have a mess; you have a clean design. I've been thinking about extending java.io.File to implement vfs-alike functionality. Are there any good reasons not to do this (other then that commons-vfs is already available)? Having a subclass of java.io.File would allow you to use your objects with 3rd party components and other java classes that work with files too. How impossible would it be to have java.io.File subclasses as wrappers around vfs? Just some random thoughts. Regards, Matthijs PS. I hope this answers your meta-question :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: digester newbie question
simon wrote:
On Mon, 2004-12-06 at 07:30, Mihai C. wrote:
Hi all, being new to digester, I have no clue how to get around my problem.
Here's the story:
I'm trying to parse a config xml that looks like this:
root
a
...
b
.
/b
b
.
/b
/a
a
...
b
.
/b
b
.
/b
/a
/root
I have two beans (ABean and BBean)
and the factory :
class Factory {
processA(ABean ab){
...
}
processB(BBean bb){
}
digest(){
Digester d = new Digester();
d.push(this); //stack bottom
d.addSetNext( root/a/b, processB , BBean); // when
root/a/b pattern mathes, execute processB on 'this' with BBean type param
d.addSetNext( root/a, processA, ABean); // when root/a
pattern mathes, execute processA on 'this' with ABean type param
d.addObjectCreate( root/a, ABean.class);
d.addObjectCreate( root/a/b, BBean.class);
... //var addCallMethod()
}
}
I get this error:
[DEBUG] Digester - -[SetNextRule]{root/a/b} Call
Factory.processB([EMAIL PROTECTED])
[ERROR] Digester - -End event threw exception
java.lang.IllegalArgumentException: argument type
mismatchjava.lang.IllegalArgumentException: argument type mismatch
Obviously, processB() was called with the wrong arg type(ABean instead of
BBean) and that because the BBean obj was just poped from the stack.
No, I think what is happening is that Digester is attempting to call a
method
processB(BBean)
on an object of type ABean. The ABean class presumably doesn't have such
a method.
The structure of your input xml implies that BBeans are children of
ABeans. But you appear to be trying to map this structure to a different
representation where ABean and BBean objects are children of a Factory
object. If you *really* want to do this, then I expect a way can be
found, but I doubt this is really what you want to achieve...
Remember that Digester has an object stack. You push an instance of
Factory on the stack initially. Then when an a tag is encountered,
your rules tell digester to create and push an ABean object onto the
stack, and call ProcessA on the (top-1) object (the Factory) passing the
top object (the ABean). All is ok so far. But then the b tag *within*
the a tag is encountered, so your rules tell Digester to create a
BBean object, push it on the stack, then call ProcessB on the (top-1)
object on the stack - which is an ABean. Now I think this probably *is*
what you want - the b tag is within the a tag, indicating that BBean
objects are children of ABean objects. So surely a method on the ABean
should be invoked to handle its children...
I hope this helps. If not, please provide a little more information on
why you don't want to map the input xml in the obvious manner..
Regards,
Simon
I agree with Simon that you probably don't want to do what you want to do.
But if you really want to, you can call addSetRoot(..) to do exactly
what you describe.
Regards,
Matthijs.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possibel contribution? System to keep a map of configured objects and to plug in rulesets dynamically
Hi Matthijs, I think your rules-related extension to Digester is very similar to the digester plugins module. Would you mind reading the javadoc for the plugins package, and then explaining a little more about the differences between that and your code? I have placed a copy of the package-summary for plugins from the CVS head here: http://www.apache.org/~skitching/digester-plugins-package-summary.html I didn't quite understand the following paragraph. Could you explain a little more? We have written a set of RuleSets that can be plugged into a digester object when needed, so that we can have a repository of often used RuleSets and per-application custom RuleSets. This is a comment about plugins in general. You can have multiple levels of plugin specificity, application-specific, company-specific, domain-specific, not-specific-at-all-aka-generic. So very common plugins can be found on the internet (hopefully), and very application-specific plugins are written by yourself or your development team. The feature of being able to have the new parsing rules embedded in the document being parsed, rather than in a separate xmlrules file, isn't currently supported by the plugins module, but I don't think it would be too hard to add to that framework. If you were willing to integrate your code with the existing plugins code, and the result wasn't too large in size, I would be interested in seeing it integrated into Digester. Even if you aren't interested in that, any feedback about the features of the existing plugins module vs your requirements would be appreciated. The bit regarding the ConfigDigester seems more application-specific to me, and in my opinion less suitable for inclusion in digester core. But others on this list may well have a different opinion. By the way, the convention on most email lists (and definitely on this one) is to reply using bottom-posting, where your comments are placed *beneath* the earlier ones. It makes it much easier to understand an email conversation when the email can be read top-to-bottom. Regards, Simon Hello Simon, Sorry, about the top-posting, I shall bottom-post from now on. There are really not too much differences between the plugin package and our classes. In our package, the 'plugins' are really just an implementation of a subinterface of the RuleSet interface. The advantage of that was that we didn't need to define an interface that specified how to load the Rules. When a new RuleSet is added, addRuleInstances is called and you can add your rules there. The pattern for which this RuleSet is applicable is set through the pattern property, that is, get/setPattern is defined in the subinterface of RuleSet that every plugin must implement. Of course you can choose to ignore the pattern property, just like you can ignore pathPrefix (in RuleLoader), although the javadoc says that you shouldn't. The plugin system that enables the loading of RuleSets is a plugin as well because it implements the same interfaces, but there is the problem of bootstrapping which is done in the main digesting application (ConfigDigester in our case). But I reckon Digester's plugin system has to deal with this too. Indeed, the ConfigDigester singleton having a Map of config objects, hasn't got much to do with plugins. I think it might be suitable as an application example, showing how to maintain a collection of objects after the xml file is parsed. It is really cool to see how much our systems look like each other. Makes me feel I can play with the big guys :D Regards, Matthijs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Possibel contribution? System to keep a map of configured objects and to plug in rulesets dynamically
Hello, My company uses xml documents and digester to configure their application at start-up. Usually we want a Map of configured objects at the end of application initialization. A problem we encounter often, is that the xml used in one application differs to the xml used in another application. Sometimes we want to configure DAO's, other times only Property objects, and even other times, MailBeans and some application-specific object. We want to be able to write different pieces of xml that configure the objects without having to modify the digester that parses them. We would like to contribute our code to the Digester project if possible as we think it might be useful for other developers as well. A short explanation of how it works follows. We have written a set of RuleSets that can be plugged into a digester object when needed, so that we can have a repository of often used RuleSets and per-application custom RuleSets. Plugging a RuleSet into the digester is also done in the xml document parsed by Digester, for example: ?xml version=1.0? config digester-ruleset class=config.PropertiesRuleSet pattern=config/properties / digester-ruleset class=config.MailBeanRuleSet pattern=config/mailbean / !-- Example properties -- properties name=example1 property key=key1 value=value1 / property key=key2 value=value2 / /properties properties name=example2 property key=key1 value=value1 / property key=key2 value=value2 / /properties mailbean name=contactForm class=ContactFormMail to email=[EMAIL PROTECTED] name=Its Me / /mailbean /config Of course, the definition of the digester-ruleset classes can be done in another xml document. From the code you would do: //Get the singleton instance of the ConfigDigester that is used througout the application ConfigDigester.getInstance().getDigester().parse(config.xml); //Get the object from the Map of configured objects Properties exampleProps = (Properties)ConfigDigester.getInstance().getConfigObject(example1); MailBean contactFormMailBean = (MailBean)ConfigDigester.getInstance().getConfigObject(contactForm); As you can see, an important aspect is that the MailBean object is kept in the configObject Map, even after being popped of the stack by digester. Let me know if this is useful for the Digester project, so I can provide the source. Best regards, Matthijs Wensveen Func. Internet Integration. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possibel contribution? System to keep a map of configured objects and to plug in rulesets dynamically
Hmm, I think this may be comparable to the digester.plugins packages? I haven't been paying attention to Digester development for quite a while so I had never seen these packages. Of course, I am still willing to provide source code to anyone that is interested... Matthijs. Matthijs Wensveen wrote: Hello, My company uses xml documents and digester to configure their application at start-up. Usually we want a Map of configured objects at the end of application initialization. A problem we encounter often, is that the xml used in one application differs to the xml used in another application. Sometimes we want to configure DAO's, other times only Property objects, and even other times, MailBeans and some application-specific object. We want to be able to write different pieces of xml that configure the objects without having to modify the digester that parses them. We would like to contribute our code to the Digester project if possible as we think it might be useful for other developers as well. A short explanation of how it works follows. We have written a set of RuleSets that can be plugged into a digester object when needed, so that we can have a repository of often used RuleSets and per-application custom RuleSets. Plugging a RuleSet into the digester is also done in the xml document parsed by Digester, for example: ?xml version=1.0? config digester-ruleset class=config.PropertiesRuleSet pattern=config/properties / digester-ruleset class=config.MailBeanRuleSet pattern=config/mailbean / !-- Example properties -- properties name=example1 property key=key1 value=value1 / property key=key2 value=value2 / /properties properties name=example2 property key=key1 value=value1 / property key=key2 value=value2 / /properties mailbean name=contactForm class=ContactFormMail to email=[EMAIL PROTECTED] name=Its Me / /mailbean /config Of course, the definition of the digester-ruleset classes can be done in another xml document. From the code you would do: //Get the singleton instance of the ConfigDigester that is used througout the application ConfigDigester.getInstance().getDigester().parse(config.xml); //Get the object from the Map of configured objects Properties exampleProps = (Properties)ConfigDigester.getInstance().getConfigObject(example1); MailBean contactFormMailBean = (MailBean)ConfigDigester.getInstance().getConfigObject(contactForm); As you can see, an important aspect is that the MailBean object is kept in the configObject Map, even after being popped of the stack by digester. Let me know if this is useful for the Digester project, so I can provide the source. Best regards, Matthijs Wensveen Func. Internet Integration. - 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]
New commons subproject vs. Configuration project
Hi, I am a certiefied Java programmer and work for a small Web development / Internet application company in the Netherlands. We have recently developed a system to configure web applications and standalone applications in a standard way. In some ways it looks like the Configuration subproject, but in other ways it is different. Our idea was to keep configuration information as centralized as possible. While it is possible to use multiple configuration files, users are encouraged to use only one configuration file. Another difference is that our configurator was meant to look a bit like a JNDI, no matter if there is a real JNDI on the background or just an XML file containing data. This also means it is possible to 'lookup' entire objects from the configurator. An obvious example would be a Properties object, but there is no real limit. You can write your own plugin to parse a piece of the configuration and supply you own objects if you want. Or just use the configuration data to configure a Logger, for example. I think this is its greatest strength. The XML you use is undefined, because different plugins can parse different pieces of XML. I think that our configuration system is very useful for the open source community, but I don't know if there is place for two different configuration systems in the Jakarta Commons project. Maybe it's possible to use each others ideas. If anyone is interested, I can provide full source, examples, documentation and javadocs, or just some extra info. Regards, Matthijs Wensveen. PS. It is possible to use the org.apache.commons.configuration classes *in* 'our' configuration system. And it's probably also possible to write a commons configuration class that uses 'our' configurator. PPS. Currently we have both SAX and DOM implementations, but if a JDOM implementation is preferred it should be easy to write. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New commons subproject vs. Configuration project
I am currently working on a separate site on sourceforge to place all
files, documentation and examples, but hopefully we can place it on
Apache some day soon.
This is how it works:
There is a singleton Context instance that is provided by a Context
subclass. Currently there are 2 implementations, StandaloneContext and
WebContext, and it will be easy to provide a JNDIContext.
After initializing, you reference the Context by calling
Context.getInstance(). So your calling classes will be unaware of the
underlying implementation.
The Context initialization consists of parsing an XML file and
delegating XML Nodes to specific handlers.
For example, config.xml:
?xml version=1.0?
config
element-handler
class=nl.func.util.context.handlers.PropertiesHandler
root-element=properties /
properties name=mail.settings
property key=mail.host value=mail.planet.nl /
property key=default.from value=[EMAIL PROTECTED] /
property key=default.bcc value=[EMAIL PROTECTED] /
/properties
/config
Now we can initialize a StandaloneContext, for example: (WebContext is
usually initialized in web.xml as a ContextListener)
new StandaloneContext(config.xml); // this will initialize a singleton
Context
Using the Context instance, you can lookup all configured objects by calling
Context ctx = Context.getInstance();
(Properties) mailSettings = ctx.lookup(mail.settings);
I'll send a link to the sourceforge project as soon as it's there.
-Matthijs.
Mark R. Diggory wrote:
Wow, I've always wanted a JNDI SPI for XML files! I imagined one day
using JXPath as the base for the search/getAttributes/lookup in such a
way as to have the XML content be very open and unrestricted and the
search filter syntax would be XPath.
/* an XmlContext is a DirContext over XML files */
javax.naming.xml.XmlContext ctx = new
javax.naming.xml.XmlContext(Hashtable env);
Element e = (Element)ctx.lookup(/foo/bar[2]);
Attributes atts = ctx.getAttributes(/foo/bar);
NamingEnumeration enum = ctx.search(/foo,[bar/@bam =
'boom'],searchControls);
while(enum.hasNext()){
Element e = (Element)enum.next();
...
}
I imagined it would also be used to write attributes, elements to create
new subcontexts. Imagine, a fully read/writable Configuration
framework... :-)
ctx.modifyAttributes(/foo/bar, attrs);
ctx.createSubContext(/foo/bar, bam);
ctx.destroySubContext(/foo/bar/bam);
I've been hoping for a way to supply a XML Configuration based
replacement for our current JNDI based distributed config which uses
LDAP servers.
Henri's right, there is room in the commons for multiple
implementations. I think this really promotes a path of
development where really good alternate approaches can exist.
Coevolution can often result in better adaptations to an environmental
condition.
-Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
