Re: [s2] XWork2 release plan
> > Although the train stops in Aachen, I fear I will > not > > join you there, as Rainer and me will go together > by > > car . But I'm sure we find some time & place in > > Antwerp :) > > Well, you have not that far from aachen to Antwerp. > I personally > efer sipping tasty Weizen in Bordbistro while > watching jammed > A3 whooshing at 300 kph ;) We'll make a call to the train station telling them there's a bomb on the track somewhere - that should keep you stalled for a couple of hours while we enjoy some delicious beer in a pub in Antwerp - smartass ;-) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=49702&messageID=103495#103495 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts + EJB
First of your are posting on the wrong mailing list. you should use the user mailing list see link. This mailing list is for developers who are developing within struts, not for developers who are using struts. http://struts.apache.org/mail.html To answer you question I did a bit of google and found this tutorial. integrating struts ejb in combination with x-doclet. http://www.laliluna.de/integration-struts-ejb-tutorial.html http://www.google.nl/search?hl=nl&hs=vWW&client=firefox-a&rls=org.mozilla:nl:official&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=struts+ejb+integration&spell=1 integrating ejb in struts web app is noting different as using EJB in a standard JSP web app. Maybe it is use full to start off with a EJB tutorial. Best regards and good luck, Mark Bakker On 11/24/06, samhr <[EMAIL PROTECTED]> wrote: Hi, Am new to Struts, currently am creating an application using Struts and EJB. I dont know how to connect the Struts with EJB component. Can someone pls help me? I searched for samples online, but am not able to understand them. Does anyone has a sample code to integrate both of them, with explanation? Looking forward for an answer Thanks in advance -- View this message in context: http://www.nabble.com/Struts-%2B-EJB-tf2695707.html#a7517679 Sent from the Struts - Dev mailing list archive at Nabble.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]
help me to configure the Struts 2.0..in tomcat
Hi.. Please help me to configure the Appache Struts 2.0.. It has contained multiple Jar files. So. If u know...Tel abt follow am menshioned... And my Main Requirement is to use jdk1.4 ver. With Struts 2.0 Is this possible...? if possible... Please Help me how to configure and use in Tomcat Webserver.. -- View this message in context: http://www.nabble.com/struts-2.0.1-sample-portlet-app-tf2682160.html#a7526085 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help me to configure the Struts 2.0..in tomcat
Please ask these types of questions on the user list. http://struts.apache.org/mail.html Thanks Niall On 11/24/06, Antony <[EMAIL PROTECTED]> wrote: Hi.. Please help me to configure the Appache Struts 2.0.. It has contained multiple Jar files. So. If u know...Tel abt follow am menshioned... And my Main Requirement is to use jdk1.4 ver. With Struts 2.0 Is this possible...? if possible... Please Help me how to configure and use in Tomcat Webserver.. -- View this message in context: http://www.nabble.com/struts-2.0.1-sample-portlet-app-tf2682160.html#a7526085 Sent from the Struts - Dev mailing list archive at Nabble.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: [s2] XWork2 release plan
Lmao ;-D Philip Luppens <[EMAIL PROTECTED]> wrote: > > Although the train stops in Aachen, I fear I will > not > > join you there, as Rainer and me will go together > by > > car . But I'm sure we find some time & place in > > Antwerp :) > > Well, you have not that far from aachen to Antwerp. > I personally > efer sipping tasty Weizen in Bordbistro while > watching jammed > A3 whooshing at 300 kph ;) We'll make a call to the train station telling them there's a bomb on the track somewhere - that should keep you stalled for a couple of hours while we enjoy some delicious beer in a pub in Antwerp - smartass ;-) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=49702&messageID=103495#103495 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
When we invented the Commons, it was not our intention to exclude "web components". If we had even suggested such a thing, I doubt that the Jakarta PMC would have approved our proposal. At the time, we took the notion that ASF projects were suppose to be tied to HTTPD very seriously. Of course, since then, we added many top-level projects that have little to do with HTTPD. But, that shouldn't mean web components have suddenly become second-class citizens. I believe that the phrase "server-related" in the charter is meant to include web servers. Unless and until the Jakarta Commons PMC rejects a proposal from the Tiles group, I consider it to be a valid alternative to be explored, and until it's been fully explored, I will consider the proposal to create a Struts Tiles subproject premature. Others may think differently, but I am entitled (and even obliged) to define what it is required to obtain my vote. (The vote need not be unanimous, but only a 3/4 majority of the PMC.) As it stands, the ASF's preferred unit of release is the TLP. If the Tiles group is not ready to become a TLP, and unwilling to even try and join the Commons, then I would suggest that Tiles is not ready to "graduate". A third alternative (aside from an independant project) would be to bring Tiles back into the Struts 2 subproject as part of the Tiles plugin. If other projects want to use Tiles, they could just grab the tiles-plugin.jar and import the appropriate packages. Rather than fuss with a separate project or subproject, we could document how to use the Tiles JAR outside of the Struts 2 environment. If volunteers from other projects begin to contribute to Tiles, and want to *build* Tiles without importing the s2 core, then the Tiles group could then apply for TLP status, either to the board or though the Incubator. In the meantime, we could continue to handle Tiles matters on the mailing lists, just as we would for any plugin (or subproject). In any event, if it would be helpful, I see no reason why we can't create tagged builds of Tiles. A build is not a release, regardless of whether we call it a "nightly", "snapshot", or "test". -Ted. On 11/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote: On 11/23/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > I'd like to see the proposal discuss the alternatives to becoming a > Struts subproject. A good role for a proposal is to summarize various > threads. Becoming a subproject seems to be a foregone conclusion of > the proposal, with no discussion of the alternatives. Well, yeah, that's what is being _proposed_. We did discuss the options on the mailing list, more than once, and came to the conclusion that becoming a Struts sub-project was the right interim step. I don't see that we need to have the discussion all over again just because the proposal has been put on the wiki. In previous threads, Jakarta was mentioned, but not so much the > Jakarta Commons. Why is it that we are not proposing to move Tiles to > the Commons, as we did with the Validator, and others? Sigh. We've had this discussion _lots_ of times already, and we've had similar discussions over in Commons. Jakarta Commons is not about web components, and people do not want it to be about web components, which is why the notion of Jakarta Web Components has been bandied about so much. Validator makes sense in Commons because it's not tied to the web; the part that does tie to the web is in Struts, not Validator. I, for one, would not want to propose Tiles as a Commons component, because I'm almost certain it would be rejected, and because I would vote against that myself. Also, Tiles might be able to become a TLP by resolution of the board. > The situation is not much different than Shale. The incubator is > charged with "acceptance and oversight of new products submitted or > proposed to become part of the Foundation". Tiles is already part of > the foundation. Yes, Tiles might be able to become a TLP, but it is my perception that the people involved are not ready for that. It behooves us to provide better options than either staying in the sandbox or going straight to TLP. That you bring up Shale is interesting; note that we went through exactly the same process with Shale as we are now proposing for Tiles. Shale went from the sandbox to a Struts sub-project first. Only later, once it found its feet as a sub-project, did it go off to TLP land. Speaking of the Incubator, we might also note that Incubator podlings > do have releases. > > Even without quantifying it as a "release", given the usual release > plan, Tiles could still create a tagged test-build. Before deciding > whether Tiles should be a subproject or not, I think I'd like to see > the volunteers create a test-build that could be a release if the PMC > gave the nod. Why would we introduce a new rule for Tiles that we have never imposed on other projects coming out of the sandbox? Moving a code branch out the sandbox is a trivial task. What's not
Re: [tiles2] tiles-documentation/showcase app
On 11/24/06, Antonio Petrelli <[EMAIL PROTECTED]> wrote: But the documentation app is, in fact, a showcase, except of some static docs (that can be moved to xdocs), so from my POV it is easier to adapt it to be showcase than to create a new showcase app from scratch. Tiles isn't that big, one example app (not documentation) should be plenty. There's no reason to keep the tests separate-- in fact the showcase app itself will need tests. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
If tiles can achieve the critical mass to become a TLP then IMO that would be the best solution - at this point it looks at least a couple of devs short of that. In the meantime its question of "where can it do its growing?". Commons makes less sense to me than staying here since theres definetly already a community here interested in Tiles - in Commons we don't know how interested the community would be and I doubt it would ever match here. Add to that the fact that the 3 interested developers are already Struts developers - but not Commons developers and the fact that tiles resources (repository & bugs) are already here staying here for the time being looks like the best option. I can only think of reasons why it would be better for tiles to remain in Struts rather than Commons. If there is a case for moving tiles to Commons, then its yet to be made for me. Making it a Struts2 sub-project seems like a backward step - what would have been the point of emarking on a "standalone tiles" if the end result is for it to just move from being part of Struts1 to part of Strus2? Again if there are the benefits of doing this then they need to be laid out. I really can't see the point of making alternative suggestions without making the case for them. I can see benefts for tiles being (temporarily) a Struts sub-project - theres an interested community here - the active developers are here - the other developers here all know what tiles is about (to varying degrees) - theres a PMC that knows the software ...and unless someone else makes a better case for an alternative then thats the best option IMO Niall On 11/24/06, Ted Husted <[EMAIL PROTECTED]> wrote: When we invented the Commons, it was not our intention to exclude "web components". If we had even suggested such a thing, I doubt that the Jakarta PMC would have approved our proposal. At the time, we took the notion that ASF projects were suppose to be tied to HTTPD very seriously. Of course, since then, we added many top-level projects that have little to do with HTTPD. But, that shouldn't mean web components have suddenly become second-class citizens. I believe that the phrase "server-related" in the charter is meant to include web servers. Unless and until the Jakarta Commons PMC rejects a proposal from the Tiles group, I consider it to be a valid alternative to be explored, and until it's been fully explored, I will consider the proposal to create a Struts Tiles subproject premature. Others may think differently, but I am entitled (and even obliged) to define what it is required to obtain my vote. (The vote need not be unanimous, but only a 3/4 majority of the PMC.) As it stands, the ASF's preferred unit of release is the TLP. If the Tiles group is not ready to become a TLP, and unwilling to even try and join the Commons, then I would suggest that Tiles is not ready to "graduate". A third alternative (aside from an independant project) would be to bring Tiles back into the Struts 2 subproject as part of the Tiles plugin. If other projects want to use Tiles, they could just grab the tiles-plugin.jar and import the appropriate packages. Rather than fuss with a separate project or subproject, we could document how to use the Tiles JAR outside of the Struts 2 environment. If volunteers from other projects begin to contribute to Tiles, and want to *build* Tiles without importing the s2 core, then the Tiles group could then apply for TLP status, either to the board or though the Incubator. In the meantime, we could continue to handle Tiles matters on the mailing lists, just as we would for any plugin (or subproject). In any event, if it would be helpful, I see no reason why we can't create tagged builds of Tiles. A build is not a release, regardless of whether we call it a "nightly", "snapshot", or "test". -Ted. On 11/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > On 11/23/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > > > I'd like to see the proposal discuss the alternatives to becoming a > > Struts subproject. A good role for a proposal is to summarize various > > threads. Becoming a subproject seems to be a foregone conclusion of > > the proposal, with no discussion of the alternatives. > > > Well, yeah, that's what is being _proposed_. We did discuss the options on > the mailing list, more than once, and came to the conclusion that becoming a > Struts sub-project was the right interim step. I don't see that we need to > have the discussion all over again just because the proposal has been put on > the wiki. > > In previous threads, Jakarta was mentioned, but not so much the > > Jakarta Commons. Why is it that we are not proposing to move Tiles to > > the Commons, as we did with the Validator, and others? > > > Sigh. We've had this discussion _lots_ of times already, and we've had > similar discussions over in Commons. Jakarta Commons is not about web > components, and people do not want it to be about web components, which is > why the noti
Struts with non-struts pages.
Hi, I currently have a pure struts application, to which I need to add new features/functionality, which I believe can't be handled by struts. The new JSP pages which I'm creating will consist of dynamic form elements (which means i won't know their names until it's created dynamically by taglibs), which means i can't use standard ActionForm objects to have it handled by struts. Hence, I'm thinking of having two different controllers - One derived from ActionServlet, and another derived from HttpServlet - for taking care of new dynamic pages. Based on the URL thats invoked, the appropriate controllers is invoked. I'm not thinking of using the ActionServlet controller because this brings Struts in scope, and is of no use to my new pages. I'm not very well happy with the multiple controller idea here. Is there a way Struts can integrate well with non-Struts pages? Has anybody worked on such cases? Please let me know. Thanks, -- Anish. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=51336&messageID=103567#103567 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts with non-struts pages.
Please ask these types of questions on the user list. http://struts.apache.org/mail.html To give you some remarks. 1. first Struts can handle dynamic form inputs look at DynaActionForm, and DynaActionFormClass 2. second if you want to use something else just use it. Struts will only react on *.do stuff unless you have configured it differently. So if you create a JSP let say /jsp/helloworld.jsp you can find it on the tomcat server at http://www.localhost:8080/jsp/helloworld.jsp Thanks On 11/24/06, Jikes2005 <[EMAIL PROTECTED]> wrote: Hi, I currently have a pure struts application, to which I need to add new features/functionality, which I believe can't be handled by struts. The new JSP pages which I'm creating will consist of dynamic form elements (which means i won't know their names until it's created dynamically by taglibs), which means i can't use standard ActionForm objects to have it handled by struts. Hence, I'm thinking of having two different controllers - One derived from ActionServlet, and another derived from HttpServlet - for taking care of new dynamic pages. Based on the URL thats invoked, the appropriate controllers is invoked. I'm not thinking of using the ActionServlet controller because this brings Struts in scope, and is of no use to my new pages. I'm not very well happy with the multiple controller idea here. Is there a way Struts can integrate well with non-Struts pages? Has anybody worked on such cases? Please let me know. Thanks, -- Anish. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=51336&messageID=103567#103567 - 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: [s2] XWork2 release plan
> We'll make a call to the train station telling them > there's a bomb on the track somewhere - that should > keep you stalled for a couple of hours while we enjoy > some delicious beer in a pub in Antwerp - smartass ;-) You know, that by day I'm fixing webservices in for a company with strange affinity to color known as "RAL 4010" ( #BF1773) - so calling by phone is really not an option for you ;) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=49702&messageID=103573#103573 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
Antonio Petrelli wrote: David H. DeWolf ha scritto: Please find the Tiles2 graduation proposal draft below. I look forward to your feedback . . . For the record, +1 Myself :) +1, but I think that also Wendy should be put as an active participant, since she helped us with Maven, gave a lot of useful suggestions and made tests. Sure, the original thought was to document the fact that we meet quota, not to exclude anyone. . . the more the merrier. Ciao Antonio - 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: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
I know I might miss the struts2 release, but I'm going to let this sit at least another day or two since some people haven't had a ton of time to chime in and because of the US holiday this week. . . David David H. DeWolf wrote: Please find the Tiles2 graduation proposal draft below. I look forward to your feedback . . . http://cwiki.apache.org/confluence/display/S2WIKI/Tiles2+Graduation+Proposal David Martin Cooper wrote: Just write up a brief proposal that we can discuss, maybe on the wiki, as Wendy suggested. Once we have that, we can bounce the idea around a bit and then vote on it. IMO, it would be a good idea to include in the proposal a bit about a Struts sub-project not being the intended final home for Tiles but rather an intermediate step in the process of growing up. You could mention options for a final home, but I personally don't feel that we need to decide on that right now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
For the sake of documentation, I'll go ahead and take some of these (and Ted's) points regarding where to go upon graduation and post them to the wiki. Thanks everyone for your continued input. . . David Niall Pemberton wrote: If tiles can achieve the critical mass to become a TLP then IMO that would be the best solution - at this point it looks at least a couple of devs short of that. In the meantime its question of "where can it do its growing?". Commons makes less sense to me than staying here since theres definetly already a community here interested in Tiles - in Commons we don't know how interested the community would be and I doubt it would ever match here. Add to that the fact that the 3 interested developers are already Struts developers - but not Commons developers and the fact that tiles resources (repository & bugs) are already here staying here for the time being looks like the best option. I can only think of reasons why it would be better for tiles to remain in Struts rather than Commons. If there is a case for moving tiles to Commons, then its yet to be made for me. Making it a Struts2 sub-project seems like a backward step - what would have been the point of emarking on a "standalone tiles" if the end result is for it to just move from being part of Struts1 to part of Strus2? Again if there are the benefits of doing this then they need to be laid out. I really can't see the point of making alternative suggestions without making the case for them. I can see benefts for tiles being (temporarily) a Struts sub-project - theres an interested community here - the active developers are here - the other developers here all know what tiles is about (to varying degrees) - theres a PMC that knows the software ...and unless someone else makes a better case for an alternative then thats the best option IMO Niall On 11/24/06, Ted Husted <[EMAIL PROTECTED]> wrote: When we invented the Commons, it was not our intention to exclude "web components". If we had even suggested such a thing, I doubt that the Jakarta PMC would have approved our proposal. At the time, we took the notion that ASF projects were suppose to be tied to HTTPD very seriously. Of course, since then, we added many top-level projects that have little to do with HTTPD. But, that shouldn't mean web components have suddenly become second-class citizens. I believe that the phrase "server-related" in the charter is meant to include web servers. Unless and until the Jakarta Commons PMC rejects a proposal from the Tiles group, I consider it to be a valid alternative to be explored, and until it's been fully explored, I will consider the proposal to create a Struts Tiles subproject premature. Others may think differently, but I am entitled (and even obliged) to define what it is required to obtain my vote. (The vote need not be unanimous, but only a 3/4 majority of the PMC.) As it stands, the ASF's preferred unit of release is the TLP. If the Tiles group is not ready to become a TLP, and unwilling to even try and join the Commons, then I would suggest that Tiles is not ready to "graduate". A third alternative (aside from an independant project) would be to bring Tiles back into the Struts 2 subproject as part of the Tiles plugin. If other projects want to use Tiles, they could just grab the tiles-plugin.jar and import the appropriate packages. Rather than fuss with a separate project or subproject, we could document how to use the Tiles JAR outside of the Struts 2 environment. If volunteers from other projects begin to contribute to Tiles, and want to *build* Tiles without importing the s2 core, then the Tiles group could then apply for TLP status, either to the board or though the Incubator. In the meantime, we could continue to handle Tiles matters on the mailing lists, just as we would for any plugin (or subproject). In any event, if it would be helpful, I see no reason why we can't create tagged builds of Tiles. A build is not a release, regardless of whether we call it a "nightly", "snapshot", or "test". -Ted. On 11/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > On 11/23/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > > > I'd like to see the proposal discuss the alternatives to becoming a > > Struts subproject. A good role for a proposal is to summarize various > > threads. Becoming a subproject seems to be a foregone conclusion of > > the proposal, with no discussion of the alternatives. > > > Well, yeah, that's what is being _proposed_. We did discuss the options on > the mailing list, more than once, and came to the conclusion that becoming a > Struts sub-project was the right interim step. I don't see that we need to > have the discussion all over again just because the proposal has been put on > the wiki. > > In previous threads, Jakarta was mentioned, but not so much the > > Jakarta Commons. Why is it that we are not proposing to move Tiles to > > the Commons, as we did with the Validator, and others?
[s1] Rework Locale Resolution patch
I have attached a patch for new locale work in s1: https://issues.apache.org/struts/browse/STR-2897 Please review and provide comments. Thanks, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
