Re: [xmlio] Naming
I don't think they should be split. If it is a library for helping the input/output of XML why separate these into separate projects. Lets not get carried away with small functional libraries. There should be a limit to the size, purpose. I mean there has to come a point where the overhead of a new subproject isn't worth the benefit of the logical separation of otherwise related classes. If the library is 1) not a parser 2) not an XML marshaller 3) not an xml ingester (like digester) 4) not a bean serializer but rather a utility for inputing and outputting XML documents (augmenting SAX with callbacks). Then it needs a name that reflects that. I believe the only name I've heard so far that doesn't make me think of one of the above is xmlutil, but then again that will open up the project to be the home of other xml utility classes beyond input and output. Is this a goal of the project? Perhaps it should be. I suggest taking the name xmlutil and growing this to an XML utility library - in the same family as beanutil, collection, lang, etc. Input and output of XML documents is just one utility that can be offered. - Mike Gary Gregory wrote: [xml-in] and [xml-out] ? Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, October 09, 2004 04:20 To: Jakarta Commons Developers List Subject: 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]
Re: [xmlio] Naming
By doing this, I believe there will be far less confusion for people browsing the commons proper and sandbox catalogs. Run with [xmlutil] I think the shoe fits :-) - Mike Mike Stanley wrote: I don't think they should be split. If it is a library for helping the input/output of XML why separate these into separate projects. Lets not get carried away with small functional libraries. There should be a limit to the size, purpose. I mean there has to come a point where the overhead of a new subproject isn't worth the benefit of the logical separation of otherwise related classes. If the library is 1) not a parser 2) not an XML marshaller 3) not an xml ingester (like digester) 4) not a bean serializer but rather a utility for inputing and outputting XML documents (augmenting SAX with callbacks). Then it needs a name that reflects that. I believe the only name I've heard so far that doesn't make me think of one of the above is xmlutil, but then again that will open up the project to be the home of other xml utility classes beyond input and output. Is this a goal of the project? Perhaps it should be. I suggest taking the name xmlutil and growing this to an XML utility library - in the same family as beanutil, collection, lang, etc. Input and output of XML documents is just one utility that can be offered. - Mike Gary Gregory wrote: [xml-in] and [xml-out] ? Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, October 09, 2004 04:20 To: Jakarta Commons Developers List Subject: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Im-/Ex-porter into Commons Sandbox
How does this compare with StAX parser implementations? - Mike On Thu, 2004-10-07 at 15:53, Oliver Zeigermann wrote: XMLBeans is super high level, XML Im-/Exporter is super low level. E.g. XML Im-/Exporter (silly name by the way, any better ideas?) could *theortically* be the base of XMLBeans. It is pretty near to SAX. Oliver On Thu, 7 Oct 2004 15:38:10 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, How does this compare to XMLBeans? Yoav Shapira Millennium Research Informatics -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Thursday, October 07, 2004 3:30 PM To: [EMAIL PROTECTED] Subject: XML Im-/Ex-porter into Commons Sandbox 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, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: XML Im-/Ex-porter into Commons Sandbox
cool. I look forward to checking it out. IMO - that's what a sandbox is for. The dependency issue is a Java problem, not just a Jakarta commons problem. BTW- There appears to be a lot of xmlio's out there: http://www.google.com/search?q=xmlio You may want to consider a different name. Also - I know you've received a lot of how does this compare with X questions, but if you don't mind --- Dom4J ? (or you can ignore that, and I'll just wait to see the sandbox and judge for myself --- which I would inevitably do anyway ;-) - Mike On Fri, 2004-10-08 at 08:07, Oliver Zeigermann wrote: StAX is a new parser type. It is streaming, i.e. you get one token after the other upon request. xmlio still uses a standard SAX parser and merely augments callbacks. Oliver On Fri, 08 Oct 2004 08:03:36 -0400, Mike Stanley [EMAIL PROTECTED] wrote: How does this compare with StAX parser implementations? - Mike On Thu, 2004-10-07 at 15:53, Oliver Zeigermann wrote: XMLBeans is super high level, XML Im-/Exporter is super low level. E.g. XML Im-/Exporter (silly name by the way, any better ideas?) could *theortically* be the base of XMLBeans. It is pretty near to SAX. Oliver On Thu, 7 Oct 2004 15:38:10 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, How does this compare to XMLBeans? Yoav Shapira Millennium Research Informatics -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Thursday, October 07, 2004 3:30 PM To: [EMAIL PROTECTED] Subject: XML Im-/Ex-porter into Commons Sandbox 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, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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]
Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/mutable package.html MutableFloat.java MutableByte.java MutableShort.java MutableObject.java MutableLong.java MutableInt.java MutableDouble.java Mutable.java
Tell Eclipse not to include javadoc comments in the format. This is what the majority of the diff contains (I recognize that crap ass javadoc formating anywhere ;-) - Mike On Fri, 2004-10-08 at 17:34, Stephen Colebourne wrote: There was rather a lot of automated reformatting in this commit ;-) Not sure that is something I'd want to encourage in the future, unless the classes existing format had issues. Stephen - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 08, 2004 8:45 PM Subject: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/mutable package.html MutableFloat.java MutableByte.java MutableShort.java MutableObject.java MutableLong.java MutableInt.java MutableDouble.java Mutable.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Please add new build to ibiblio
Hey... On Thu, 2004-09-30 at 19:58, Joe Germuska wrote: At 12:54 PM -0700 9/30/04, Martin Cooper wrote: Hmmm.. Personally, I don't think putting it in a different package is overkill. Adding velocity requires the addition of Velocity.jar to build, but not to run (unless of course, you use the class ;-). I'd prefer to avoid a required build-time dependency on something like Velocity. Better would be to borrow the approach Commons Chain uses, and only build Velocity-specific code if the Velocity jar is present. I'm kind of ambivalent about this approach. I would be concerned that you'd be building jars which are supposed to represent the same artifact but which have different contents based on the build circumstances. I guess also since I'm generally accustomed to using Maven for builds, I don't really see the gain in conditional compilation, because satisfying dependencies is automatic. I agree with this as well. If adding support for velocity adds a build time dependency that people aren't comfortable with, I'd rather find a different home, but I do believe this is the best place for it (as it is probably common practice). I'd rather not see different build flavors. That could seems to be more confusing in the end. I believe the added confusion doesn't justify the gains. Do you suggest the conditional compilation because you don't want people to have to bother with the dependency? Or because you want to make it possible for people to keep the Velocity dependency out of their commons-email jar for some reason? Joe
RE: [email] Please add new build to ibiblio
hi, On Fri, 2004-10-01 at 08:24, Shapira, Yoav wrote: Hi, Hmm. Email is a simple component. If we try to make it more complicated, we'd end up with something like [configuration] should have had a simple, clean, fast, efficient 1.0 release ages ago but has been adding features, refactoring, etc. I couldn't agree more I understand the use case for combining velocity with email, and it's a good one, sending all kinds of fancy and flexible templated email messages. But it it's done, it should be a plugin or contrib. module or whatever technique you want to apply such that the simple use case without velocity is supported without the user having to have velocity on the classpath. I don't know about this. The Velocity Email (which I have yet to submit ;-), is a single class that extends HtmlEmail. I will look at what chains did to only build it if velocity is on the classpath, but I really don't like this idea. I think it results in fractioned builds and will cause more confusion in the long run. Still, adding this class to the email.jar doesn't affect the end user at all. They can still use the email classes and jar without having velocity on the classpath. However, if they choose to use the VelocityEmail class they will obviously, need velocity. Yoav Shapira Millennium Research Informatics -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Friday, October 01, 2004 8:22 AM To: Jakarta Commons Developers List Subject: Re: [email] Please add new build to ibiblio Maybe this has a better home at velocity ? Mvgr, Martin On Fri, 2004-10-01 at 01:58, Joe Germuska wrote: At 12:54 PM -0700 9/30/04, Martin Cooper wrote: Hmmm.. Personally, I don't think putting it in a different package is overkill. Adding velocity requires the addition of Velocity.jar to build, but not to run (unless of course, you use the class ;-). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Please add new build to ibiblio
On Fri, 2004-10-01 at 08:21, Martin van den Bemt wrote:
Maybe this has a better home at velocity ?
Maybe, but this does seem like common practice with the email.
But lets talk about this for a second. (and revisit - the plug-in
adapter idea that I gracefully spoke up against earlier).
For my project, I developed an alternative way to use email in the
Spring Framework. I don't terribly care for the approach taken by the
Spring Framework (discussed in this blog entry -
http://www.jroller.com/page/raible?anchor=sending_velocity_based_e_mail)
In fact, I prefer the commons-email component. I believe it has a
straight forward, OO design for creating and sending mail in Java.
To centralize my SMTP configuration, and utilize Spring IOC, I created a
Factory for generating Email objects.This is very basic, but offers
a clean way to both integrate commons-email into IOC containers, and
provide TemplateEmail apdapters. The factory interface looks something
like:
public interface EmailFactory
{
public TemplateEmail createEmail();
// other convenience methods such as the following
public TemplateEmail createEmail(Collection toList, Collection
ccList);
public void setHost(String host)
public void setPort(int port)
public void setUsername(String username);
public void setPassword(String username);
public void setFromEmail(String fromEmail);
public void setFromName(String fromName);
}
Then in my Spring config file. I have the following.
bean id=beanThatSendsEmail class=some.bean.that.sends.Email
constructor-argref local=emailFactory//constructor-arg
/bean
bean id=emailFactory class=net.mstanley.email.VelocityEmailFactory
constructor-argref local=velocityEngine//constructor-arg
property name=hostlocalhost/property
property name=fromEmail[EMAIL PROTECTED]/property
/bean
bean id=velocityEngine
class=org.springframework.ui.velocity.VelocityEngineFactoryBean
property name=velocityProperties
props
prop key=resource.loaderclass/prop
prop key=class.resource.loader.class
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
/prop
/props
/property
/bean
My client code simply becomes:
TemplateEmail email = emailFactory.createEmail(toList, ccList);
email.setSubject(Some meaningful subject);
email.setPlainTextTemplate(velocity/mail/SampleEmail.vm);
email.send();
I'll send the interface, abstract implementation, and Velocity
implementation of TemplateEmail and email factory.
With this approach VelocityEmailFactory and VelocityEmail can become
template mail adapters. These adapters can be additional modules.
Thoughts?
- Mike
Mvgr,
Martin
On Fri, 2004-10-01 at 01:58, Joe Germuska wrote:
At 12:54 PM -0700 9/30/04, Martin Cooper wrote:
Hmmm.. Personally, I don't think putting it in a different package is
overkill. Adding velocity requires the addition of Velocity.jar to
build, but not to run (unless of course, you use the class ;-).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
sandbox proposal. Events
I've implemented a pattern, somewhat based off the .NET event and delegate pattern, however the pattern is also commonly seen in frameworks (to some extent). At a high level, the pattern is made up of two objects: - Event - DelegateMethod The Event is a container for DelegateMethods. Delegate Methods are registered with the Event (added to the container). The first delegate method added to the container determines the contract for that event. I.e. each method added must have similar signatures (take the same number and types of parameters and return the same type). At any time the event can be fired. When an event is fired it invokes the delegate methods in the order they were added. The event can be configured to fail on first exception, or continue without failing. If the delegate methods return a value, the last value would be returned (this is the behavior of the .NET approach. I'm open to other suggestions). A Delegate Method gets created with an instance of an object and the name of the method (optionally when instantiating the Delegate Method you may specify the signature - or actual Method, in the case that there are multiple methods with the same name but different signatures). This method will be invoked using reflection (delegateMethod.invoke(args)) when the event is fired. At it's core this is the basic idea. Above this, there are (*plans*) to create Asynchronous Delegate Methods and events, providing simple support for multi-threaded events. This will use the same concepts from .NET (callbacks, begin invokes, end invokes, async results, etc). I'm also investigating migrating the pattern to utilize commons-chain. Currently this does not exist as a stand-alone library. However, if there is interest, I will begin to pull it out and contribute it to the commons-sandbox. - Mike
Re: sandbox proposal. Events
Craig, Cool. I'll look into these and begin extracting the library for contribution. Perhaps [delegate] as an alternate name but if [event] is not active, i think that would be more ideal. I'll look at that more closely. Maybe they can be combined. I'd also like to talk more about pipeline, chain, and struts-chain. I had an opportunity over the weekend to look through chain and struts-chain and like what I see. I have some suggestions and ideas, and also would like to pick your brain more about your plans. This may not be the right forum for that however. I'll ping you later to discuss more. Just so you are aware, I started putting together an article Introducing Commons Chain and plan on touching on how it is being used as an alternative approach to the current Request Processor model. I'd love to have an opportunity to speak with you more about your thoughts on future direction. I have noticed you mention tidbits of cocoon's site-map and of course there were the Turbine 3 pipeline efforts as well. Not sure how these relate to the pipeline package you mentioned above. I will jump back on the Struts development list as well ( i have something else unrelated to contribute too ;-) Talk to you soon - Mike On Mon, 2004-10-04 at 12:38, Craig McClanahan wrote: Mike, This pattern does indeed sound interesting. You might also want to take a look at the [pipeline] sandbox package (contributed by Kris Nuttycombe) that I checked in over the weekend. It offers a different tack on handling asynchronous events, and is also investigating how an interaction with [chain] might be beneficial. From a practical perspective, there exists already a sandbox package named [events], originally extracted from [collections]. I haven't been tracking whether this is actually active or not; if so, we'd need to use some different top level name for the package itself. Craig On Mon, 04 Oct 2004 11:19:15 -0400, Mike Stanley [EMAIL PROTECTED] wrote: I've implemented a pattern, somewhat based off the .NET event and delegate pattern, however the pattern is also commonly seen in frameworks (to some extent). At a high level, the pattern is made up of two objects: - Event - DelegateMethod The Event is a container for DelegateMethods. Delegate Methods are registered with the Event (added to the container). The first delegate method added to the container determines the contract for that event. I.e. each method added must have similar signatures (take the same number and types of parameters and return the same type). At any time the event can be fired. When an event is fired it invokes the delegate methods in the order they were added. The event can be configured to fail on first exception, or continue without failing. If the delegate methods return a value, the last value would be returned (this is the behavior of the .NET approach. I'm open to other suggestions). A Delegate Method gets created with an instance of an object and the name of the method (optionally when instantiating the Delegate Method you may specify the signature - or actual Method, in the case that there are multiple methods with the same name but different signatures). This method will be invoked using reflection (delegateMethod.invoke(args)) when the event is fired. At it's core this is the basic idea. Above this, there are (*plans*) to create Asynchronous Delegate Methods and events, providing simple support for multi-threaded events. This will use the same concepts from .NET (callbacks, begin invokes, end invokes, async results, etc). I'm also investigating migrating the pattern to utilize commons-chain. Currently this does not exist as a stand-alone library. However, if there is interest, I will begin to pull it out and contribute it to the commons-sandbox. - Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sandbox proposal. Events
On Mon, 2004-10-04 at 12:42, Jung, Eric wrote: If the delegate methods return a value, the last value would be returned (this is the behavior of the .NET approach. I'm open to other suggestions). How about the option of either (1) receiveing the last value or (2) receiving an array of values, where each array element represents a return value? It currently returns the last value. The problem with returning an array of values is the problem with matching up methods to return values. Since order is retained this can be done by keeping track of when something was added (return index on registration to ensure syncrhonized index etc.) I didn't add this though because (1) at the time I wrote it I didn't need this capability and (2) I questioned if I ever would need this. if other's can think of a situation that calls for (2), I'm thinking the best way to handle it would be to return an EventResult. That allowed you to obtain return values / stack traces, and other invocation info for each method based on the registration index of the method. - Mike -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 12:39 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: sandbox proposal. Events Mike, This pattern does indeed sound interesting. You might also want to take a look at the [pipeline] sandbox package (contributed by Kris Nuttycombe) that I checked in over the weekend. It offers a different tack on handling asynchronous events, and is also investigating how an interaction with [chain] might be beneficial. From a practical perspective, there exists already a sandbox package named [events], originally extracted from [collections]. I haven't been tracking whether this is actually active or not; if so, we'd need to use some different top level name for the package itself. Craig On Mon, 04 Oct 2004 11:19:15 -0400, Mike Stanley [EMAIL PROTECTED] wrote: I've implemented a pattern, somewhat based off the .NET event and delegate pattern, however the pattern is also commonly seen in frameworks (to some extent). At a high level, the pattern is made up of two objects: - Event - DelegateMethod The Event is a container for DelegateMethods. Delegate Methods are registered with the Event (added to the container). The first delegate method added to the container determines the contract for that event. I.e. each method added must have similar signatures (take the same number and types of parameters and return the same type). At any time the event can be fired. When an event is fired it invokes the delegate methods in the order they were added. The event can be configured to fail on first exception, or continue without failing. If the delegate methods return a value, the last value would be returned (this is the behavior of the .NET approach. I'm open to other suggestions). A Delegate Method gets created with an instance of an object and the name of the method (optionally when instantiating the Delegate Method you may specify the signature - or actual Method, in the case that there are multiple methods with the same name but different signatures). This method will be invoked using reflection (delegateMethod.invoke(args)) when the event is fired. At it's core this is the basic idea. Above this, there are (*plans*) to create Asynchronous Delegate Methods and events, providing simple support for multi-threaded events. This will use the same concepts from .NET (callbacks, begin invokes, end invokes, async results, etc). I'm also investigating migrating the pattern to utilize commons-chain. Currently this does not exist as a stand-alone library. However, if there is interest, I will begin to pull it out and contribute it to the commons-sandbox. - Mike - 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: sandbox proposal. Events
Thought about the Hash approach too. That won't suffice. I don't want to limit the number of times a method can be added to an event chain. Take for example, the ability to manipulate an image (not the best example - but it adequately demonstrates what I'm talking about): It would be possible to create event chains to do specific tasks by combining methods in order: - blur(Graphic) - blur(Graphic) - rotate(Graphic) - flip(Graphic) All these can manipulate the parameter. By allowing delegate methods to be added any number of times you can create functional chains. It would be possible to provide both (where the hash code would return the last one executed). - Mike On Mon, 2004-10-04 at 13:23, Jung, Eric wrote: I use an event handler chain (my term for the pattern you describe) in an application right now that requires the handler(s) which failed be identified after the event handler chain completes. [The chain may or may not continue processing if one handler fails]. The best way I thought to do this was to use an array of return values. Order is derived via the means you describe below (element indices coupled with a return value from the register delegate method). However, a more general approach might be to return a hash from the register delegate method and use a Map of return values, instead of an array or list. My two cents, Eric Jung -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 1:05 PM To: Jakarta Commons Developers List Subject: RE: sandbox proposal. Events On Mon, 2004-10-04 at 12:42, Jung, Eric wrote: If the delegate methods return a value, the last value would be returned (this is the behavior of the .NET approach. I'm open to other suggestions). How about the option of either (1) receiveing the last value or (2) receiving an array of values, where each array element represents a return value? It currently returns the last value. The problem with returning an array of values is the problem with matching up methods to return values. Since order is retained this can be done by keeping track of when something was added (return index on registration to ensure syncrhonized index etc.) I didn't add this though because (1) at the time I wrote it I didn't need this capability and (2) I questioned if I ever would need this. if other's can think of a situation that calls for (2), I'm thinking the best way to handle it would be to return an EventResult. That allowed you to obtain return values / stack traces, and other invocation info for each method based on the registration index of the method. - Mike -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 12:39 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: sandbox proposal. Events Mike, This pattern does indeed sound interesting. You might also want to take a look at the [pipeline] sandbox package (contributed by Kris Nuttycombe) that I checked in over the weekend. It offers a different tack on handling asynchronous events, and is also investigating how an interaction with [chain] might be beneficial. From a practical perspective, there exists already a sandbox package named [events], originally extracted from [collections]. I haven't been tracking whether this is actually active or not; if so, we'd need to use some different top level name for the package itself. Craig On Mon, 04 Oct 2004 11:19:15 -0400, Mike Stanley [EMAIL PROTECTED] wrote: I've implemented a pattern, somewhat based off the .NET event and delegate pattern, however the pattern is also commonly seen in frameworks (to some extent). At a high level, the pattern is made up of two objects: - Event - DelegateMethod The Event is a container for DelegateMethods. Delegate Methods are registered with the Event (added to the container). The first delegate method added to the container determines the contract for that event. I.e. each method added must have similar signatures (take the same number and types of parameters and return the same type). At any time the event can be fired. When an event is fired it invokes the delegate methods in the order they were added. The event can be configured to fail on first exception, or continue without failing. If the delegate methods return a value, the last value would be returned (this is the behavior of the .NET approach. I'm open to other suggestions). A Delegate Method gets created with an instance of an object and the name of the method (optionally when instantiating the Delegate Method you may specify the signature - or actual Method, in the case that there are multiple methods with the same name but different signatures). This method will be invoked using reflection
Re: sandbox proposal. Events
On Mon, 2004-10-04 at 13:40, Craig McClanahan wrote:
Perhaps the EventResult instance that encapsulates the result and any
exception could also encapsulate the Method instance that was actually
called? That way, an array or List of EventResults would still be
understandable. And, if you only cared about the last one, it's easy
to find.
I agree. EventResult seems to be the most encompassing.
On the other hand, there will probably be use cases for several
different execution patterns:
- Proceed until a method says we're done (i.e. what [chain] does)
- Proceed unless an exception was thrown, until all methods are called
- Proceed even if an exception is thrown, until all methods are called.
Yup yup. This is currently how I implemented when execution should
stop. However, I did not provide a way for a delegate method to short
circuit (we're done) the invocation process. I believe chain does
this based on the return type of execute. Since the delegate methods
can have any return type (or even void), we would need to do this a
little differently. The best thing I can think of would be to add an
interface StopCondition (that could be set as an optional property for
an event), that has the following simple signature
public StopCondition
{
public boolean stopProcessing(EventResult)
}
so the (very psuedoe) fireEvent() would behave something like
public EventResult fireEvent(args)
eventResult = new EventResult
foreach registeredMethod
{
Object result = nextMethod.invoke(args)
eventResult.add(nextMehod, nextMethodIndex, result)
if (stopCondition.stop(eventResult))
break
}
return eventResult
- Mike
Craig
On Mon, 04 Oct 2004 13:35:39 -0400, Mike Stanley [EMAIL PROTECTED] wrote:
Thought about the Hash approach too. That won't suffice. I don't want
to limit the number of times a method can be added to an event chain.
Take for example, the ability to manipulate an image (not the best
example - but it adequately demonstrates what I'm talking about): It
would be possible to create event chains to do specific tasks by
combining methods in order:
- blur(Graphic)
- blur(Graphic)
- rotate(Graphic)
- flip(Graphic)
All these can manipulate the parameter. By allowing delegate methods to
be added any number of times you can create functional chains.
It would be possible to provide both (where the hash code would return
the last one executed).
- Mike
On Mon, 2004-10-04 at 13:23, Jung, Eric wrote:
I use an event handler chain (my term for the pattern you describe) in an
application right now that requires the handler(s) which failed be
identified after the event handler chain completes. [The chain may or may
not continue processing if one handler fails]. The best way I thought to do
this was to use an array of return values. Order is derived via the means
you describe below (element indices coupled with a return value from the
register delegate method). However, a more general approach might be to
return a hash from the register delegate method and use a Map of return
values, instead of an array or list.
My two cents,
Eric Jung
-Original Message-
From: Mike Stanley [mailto:[EMAIL PROTECTED]
Sent: Monday, October 04, 2004 1:05 PM
To: Jakarta Commons Developers List
Subject: RE: sandbox proposal. Events
On Mon, 2004-10-04 at 12:42, Jung, Eric wrote:
If the delegate methods return a value,
the last value would be returned (this is the
behavior of the .NET approach. I'm open to other suggestions).
How about the option of either (1) receiveing the last value or (2)
receiving an array of values, where each array element represents a return
value?
It currently returns the last value. The problem with returning an
array of values is the problem with matching up methods to return
values. Since order is retained this can be done by keeping track of
when something was added (return index on registration to ensure
syncrhonized index etc.) I didn't add this though because (1) at the
time I wrote it I didn't need this capability and (2) I questioned if I
ever would need this.
if other's can think of a situation that calls for (2), I'm thinking the
best way to handle it would be to return an EventResult. That allowed
you to obtain return values / stack traces, and other invocation info
for each method based on the registration index of the method.
- Mike
-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: Monday, October 04, 2004 12:39 PM
To: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: Re: sandbox proposal. Events
Mike,
This pattern does indeed sound interesting. You might also want to
take a look at the [pipeline] sandbox package (contributed
RE: sandbox proposal. Events
On Mon, 2004-10-04 at 13:40, Jung, Eric wrote: I see. Good point. So how about the original array (or List) idea instead? Do you see any problems with that? EventResult will probably be the best. It would have an List of single results (delegate method, when it was executed, return value, exception if thrown, etc) but can implement the basic List interface so it can be iterated or accessed by index. etc - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 1:36 PM To: Jakarta Commons Developers List Subject: RE: sandbox proposal. Events Thought about the Hash approach too. That won't suffice. I don't want to limit the number of times a method can be added to an event chain. Take for example, the ability to manipulate an image (not the best example - but it adequately demonstrates what I'm talking about): It would be possible to create event chains to do specific tasks by combining methods in order: - blur(Graphic) - blur(Graphic) - rotate(Graphic) - flip(Graphic) All these can manipulate the parameter. By allowing delegate methods to be added any number of times you can create functional chains. It would be possible to provide both (where the hash code would return the last one executed). - Mike On Mon, 2004-10-04 at 13:23, Jung, Eric wrote: I use an event handler chain (my term for the pattern you describe) in an application right now that requires the handler(s) which failed be identified after the event handler chain completes. [The chain may or may not continue processing if one handler fails]. The best way I thought to do this was to use an array of return values. Order is derived via the means you describe below (element indices coupled with a return value from the register delegate method). However, a more general approach might be to return a hash from the register delegate method and use a Map of return values, instead of an array or list. My two cents, Eric Jung -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 1:05 PM To: Jakarta Commons Developers List Subject: RE: sandbox proposal. Events On Mon, 2004-10-04 at 12:42, Jung, Eric wrote: If the delegate methods return a value, the last value would be returned (this is the behavior of the .NET approach. I'm open to other suggestions). How about the option of either (1) receiveing the last value or (2) receiving an array of values, where each array element represents a return value? It currently returns the last value. The problem with returning an array of values is the problem with matching up methods to return values. Since order is retained this can be done by keeping track of when something was added (return index on registration to ensure syncrhonized index etc.) I didn't add this though because (1) at the time I wrote it I didn't need this capability and (2) I questioned if I ever would need this. if other's can think of a situation that calls for (2), I'm thinking the best way to handle it would be to return an EventResult. That allowed you to obtain return values / stack traces, and other invocation info for each method based on the registration index of the method. - Mike -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 12:39 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: sandbox proposal. Events Mike, This pattern does indeed sound interesting. You might also want to take a look at the [pipeline] sandbox package (contributed by Kris Nuttycombe) that I checked in over the weekend. It offers a different tack on handling asynchronous events, and is also investigating how an interaction with [chain] might be beneficial. From a practical perspective, there exists already a sandbox package named [events], originally extracted from [collections]. I haven't been tracking whether this is actually active or not; if so, we'd need to use some different top level name for the package itself. Craig On Mon, 04 Oct 2004 11:19:15 -0400, Mike Stanley [EMAIL PROTECTED] wrote: I've implemented a pattern, somewhat based off the .NET event and delegate pattern, however the pattern is also commonly seen in frameworks (to some extent). At a high level, the pattern is made up of two objects: - Event - DelegateMethod The Event is a container for DelegateMethods. Delegate Methods are registered with the Event (added to the container). The first delegate method added to the container determines the contract for that event. I.e. each method added must have similar signatures (take the same number and types of parameters and return
RE: sandbox proposal. Events
On Mon, 2004-10-04 at 15:14, Jung, Eric wrote: Not sure what EventResult is (I was referring to a generic return object, not mentioning any specific class or interface for a return type), As am I. EventResults is simply a container for generic return objects. More specific than a List or Array, since there are convenience methods for retrieving more details (such as what exact DelegateMethod returned this object, and was it the first,second... last method executed, did it throw an exception, what was the stack trace, etc...) Same as the list/array idea, just more details. but while we're on the subject, have you considered java.util.EventObject as the elements in the list/array? This is what I use in my event chain implementation. EventObject is passed to the invoked object. This is a different style to handling events. I explain more below... My concept of EventResults is more a container (like a list) for collecting Delegate Method invocation results. Where you are advocating a List of generic objects, I'm saying Great, but I want a more specialized container that implements List and adds methods for managing Delegate Method invocation results. You might also consider using java.util.EventListener, java.util.EventListenerProxy, and java.util.TooManyListenersException as appropriate. All of these were introduced in JSDK 1.3. Events have been around a while in JDK (since 1.1). My implementation takes a different approach to events than the JDK. Where the JDK uses Class signatures, interfaces, and event objects, I utilize reflection and method invocation. Allowing more arbitrary invocation of methods. Using this delegateMethod/event registry approach, any existing class/method can be invoked when an event is fired/raised. Without requiring classes to implement an interface or signature. Look at .NET's events and delegates. They do something similar to this. Let me package everything up and then contribute it. Then it may be easier for me to demonstrate what I'm trying to accomplish. - Mike p.s. I'm not advocating that this is a better way of handling events, just a different approach. (I do believe it is more convenient and flexible to utilize. especially when adding events and event handlers to existing components.) I also think this fits nicely with frameworks, and other patterns such as the chain of responsibility. -Eric Jung -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 3:09 PM To: Jakarta Commons Developers List Subject: RE: sandbox proposal. Events On Mon, 2004-10-04 at 13:40, Jung, Eric wrote: I see. Good point. So how about the original array (or List) idea instead? Do you see any problems with that? EventResult will probably be the best. It would have an List of single results (delegate method, when it was executed, return value, exception if thrown, etc) but can implement the basic List interface so it can be iterated or accessed by index. etc - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 1:36 PM To: Jakarta Commons Developers List Subject: RE: sandbox proposal. Events Thought about the Hash approach too. That won't suffice. I don't want to limit the number of times a method can be added to an event chain. Take for example, the ability to manipulate an image (not the best example - but it adequately demonstrates what I'm talking about): It would be possible to create event chains to do specific tasks by combining methods in order: - blur(Graphic) - blur(Graphic) - rotate(Graphic) - flip(Graphic) All these can manipulate the parameter. By allowing delegate methods to be added any number of times you can create functional chains. It would be possible to provide both (where the hash code would return the last one executed). - Mike On Mon, 2004-10-04 at 13:23, Jung, Eric wrote: I use an event handler chain (my term for the pattern you describe) in an application right now that requires the handler(s) which failed be identified after the event handler chain completes. [The chain may or may not continue processing if one handler fails]. The best way I thought to do this was to use an array of return values. Order is derived via the means you describe below (element indices coupled with a return value from the register delegate method). However, a more general approach might be to return a hash from the register delegate method and use a Map of return values, instead of an array or list. My two cents, Eric Jung -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 1:05 PM To: Jakarta Commons Developers List Subject: RE: sandbox proposal. Events On Mon, 2004-10-04 at 12:42, Jung, Eric wrote
Re: sandbox proposal. Events
On Mon, 2004-10-04 at 15:47, Mario Ivankovits wrote: Mike Stanley wrote: Thought about the Hash approach too. That won't suffice. Havent looked at [event] now, but the first thing about how to handle results which comes into my mind was a ResultHandler - what if you just provide a way to set a ResultHandler - a interface with a method like ResultHandler.eventProcessed(methodname, returnCode) Similar to what I was thinking with the StopCondition (ProcessHandler or something may be a better name). maybe eventProcessed could have a return value e.g. a boolean where you could return false if you would like to stop any further propagation - or throw an exception which might rollup too That way one could collect the result in an List, Map or whatever I was thinking the best thing to do would be to collect the results in a specialized container. But the same idea. - Mike --- Mario
RE: sandbox proposal. Events
Hi. On Mon, 2004-10-04 at 18:16, Michael Heuer wrote: On Mon, 4 Oct 2004, Mike Stanley wrote: On Mon, 2004-10-04 at 15:14, Jung, Eric wrote: You might also consider using java.util.EventListener, java.util.EventListenerProxy, and java.util.TooManyListenersException as appropriate. All of these were introduced in JSDK 1.3. Events have been around a while in JDK (since 1.1). My implementation takes a different approach to events than the JDK. Where the JDK uses Class signatures, interfaces, and event objects, I utilize reflection and method invocation. Allowing more arbitrary invocation of methods. Using this delegateMethod/event registry approach, any existing class/method can be invoked when an event is fired/raised. Without requiring classes to implement an interface or signature. Look at .NET's events and delegates. They do something similar to this. Let me package everything up and then contribute it. Then it may be easier for me to demonstrate what I'm trying to accomplish. - Mike p.s. I'm not advocating that this is a better way of handling events, just a different approach. (I do believe it is more convenient and flexible to utilize. especially when adding events and event handlers to existing components.) I also think this fits nicely with frameworks, and other patterns such as the chain of responsibility. For what it's worth, my approach has been to adapt the event pattern in Swing for other purposes. I've documented that pattern and provided velocity source code generation templates in The event pattern used in Swing is the Java Event pattern discussed above. It involves creating a specific Event Listener interface, event listener concrete classes (typically this is done inline), and an Event Object (or Event Source) which is sent from the class that fires the event to all the event listeners that have been registered. Like I said, there is nothing wrong with that approach. It is core Java. The code I will be contributing provides an alternative that utilizes reflection, dynamic invocation, and method invocation. This really is more of a MultiCastDelegate, but if you are familiar with .NET, you see that they use MultiCastDelegates as the basis of their event model. The dynamic delegate can be used in eventing, but really its about invoking an ordered list of methods on various target objects. - Mike http://shore.net/~heuermh/event-codegen-1.0.tar.gz michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] Please add new build to ibiblio
I don't think there is a maintainer for this (ultra-tiny but useful), sandbox component. Can someone take the initiative and push the latest build to the repository at ibiblio? Maybe even coordinate a 0.2 release :-) In addition, I have a basic class VelocityHtmlEmail that extends HtmlEmail and adds support for setting the Html Msg with a template, and Plain Text Msg with templates. This is very basic, but I find it very useful, especially when working with other developers that aren't familiar with Velocity. I there is interest I will contribute this class to the project. - Mike
Re: [email] Please add new build to ibiblio
On Thu, 2004-09-30 at 11:30, Joe Germuska wrote: At 10:32 AM -0400 10/1/04, Mike Stanley wrote: I don't think there is a maintainer for this (ultra-tiny but useful), sandbox component. Can someone take the initiative and push the latest build to the repository at ibiblio? Maybe even coordinate a 0.2 release :-) I'm not the maintainer, but I recently got sandbox karma and I'm interested in commons-email. cool. I guess I wouldn't think it appropriate to put on ibiblio as it is now. Would you be satisfied with a SNAPSHOT build on the Apache nightly-build/beta repository? http://cvs.apache.org/repository/ Well, there is currently two different (and old) Snapshot builds on ibiblio and a very old 0.1 release. I'd prefer to see an updated snapshot build (with the timestamp format preferably) or something get put up there. After all the code does work right now, and has changed significantly since the last snapshot build (the build doesn't even have the authentication support). I would think that moving this to a 0.2 release would be acceptable. After all 0.2 is still indicates that the code is very pre-pre-alpha. Maybe I'm making too much of the sandbox status and the like, but my sense has been that the ibiblio mirror is intended for more official, finished stuff. In addition, I have a basic class VelocityHtmlEmail that extends HtmlEmail and adds support for setting the Html Msg with a template, and Plain Text Msg with templates. This is very basic, but I find it very useful, especially when working with other developers that aren't familiar with Velocity. I there is interest I will contribute this class to the project. That sounds interesting. If the class takes the responsibility for interacting with Velocity, I kind of feel that it should be in some alternate package, to keep the core dependencies lighter -- but for one class, that feels a little bit much too. Hmmm.. Personally, I don't think putting it in a different package is overkill. Adding velocity requires the addition of Velocity.jar to build, but not to run (unless of course, you use the class ;-). Once upon a time, I wrote a template abstraction API which could be brought to bear on this problem. It was quite simple, but I was able to use it to set up templated email that could use Velocity or Jelly as template languages. The Jelly template thing was just a proof of concept. Alternatively, we can borrow the template abstraction used in Groovy for this sort of thing. For now, why don't you file a Bugzilla ticket and attach the source for the class. That will put it somewhere where it won't get lost while we see if anyone else out there has strong feelings about some of these questions... Will do. Joe
RE: [email] Please add new build to ibiblio
On Thu, 2004-09-30 at 12:16, Shapira, Yoav wrote: Hi, I guess I wouldn't think it appropriate to put on ibiblio as it is now. Would you be satisfied with a SNAPSHOT build on the Apache nightly-build/beta repository? http://cvs.apache.org/repository/ Maybe I'm making too much of the sandbox status and the like, but my sense has been that the ibiblio mirror is intended for more official, finished stuff. I don't think you're making too much of it: I agree with the above. Yeah, but there is already junk up there. Why not put something that can be used up there? Maybe don't include the recently committed changes (relatively recent that is. one change 4 weeks ago, the last changes since then were more than 8 months ago). Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Please add new build to ibiblio
Yeah, but there is already junk up there. Why not put something that can be used up there? Because two wrongs don't make a right IMHO ;) I see your point. My gripe with everything I think has more to do with the auto-build of the sites. This isn't really the best example, but docs/api/etc should match the releases - and not the head - or at the very least, offer both. In all honesty, I wasn't even familiar with the http://cvs.apache.org/repository until today, otherwise I wouldn't have bothered anyone with this. I do think the email stuff is useful (although a very small library). Glad to see that there is an echo response :-) - Mike If anything, we should either remove what's there (which is against iBiblio policy I think, so can't be done) or add a notice that says the stuff on there is junk and users should turn to XXX (whatever URL we want) to track development, and also that when a stable release is available it will be put up in iBiblio. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: [email] Please add new build to ibiblio
I hadn't realized there was one -- do you have a pointer? However, if using that requires a dependency on Groovy, then I'd want to wait until Groovy hits 1.0. My sense is that it's still prone to a lot of change. I can't really attest to it. But I did notice it a little while ago. I don't think there's a lot there, just an approach (but that template engine abstraction is pretty straight forward). I don't think we should depend on groovy, I was simply suggesting approaching it a similar way. Mike, do you know that your e-mail is timestamped one day ahead? Is that your way of staying on the cutting edge? ;^) HAHA! That's awesome. I did not know this. In fact, I was complaining last night when I thought my clock was 5 minutes slow. Turns out it was 23 hours and 55 minutes fast :-) Time to investigate where my NTP daemon went... Thanks for the heads up. - Mike Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [betwixt] Betwixt troubles...
Ok cool. Thanks for looking into this for me. (don't worry about it being late, not a big deal. I just had to use Castor for the unmarshalling and Betwixt for the Marshalling - not really the most elegant but it did the trick temporarily. It's actually funny, because I tried just switching to Castor completely, but was unable to do the complex marshalling with it, however it did manage to handle the unmarshalling well. ;-) 1) Somehow I got it in my head that the name attribute was optional if the property attribute was present, and that the property this would cause the name of the element/attribute to be the default value (based off the property). 2) Ok. So what is the best thing to do. Should I grab a CVS snapshot? Is this pretty stable (comparable to the 2/2003 snapshot, and/or alpha 1 release - btw I view those as stable enough to use in prod)? Thanks, Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 9:09 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Hi Mike, A lot later than anticipated, but finally got some time for betwixt last night :) The reason why it doesn't work for you has 2 reasons : 1) Your .betwixt is incorrect (explaining the exceptions) (see CVS for a good one). You HAVE to have the name property in an element and attribute element. 2) There was indeed a bug in betwixt that prevented elements without any updater (in your case a setBody() , to set the attribute values in the bean (in your case setName and setStatus). Betwixt now checks to see if there are any attributes present and tries to set values in that scenario. Hope this helps and not too late ;) Mvgr, Martin On Wed, 2003-11-12 at 15:37, Mike Stanley wrote: ok. and yes you have permission to use it in any way that matters. I just looked it over though, and I accidentally included copyright disclaimers at the top of some of the files. I will resend them without the disclaimers. It was written from scratch, no real world code used, completely fictitious -- my class templates include the disclaimer and I just forgot to remove it in some places. I can either resend it with this stuff removed - or - give you permission to remove it and add the APL to it. Whatever satisfies the legal requirement. Your call. Thanks, and like I said before I'd be more than happy to look into / patch the issue(s). Just waiting for confirmation. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 9:21 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... I'll try to find some time to confirm it tonight, but since a lot of family matters atm, that time can be consumed by that.. Do we have permission (when needed) to add your scenario to the betwixt CVS tree ? (and therefor give it an apache license?) Mvgr, Martin On Wed, 2003-11-12 at 15:12, Mike Stanley wrote: Please confirm this is a bug, or please offer some advice on what I'm doing wrong. If this isn't sufficient to confirm the bug please let me know, and I will modify the example. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 2:07 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... here is a zipped up eclipse project (minus the jar dependencies). There is a unit test that demonstrates the bug that I'm talking about. The unit test has to test methods, testGetAsXml which passes, and testParseMsg which fails. Aside from the betwixt dependencies, this project is also dependent on log4j, and commons-lang. Hope this provides a decent enough demo of the bugs. Note: I've tried this with the alpha release of betwixt, as well as the snapshot from 2/11/2003. When using the snapshot, the testGetAsXml fails with a null pointer exception. The alpha release shows the marshalling/unmarshalling behavior noted in this thread. I also tried variations on the parser configurations. Thanks for the help. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 09, 2003 12:14 PM To: Jakarta Commons Developers List Subject: RE: Betwixt troubles... Can you supply us with a tescase that shows us the bahaviour (esp that you believe it is a bug), since there is too little info in the mail to test this (we needs the beans / bean. One thing I know is that eg Bean.betwixt files only supplies beaninfo for Bean.java and not for any classes embedded in Bean.java. Mvgr, Martin
RE: [betwixt] Betwixt troubles...
One other question: You said something about Bean.betwixt files only supplies beaninfo for Bean.java and not classes embedded in Bean.java. If I have BeanA.java and BeanA.betwixt. I also have BeanB.java and BeanB.betwixt. My BeanA class has a property of type BeanB. Will Betwixt be able to marshall/unmarshall this correctly? i.e. beanA beanB propertyXvalue/propertyX /beanB /beanA --- but again, I will need the betwixt files to map beans to the XML (which I need to conform to and is out of my control). Thanks for the help. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 10:41 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Ok cool. Thanks for looking into this for me. (don't worry about it being late, not a big deal. I just had to use Castor for the unmarshalling and Betwixt for the Marshalling - not really the most elegant but it did the trick temporarily. It's actually funny, because I tried just switching to Castor completely, but was unable to do the complex marshalling with it, however it did manage to handle the unmarshalling well. ;-) 1) Somehow I got it in my head that the name attribute was optional if the property attribute was present, and that the property this would cause the name of the element/attribute to be the default value (based off the property). 2) Ok. So what is the best thing to do. Should I grab a CVS snapshot? Is this pretty stable (comparable to the 2/2003 snapshot, and/or alpha 1 release - btw I view those as stable enough to use in prod)? Thanks, Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 9:09 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Hi Mike, A lot later than anticipated, but finally got some time for betwixt last night :) The reason why it doesn't work for you has 2 reasons : 1) Your .betwixt is incorrect (explaining the exceptions) (see CVS for a good one). You HAVE to have the name property in an element and attribute element. 2) There was indeed a bug in betwixt that prevented elements without any updater (in your case a setBody() , to set the attribute values in the bean (in your case setName and setStatus). Betwixt now checks to see if there are any attributes present and tries to set values in that scenario. Hope this helps and not too late ;) Mvgr, Martin On Wed, 2003-11-12 at 15:37, Mike Stanley wrote: ok. and yes you have permission to use it in any way that matters. I just looked it over though, and I accidentally included copyright disclaimers at the top of some of the files. I will resend them without the disclaimers. It was written from scratch, no real world code used, completely fictitious -- my class templates include the disclaimer and I just forgot to remove it in some places. I can either resend it with this stuff removed - or - give you permission to remove it and add the APL to it. Whatever satisfies the legal requirement. Your call. Thanks, and like I said before I'd be more than happy to look into / patch the issue(s). Just waiting for confirmation. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 9:21 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... I'll try to find some time to confirm it tonight, but since a lot of family matters atm, that time can be consumed by that.. Do we have permission (when needed) to add your scenario to the betwixt CVS tree ? (and therefor give it an apache license?) Mvgr, Martin On Wed, 2003-11-12 at 15:12, Mike Stanley wrote: Please confirm this is a bug, or please offer some advice on what I'm doing wrong. If this isn't sufficient to confirm the bug please let me know, and I will modify the example. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 2:07 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... here is a zipped up eclipse project (minus the jar dependencies). There is a unit test that demonstrates the bug that I'm talking about. The unit test has to test methods, testGetAsXml which passes, and testParseMsg which fails. Aside from the betwixt dependencies, this project is also dependent on log4j, and commons-lang. Hope this provides a decent enough demo of the bugs. Note: I've tried this with the alpha release of betwixt, as well as the snapshot from 2/11/2003. When using the snapshot, the testGetAsXml
RE: [betwixt] Betwixt troubles...
Ah, Cool. Thanks. -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 11:07 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... That should be possible :) You cannot however from BeanA.betwixt also format the content of BeanB.java.. That was one of the mistakes I made when first started using betwixt.. Mvgr, Martin On Mon, 2003-11-24 at 16:57, Mike Stanley wrote: One other question: You said something about Bean.betwixt files only supplies beaninfo for Bean.java and not classes embedded in Bean.java. If I have BeanA.java and BeanA.betwixt. I also have BeanB.java and BeanB.betwixt. My BeanA class has a property of type BeanB. Will Betwixt be able to marshall/unmarshall this correctly? i.e. beanA beanB propertyXvalue/propertyX /beanB /beanA --- but again, I will need the betwixt files to map beans to the XML (which I need to conform to and is out of my control). Thanks for the help. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 10:41 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Ok cool. Thanks for looking into this for me. (don't worry about it being late, not a big deal. I just had to use Castor for the unmarshalling and Betwixt for the Marshalling - not really the most elegant but it did the trick temporarily. It's actually funny, because I tried just switching to Castor completely, but was unable to do the complex marshalling with it, however it did manage to handle the unmarshalling well. ;-) 1) Somehow I got it in my head that the name attribute was optional if the property attribute was present, and that the property this would cause the name of the element/attribute to be the default value (based off the property). 2) Ok. So what is the best thing to do. Should I grab a CVS snapshot? Is this pretty stable (comparable to the 2/2003 snapshot, and/or alpha 1 release - btw I view those as stable enough to use in prod)? Thanks, Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 9:09 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Hi Mike, A lot later than anticipated, but finally got some time for betwixt last night :) The reason why it doesn't work for you has 2 reasons : 1) Your .betwixt is incorrect (explaining the exceptions) (see CVS for a good one). You HAVE to have the name property in an element and attribute element. 2) There was indeed a bug in betwixt that prevented elements without any updater (in your case a setBody() , to set the attribute values in the bean (in your case setName and setStatus). Betwixt now checks to see if there are any attributes present and tries to set values in that scenario. Hope this helps and not too late ;) Mvgr, Martin On Wed, 2003-11-12 at 15:37, Mike Stanley wrote: ok. and yes you have permission to use it in any way that matters. I just looked it over though, and I accidentally included copyright disclaimers at the top of some of the files. I will resend them without the disclaimers. It was written from scratch, no real world code used, completely fictitious -- my class templates include the disclaimer and I just forgot to remove it in some places. I can either resend it with this stuff removed - or - give you permission to remove it and add the APL to it. Whatever satisfies the legal requirement. Your call. Thanks, and like I said before I'd be more than happy to look into / patch the issue(s). Just waiting for confirmation. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 9:21 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... I'll try to find some time to confirm it tonight, but since a lot of family matters atm, that time can be consumed by that.. Do we have permission (when needed) to add your scenario to the betwixt CVS tree ? (and therefor give it an apache license?) Mvgr, Martin On Wed, 2003-11-12 at 15:12, Mike Stanley wrote: Please confirm this is a bug, or please offer some advice on what I'm doing wrong. If this isn't sufficient to confirm the bug please let me know, and I will modify the example. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 10
RE: [betwixt] Betwixt troubles...
I'm sorry - I'm turning into a pain in the ass --- how about properties of properties i.e. attribute name=name property=beanB.name/ -- would this be handled beanA.getBeanB().getName() appropriately? Figured, I'd ask while I have your ear ;-) -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 11:07 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... That should be possible :) You cannot however from BeanA.betwixt also format the content of BeanB.java.. That was one of the mistakes I made when first started using betwixt.. Mvgr, Martin On Mon, 2003-11-24 at 16:57, Mike Stanley wrote: One other question: You said something about Bean.betwixt files only supplies beaninfo for Bean.java and not classes embedded in Bean.java. If I have BeanA.java and BeanA.betwixt. I also have BeanB.java and BeanB.betwixt. My BeanA class has a property of type BeanB. Will Betwixt be able to marshall/unmarshall this correctly? i.e. beanA beanB propertyXvalue/propertyX /beanB /beanA --- but again, I will need the betwixt files to map beans to the XML (which I need to conform to and is out of my control). Thanks for the help. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 10:41 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Ok cool. Thanks for looking into this for me. (don't worry about it being late, not a big deal. I just had to use Castor for the unmarshalling and Betwixt for the Marshalling - not really the most elegant but it did the trick temporarily. It's actually funny, because I tried just switching to Castor completely, but was unable to do the complex marshalling with it, however it did manage to handle the unmarshalling well. ;-) 1) Somehow I got it in my head that the name attribute was optional if the property attribute was present, and that the property this would cause the name of the element/attribute to be the default value (based off the property). 2) Ok. So what is the best thing to do. Should I grab a CVS snapshot? Is this pretty stable (comparable to the 2/2003 snapshot, and/or alpha 1 release - btw I view those as stable enough to use in prod)? Thanks, Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 9:09 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Hi Mike, A lot later than anticipated, but finally got some time for betwixt last night :) The reason why it doesn't work for you has 2 reasons : 1) Your .betwixt is incorrect (explaining the exceptions) (see CVS for a good one). You HAVE to have the name property in an element and attribute element. 2) There was indeed a bug in betwixt that prevented elements without any updater (in your case a setBody() , to set the attribute values in the bean (in your case setName and setStatus). Betwixt now checks to see if there are any attributes present and tries to set values in that scenario. Hope this helps and not too late ;) Mvgr, Martin On Wed, 2003-11-12 at 15:37, Mike Stanley wrote: ok. and yes you have permission to use it in any way that matters. I just looked it over though, and I accidentally included copyright disclaimers at the top of some of the files. I will resend them without the disclaimers. It was written from scratch, no real world code used, completely fictitious -- my class templates include the disclaimer and I just forgot to remove it in some places. I can either resend it with this stuff removed - or - give you permission to remove it and add the APL to it. Whatever satisfies the legal requirement. Your call. Thanks, and like I said before I'd be more than happy to look into / patch the issue(s). Just waiting for confirmation. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 9:21 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... I'll try to find some time to confirm it tonight, but since a lot of family matters atm, that time can be consumed by that.. Do we have permission (when needed) to add your scenario to the betwixt CVS tree ? (and therefor give it an apache license?) Mvgr, Martin On Wed, 2003-11-12 at 15:12, Mike Stanley wrote: Please confirm this is a bug, or please offer some advice on what I'm doing wrong. If this isn't sufficient
RE: [General] New sandbox component idea
Rules based load balancer? Seems to me like this could need a load balancer of its own. Have you stress tested it? I'm not saying it can't be useful as a smart (policy based) redirector, but as a thin large scale load balancer the Servlet lifecycle may be a little heavier than necessary. Can you give an example in which this serves as a better load balancer than other alternatives? - Mike -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 1:33 PM To: Jakarta Commons Developers List Subject: RE: [General] New sandbox component idea Howdy, Yup, and I use them. This is a bit different, in two ways: - pure servlet container, since there's nothing tomcat-specific How are you handling session affinity and/or migration? A simple way: the same rule will always redirect to the same server. So if the load balancer's administrator changes the rules while a user is using the system, and the app depends on session stuff, the user is screwed. That aspect would seem to be something to discuss with Filip. I think that it would be useful to add that concept to the Tomcat work. Maybe: discussion can't hurt, which I why I brought this up ;) I've taken care to make my stuff portable to other servlet containers, not just tomcat, so I don't want to tie it tightly into tomcat. BTW, to your list of other web components for perhaps a WebApp Commons, I would maybe add some things from the log4j-sandbox that I've been working on. There are servlets there that I hope will some day grow into a log4j administration webapp. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: [betwixt] Betwixt troubles...
Please confirm this is a bug, or please offer some advice on what I'm doing wrong. If this isn't sufficient to confirm the bug please let me know, and I will modify the example. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 2:07 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... here is a zipped up eclipse project (minus the jar dependencies). There is a unit test that demonstrates the bug that I'm talking about. The unit test has to test methods, testGetAsXml which passes, and testParseMsg which fails. Aside from the betwixt dependencies, this project is also dependent on log4j, and commons-lang. Hope this provides a decent enough demo of the bugs. Note: I've tried this with the alpha release of betwixt, as well as the snapshot from 2/11/2003. When using the snapshot, the testGetAsXml fails with a null pointer exception. The alpha release shows the marshalling/unmarshalling behavior noted in this thread. I also tried variations on the parser configurations. Thanks for the help. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 09, 2003 12:14 PM To: Jakarta Commons Developers List Subject: RE: Betwixt troubles... Can you supply us with a tescase that shows us the bahaviour (esp that you believe it is a bug), since there is too little info in the mail to test this (we needs the beans / bean. One thing I know is that eg Bean.betwixt files only supplies beaninfo for Bean.java and not for any classes embedded in Bean.java. Mvgr, Martin On Fri, 2003-11-07 at 19:51, Mike Stanley wrote: Please note: I sent this to the developers list and not the users list, because I believe it to be a bug, and if confirmed - I may patch it. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 1:26 PM To: Jakarta Commons Dev Subject: Betwixt troubles... Hey everyone, I'm running into an issue with some Betwixt code. I'm trying to Write/Read a bean associated with .betwixt file. I can't seem to get attributes to be set when reading in the xml. writing works fine. I've tried several ways (including defaulting to primitiveTypes and specificing an updater method). Here is the content of the file: ?xml version=1.0 encoding=UTF-8? info primitiveTypes=attribute element name=rcss attribute property=type/ element name=requests element name=isValid element name=agent-id attribute name=value property=agentId/ /element !-- element name=agent-id property=agentId updater=setAgentId/ -- /element /element /element /info Results form a write: ?xml version='1.0' ? rcss type=request src=167.154.203.22 requestor=install_app requests isValid cert=Z0123456789 agent-id value=01/ /isValid /requests /rcss --- Results from read: ?xml version='1.0' ? rcss type=request src=167.154.203.22 requestor=install_app requests isValid agent-id/ /isValid /requests /rcss --- What is going wrong? What can I do to fix this problem? modifying the format of the XML is not an option. Also note - using the Commented out element in the betwixt file instead of specifically specifying the attribute, results in agent-id01/agent-id which isn't correct either. Thanks for your help. - Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martin van den Bemt [EMAIL PROTECTED] mvdb.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]
RE: [betwixt] Betwixt troubles...
ok. and yes you have permission to use it in any way that matters. I just looked it over though, and I accidentally included copyright disclaimers at the top of some of the files. I will resend them without the disclaimers. It was written from scratch, no real world code used, completely fictitious -- my class templates include the disclaimer and I just forgot to remove it in some places. I can either resend it with this stuff removed - or - give you permission to remove it and add the APL to it. Whatever satisfies the legal requirement. Your call. Thanks, and like I said before I'd be more than happy to look into / patch the issue(s). Just waiting for confirmation. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 9:21 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... I'll try to find some time to confirm it tonight, but since a lot of family matters atm, that time can be consumed by that.. Do we have permission (when needed) to add your scenario to the betwixt CVS tree ? (and therefor give it an apache license?) Mvgr, Martin On Wed, 2003-11-12 at 15:12, Mike Stanley wrote: Please confirm this is a bug, or please offer some advice on what I'm doing wrong. If this isn't sufficient to confirm the bug please let me know, and I will modify the example. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 2:07 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... here is a zipped up eclipse project (minus the jar dependencies). There is a unit test that demonstrates the bug that I'm talking about. The unit test has to test methods, testGetAsXml which passes, and testParseMsg which fails. Aside from the betwixt dependencies, this project is also dependent on log4j, and commons-lang. Hope this provides a decent enough demo of the bugs. Note: I've tried this with the alpha release of betwixt, as well as the snapshot from 2/11/2003. When using the snapshot, the testGetAsXml fails with a null pointer exception. The alpha release shows the marshalling/unmarshalling behavior noted in this thread. I also tried variations on the parser configurations. Thanks for the help. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 09, 2003 12:14 PM To: Jakarta Commons Developers List Subject: RE: Betwixt troubles... Can you supply us with a tescase that shows us the bahaviour (esp that you believe it is a bug), since there is too little info in the mail to test this (we needs the beans / bean. One thing I know is that eg Bean.betwixt files only supplies beaninfo for Bean.java and not for any classes embedded in Bean.java. Mvgr, Martin On Fri, 2003-11-07 at 19:51, Mike Stanley wrote: Please note: I sent this to the developers list and not the users list, because I believe it to be a bug, and if confirmed - I may patch it. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 1:26 PM To: Jakarta Commons Dev Subject: Betwixt troubles... Hey everyone, I'm running into an issue with some Betwixt code. I'm trying to Write/Read a bean associated with .betwixt file. I can't seem to get attributes to be set when reading in the xml. writing works fine. I've tried several ways (including defaulting to primitiveTypes and specificing an updater method). Here is the content of the file: ?xml version=1.0 encoding=UTF-8? info primitiveTypes=attribute element name=rcss attribute property=type/ element name=requests element name=isValid element name=agent-id attribute name=value property=agentId/ /element !-- element name=agent-id property=agentId updater=setAgentId/ -- /element /element /element /info Results form a write: ?xml version='1.0' ? rcss type=request src=167.154.203.22 requestor=install_app requests isValid cert=Z0123456789 agent-id value=01/ /isValid /requests /rcss --- Results from read: ?xml version='1.0' ? rcss type=request src=167.154.203.22 requestor=install_app requests isValid agent-id/ /isValid /requests /rcss --- What is going
RE: [betwixt] Betwixt troubles...
here is a zipped up eclipse project (minus the jar dependencies). There is a unit test that demonstrates the bug that I'm talking about. The unit test has to test methods, testGetAsXml which passes, and testParseMsg which fails. Aside from the betwixt dependencies, this project is also dependent on log4j, and commons-lang. Hope this provides a decent enough demo of the bugs. Note: I've tried this with the alpha release of betwixt, as well as the snapshot from 2/11/2003. When using the snapshot, the testGetAsXml fails with a null pointer exception. The alpha release shows the marshalling/unmarshalling behavior noted in this thread. I also tried variations on the parser configurations. Thanks for the help. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 09, 2003 12:14 PM To: Jakarta Commons Developers List Subject: RE: Betwixt troubles... Can you supply us with a tescase that shows us the bahaviour (esp that you believe it is a bug), since there is too little info in the mail to test this (we needs the beans / bean. One thing I know is that eg Bean.betwixt files only supplies beaninfo for Bean.java and not for any classes embedded in Bean.java. Mvgr, Martin On Fri, 2003-11-07 at 19:51, Mike Stanley wrote: Please note: I sent this to the developers list and not the users list, because I believe it to be a bug, and if confirmed - I may patch it. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 1:26 PM To: Jakarta Commons Dev Subject: Betwixt troubles... Hey everyone, I'm running into an issue with some Betwixt code. I'm trying to Write/Read a bean associated with .betwixt file. I can't seem to get attributes to be set when reading in the xml. writing works fine. I've tried several ways (including defaulting to primitiveTypes and specificing an updater method). Here is the content of the file: ?xml version=1.0 encoding=UTF-8? info primitiveTypes=attribute element name=rcss attribute property=type/ element name=requests element name=isValid element name=agent-id attribute name=value property=agentId/ /element !-- element name=agent-id property=agentId updater=setAgentId/ -- /element /element /element /info Results form a write: ?xml version='1.0' ? rcss type=request src=167.154.203.22 requestor=install_app requests isValid cert=Z0123456789 agent-id value=01/ /isValid /requests /rcss --- Results from read: ?xml version='1.0' ? rcss type=request src=167.154.203.22 requestor=install_app requests isValid agent-id/ /isValid /requests /rcss --- What is going wrong? What can I do to fix this problem? modifying the format of the XML is not an option. Also note - using the Commented out element in the betwixt file instead of specifically specifying the attribute, results in agent-id01/agent-id which isn't correct either. Thanks for your help. - Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martin van den Bemt [EMAIL PROTECTED] mvdb.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] BetwixtTest.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Betwixt troubles...
Hey everyone, I'm running into an issue with some Betwixt code. I'm trying to Write/Read a bean associated with .betwixt file. I can't seem to get attributes to be set when reading in the xml. writing works fine. I've tried several ways (including defaulting to primitiveTypes and specificing an updater method). Here is the content of the file: ?xml version=1.0 encoding=UTF-8? info primitiveTypes=attribute element name=rcss attribute property=type/ element name=requests element name=isValid element name=agent-id attribute name=value property=agentId/ /element !-- element name=agent-id property=agentId updater=setAgentId/ -- /element /element /element /info Results form a write: ?xml version='1.0' ? rcss type=request src=167.154.203.22 requestor=install_app requests isValid cert=Z0123456789 agent-id value=01/ /isValid /requests /rcss --- Results from read: ?xml version='1.0' ? rcss type=request src=167.154.203.22 requestor=install_app requests isValid agent-id/ /isValid /requests /rcss --- What is going wrong? What can I do to fix this problem? modifying the format of the XML is not an option. Also note - using the Commented out element in the betwixt file instead of specifically specifying the attribute, results in agent-id01/agent-id which isn't correct either. Thanks for your help. - Mike
RE: Betwixt troubles...
Please note: I sent this to the developers list and not the users list, because I believe it to be a bug, and if confirmed - I may patch it. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 1:26 PM To: Jakarta Commons Dev Subject: Betwixt troubles... Hey everyone, I'm running into an issue with some Betwixt code. I'm trying to Write/Read a bean associated with .betwixt file. I can't seem to get attributes to be set when reading in the xml. writing works fine. I've tried several ways (including defaulting to primitiveTypes and specificing an updater method). Here is the content of the file: ?xml version=1.0 encoding=UTF-8? info primitiveTypes=attribute element name=rcss attribute property=type/ element name=requests element name=isValid element name=agent-id attribute name=value property=agentId/ /element !-- element name=agent-id property=agentId updater=setAgentId/ -- /element /element /element /info Results form a write: ?xml version='1.0' ? rcss type=request src=167.154.203.22 requestor=install_app requests isValid cert=Z0123456789 agent-id value=01/ /isValid /requests /rcss --- Results from read: ?xml version='1.0' ? rcss type=request src=167.154.203.22 requestor=install_app requests isValid agent-id/ /isValid /requests /rcss --- What is going wrong? What can I do to fix this problem? modifying the format of the XML is not an option. Also note - using the Commented out element in the betwixt file instead of specifically specifying the attribute, results in agent-id01/agent-id which isn't correct either. Thanks for your help. - Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
