About Master-Detail / Radio Buttons / Indexed Properties Behavious !!!
Hi Theres, I am facing some issues about master-detail / radio button for indexed properties. Issues are:-___ Problem 1 __1. I am facing later mentioned problem ofmaster-detail from on session time out.I am usingDynaActionForms with array properties as form-beanproperty.form-property name=vefiryOrMakeBrokerDetailtype=com.abamco.clientVerification.VerifyOrMakeBrokerPayments[]/and i have set session as its action scope. But 2.when my application restarts and i Re-fresh themasteer-detail form itgives me the following error:- Error Start-HTTP Status 500 - type Exception reportmessage description The server encountered an internalerror() that prevented it from fulfilling this request.exception javax.servlet.ServletException: BeanUtils.populateorg.apache.struts.util.RequestUtils.populate(RequestUtils.java:1190)g.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:821)g.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254)g.apache.struts.action.ActionServlet.process(ActionServlet.java:1480)org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:524)javax.servlet.http.HttpServlet.service(HttpServlet.java:763)javax.servlet.http.HttpServlet.service(HttpServlet.java:856)root cause java.lang.ArrayIndexOutOfBoundsException java.lang.reflect.Array.get(Native Method)org.apache.struts.action.DynaActionForm.get(DynaActionForm.java:296)g.apache.commons.beanutils.PropertyUtils.getIndexedProperty(PropertyUtils.java:474)g.apache.commons.beanutils.PropertyUtils.getIndexedProperty(PropertyUtils.java:428)g.apache.commons.beanutils.PropertyUtils.getNestedProperty(PropertyUtils.java:770)g.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:801)g.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:881)org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808)org.apache.struts.util.RequestUtils.populate(RequestUtils.java:1188)g.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:821)g.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254)g.apache.struts.action.ActionServlet.process(ActionServlet.java:1480)org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:524)javax.servlet.http.HttpServlet.service(HttpServlet.java :763)javax.servlet.http.HttpServlet.service(HttpServlet.java:856)note The full stack trace of the root cause isavailable in the Tomcat logs.Apache Tomcat/5.0.16- Error End -I have my own created reset button in whichi nullify all teh feilds. But, tis method is now acallback method. I do't override thereset(ActionMapping,HttServletRequest) method. All theform properties exactly matching with theircorresponding dynaactionfrom properties and thisscreen is working properly. It only behave abnormallywhen my web app context restarts or tomcat restarts asin that case session will lost.__ Problem 2 _2. Also, One more problem.I have tried to fix it butas a new commer I have now stucked. Actually, I have abean which i want to use in jsp with iterate tag. andi have like this:-logic:present name=individualAccountRegFormproperty=clientlogic:iterate id=clientname=individualAccountRegForm property=clienthtml:hidden name=client indexed=trueproperty=status/trtd align=lefthtml:text name=client indexed=true property=clientId//tdtd align=lefthtml:radio name=clientproperty=primaryClient idName=clientvalue=primaryClient indexed=true//td /tr/logic:iterate/logic:presentI mean to say that if i have indexed properties and iwant to check some equal operator on it then there isno indexed attribute in logic:equal or any othercomparison tag. even then it picks the indexedproperty value properly. How this happens.Is thie anyauto build flexibility in those tags top check thecommign property that either iot is a normal orindexed property.__ Problem 3I have the radio buttons, but they are not behavingproperly.I want to use radio buttons with indexedproperty.Actually one of my indexed property willbehave like radio button and if i have more than onerows then i will have more than one radio buttons.Inthat case how can i set radio button to enable onlyone at a time.I tryied it, but all the button willenable at a time(menas previous button will remainenable when we press any other radio button to getenable it should disable the previous enable button) Regards, DIV P align=leftFONT face=Times New RomanBuland Altaf Malik,BRSTRONGSr. Software Engineer/STRONG, BRSoftech System's(pvt)Ltd. BR10/25 asad jan road lahore,cantt - 54810 PakistanBRTel: 92-42-6665812 , 92-42-6660802/FONT/P P align=leftFONT face=Times New RomanMob: 0333-4344113BRFax: 92-42-6665792/FONT/P P align=leftFONT face=Times New RomanA href=http://www.softech.com.pk/;http://www.softech.com.pk/ABRA href=mailto:[EMAIL PROTECTED][EMAIL
Repository Reorg (Once More With Feeling)
Here's another crack at trying to get us moving forwards on the repository reorg. Given the feedback of our most recent discussions, I'd like to focus on the following motivations for a particular decision on the organization of the repository, followed by what seems to make sense based on those motivations: * Use Subversion for the new repository (I've played enough to be sold). * Use Maven 1.0 for the build tool (we need to deal with persistent user complaints about complexity of our build process, plus enable independent module releases gracefully). * In general, follow Maven's recommendations for directory layout on multi-module builds. * Continue to build 1.2.x releases off the old (jakarta-struts) repository (taking the time pressure off on getting the new architecture perfect the first time). * Focus the new repository on supporting 1.3.x development (generally backwards compatibile, but using chain-based request processor, adding support for portlet), in prep for later migration to 2.x.x development (which might end up in either separate modules or a separate repository -- too early to tell at this point). * Separate modules for independently releaseable artifacts. * Modules can depend on each other (i.e. pretty much all will depend on core), but we should exercise caution if the dependency tree gets deep ... complexity lurks here. * The core module should have no view tier dependencies. * There is no need for a separate JSP-specific module for TagUtils. That class is tightly coupled to the legacy tag libraries, so it should go in the same module. * We'll need to do some minor refactoring to optimize things after the rearrangement, but that shouldn't delay getting started. * Each module (of course) includes its appropriate complement of unit tests. Given the above, here's my suggestion for the top-level modules in the initial repository, and the packages and classes that should be included there: (1) core -- Core Framework Dependencies: commons-beanutils commons-chain commons-digester commons-fileupload commons-logging commons-resources (once graduated) commons-validator jakarta-oro (inherited from commons-validator) Packages and Classes: org.apache.struts.Globals org.apache.struts.action.* org.apache.struts.chain.* org.apache.struts.chain.legacy.* org.apache.struts.chain.portlet.* (to be created) org.apache.struts.chain.servlet.* org.apache.struts.chain.util.* org.apache.struts.config.* org.apache.struts.config.impl.* org.apache.struts.tiles.* org.apache.struts.tiles.actions.* org.apache.struts.tiles.beans.* org.apache.struts.tiles.definition.* org.apache.struts.tiles.xmlDefinition.* org.apache.struts.util.* org.apache.struts.validator.* org.apache.struts.validator.validwhen.* NOTE: Plan on migrating to commons-resources in 1.3 time frame. NOTE: Should end up with a single integrated request processor chain for tiles/nontiles. NOTE: Should end up with request processor chain that works in portlet environment, providing adapters to call 1.x compatible Action methods. (2) addons -- Standard generic add-in functionality Dependencies: core Packages and Classes: org.apache.struts.actions.* org.apache.struts.plugins.* org.apache.struts.upload.* (3) taglib -- Legacy non-EL based tag libraries Dependencies: core Packages and Classes: org.apache.struts.taglib.* (i.e. the TagUtils class) org.apache.struts.taglib.bean.* org.apache.struts.taglib.html.* org.apache.struts.taglib.logic.* org.apache.struts.taglib.nested.* org.apache.struts.taglib.nested.bean.* org.apache.struts.taglib.nested.html.* org.apache.struts.taglib.nested.logic.* NOTE: Generation process for TLDs and associated docs should live here, but the resulting docs will probably need to be imported into site somehow. (4) taglib-el -- Legacy EL-based tag libraries Dependencies: core, taglib Packages and Classes: org.apache.strutsel.taglib.bean.* org.apache.strutsel.taglib.html.* org.apache.strutsel.taglib.logic.* org.apache.strutsel.taglib.tiles.* org.apache.strutsel.taglib.utils.* (5) faces -- Struts-JSF integration Dependencies: core Packages and Classes: org.apache.struts.faces.* org.apache.struts.faces.application.* org.apache.struts.faces.component.* org.apache.struts.faces.renderer.* org.apache.struts.faces.tagib.* org.apache.struts.faces.util.* NOTE: The only components that should be included are those that have direct analogs to legacy Struts tags (to easy conversion). General purpose JSF components (if any) should go elsewhere. (6) examples -- Example Struts-based web applicatons All the existing example applications from core, tiles, struts-el, struts-chain, struts-faces, ... *except* documentation, which gets subsumed into the site module. May need to make sub-modules here; remains to be seen. (7) site -- Struts web site source Dependencies: None. All the usual xdocs stuff to create our website and the associated documentation. WDYT? I'd like to take advantage of the fact that I've got a modicum of
Re: Repository Reorg (Once More With Feeling)
A few comments: 1) I don't consider Tiles to be core Struts functionality at all, and would very much prefer to see it be its own module, or another part of 'addons'. Note that we've had numerous requests to make Tiles available unbundled from Struts, and in his session at JavaOne, David Geary explained how to use Tiles with JSF and without Struts. Plenty of people are building Struts apps without using Tiles, too, emphasising the fact that it really isn't core functionality. 2) Is this presuming a change of Servlet / JSP version dependencies? Otherwise I'm not sure how feasible it would be to move 'upload' to 'addons', because of all the wrapping and unwrapping we have to do for Servlet 2.2 compatibility. 3) This kind of repackaging seems fairly drastic as part of a point release, since it will affect how people download and build their Struts apps. But if everyone else is OK with that, I won't object. 4) This would probably need to wait for 2.x, but I'd like to get away from the 'strutsel' in the taglibs-el package name, and have it be perhaps 'struts.el' instead, so that all of Struts is in 'org.apache.struts'. More consistent, and easier for log config as well. 5) I'd like us to find some kind of plugin mechanism for the web site, so that the non-core modules had add their piece to the main site without a lot of dependencies. Not sure how that would work, off the top of my head, but I think it would be a good goal. 6) I'm not against moving to Maven, but I would like to note that if we put the same energy into improving the existing build system, instead of switching to a new one, the one we have wouldn't be as hard to use as people seem to feel it is... 7) I think we need a better term than 'module', since that's already taken in the context of Struts apps. ;-) -- Martin Cooper On Sat, 17 Jul 2004 14:56:45 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: Here's another crack at trying to get us moving forwards on the repository reorg. Given the feedback of our most recent discussions, I'd like to focus on the following motivations for a particular decision on the organization of the repository, followed by what seems to make sense based on those motivations: * Use Subversion for the new repository (I've played enough to be sold). * Use Maven 1.0 for the build tool (we need to deal with persistent user complaints about complexity of our build process, plus enable independent module releases gracefully). * In general, follow Maven's recommendations for directory layout on multi-module builds. * Continue to build 1.2.x releases off the old (jakarta-struts) repository (taking the time pressure off on getting the new architecture perfect the first time). * Focus the new repository on supporting 1.3.x development (generally backwards compatibile, but using chain-based request processor, adding support for portlet), in prep for later migration to 2.x.x development (which might end up in either separate modules or a separate repository -- too early to tell at this point). * Separate modules for independently releaseable artifacts. * Modules can depend on each other (i.e. pretty much all will depend on core), but we should exercise caution if the dependency tree gets deep ... complexity lurks here. * The core module should have no view tier dependencies. * There is no need for a separate JSP-specific module for TagUtils. That class is tightly coupled to the legacy tag libraries, so it should go in the same module. * We'll need to do some minor refactoring to optimize things after the rearrangement, but that shouldn't delay getting started. * Each module (of course) includes its appropriate complement of unit tests. Given the above, here's my suggestion for the top-level modules in the initial repository, and the packages and classes that should be included there: (1) core -- Core Framework Dependencies: commons-beanutils commons-chain commons-digester commons-fileupload commons-logging commons-resources (once graduated) commons-validator jakarta-oro (inherited from commons-validator) Packages and Classes: org.apache.struts.Globals org.apache.struts.action.* org.apache.struts.chain.* org.apache.struts.chain.legacy.* org.apache.struts.chain.portlet.* (to be created) org.apache.struts.chain.servlet.* org.apache.struts.chain.util.* org.apache.struts.config.* org.apache.struts.config.impl.* org.apache.struts.tiles.* org.apache.struts.tiles.actions.* org.apache.struts.tiles.beans.* org.apache.struts.tiles.definition.* org.apache.struts.tiles.xmlDefinition.* org.apache.struts.util.* org.apache.struts.validator.* org.apache.struts.validator.validwhen.* NOTE: Plan on migrating to commons-resources in 1.3 time frame. NOTE: Should end up with a single integrated request processor chain for tiles/nontiles. NOTE: Should end up with request processor chain that works in portlet environment, providing
Re: Repository Reorg (Once More With Feeling)
Craig McClanahan wrote: * Focus the new repository on supporting 1.3.x development (generally backwards compatibile, but using chain-based request processor, adding support for portlet), in prep for later migration to 2.x.x development (which might end up in either separate modules or a separate repository -- too early to tell at this point). I think there should be support for RiA and SoA in the new request processor, which is what the chain enables. Not many new HTML/HTTP apps will be constructed in '05 to be operated in '06, '07. So one could get a SOAP or similar type request and not have to refactor. I think that should be the main goal, have it work with RiA/SoA 1st and then look for a way how to make it backaward compatiable and support legacy html/html apps (since that is well known how those work). At worst, make an interface or mechanisam so that people can implement a protocol. (Also perform() got removed and Struts is still to mark beans and logic for depecation. And it be nice that a nightly build ships with a sample chain. And ... what happend to 1.2.1 as far as a download link from an html page with due note as to release level (red/yellow/orange)). .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
