503 error
Hello- all of a sudden my tomcat keeps giving me a 503 error "This application is not currently avail" whenever I try to browse to http://localhost:8080/foo where /foo is an app that I have had working for weeks. I cant figure this one out. What could have happened such that this app is no longer recognized by Tomcat? The webapps/foo directory is still there. thanks -will
Re: cvs commit: jakarta-struts/contrib/validator/src/example/com/wintecinc/struts/example/validator ApplicationResources.properties ApplicationResources_fr.properties CityStateZip.java MultiRegistrationAction.java RegistrationAction.java RegistrationForm.java TypeAction.java TypeForm.java
how about one big commit ;)
[EMAIL PROTECTED] writes:
> dwinterfeldt01/07/08 20:11:09
>
> Added: contrib/validator/src/example/com/wintecinc/struts/example/validator
> ApplicationResources.properties
> ApplicationResources_fr.properties
> CityStateZip.java MultiRegistrationAction.java
> RegistrationAction.java RegistrationForm.java
> TypeAction.java TypeForm.java
> Log:
> Adding Struts Validator.
>
> Revision ChangesPath
> 1.1
>jakarta-struts/contrib/validator/src/example/com/wintecinc/struts/example/validator/ApplicationResources.properties
>
> Index: ApplicationResources.properties
> ===
> button.cancel=Cancel
> button.confirm=Confirm
> button.reset=Reset
> button.save=Save
>
> # Errors
> errors.footer=
> errors.header=Validation ErrorYou must correct
>the following error(s) before proceeding:
> errors.ioException=I/O exception rendering error messages: {0}
> error.database.missing=User database is missing, cannot validate logon
>credentials
> errors.required={0} is required.
> errors.invalid={0} is invalid.
>
> errors.byte={0} must be an byte.
> errors.short={0} must be an short.
> errors.integer={0} must be an integer.
> errors.long={0} must be an long.
> errors.float={0} must be an float.
> errors.double={0} must be an double.
>
> errors.date={0} is not a date.
>
> errors.range={0} is not in the range {1} through {2}.
>
> errors.creditcard={0} is not a valid credit card number.
>
> errors.email={0} is an invalid e-mail address.
>
>
> # Registration Form
> registrationForm.title=Registration
> registrationForm.title.create=Register
> registrationForm.title.edit=Edit User Information
> registrationForm.firstname.displayname=First Name
> registrationForm.lastname.displayname=Last Name
> registrationForm.addr.displayname=Address
> registrationForm.city.displayname=City
> registrationForm.stateprov.displayname=State
> registrationForm.zippostal.displayname=Zip
> registrationForm.phone.displayname=Phone
> registrationForm.email.displayname=E-mail
> registrationForm.lastname.maskmsg=Last Name can only be letters and numbers, no
>spaces.
>
> # Type form
> typeForm.title=Type Form
> typeForm.title.create=Type Form
> typeForm.byte.displayname=Byte Field
> typeForm.short.displayname=Short Field
> typeForm.integer.displayname=Integer Field
> typeForm.long.displayname=Long Field
> typeForm.float.displayname=Float Field
> typeForm.double.displayname=Double Field
> typeForm.date.displayname=Date Field
> typeForm.creditCard.displayname=Credit Card
>
>
> 1.1
>jakarta-struts/contrib/validator/src/example/com/wintecinc/struts/example/validator/ApplicationResources_fr.properties
>
> Index: ApplicationResources_fr.properties
> ===
> button.cancel=Annulent
> button.confirm=Confirment
> button.reset=Remettent
> button.save=Économiser
>
> # Errors
> errors.footer=
> errors.header=Erreur De ValidationVous devez
>corriger l'error(s) suivant avant procédant:
> errors.ioException=Exception de E/S rendant des messages d'erreur: {0}
> error.database.missing=La base de données d'utilisateur est manquante, ne
>peut pas valider des qualifications de procédure de connexion
> errors.required={0} est exigé.
> errors.invalid={0} est incorrect.
>
> errors.byte=Le {0} doit être un nombre byte.
> errors.short=Le {0} doit être un nombre short.
> errors.integer=Le {0} doit être un nombre integer.
> errors.long=Le {0} doit être un nombre long.
> errors.float=Le {0} doit être un nombre float.
> errors.double=Le {0} doit être un nombre double.
>
> errors.date=Le {0} n'est pas une date.
>
> errors.range=Le {0} n'est pas dans l'intervalle {1} à {2}.
>
> errors.creditcard=Le {0} n'est pas un nombre valide de carte de crédit.
>
> errors.email=Le {0} est une adresse incorrecte de e-mail.
>
>
> # Registration Form
> registrationForm.title=Enregistrement
> registrationForm.title.create=Registre
> registrationForm.title.edit=Éditez L'Information D'Utilisateur
> registrationForm.firstname.displayname=Prénom
> registrationForm.lastname.displayname=Dernier Nom
> registrationForm.addr.displayname=Adresse
> registrationForm.city.displayname=Ville
> registrationForm.stateprov.displayname=État/Province
> registrationForm.zippostal.displayname=Code postal
> registrationForm.phone.displayname=Téléphone
> registrationForm.emai
Re: question
thanks! Oleg V Alexeev writes: > Hello William, > > Friday, June 29, 2001, 8:46:26 AM, you wrote: > > WS> I am trying to do the following with Tomcat and Struts but am not sure > WS> how to go about it: > > WS> I want to implement a Servlet that dispatches / forwards to jsp > WS> pages. Before the dispatch, however, I would like to set an attribute > WS> of the PageContext of the jsp page that I will be dispatching to. > > You can set attribute in request scope and forward to the JSP page. > You can not set attribute in page scope outside of JSP page. > > P.S. I think that there is already exist maillist for such questions - > [EMAIL PROTECTED] > > -- > Best regards, > Olegmailto:[EMAIL PROTECTED] > >
question
Hello - I am trying to do the following with Tomcat and Struts but am not sure how to go about it: I want to implement a Servlet that dispatches / forwards to jsp pages. Before the dispatch, however, I would like to set an attribute of the PageContext of the jsp page that I will be dispatching to. Is this possible? thanks in advance -will
Re: installing struts taglibs
thanks for the explaination. -will Craig R. McClanahan writes: > > > On Thu, 21 Jun 2001, William Shulman wrote: > > > > > thanks Craig- > > > > I may be appealing to the wrong crowd (as I expect this stuff is all > > part of the Servlet spec), but this somehow seems to be less modular > > than I would like. It seems that the spirit or .war files is to be an > > extension of the .jar file concept, generalized to entire j2ee > > applications. When I obtain a .jar file for classes I would like to > > use -- all I need to do is place that .jar file in my CLASSPATH and I > > can use the classes. The analogy does not seem to fully carry over > > into .war files. Would it not be better if I was able to package my > > entrire application and supporting resources (html, xml, tld, > > etc.. files) and have the servlet or j2ee system know how to access > > all of those resources in a generic way, similar to the approach with > > .jar files and classes? It seems that the current approach only goes > > half way -- I can introduce a .war file and have the servlet container > > interpret its structure in some ways (making a context, recognizing > > the docroot, etc), but not in other ways (allowing my jsp files to > > import or declare taglibs contained in the .war file, or recognize classes) > > > > Well, you've certainly got most of the "self contained" stuff you are > after: > * Want to use a JAR file in your app? Stick it into /WEB-INF/lib > and it is automatically available to you. > * Want to access a static resource in your app? Use > ServletContext.getResource() and you don't have to care how the > servlet container deals with it. > * Want to change the context path of your app? The details of how > to do this vary by servlet container, but it's trivially easy > (especially with Struts) to make your application independent > of what the actual context path is. > * Want to us a tag library? Somehow, you've got to create a mapping > from the URI used in your pages to the corresponding TLDs. There > are a variety of ways to do this, but I've found that explicitly > referencing TLDs in the WEB-INF directory is the least confusing. > > > Is there some design reason for this that I do not understand? It > > seems things could be architected such that the steps you outline > > below are not needed. > > > > For the separate TLD files themselves, there's a spec-related issue that > caused this approach. > > The JSP 1.1 spec defines the concept of a tag library that is encapsulated > in a single JAR file (including the TLD, which you placed at the > META-INF/tablib.tld entry. Thus, you could just drop a tab library into > your WEB-INF/lib directory, create a URI for it in web.xml, and go. > > Now, originally, Struts only had one tag library, so this strategy was > quite useful -- stick the "struts.tld" file into struts.jar, and > everything was fine. However, Struts now has four tag libraries (and the > number is likely to grow in the future). But you cannot have more than > one encapsulated TLD in a single JAR file in JSP 1.1 -- and separating > struts.jar into five JAR files doesn't really help anything. > > In JSP 1.2, this changes -- you'll be able to to encapsulate all of the > Struts tag libraries in struts.jar and dispense with the separate TLD > files. But, until JSP 1.2 containers are widely deployed, we're stuck > with the 1.1 restrictions. > > But the bottom line is that the architecture of web applications is > defined by the servlet spec. Therefore, Struts has to live within those > rules, just like any other web application or framework based on servlets > will have to. > > > -will > > > > > > Craig > >
Re: installing struts taglibs
thanks Craig- I may be appealing to the wrong crowd (as I expect this stuff is all part of the Servlet spec), but this somehow seems to be less modular than I would like. It seems that the spirit or .war files is to be an extension of the .jar file concept, generalized to entire j2ee applications. When I obtain a .jar file for classes I would like to use -- all I need to do is place that .jar file in my CLASSPATH and I can use the classes. The analogy does not seem to fully carry over into .war files. Would it not be better if I was able to package my entrire application and supporting resources (html, xml, tld, etc.. files) and have the servlet or j2ee system know how to access all of those resources in a generic way, similar to the approach with .jar files and classes? It seems that the current approach only goes half way -- I can introduce a .war file and have the servlet container interpret its structure in some ways (making a context, recognizing the docroot, etc), but not in other ways (allowing my jsp files to import or declare taglibs contained in the .war file, or recognize classes) Is there some design reason for this that I do not understand? It seems things could be architected such that the steps you outline below are not needed. -will Craig R. McClanahan writes: > Copying the WAR files is how you would install the example applications > that come with Struts. For your own apps, you basically need to: > - Add "struts.jar" to the WEB-INF/lib directory of your webapp > - Copy the Struts TLD files into the WEB-INF directory of your > webapp (although some prefer WEB-INF/tlds instead) > - Make the URIs you use in web.xml and/or your pages point at wherever > you actually installed these TLDs. > > Craig > >
installing struts taglibs
Hello - I have been using the struts tablibs for a few weeks now and integrated them with my application by adding taglib declarations in my web.xml file to point to the struts tld files. However, I was reading the installation notes again and noticed that another way to install struts is to simply copy all of the struts .war files into my webapps directory. However, it seems that I still have to modify my web.xml file to include the struts taglibs. Is this the case or am I doing someting wrong. I was hoping I could just copy the .war files and be done. -will
Re: DTD Location
Another way is to implement your own EntityResolver to maintain a local cache. This is explained in the javadoc for the EntryResolver class (somewhere in javax.xml...) -will [EMAIL PROTECTED] writes: > Currently, the XML indicates that the DTD is located over the web using a > public qualifier. Does it really check over the web for the DTD to > validate against? I would rather not do this for performance reasons. If > it does, can I change the reference to a SYSTEM ref instead. What is the > recommended approach for a production implementation? > > Thanks in Advance, > Ken Hoying > Practice Partner > TITAN Technology Partners > Pager: 216-275-7284 >
Re: question
Thanks Oleg Oleg V Alexeev writes: > Hello William, > > Can you wrap iterate tag with xsl transformer and process whole > result? Or use xsl tags from taglibs project? > This will not be possible. Basically, I have a Hashtable of objects that each have a property that is an XML string. I want to iterate over the Hastable's values and pass the XML string from each object to a custom tag I have to render the XML with an XSL template. > At end of iterate tag there is bodyContent.clearBody() call. I think > it is reason for this exception and so you can not use any direct > manipulations with pageContext.out here. > Hmm, this seems like it could end up being a problem for many people. I just looked at the code. I am not sure what clearBody() does (I'm new to Struts), but if I understand you correctly, are you saying that Custom tags, when invoked inside the iterate tag, may or may not behave properly? I would think that tags should always behave in a "context free" way just like any code in any language does. In Java, you would barf if you saw a function that behaved differently based on the the state of the caller. Imaging if suddenly Object.toString() broke because you are calling it inside of a method that "did not intend Object.toString() to be called withing its context". In this case, I implemented my Tag after the iterate tag was implemented and so MAYBE I can find a workaround. However, there might be many tags out there that work perfectly but may break if used inside the iterate tag. Do you think there is a way for the struts team to fix this or am I missing something and you do not think this is a bug. thanks for you reply -will > Tuesday, June 12, 2001, 5:52:10 AM, you wrote: > > > WS> Inside of the logic:iterate tag, I am passing a string to an xsl > WS> tranformer, using pageContext.out as the writer the tranformer will > WS> write its results to. When I do so, there is a complaint that says: > > WS> "Illegal to flush within a custom tag" > > > WS> I tried to do the same thing (use an xsl tranformer) inside of some > WS> custom tags I have written and I get no such error -- I only get the > WS> erro inside of the login:iterate tag. > > WS> Does anyone know if there is soem reason this might be happening > WS> inside the iterate tag? I have been banging my head against the wall on this > WS> one. > > WS> I cant find what code is complaining and I thought you struts guys may > WS> have an idea since I can only reproduce in the iterate tag. > > WS> thanks much in advance > > WS> -will > > > > -- > Best regards, > Olegmailto:[EMAIL PROTECTED] > >
question
Inside of the logic:iterate tag, I am passing a string to an xsl tranformer, using pageContext.out as the writer the tranformer will write its results to. When I do so, there is a complaint that says: "Illegal to flush within a custom tag" I tried to do the same thing (use an xsl tranformer) inside of some custom tags I have written and I get no such error -- I only get the erro inside of the login:iterate tag. Does anyone know if there is soem reason this might be happening inside the iterate tag? I have been banging my head against the wall on this one. I cant find what code is complaining and I thought you struts guys may have an idea since I can only reproduce in the iterate tag. thanks much in advance -will
Re: [PROPOSAL] Struts Extensions
> > The same would probably be true of Oleg's BeanFactory. Plug it in. Plug > it out. This sounds interesting. Does anyone have a pointer to this BeanFactory code? thanks -will
Re: Proposed feature: Bean property transformations
If the Transformation interface translates objects to and from
Strings, how is it different than PropertyEditors?
-will
Ron Smith writes:
> I like the idea of combining transformations with some validation
> logic. After all, you commonly validate the contents of a String by
> trying to transform it into some other data type.
> I'm also interested in the discussions going on about client side
> validation and locale/language specific validation/presentation
> although I haven't looked at it that closely.
>
> Like you, this is something I could use right away, so I'm probably
> going to work on putting something basic together pretty soon.
>
> I was thinking of having a Transformation interface that supported
> transforming an object from its primary form to a secondary form -
> for instance transforming a Date object into a String. This would
> be a forward transformation. The Transformation interface would also
> support transforming an object from its secondary form to its primary
> form (e.g. String to Date) - a reverse transformation.
> Although validation would be implicitly
> done as a part of transformation, there'd be a seperate validate(Object) function
> that could be called to just validate an object in its secondary form (e.g.
> a String that holds a date representation).
> I'd have various types of transformation classes to support the different
> data types in the application. Some would be fairly generic and reusable
> and some would be pretty application specific.
>
> I'd probably have the ActionForm have two sets of attributes for its
> fields - the fields in String form as they came in the HTTP request, and
> the fields in their primary data type form. This is because I usually don't
> have a simple mapping between a form's fields and the attributes of a
> business entity bean, so It doesn't help me to try to transform into
> another bean's fields, might as well keep it all in the same ActionForm
> object.
> It'd be nice to have something automatically apply the correct
> transformations to each field in the ActionForm and generate error
> messages for any transformations/validations that failed.
>
> I'd also like to have something generic enough that it could be used
> in non-servlet type of applications as well.
>
>
> Ted Husted wrote:
>
> > What I'm missing is a comprehensive, general package for converting data
> > types and formatting properties for presentation. Most of this
> > functionality is available somewhere in java and javax space, but it's
> > spread around.
> >
> > What would be most useful, I think, is a single, generic package that
> > provided
> >
> > (1) validation of Strings using regular expressions (a la David
> > Winterfeldt's servlet), with direct support for native and JDBC
> > datatypes,
> >
> > (2) binary to String and String to binary conversions for all native and
> > standard types, and support for adding others,
> >
> > (3) given a formatting specification ("00#.##") and data of any
> > supported type, return a formatted presentation String,
> >
> > (4) support for locale-senstive transformations with (3),
> >
> > (5) support for extending the formatting specification for unusual
> > circumstances, and
> >
> > (6) provide simple date-calculation methods and a countdown presentation
> > format (seconds, minutes, hours, or days from now until then).
> >
> > We could then use this helper object during the validation cycle to
> > convert incoming Strings to the other types needed by business-logic
> > objects, AND pass through the functionality from a > > tag, that could pull a property from a given bean, transform it, and return a
>formatted String for direct use by the view.
> >
> > If there is not something like this already out there, I've very
> > interested in getting started on this package, since I really, really
> > need it for my own projects. Could be a nice addition to the Commons ...
> >
> > I'm cross-posting this to Struts user in case someone can suggest a
> > package that already provides this functionality.
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Custom Software ~ Technical Services.
> > -- Tel 716 737-3463.
> > -- http://www.husted.com/about/struts/
> >
> > Ron Smith wrote:
> > >
> > > I've been thinking of implementing this feature lately and I haven't
> > > seen it proposed on this list yet. Any comments?
> > >
> > > Summary:
> > > Provide a means to flexibly plug in transformations that could
> > > be applied to JavaBean properties for presentation in a JSP page.
> > > What transformation to apply to which JavaBean property
> > > is specified in the Struts JSP tags (e.g. bean:write).
> > > Transformations are Java classes that are responsible for taking
> > > a JavaBean property or any other Object, applying whatever
> > > transformation, and returning the transformed Object for
> > > presentation in
RE: PropertyUtils Enhancement Source Code
> The problem with your suggestion of implementing this using the Struts > BeanUtils is that it has been deprecated because its been donated to the > Jakarta Commons project. I understand Struts will be changed to use the > Jakarta Commons version in 1.1. BeanUtils are "utility methods for > populating JavaBeans" and the question is would we be able to persuade > Jakarta Commons to include this when it doesn't have anything to do with > JavaBeans? This should not be that big of an issue. AND, DynamicPropertyMappers (or whatever we want to call them) has everything to do with JavaBeans in my opinion. -will
RE: PropertyUtils Enhancement Source Code
I think this *may* solve the problem at the wrong level of abstraction. The
concept of Dynamic Properties, while useful in dealing with forms, has
nothing to do with forms and ActionForms intrinsicly. Dynamic
Properties should be available as a tool for any Java programming
task. I can think of many uses that do not even involve web
applications. To couple the idea of Dynamic properties to web forms
would be a mistake.
That said, your solution below does not, per say, couple Dynamic
properties to ActionForms. It seems that you just want to use Dynamic
properties with ActionForms, which seems fine to me. Otherwise, you
suggestion is very similar to the implementation approach I outlined
below.
Without question, however, Dynamic Properties should be part of the
struts beans package. Of course I am biased ;), but I think the
implementation I outlined in my last email on the topic (below) is the
right way to do this (similar to Niall's approach). There are
differences, however, with Niall's. For one, getValue and setValue
should deal with Objects and not Strings. My solution also contains
the concept of a registry for registering dynamic PropertyMappers
and how it should be integrated with the PropertyUtils class.
-will
Niall Pemberton writes:
> I would prefer to see dynamic properties for ActionForms implemented in
> Struts - which is on the 1.1 ToDo list.
>
> We have customized Struts to do dynamic properties along the following
> lines:
>
> 1) Created a "DynamicProperties" interface which has the following methods:
>
> public String getValue(String property);
> public String getValue(int index, String property);
> public void setValue(String property, String value);
> public void setValue(int index, String property, String value);
>
> 2) Sub-classed "ActionServlet" and changed the "processPopulate" method to
> populate the ActionForm using the above setters if its an instance of
> "DynamicProperties" or using its normal reflection if not.
>
> 3) Modified Struts tags to retrieve bean values using the above getters if
> its an instance of "DynamicProperties" or using its normal reflection if
> not.
>
> 4) Created a sub-class of ActionForm (DynamicActionForm) which implements
> our "DynamicProperties" interface.
>
> Now we only have one DynamicActionForm and don't have to go round setting up
> loads of different "ActionForm" classes. The DynamicActionForm is a bit
> simplistic and wouldn't suit everyones needs, but the advantage of this is
> people could create their own concrete implementations.
>
> It would be interesting to hear others opinions on how dynamic properties
> should be implemented.
>
> Niall
>
>
> > -Original Message-
> > From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
> > Sent: 28 May 2001 16:59
> > To: [EMAIL PROTECTED]
> > Subject: Re: PropertyUtils Enhancement Source Code
> >
> >
> > I always like doing things more generic, but in this
> > particular case I like being able to tell that a value
> > in a long nested property was a key for a
> > java.util.Map.
> >
> > "foo.someMap.firstPerson.address.zip"
> >vs.
> > "foo.someMap{firstPerson}.address.zip"
> >
> > It seems like the most common/standard things you
> > would store something in are arrays, Collection/List,
> > and a Map. I'm not sure if the indexed property can
> > handle a Collection or a Collection/List, but it could
> > easily be modified if it doesn't. The only other
> > thing left is a Map. So I don't think it is that bad
> > to have special syntax. There is improved readability
> > and it would cover the final major interface not cover
> > by nested properties from the Collections API.
> >
> > It would still be nice to have a generic way to plug
> > in something for other classes though. We'll see what
> > other people think.
> >
> > David
> >
> > --- William Shulman <[EMAIL PROTECTED]> wrote:
> > >
> > > David-
> > >
> > > I think your idea is a great one. Ideally, you would
> > > configure the
> > > BeanInfo for Map like classes with a readMethod that
> > > treats the names
> > > of Map properties as keys. That way the evalulation
> > > expression
> > > "foo.someMap.firstName" would result in 'firstName'
> > > being treated as a key
> > > to be looked up in the Map and returned. This is the
> > > way the java
> &
Re: PropertyUtils Enhancement Source Code
I hear what you are saying. You see maps as a first order concept that
you would like formalized in the syntax of bean expressions. I can see
that, but I still do favor staying as close to the original bean
specification as we can without loosing expressiveness. Because using
the '.' operator requires no syntactic changes to the expression
language and can implement the same semantics as 'map{key}', I see no
reason to add new base contructs to the language.
-will
David Winterfeldt writes:
> I always like doing things more generic, but in this
> particular case I like being able to tell that a value
> in a long nested property was a key for a
> java.util.Map.
>
> "foo.someMap.firstPerson.address.zip"
>vs.
> "foo.someMap{firstPerson}.address.zip"
>
> It seems like the most common/standard things you
> would store something in are arrays, Collection/List,
> and a Map. I'm not sure if the indexed property can
> handle a Collection or a Collection/List, but it could
> easily be modified if it doesn't. The only other
> thing left is a Map. So I don't think it is that bad
> to have special syntax. There is improved readability
> and it would cover the final major interface not cover
> by nested properties from the Collections API.
>
> It would still be nice to have a generic way to plug
> in something for other classes though. We'll see what
> other people think.
>
> David
>
> --- William Shulman <[EMAIL PROTECTED]> wrote:
> >
> > David-
> >
> > I think your idea is a great one. Ideally, you would
> > configure the
> > BeanInfo for Map like classes with a readMethod that
> > treats the names
> > of Map properties as keys. That way the evalulation
> > expression
> > "foo.someMap.firstName" would result in 'firstName'
> > being treated as a key
> > to be looked up in the Map and returned. This is the
> > way the java
> > beans specification exposes hooks to "override" when
> > the '.' operator
> > does.
> >
> > Unfortunately, doing this in practice is quite
> > difficult. Without going into
> > the details, if you investigate this method in the
> > java beans API's you will
> > find it quite inflexible. However, the idea is
> > right. We should be able to
> > explicitly define how properties of a given type are
> > accessed and mutated.
> >
> > I think the right way to implement this is to create
> > an interface called
> > PropertyMapper and support a mechanism for linking
> > property mappers
> > with java Classes via a PropertyMapperRegistry.
> >
> > public interface PropertyMapper {
> > public Object getProperty(Object bean, String
> > propName);
> > public Object setProperty(Object bean, String
> > propName, Object propValue);
> > }
> >
> > public class PropertyMapperRegistry {
> > public PropertyMapper getPropertyMapper(Class
> > type);
> > public void registerPropertyMapper(Class type,
> > PropertyMapper pm);
> > }
> >
> > Then, the struts PropertyUtils.getPropertyValue and
> > setPropertyValue methods
> > (I might have the names slightly wrong) would first
> > look to see if a
> > PropertyMapper is registered for a given type, and
> > use that PropertyMapper if
> > possible. If a PropertyMapper is not registered for
> > a given type, then the
> > PropertyUtils falls back to the standard readMethod
> > and writeMethod supplied
> > by the property's PropertyDescriptor.
> >
> > Here is how you would implement a PropertyMapper for
> > HashMaps
> >
> > public class HashMapPropertyMapper implements
> > PropertyMapper {
> > public Object getProperty(Object bean, String
> > propName) {
> >return( ((HashMap)bean).get(propName) );
> > }
> >
> > public Object setProperty(Object bean, String
> > propName, Object propValue) {
> >return( ((HashMap)bean).put(propName, propValue)
> > );
> > }
> > }
> >
> > The reason I favor this approach is:
> > (1) This method is very close the initial spirit of
> > the Java Beans spec
> > (2) No new syntax is introduced. We do not need { }
> > and can utilize the
> > existing '.' (dot) operator.
> > (3) This solution is more general than a solution
> > just for HashMaps.
> > Although this is applied really well to HashM
Re: PropertyUtils Enhancement Source Code
David-
I think your idea is a great one. Ideally, you would configure the
BeanInfo for Map like classes with a readMethod that treats the names
of Map properties as keys. That way the evalulation expression
"foo.someMap.firstName" would result in 'firstName' being treated as a key
to be looked up in the Map and returned. This is the way the java
beans specification exposes hooks to "override" when the '.' operator
does.
Unfortunately, doing this in practice is quite difficult. Without going into
the details, if you investigate this method in the java beans API's you will
find it quite inflexible. However, the idea is right. We should be able to
explicitly define how properties of a given type are accessed and mutated.
I think the right way to implement this is to create an interface called
PropertyMapper and support a mechanism for linking property mappers
with java Classes via a PropertyMapperRegistry.
public interface PropertyMapper {
public Object getProperty(Object bean, String propName);
public Object setProperty(Object bean, String propName, Object propValue);
}
public class PropertyMapperRegistry {
public PropertyMapper getPropertyMapper(Class type);
public void registerPropertyMapper(Class type, PropertyMapper pm);
}
Then, the struts PropertyUtils.getPropertyValue and setPropertyValue methods
(I might have the names slightly wrong) would first look to see if a
PropertyMapper is registered for a given type, and use that PropertyMapper if
possible. If a PropertyMapper is not registered for a given type, then the
PropertyUtils falls back to the standard readMethod and writeMethod supplied
by the property's PropertyDescriptor.
Here is how you would implement a PropertyMapper for HashMaps
public class HashMapPropertyMapper implements PropertyMapper {
public Object getProperty(Object bean, String propName) {
return( ((HashMap)bean).get(propName) );
}
public Object setProperty(Object bean, String propName, Object propValue) {
return( ((HashMap)bean).put(propName, propValue) );
}
}
The reason I favor this approach is:
(1) This method is very close the initial spirit of the Java Beans spec
(2) No new syntax is introduced. We do not need { } and can utilize the
existing '.' (dot) operator.
(3) This solution is more general than a solution just for HashMaps.
Although this is applied really well to HashMaps, With this method,
we can implement PropertyMappers for any class. One example that comes to
mind is this (although slightly academic):
Imagine we have a FileManager class that we use to create java.io.File
objects (kind of a File Factory). We might want to abstractly define that
a properties of FileManagers are File objects obtained through the
FileManager, such that we can write expressions like this:
"someObject.myFileManager./usr/local/apache/logs/error"
To put it simply, we can make the '.' operator mean anything we want it to mean
for a given target class. Kind of cool. This kind of thing can also be seen
in the Python programming language where the developer can override the
imlementation of '.' and is also similar to 'tie' in Perl .
-will
David Winterfeldt writes:
> Here is the source. I've done some basic tests and I
> think everything is working.
>
> David
>
> --- David Winterfeldt <[EMAIL PROTECTED]> wrote:
> > For an array you can do this for a property
> > "type[index]". I don't know if this has been
> > suggested before, but what if you could also do this
> > for a Hashmap. I was thinking something like
> > form{name}. I'm sure there are lots of other uses,
> > but it could let you make a bean/form class that
> > just
> > used a Hashmap for rapid prototyping. This also
> > might
> > be a simple/temporary solution for the beans that
> > don't need setters and getters.
> >
> > public Hashmap getForm();
> >
> > > maxlength="30"/>
> > > maxlength="30"/>
> > > maxlength="30"/>
> >
> >
> > David
> >
> > __
> > Do You Yahoo!?
> > Yahoo! Auctions - buy the things you want at great
> > prices
> > http://auctions.yahoo.com/
>
>
> __
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
Re: Logical name usage in the URL
one thing to think about: if you are running a web server, like Apache for instance, in front of your app servers, you can configure rewrite rules to map 'pretty urls' to actual urls on your app server or servlet container. If you want to do this with Apache look at the mod_rewrite stuff on the apache web site. There are reasons, however, why it is noce to have the servlet environments aware of this mapping as well. -will Venkatesh Mahipati writes: > Hello, > I am developing an application using struts, for which I would like to have > the below requirement. > > My requirement is, > Instead of using this URL http://venkatesh:8080/cart/home.jsp, > > I want to use http://venkatesh:8080/cart/welcome. > > That is to say, > I want to refer home.jsp file by using the logical name - say, welcome. > > I tried to customize struts-Config.xml and web.xml nothing has turned up. > Could you explore on the same and give some relevant tag usage where I have > to put it. > > Cheers, > > Venky > > > > ***Confidential Notice > > This e-mail communication may contain information that is > confidential and privileged. The information is intended > to be for the use of the addressee only. If you are not the > named addressee you should not disseminate, distribute or > copy this e-mail: to do so could be a breach of confidence. > > Kshema Technologies Ltd., > # 33/1, Lalbagh Road, Bangalore 560027, INDIA. > Tel: (91) 80- 2995114/5/6 > Fax: (91) 80 2272933 > > **
RE: RE-2: cvs commit:jakarta-struts/src/share/org/apache/struts/acti on Action.javaActionForm.java
Sounds like another good solution might be to implement a parameter
stack in the request object. The parameter stack is a stack of
Dictionary objects. When parameters are introduced, they are placed
in the Dictionary on the top of the stack. Similarly for lookup. Stack
frames (i.e. the Dictionaries) are pushed and popped appropriately as
you chain.
Just a thought. There may be some details to work out, but the
solution would be very general and useful in many places.
-will
Martin Cooper writes:
> As far as I am aware, you cannot add parameters to the request.
>
> I think storing values as request attributes and then looking there for
> parameter values would be very dangerous. You could potentially break
> existing code that uses request attributes to store data for chaining actions.
>
> Incidentally, Hal, I faced a similar problem in chaining actions. What I
> did was to instantiate a separate form bean and store the chaining
> parameters in that, then use one well-known (between our Actions, I mean)
> request attribute to store that bean. The chained-to action checks for that
> bean first, otherwise it uses the one Struts passed to the perform() method.
>
> --
> Martin Cooper
>
>
> At 12:38 PM 5/11/01, Deadman, Hal wrote:
> >I thought of that too but I don't know how to add parameters to the request.
> >Maybe you could use request.setAttribute and store the multi-part request
> >String parameters as attributes in the requet object. Then code that looks
> >for parameters could be changed to a method that looks for parameters or
> >attributes. I don't know if that would help matters much.
> >
> >I use something similar in my application so that I can have an action that
> >is accessed from a link or from another action. In one case the paramters
> >are passed on the url and in the other case parameters are passed as request
> >attributes. The receiving action calls a method that checks for one and then
> >the other, using the first one it finds.
> >
> > protected String findStringParameter(HttpServletRequest request, String
> >key)
> > {
> > String value = request.getParameter(key);
> > if (value == null)
> > {
> > value = (String) request.getAttribute(key);
> > }
> > return value;
> > }
> >
> > > -Original Message-
> > > From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, May 11, 2001 2:19 PM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE-2: cvs commit:
> > > jakarta-struts/src/share/org/apache/struts/acti on Action.java
> > > ActionForm.java
> > >
> > >
> > > On second thought, I'm going to toy around with putting the request
> > > parameters
> > > directly into the request from MultipartRequestHandler
> > > instead of using
> > > MultipartRequestHandler itself to store attributes. If I can
> > > get it to work
> > > this will solve all
> > > the problems without adding any new methods to anything, or changing
> > > anything.
> > >
> > > -Original Message-
> > > From: SCHACHTER,MICHAEL (HP-NewJersey,ex2)
> > > Sent: Friday, May 11, 2001 2:08 PM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: cvs commit:
> > > jakarta-struts/src/share/org/apache/struts/action Action.java
> > > ActionForm.java
> > >
> > >
> > > Is this an acceptable resolution to this problem for
> > > everybody? If so, I'll
> > > go ahead and fix the token problem in the Action class, be
> > > creating new
> > > isTokenValid() method that takes an HttpServletRequest and a
> > > MultipartRequestHandler
> > > as arguments, when using it for multipart forms. The other
> > > token methods
> > > don't
> > > need to be changed, as they only deal with retrieiving
> > > session information.
> > >
> > > -Original Message-
> > > From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, May 11, 2001 1:29 PM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: cvs commit:
> > > jakarta-struts/src/share/org/apache/struts/action Action.java
> > > ActionForm.java
> > >
> > >
> > > Hal,
> > >
> > > It was my understanding that since isCancelled is a protected
> > > method in the
> > > Action class,
> > > that it was the Action developer's job to call the method.
> > >
> > > -Original Message-
> > > From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, May 11, 2001 1:24 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: cvs commit:
> > > jakarta-struts/src/share/org/apache/struts/action Action.java
> > > ActionForm.java
> > >
> > >
> > > Doesn't the Struts framework need to call this new method
> > > somewhere? The
> > > application code can't call the isCancelled method because
> > > the Action class
> > > code will never be called. If Struts ActionServlet calls the
> > > form validate
> > > when a user clicked cancel, the validation will likely fail
