Re: Dojo plugin deprecated
I don't know, I think Andreas' point has at least some validity... the page he linked to does in fact state: "*First-class AJAX support* - Add interactivity and flexibility with AJAX tags that look and feel just like standard Struts tags." Seems like if that's no longer the case, to whatever extent it's no longer the case, then that line should be removed from that page or modified as necessary, in the interest of honest advertising if nothing else. Just being able to use any AJAX library you wish, as Al correctly states, doesn't by extension mean that S2 has "first-class AJAX support". At least, *I* wouldn't consider it first-class support. What Martin said is of course valid as well: if someone out there wants these tags/plugin to exist, put in the effort. The Struts team has the right to do what they want with the project, and you have the right to not use S2 if it doesn't meet your needs... better still, MAKE IT meet your needs and give back... I think you'll find many people being quite grateful to you for your efforts. Frank -- Frank W. Zammetti Author of "Practical Dojo Projects" and "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" (For info: apress.com/book/search?searchterm=zammetti&act=search) My "look ma, I have a blog too!" blog: zammetti.com/blog Al Sutton wrote: The other thing to remember is that S2 doesn't stop you taking any of the existing AJAX frameworks and using them directly in your JSPs, so it's no like the change has completely barred the use of AJAX functionality. Al. Martin Cooper wrote: Let's be clear about this. * Lots of people think that the Dojo-based AJAX tags would be useful if they worked with the latest versions of Dojo, or some other toolkit. * Few, if any, people want to use them in their current form. * Nobody has stepped up and offered to migrate these tags to anything else, whether that's a newer version of Dojo or another toolkit. So, the short answer is, step up or shut up. We'd be happy to see someone take on this task, but I have had it up to _here_ with people who complain and expect someone else to do the work. -- Martin Cooper On Wed, Jan 14, 2009 at 10:19 PM, Andreas Joseph Krogh wrote: On Wednesday 14 January 2009 23:42:18 Gustave Pheiffers wrote: Thanks for the info. It would be a shame if the easy to use especially the "http://struts.apache.org/2.1.6/index.html). Built-in AJAX-support (first-class AJAX support) is one of the things Struts2 announces as a main-feature, and with the dojo-plugin going away this isn't true any more. This means Struts-2.1 no longer has any decent ui-tags? -- Andreas Joseph Krogh Senior Software Developer / CEO +-+ OfficeNet AS| The most difficult thing in the world is to | Karenslyst Allé 11 | know how to do a thing and to watch | PO. Box 529 Skøyen | somebody else doing it wrong, without | 0214 Oslo | comment.| NORWAY | | Tlf:+47 24 15 38 90 | | Fax:+47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Concerned Strutszien: A Manifesto
dusty wrote: So we get more aggressive with our releases. We definitely want to preserve compatibility but if we have a good reason for breaking compatibility we let people know and show them how to migrate. At the same time we get more aggressive with marketing, by overhauling the website, getting the project blog going, re-organizing the wiki and documentation, getting the source available from Fisheye, maybe even start a conference. Everything but the conference part seems pretty doable. I for one don't think S2 needs any marketing, or a web site overhaul, or any of that sort of thing. I can't think of too many projects that have become a big-time success based on that sort of thing... in fact, JSF is one great counter-example to that theory. Many people got turned off to JSF early because for a long time it was nothing but marketing hype. It basically took people stopping the hype train for a while and actually churning out some half-way decent technology for it to be seen as something more at this point. I think in terms of die-hard Struts developers, there's decent buy-in for S2. I think many Struts developers are migrating to S2 (not necessarily migrating existing apps, but in terms of new development). Where I get the impression there's a shortcoming is in attracting new developers. Assuming that's true, the question should be why that is... why are other frameworks gaining mindshare while S2 maybe isn't (or at least not as fast as it should be given its lineage and Apache branding, which is still a big positive for any project). I think the answer is twofold. First, in terms of what S2 offers, frankly, there's not really a whole lot that truly excites developers. There's nothing revolutionary about it. Some would say that's a positive, and part of me would agree, but when there's so many frameworks to choose from, if you don't have anything that truly differentiates your offering then it's just going to be one more option among many. I think however that there's a really more fundamental problem that isn't S2's fault at all: many new development projects, maybe even most at this point, are (buzzword alert!) Web 2.0 in nature. They are much more client-heavy and just fundamentally work differently than what Struts has historically been used to build (yes, that's a generality to be sure, but I think it is, *generally*, true). If you buy that theory, then you have to reasonably ask what does S2 offer to make developing those types of applications easier? And then when you have an answer to that question you have to compare it to other frameworks that people are using for applications of that nature. Things like ZK, GWT, JSF, Rails, and so on. You can even compare it to using something like Dojo or Ext JS with a more lightweight back-end based on something like DWR. Does S2 give me something tangible compared to those? Does it fundamentally make my job easier, or my application better? If you are unable to articulate really clearly and strongly and in a demonstratable fashion where S2 helps in this regard, then I believe it's a losing proposition. To be sure, there *are* some cool things in S2. What I for one don't see, and I've heard a similar feeling expressed by many as recently as at The Ajax Experience earlier this month, is a clear, coherent vision of how S2 lets me develop these so-called Web 2.0 applications better than any other framework. What is there in S2 to truly excite Web 2.0 developers in S2 as compared to other frameworks? That to me is the fundamental question to be answered, and the fundamental reason S2 doesn't have the uptake many feel it should. I hesitate to put it this way because it seems potentially unfair, but I'll say it anyway: it's almost like S2 is standing on the sidelines while the web development world moves in a fundamentally different direction, and S2 isn't keeping up as well as it needs to in order to be the success S1 was. Please understand I'm not at all being critical of S2 or of anyone involved in it. These are my impressions of things, but they are in part based on conversations I've had with other developers expressing similar thoughts, so I know it's not just me. My hope is that something constructive can come from these comments, and that's certainly my purpose in taking the time to write this reply. Frank -- Frank W. Zammetti Author of "Practical Dojo Projects" and "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" (For info: apress.com/book/search?searchterm=zammetti&act=search) My "look ma, I have a blog too!" blog: zammetti.com/blog Don has been a kind of de-facto leader for
Re: S2 as JSR for Action Framework
Adam Hardy wrote: Frank, do you not use the back button? I reckon I use it from around 5 to 50 times a day. Of course I do... Although I can't say how often because that would imply how much surfing the web I'm doing as opposed to actually working and my boss just *might* read this list some day :) I think the paradigm shift is less a shift and more of a paradigm split. Web2 and javascript-based apps have taken their place (after 10 years finally) at the top of the web food chain. What's the best term? Rich client? That might be a fair way to put it, and this is something I've talked extensively about over the past few years... I tend to use the term web SITE vs. web APP... I talk about that in all of my books actually, and the first one is a few years old. Web SITES are fundamentally different animals than web APPS, and I think the rules are a bit different for their development as well. But Web2 hasn't replaced bog-standard HTML as its version number suggests, it complements it, leaving a big space for low-Javascript clients which just use the barest minimum or no javascript. Yep, I don't disagree with that at all. It's obviously only the former websites which need no back-button, and obviously the latter where the back button is very useful. Hehe, we're pretty much saying the same thing I think :) Maybe W3C has already thought of this - I don't know - and we'll see window.disableHistory appear in the DOM (or something similar) Sure... about the same time they get rid of the and tags :) Regards Adam Frank -- Frank W. Zammetti Author of "Practical Dojo Projects" abd "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" (For info: apress.com/book/search?searchterm=zammetti&act=search) My "look ma, I have a blog too!" blog: zammetti.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
Don Brown wrote: > This is a nice design, when you can do it. GWT is also a good way to > build these types of apps. Unfortunately, they can easily break much > of what makes the web what it is - the back button, unique, > addressable URI's, accessibility, search engine crawling, etc. > It's always interesting how often you hear the "this breaks the web" sorts of statements. I'm not arguing the factuality of the statement, I just find it interesting. It's also interesting the way you put it here... you don't say anything like "this breaks the web", nor do you make a value judgment on it (well, I suppose the word "unfortunately" implies a value judgment, but it's not explicit). I think we're at an interesting point in time right now... many people are kind of mentally stuck in the sense that they see the ways in which RIAs (can) break things like the back button and they think "well, that's bad". But, maybe we shouldn't be asking if RIAs are the way to go, but we should instead be asking different questions like "is the back button as a navigational metaphor something we really want to be perpetuating anyway"? It's kind of like if someone came up with a hydrogen-based fuel system for cars but for some reason (work with me here!) you could never use a cell phone in the car or it'd explode... I don't think we shouldn't at that point be asking if the fuel system is the right answer or not, we should be asking whether the limitation it imposes is something that should factor into the decision at all in the first place. Wouldn't we be better off if you couldn't use cell phones in cars anyway?!? Note that I'm not making a value judgment here either necessarily, although I suspect my opinion is fairly obvious :) I do think we're in the midst of a paradigm shift to a large extent, and I think there's some fascinating consequences of that shift. Frank -- Frank W. Zammetti Author of "Practical Dojo Projects" abd "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" (For info: apress.com/book/search?searchterm=zammetti&act=search) My "look ma, I have a blog too!" blog: zammetti.com/blog > Don > > >> -- >> Martin Cooper >> >> >> This idea of a JSR would be standardizing the third group, but I >> >>> wonder if maybe the better direction to go is not a new API, but build >>> extensions on JAX-RS [2]. To me, this group's niche is apps that need >>> lightweight presentation engines a layer above servlets, but still >>> very much "web-y". JSR 311 aims to make restful resources easy to >>> build, which isn't far from restful web applications. Especially as >>> more and more applications are starting to rely on client-side AJAX >>> interfaces, the need for a solid RESTful backend only gets stronger. >>> The storage of server-side state of the component frameworks becomes >>> less important, and if you don't want the bulk of Grails, this >>> approach may be attractive. >>> >>> For my day job, we need to build REST interfaces to our web apps, so >>> we are looking to standardize on JAX-RS. Well, we also need a >>> lightweight web framework for our plugin system, and if we are already >>> using something like Jersey [3], it would be nice to be able to write >>> web apps using the same technology. This use case is obviously very >>> specific to our situation, but it is the direction I'll likely be >>> taking in the next few months. >>> >>> Don >>> >>> [1] http://www.source-code.biz/MiniTemplator/ >>> [2] https://jsr311.dev.java.net/ >>> [3] https://jersey.dev.java.net/ >>> >>> On Fri, Aug 22, 2008 at 4:31 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: >>> >>>> hi all >>>> >>>> is it possible that S2 become part of JCP? >>>> >>>> java server action framework >>>> >>>> right now only component framework there >>>> >>>> any idea? >>>> >>>> >>>> >>>> -- >>>> -- >>>> Frans Thamura >>>> Meruvian Foundation >>>> >>>> Mobile: +62 855 7888 699 >>>> Linkedin: http://www.linkedin.com/in/fthamura >>>> >>>> Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... >>>> URL: >>>> >>> http://naga
Re: S2 as JSR for Action Framework
Ian Roughley wrote: > Maybe no-one wants to admit it publicly :-) Well, if that were true, it'd be a bigger problem than simply slow adoption rates :) -- Frank W. Zammetti Author of "Practical Dojo Projects" abd "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" (For info: apress.com/book/search?searchterm=zammetti&act=search) My "look ma, I have a blog too!" blog: zammetti.com/blog > Not that it's a particularly good metric, but I always thought the > adoption rates were very slow. However, I'm always surprised how many > companies are using s2 when I speak to people at conferences. Maybe > no-one wants to admit it publicly :-) > /Ian > > James Mitchell wrote: >> That's a hard question to answer. It's probably like politics. >> You'll get completely different answers depending on who you ask. >> >> On Fri, Aug 22, 2008 at 11:11 AM, Musachy Barroso <[EMAIL PROTECTED]> >> wrote: >> >>> That's a good point, and I do have a question myself, how are we doing >>> adoption-wise? Judging from the users mailing list traffic, I would >>> say well. In any case, just better of talking about this on the user >>> list rather than here. >>> >>> musachy >>> >>> On Fri, Aug 22, 2008 at 10:52 AM, James Mitchell >>> <[EMAIL PROTECTED]> wrote: >>> >>>> Let the marketplace decide. >>>> >>>> Just my $0.02 >>>> >>>> On Fri, Aug 22, 2008 at 2:31 AM, Frans Thamura <[EMAIL PROTECTED]> >>>> wrote: >>>> >>>>> hi all >>>>> >>>>> is it possible that S2 become part of JCP? >>>>> >>>>> java server action framework >>>>> >>>>> right now only component framework there >>>>> >>>>> any idea? >>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Frans Thamura >>>>> Meruvian Foundation >>>>> >>>>> Mobile: +62 855 7888 699 >>>>> Linkedin: http://www.linkedin.com/in/fthamura >>>>> >>>>> Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... >>>>> URL: >>>>> http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco >>>>> >>>>> >>>>> - >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>>> >>>> >>>> -- >>>> James Mitchell >>>> >>>> - >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> >>> >>> -- >>> "Hey you! Would you help me to carry the stone?" Pink Floyd >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> >> >> > > > > __ Information from ESET Smart Security, version of virus > signature database 3380 (20080822) __ > > The message was checked by ESET Smart Security. > > http://www.eset.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Deprecate or remove Dojo plugin
So, essentially, the suggestion is this: http://wiki.apache.org/struts/AjaxStruts ...but expanded a lot :) Frank -- Frank W. Zammetti Author of "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" for info: apress.com/book/search?searchterm=zammetti&act=search Java Web Parts - javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! My "look ma, I have a blog too!" blog: zammetti.com/blog Struts Two wrote: Though I am not a struts 2 developer but I personally love Dave idea. I have now swtiched using dojo 1.1.1 and I had to write my own scripts to simiulate some of struts 2 tags [though not as neat as those tags]. With the information there, people can build on it and share it with others as well. - Original Message From: Dave Newton <[EMAIL PROTECTED]> To: Struts Developers List Sent: Friday, July 25, 2008 9:38:37 AM Subject: Re: [PROPOSAL] Deprecate or remove Dojo plugin I was thinking about all this last night. One thing that might be useful is to provide enough information to implement existing tags in raw Dojo/JavaScript--there's enough being done by the S2 components/tags that it might throw a lot of people off to write it by hand. Sort of a migration guide. Dave __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ - 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] Deprecate or remove Dojo plugin
I think that ignores the underlying complexity of developing complex
RIAs today. I would take any of the apps I've developed on the job over
the past 5+ years and put them up against any out there in terms of
complexity... when I talk to other developers about what they're doing
it's nearly always the case that what they describe is orders of
magnitude less complex than some of the project I've been involved in.
And all the while I've had to mentor teams to get them up to speed so
they could develop these applications with me. I'm not saying any of
that to try and be impressive, I'm saying that so I can then say this:
the paradigm shift of doing heavy client-side AJAX-based RIA development
when you are used to doing the "classic" server-heavy model of web
development isn't as simple as choosing a good library and doing some
simple calls as you show. Things just aren't that simple once you move
beyond "level 1", so to speak :)
Now, I suppose you could say that then a taglib approach is quickly
going to become not up to the task either, which I'd agree with. You
could further say that if that's the case, why not just start by
learning a good library and forget about tags. There's some degree of
correctness in that I think. But I've seen it time and time again: good
Java developers who transition to a client-side model just seem to have
trouble "getting it", and whether you use tags or a library directly it
doesn't seem to matter. Things that I, and I suspect you, would take
for granted seem difficult for them to comprehend... things like
following the applications' flow when things are moving from server to
client, timing issues, dealing with security, not to mention the still
less-than-optimal debugging capabilities available.
But what I've *also* seen time and time again is that a tag-based
approached is easier for them to wrap their brains around initially than
using a library directly because it's closer to what they already know.
Think about all you're taking for granted when you write
$("#content).load(url); ... you assume they know about the DOM, that
they understand the concept of a URL's response not overwriting the
entire page... and what does that call look like when you have to deal
with error callbacks? And timeout conditions? And security
constraints? Is it still as simple as just that? If so then jQuery is
more than good, it's freakin' miraclulous!
Having a taglib, at least initially, that keeps those details away from
them is a good thing... yes, they'll quickly outgrow them, but then
they'll quickly come to the point you're at and want to use the
libraries directly, and will at that point no longer be the huge mental
leap that it was at the start.
Frank
--
Frank W. Zammetti
Author of "Practical DWR 2 Projects"
and "Practical JavaScript, DOM Scripting and Ajax Projects"
and "Practical Ajax Projects With Java Technology"
for info: apress.com/book/search?searchterm=zammetti&act=search
Java Web Parts - javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
My "look ma, I have a blog too!" blog: zammetti.com/blog
Bob Tiernay wrote:
Having a simple taglib-based approach to do some of the more common
AJAX-y things, maybe some widgets here and there too, means that Java
developers can leverage their existing skills without having to take
the plunge into heavy client-side development, which I can say from
the experience of mentoring some junior-level teams can be a very
difficult hill to climb, regardless of what whiz-bang library you
choose to use to try and make it easier. The very nature of
Javascript, for many Java developers, is a difficult leap to make.
Today's whiz-bang libraries make things dead simple to perform ajax
requests. For instance, with jQuery to get the contents of a url and
place it in a div element #content:
$("#content).load(url);
I guess I fail to see how even junior-level team members would have a
difficult learning curve with this. Learning jQuery quickly is easy
to do and is much of the appeal.
And as others have mentioned, the libraries such as jQuery have a
great user base, with much to offer in terms of support. Just
checkout the #jquery freenode irc channel, for instance.
Part of being a developer is learning new technologies, and if those
technologies are easy to use and powerful, then that's where the ROI
really pays off. We should be nudging people in these directions with
better documentation on how to best integrate with existing libraries.
This would be a far better place to focus energy, imo.
Bob
-
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] Deprecate or remove Dojo plugin
As you could probably guess, I've had a lot of success with AjaxParts Taglib ;) I've also had a lot of success with Dojo, ExtJS, ActiveWidgets, dHTMLx and my personal favorite, DWR (I've found that DWR, plus best-of-breed widgets is all the "framework" I need, which is why I haven't posted here much lately, I haven't touched Struts in over a year myself). (As to Dojo's popularity... well, it's definitely not a "de facto" anything, that's for sure. May be some day, but not yet. Like Ted, I find that as much as Dojo gets talked about, I don't hear from as many people using it as the "press", so to speak, would suggest. It certainly *is* popular, no question about that, but it seems like other libraries, most notably jQuery, have kind of eclipsed it as the "place to be" in terms of client-side libraries.) Not to toot my own horn or anything... but, what the heck :) ... speaking as someone who pioneered the whole "AJAX via taglib" approach (if it wasn't first, it was definitely *one of* the first, but for those that maybe haven't been around Struts as long as others, AjaxParts Taglib, or APT, was originally an enhanced version of the S1 HTML taglib that I created in early 2005)... I have a strong opinion that it's a good approach for many users. Having a simple taglib-based approach to do some of the more common AJAX-y things, maybe some widgets here and there too, means that Java developers can leverage their existing skills without having to take the plunge into heavy client-side development, which I can say from the experience of mentoring some junior-level teams can be a very difficult hill to climb, regardless of what whiz-bang library you choose to use to try and make it easier. The very nature of Javascript, for many Java developers, is a difficult leap to make. If the question is should the plugin be deprecated *without a replacement ready day one*, my opinion is that's a bad idea. Whether the current plugin is the right answer or not, I think it's better than nothing. Especially for those developers who aren't ready to make the leap to heavy client-side coding as many of us have done, a taglib-based approach is a godsend. I know this because while APT may not have the largest user community around, we have a very happy community, based on the feedback we get. Clearly the tag-based approach is something many developers very much want and like, and it's something that I think is a pretty attractive feature of S2. Losing it, even temporarily, would hurt I think, if in no other way than perception. Even if there's no one ready, willing and able to do the work to address the shortcomings of the plugin, I don't think that's a reason to deprecate it. It may be fair to update some documentation to say something along the lines of "use at your own risk", whatever text reflects the true state of it, but beyond that I think it would be a step backwards for Struts, if in no other way than perception, to lose this capability, even if only briefly. Frank P.S. - Ted, I see you're doing your TAE presentation again this year... I'll be attending again as well (although my proposal didn't get picked up, maybe next year), hope we can hook up at some point. Anyone else going to be in town? -- Frank W. Zammetti Author of "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" for info: apress.com/book/search?searchterm=zammetti&act=search Java Web Parts - javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! My "look ma, I have a blog too!" blog: zammetti.com/blog Ted Husted wrote: +1 for Musachy's suggestion, and I'm also at a point where I could help with the implementation. As to Ajax-enabling some of the tags, there are several tag-based Ajax libraries out there that we could look at embedding or emulating. In this case, we wouldn't be adopting a general-purpose Ajax library, but special-purpose scripts designed to be used with tags. * Ajax Tags - http://ajaxtags.sourceforge.net * Prize Tags - http://jenkov.com/prizetags/index.html * JSON-taglib - http://json-taglib.sourceforge.net/ * AjaxParts Taglib - http://javawebparts.sourceforge.net/ Has anyone had good or bad experiences with tag-based libraries like these? -Ted. On Mon, Jul 21, 2008 at 11:33 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote: I am not sure about that approach. On one hand it is very "strutsish", in that is supports many ways of doing the same thing, and provides ways to extend what is provided, on the other hand, I think we should learn from other frameworks and just don't give users that many
RE: [OT] Re: environment awareness (project stage in JSF)
I'd contend that once you hit QA it's an admin's job to point to an appropriate DB server for instance, not a dev's (although the devs will clearly have a say)... However, none of this should be built into the EAR and therefore can be changed in any environment without the EAR itself changing. Frank -Original Message- From: Al Sutton <[EMAIL PROTECTED]> Sent: Sunday, June 29, 2008 9:06 AM To: Struts Developers List Subject: Re: [OT] Re: environment awareness (project stage in JSF) Then the questoin becomes "Hows does the developer create a configuration set when the application is released which uses the database server which is chosen by the tech support team when things start going wrong at a later date?" Al. Dave Newton wrote: > --- On Sun, 6/29/08, Al Sutton <[EMAIL PROTECTED]> wrote: > >> If the techies at DR just had a "dev, test, or prod" >> switch how could they have done that? >> > > How could they do it if they had to change code? > > Complex environments require complex configuration management; I'm not sure > how the example contraindicates that. > > Lots of environments (even my non-Orbitz-scale ones) require more > configurability than "dev, test, prod", although they can be useful > shorthands for configuration sets. > > Dave > > > - > 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: [OT] Re: environment awareness (project stage in JSF)
>>> and much more in different environments. >>> >>> -bp >>> >>> >>> On Jun 28, 2008, at 4:56 AM, Al Sutton wrote: >>> >>>> I think the concept is an idea which will appeal to lazy developers. >>>> >>>> Why on earth would you want to put conditionals into your code that >>>> you know will only evaluate to a set value in the environment they >>>> run in? >>>> >>>> If anything it makes problems harder to track down because if >>>> someone takes a copy of the app from a production machine to a dev >>>> machine to further investigate a problem it will behave >>>> differently, which is just a hiding to nowhere in multi-threaded >>>> apps such as S2 webapps. >>>> >>>> An example of one of the "joys" that can come from this type of >>>> idea came from a project I worked on where a coder used log4j and >>>> isDebug to conditionally build a log string and log some extra >>>> data. This might be seen as a good idea, except the code within the >>>> conditional block didn't properly check all the objects were not >>>> null and under certain functionally valid conditions an NPE was >>>> thrown, so when a problem arose in production at a customers site >>>> they were asked to turn debug logging on and all that they sent >>>> back was a log with an number of NPEs which didn't relate to the >>>> original problem. >>>> >>>> Ohhh the fun we had explaining that a new release had to go through >>>> their change (long) control procedure just so we could find out >>>> what the original problem was and until that we we're kind of >>>> stuffed finding out what in their environment triggered the problem. >>>> >>>> Yes in an ideal world it shouldn't have happened. Yes it probably >>>> should have been picked up by some QA test somewhere. But don't we >>>> all live in the real world? >>>> >>>> Al. >>>> >>>> >>>> >>>> Chris Pratt wrote: >>>>> We use something similar in our system. The system uses a bunch of >>>>> resource bundles that are separated into logical domains, and each >>>>> entry can be overridden by a local file on each machine. Plus each >>>>> entry can be scoped by environment (production, test, development), >>>>> machine, or application name (in case multiple applications are >>>>> sharing a library component). We have log4j and spring >>>>> configurers so >>>>> that it is tightly integrated into the tools we use. It's saved >>>>> us an >>>>> eternity of time tracking down bugs from one environment to the next >>>>> since we deploy the same WAR file that was accepted by the quality >>>>> assurance group into production and let the configuration take >>>>> care of >>>>> itself. >>>>> >>>>> I've often thought of creating a Google Code project to open source >>>>> it, but wasn't sure if there would be enough interest. >>>>> (*Chris*) >>>>> >>>>> On Fri, Jun 27, 2008 at 1:38 PM, Brian Pontarelli >>>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>>> Yeah, I found that environment resolution was a key feature for >>>>>> any large >>>>>> application. At Orbitz we could deploy the same bundle to any >>>>>> server and the >>>>>> bundle would figure out where it was and configure itself for that >>>>>> environment. Worked really well. >>>>>> >>>>>> I have also provided this type of feature in JCatapult using an >>>>>> API that can >>>>>> be implemented however developers need. The default >>>>>> implementation uses >>>>>> JNDI, but it is simple to change it. The nice thing about that is >>>>>> you can >>>>>> assume at all times that the environment is available and make >>>>>> assumptions >>>>>> around that. >>>>>> >>>>>> -bp >>>>>> >>>>>> On Jun 27, 2008, at 1:53 PM, Frank W. Zammetti wrote: >>>>>> >>>>>> >>>>>>> We d something similar as well, but we decided to use a simple >>>>>>> env var in >>>>>>> all environments... So the exact same EAR can deploy to any >>>>>>> environment and >>>>>>> the code within simply looks for that var and acts accordingly. >>>>>>> Simple but >>>>>>> highly effective. >>>>>>> >>>>>>> Frank >>>>>>> >>>>>>> -Original Message- >>>>>>> From: Ian Roughley <[EMAIL PROTECTED]> >>>>>>> Sent: Friday, June 27, 2008 2:59 PM >>>>>>> To: Struts Developers List >>>>>>> Subject: Re: environment awareness (project stage in JSF) >>>>>>> >>>>>>> I've actually had to implement this type of feature in multiple >>>>>>> enterprise applications. However, I would say that it's not >>>>>>> knowing the >>>>>>> environment, but being able to change configuration elements per >>>>>>> environment that is important (for what I did, and in rails I [The entire original message is not included] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: environment awareness (project stage in JSF)
e hotel called us up and mentioned that they had quickly > sold out over New Years at a whopping $6 a night. Luckily they only > had 5 rooms or something, but we ate the cost of selling a 5-star > hotel at 98% off. > > I think the principle is sound, just needs a lot of testing and > understanding. I definitely don't think it has anything to do with > lazy developers. In fact, some of the best developers I know use it > extremely well to control size, performance, scale, functionality, and > much more in different environments. > > -bp > > > On Jun 28, 2008, at 4:56 AM, Al Sutton wrote: > >> I think the concept is an idea which will appeal to lazy developers. >> >> Why on earth would you want to put conditionals into your code that >> you know will only evaluate to a set value in the environment they >> run in? >> >> If anything it makes problems harder to track down because if someone >> takes a copy of the app from a production machine to a dev machine to >> further investigate a problem it will behave differently, which is >> just a hiding to nowhere in multi-threaded apps such as S2 webapps. >> >> An example of one of the "joys" that can come from this type of idea >> came from a project I worked on where a coder used log4j and isDebug >> to conditionally build a log string and log some extra data. This >> might be seen as a good idea, except the code within the conditional >> block didn't properly check all the objects were not null and under >> certain functionally valid conditions an NPE was thrown, so when a >> problem arose in production at a customers site they were asked to >> turn debug logging on and all that they sent back was a log with an >> number of NPEs which didn't relate to the original problem. >> >> Ohhh the fun we had explaining that a new release had to go through >> their change (long) control procedure just so we could find out what >> the original problem was and until that we we're kind of stuffed >> finding out what in their environment triggered the problem. >> >> Yes in an ideal world it shouldn't have happened. Yes it probably >> should have been picked up by some QA test somewhere. But don't we >> all live in the real world? >> >> Al. >> >> >> >> Chris Pratt wrote: >>> We use something similar in our system. The system uses a bunch of >>> resource bundles that are separated into logical domains, and each >>> entry can be overridden by a local file on each machine. Plus each >>> entry can be scoped by environment (production, test, development), >>> machine, or application name (in case multiple applications are >>> sharing a library component). We have log4j and spring configurers so >>> that it is tightly integrated into the tools we use. It's saved us an >>> eternity of time tracking down bugs from one environment to the next >>> since we deploy the same WAR file that was accepted by the quality >>> assurance group into production and let the configuration take care of >>> itself. >>> >>> I've often thought of creating a Google Code project to open source >>> it, but wasn't sure if there would be enough interest. >>> (*Chris*) >>> >>> On Fri, Jun 27, 2008 at 1:38 PM, Brian Pontarelli >>> <[EMAIL PROTECTED]> wrote: >>> >>>> Yeah, I found that environment resolution was a key feature for any >>>> large >>>> application. At Orbitz we could deploy the same bundle to any >>>> server and the >>>> bundle would figure out where it was and configure itself for that >>>> environment. Worked really well. >>>> >>>> I have also provided this type of feature in JCatapult using an API >>>> that can >>>> be implemented however developers need. The default implementation >>>> uses >>>> JNDI, but it is simple to change it. The nice thing about that is >>>> you can >>>> assume at all times that the environment is available and make >>>> assumptions >>>> around that. >>>> >>>> -bp >>>> >>>> On Jun 27, 2008, at 1:53 PM, Frank W. Zammetti wrote: >>>> >>>> >>>>> We d something similar as well, but we decided to use a simple env >>>>> var in >>>>> all environments... So the exact same EAR can deploy to any >>>>> environment and >>>>> the code wit
RE: environment awareness (project stage in JSF)
We d something similar as well, but we decided to use a simple env var in all environments... So the exact same EAR can deploy to any environment and the code within simply looks for that var and acts accordingly. Simple but highly effective. Frank -Original Message- From: Ian Roughley <[EMAIL PROTECTED]> Sent: Friday, June 27, 2008 2:59 PM To: Struts Developers List Subject: Re: environment awareness (project stage in JSF) I've actually had to implement this type of feature in multiple enterprise applications. However, I would say that it's not knowing the environment, but being able to change configuration elements per environment that is important (for what I did, and in rails I think this is the most important elements). i.e. change the SMTP, temp file dir, admin user email address, etc. depending on whether you are testing locally vs. production. If developers are using spring, there is a way to load property files with a hostname extension (which is one solution) - but should we always expect users to be using Spring? The other question is being able to modify struts.property properties depending on env (i.e. devMode=true in development and never in production). /Ian Antonio Petrelli wrote: > 2008/6/27 James Holmes <[EMAIL PROTECTED]>: > >> http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2 >> >> I like it. This is one of the features of RoR that I really found useful - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: environment awareness (project stage in JSF)
We d something similar as well, but we decided to use a simple env var in all environments... So the exact same EAR can deploy to any environment and the code within simply looks for that var and acts accordingly. Simple but highly effective. Frank -Original Message- From: Ian Roughley <[EMAIL PROTECTED]> Sent: Friday, June 27, 2008 2:59 PM To: Struts Developers List Subject: Re: environment awareness (project stage in JSF) I've actually had to implement this type of feature in multiple enterprise applications. However, I would say that it's not knowing the environment, but being able to change configuration elements per environment that is important (for what I did, and in rails I think this is the most important elements). i.e. change the SMTP, temp file dir, admin user email address, etc. depending on whether you are testing locally vs. production. If developers are using spring, there is a way to load property files with a hostname extension (which is one solution) - but should we always expect users to be using Spring? The other question is being able to modify struts.property properties depending on env (i.e. devMode=true in development and never in production). /Ian Antonio Petrelli wrote: > 2008/6/27 James Holmes <[EMAIL PROTECTED]>: > >> http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2 >> >> I like it. This is one of the features of RoR that I really found useful - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] 2.1.3 is 34% complete...keep it up
James Holmes wrote: +2 Dojo is a best. I'm all for something lighter like jQuery, Prototype, etc. "Dojo is a best"? Did you mean "Dojo is a beast", "Dojo is a bust" or "Dojo is the best"? *Slightly* different meanings there :) At least between the first two and the last one - LOL Frank On Fri, Jun 20, 2008 at 11:47 AM, Al Sutton <[EMAIL PROTECTED]> wrote: Deprecate the dojo plugin and allow users to work directly with any ajax framework Musachy Barroso wrote: So many dojo issues... musachy On Fri, Jun 20, 2008 at 10:36 AM, Don Brown <[EMAIL PROTECTED]> wrote: The Great Struts Bug Hunt is progressing nicely, with 50 issues closed already. Don't be shy and join in the efforts to close out the remaining 95 issues. Any help, from attaching fixes, to creating repeatable test cases, to just adding in your 2 cents on the issue is appreciated. I put the release health status portlet on our default JIRA dashboard at http://issues.apache.org/struts or you can view it directly at: https://issues.apache.org/struts/secure/RunPortlet.jspa?portletKey=com.sourcelabs.jira.plugin.portlet.releases:releases&defaultUserType=all&projectid=10030&randomproject=false&versionid=21864&versionlist=&; The list of open issues is here: http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=true&pid=10030&fixfor=21864 Here is a nice FAQ on how to help: http://struts.apache.org/helping.html More updates to come... Don - 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] -- Frank W. Zammetti Author of "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" for info: apress.com/book/search?searchterm=zammetti&act=search Java Web Parts - javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! My "look ma, I have a blog too!" blog: zammetti.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature sponsorship proposal
On Tue, April 8, 2008 9:30 am, Martin Gilday wrote: > How do you decide if the dontated feature is large enough to warrant > creditation? All of my open-source projects run under the idea that *every* contribution of *any* size should be acknowledged. Each of them (JWP and DataVision for example) include a list of contributors somewhere (JWP has a separate contributors file: http://javawebparts.svn.sourceforge.net/viewvc/javawebparts/trunk/javawebparts/contributors.txt?view=markup while DataVision has it as part of it's changelog: http://datavision.svn.sourceforge.net/viewvc/datavision/trunk/ChangeLog?view=markup as well as the Credits section of the web site and documentation) in which we say what they contributed and simply say thanks. Even if they just point something out that a committer later addresses, i.e., they don't contribute code or documentation something "concrete", they still deserve a mention IMO. (I don't know what project Don was referring to originally, but all the ones I run have this basic philosophy as he described) > Do you take it away once the feature has changed substantially over > time? IMO, no. You just keep building up the list forever. I don't see how you do otherwise. Just because the code someone contributed is no longer in use doesn't mean acknolwedgement of their involvement should be taken away. They still took the time to contribute in some fashion and therefore deserve to be listed as long as the project continues. Frank -- Frank W. Zammetti Author of "Practical DWR 2 Projects" and "JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" for info: apress.com/book/search?searchterm=zammetti&act=search Java Web Parts - javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! My "look ma, I have a blog too!" blog: zammetti.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
Niall Pemberton wrote: On Jan 16, 2008 3:47 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Niall Pemberton wrote: For the record I agree with Martin and in my book votes-are-votes whoever they come from. Well, I'm reading the bylaws right now: Yeah and missing the wood for the trees. Not a fair comment Niall. All people have to go on is the stated policy of a project, of which the bylaws are a primary part of. If they aren't an accurate reflection of the reality, there's a problem. I'm not missing a thing, except that Struts apparently has its bylaws, and then they have another set of "bylaws" that are actually acted upon that live in the minds of its developers and not in the written words of the stated bylaws. I view this is a problem. Vetos need justification whoever they're from and it the justification is considered valid I'm sure it would be acted upon. +1s are easier to throw around, but I'm a whole lot happier the more I see, again whoever they're from. I'm in complete agreement with that, and I have ZERO doubt that binding voters taken non-binding votes into account. Hopefully (personal opinion coming here) people throwing a +1 on a release means they've at least checked out the distro and tested it in some way. Also completely agree, doesn't matter where the +1 comes from, you'd hope, and I'm relatively sure, that's usually the case. > The fact that most votes I see is usually committers is disappointing and I think you're just contributing in this debate to putting off non-committers voting by telling them they have no value. Absolutely not! Questioning something in a project in no way diminishes the project, it in fact enhances it. That's what I'm doing here, questioning and seeking clarification, which so far has been elusive. I am in no way, shape or form telling anyone their vote has no value. What I *AM* pointing out is that there is NO WAY TO KNOW who's vote actually has value, and how much, because the written bylaws arguably do not represent the reality... and I only say arguably because there's discrepancy in whether they do apply or not, and what's been said in this thread 100% supports that claim. Whatever the policy/by-laws/rules/admin says is it currently working - I would say so, except it would be nice to have more people voting. Yes, it's working. But that's no guarantee it always will, and there's nothing to say it couldn't work better. What I don't understand is why there's any hesitation to get the bylaws inline with reality, whatever that reality is. Isn't that the easy answer? Ends any debate between Ted and Martin, shuts me up, and likely gets more people to vote because they understand precisely what it means to do so. Forget any of the specifics, why is that singular goal not desirable? Niall Frank -- Frank W. Zammetti Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Dave Newton wrote: --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote: Ted Husted wrote: Since everyone here is a volunteer, there's no way to enforce an obligation, and the ASF guidelines remind us of this. A vote is an opinion, not a commitment. Didn't you effectively say the opposite just yesterday? : "It's true that we're volunteers, and any of us can walk away whenever we like, but it's also true that when we vote +1 on a GA, each voter is saying that he or she intends to help support the release. If the release includes a J4 distribution, it means that we are each saying that we will make a good-faith effort to support that distribution too." It doesn't sound like the opposite. "Intention" is not "obligation", and a "good-faith effort" is just that--an expressed intent made in good faith to support the distro. IMO "obligation" means that regardless of other circumstances that support *must* be provided. That's my point though: obligation probably isn't the right word under any circumstances. The best you can hope for, ask for or expect, is a good-faith statement of intent. If everyone here is saying that a +1 implies such a good-faith intention to support, then there's no problem, everything is right with the world There seems to be some question about that implied meaning though, which is where this discussion began as I recall. d. Frank -- Frank W. Zammetti Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
the other way around. I don't disagree that flexibility is good, to a degerr, and I'm not looking to write up a binding contract here either :) But the fact that this discussion began in the first place from an apparent disagreement between you and Martin about the meaning of something that there probably shouldn't have been any question about in the first place I take as a sign that there is some level of disconnect going on, and getting the bylaws right if for no other reason than everyone can point to it and say "that's the right answer", is the way to deal with it. -Ted. Frank -- Frank W. Zammetti Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Ted Husted wrote: On Jan 16, 2008 10:47 AM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: (1) If as you say Niall "votes are votes", then that SHOULD mean that non-binding voters can veto a release, but the bylaws say differently: "3 binding +1 votes" and "no binding vetos" is the benchmark to whether a action passes or not. It doesn't say "3 +1 votes from anyone", nor does it say "no vetos from anyone", it specifically spells out binding votes. Non-binding votes are not officially considered in other words. Nobody can veto a release. It's a majority vote action not a consensus vote action. That may be so in practice Ted, but the bylaws say differently: "An action requiring consensus approval must receive at least 3 binding +1 votes and no binding vetos." Does that not say, effectively, that a single binding -1 causes an action (which I assume a release is) to not have consensus approval? Seems to me that's exactly what it says. We don't "count" non-binding votes, but most of us would take them into consideration. If I'm on the fence, and a number of contributors cast +1 non-binding votes, then I'm more likely to cast my binding vote for GA. The inverse is also true. And I think that's a perfectly reasonable way to approach it, but that's not what the bylaws says, nor is it what Nial and Nathan say is in "their books" (I'm not picking on you two by the way, but I don't think you're the only ones that feel that way, hence it's likely a reflection on a larger group feeling). We publish the project guidelines (or "by laws") to cover the common cases, so that we don't have to have these types of discussions every time we create a release. We're not trying to be legalistic, we're just trying to get the work done. And that too is reasonable, except that now you've got Martin seemingly disagreeing with you (how this all started as I recall) and both Niall and Nathan apparently with understanding that don't seem to jive with the bylaws, hence it seems obvious to me that something needs to be done, and the easiest answer is probably to rewrite the bylaws to match the consensus view, whatever that turns out to be. Since everyone here is a volunteer, there's no way to enforce an obligation, and the ASF guidelines remind us of this. A vote is an opinion, not a commitment. Didn't you effectively say the opposite just yesterday? : "It's true that we're volunteers, and any of us can walk away whenever we like, but it's also true that when we vote +1 on a GA, each voter is saying that he or she intends to help support the release. If the release includes a J4 distribution, it means that we are each saying that we will make a good-faith effort to support that distribution too." Maybe it's a semantic thing, but if a +1 vote means "...he or she intends to help support the release", isn't that an obligation? Or is "obligation" simply the wrong term? Perhaps willingness, as I suggested yesterday? The key thing to me is what are the expectations of the commiters when we vote +1 on a GA release. Right now, the general feeling is that a +1 GA vote doesn't indicate that the committer will have the bandwidth available to support the release. Meaning, if I want to ask about that, we need to ask in a different context. We're saying the same thing here. I personally feel that a +1 *should* imply something, but if everyone disagrees with me, that's fine, but it seems obvious there isn't consensus on that right now, and the bylaws say something that not everyone else seems to be saying in any case, so what's the final arbiter of which way is accurate? The bylaws should spell it all out clearly and unambiguously, regardless of what it is that they actually spell out, just to avoid such situations. I understand the bylaws aren't meant to be legalize, but I believe I've pointed out some contradictions and interpretations that should be dealt with so there's never any debate over what a vote does or does not mean, what obligations someone does or does not have. I don't so much care what the answers actually are, only that they are clear and unassailable, and I'd expect everyone would want that level of clarity from any project they're involve din. -Ted. Frank -- Frank W. Zammetti Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
Niall Pemberton wrote: For the record I agree with Martin and in my book votes-are-votes whoever they come from. Well, I'm reading the bylaws right now: http://struts.apache.org/dev/bylaws.html ...and a couple of things stand out to me: (1) It is specifically stated that the act of voting carries certain obligations. Good. (2) Much to my surprise, it does NOT seem to say that binding votes are counted any differently than non-binding votes, only that binding votes are cast by PMC Members, nor does it limit the obligation clause to binding votes. (3) +/-0 means no opinion, it doesn't mean "release is good but I will not/cannot support it". There are some contradictions and potential problems contained within these bylaws as they are currently written given these points, and they should IMO be addressed. (1) If as you say Niall "votes are votes", then that SHOULD mean that non-binding voters can veto a release, but the bylaws say differently: "3 binding +1 votes" and "no binding vetos" is the benchmark to whether a action passes or not. It doesn't say "3 +1 votes from anyone", nor does it say "no vetos from anyone", it specifically spells out binding votes. Non-binding votes are not officially considered in other words. So, the bylaws pretty clearly make a differentiation between binding and non-binding votes, regardless of what's in your book :). Is anyone comfortable saying that non-committers/non-PMC members can veto a release? I would think not, and therefore votes are NOT votes. If everyone IS comfortable saying that, then great, I'm all for it, just spell it out properly in the bylaws. (2) Martin earlier contended that a PMC member should vote +0 if they think the release should go but they do not intend or are unable to support it. The bylaws say otherwise. They effectively say that ANY vote carries the implication of "..agreeing to help do the work", which has to include support because there's no limited definition of "the work". This is true because this sentence: "The act of voting carries certain obligations. Voters are not only stating their opinion, they are also agreeing to help do the work." ...applies to ALL vote types (it doesn't say otherwise), and it is not overridden in the definition of what each vote type means in the table below it. Maybe some think that "do the work" only means apply the patches and roll the release, but then that leaves support undefined, which isn't good. (3) There is an obligation on the part of ALL voters, that's clearly stated. Let me be clear: I for one am OK with that, *IF* it's actually the intent. But, if I had understood that before, I wouldn't have voted +1 all those times frankly because as a non-project member I would not have accepted any "obligation". I would have as a committer, but not as an anonymous community member. I wonder how many non-members have voted over the years and not understood they were accepting an "obligation"? I seriously doubt everyone did. I think these bylaws need to be clearer. It "votes are votes", as Niall says, that's great, but let's make it crystal clear. If there's no implied obligation of a +1 vote, as Martin contends, so be it, let's make that crystal clear too. Niall Frank -- Frank W. Zammetti Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
Martin Cooper wrote: That's a fair question, but I have an answer for it. Of course you do. If you didn't, I'd think you'd gone on vacation or something. ;-) :) So you're saying that if a non-committer thinks a release looks OK, a +1 says just that and means nothing more, Yes. > whereas if a committer thinks it looks OK, they can't vote the same way unless they're committing to support it, and therefore cannot contribute to the binding vote count required for a release. Yes. > But why would the non-committer vote in such an inconsistent way? Surely the appropriate thing to do would be to vote +0, which is what the committer would have to do in order to indicate that they thought the release looked OK but were not in a position to support it. No, because that would also imply that the non-binding +1 has the same implied willingness to support (because otherwise there would be no difference between 0 and +1), and I contend that *NO* non-binding vote *EVER* carries that implication, as a binding vote does. Binding and non-binding votes cannot be equated in any way other than the statement about the fitness of the release, otherwise there would be no reason to differentiate binding from non-binding votes in the first place. Any meaning above and beyond fitness of release is the sole pervue of the binding votes and voters. In any case, I'm going to sign out of this discussion now, as I have enough to do keeping up with my day job, and don't feel the need to further defend my right to vote +1 as I feel appropriate. That's cool Martin, I'm bowing out now too. You've made your position clear, and anyone can read it and make up their own mind about it. I'm glad you got the chance to "defend your right", as you see it. Martin Cooper Frank -- Frank W. Zammetti Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
Martin Cooper wrote: On Jan 14, 2008 10:40 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Don't forget, I'm not a committer, I'm not an Apache member in any way, so me casting a non-binding +1 vote means squat other than "yeah, one extra set of eyes has looked at it and thinks it looks good". Oh, I don't think that follows at all. Most of supporting a release is not making commits. It's helping folks on the lists, submitting bug reports and patches, updating documentation, and all manner of other things. Those are things that any contributor can do, not just committers, so I'm not sure I understand why you believe non-committers would get a "bye" on their +1 votes. That's a fair question, but I have an answer for it. Put simply, I feel that anyone officially made a member of a project team has accepted a greater level of responsibility than someone in the larger user community. In the same way that if I participate in a Microsoft beta program, and I tell them that the beta looks solid, that doesn't imply anything about any support I'm willing, ready and able to contribute, it's the same in a community-driven project. I may still be willing and able to write Wiki entries about the product, help polish docs, answer questions on mailing lists, things like that, but me telling them the build looks good doesn't imply I'm going to be around to do any of that because my responsibility begins and ends with validating the beta. It's different for a member of the development team: it's a higher level of responsibility. If this wasn't all implicitly true, what would ever be the difference between a binding and non-binding vote? Wouldn't they be relegated to the same level of meaning? Clearly binding votes carry more weight, but on what basis? I'd argue at least part of it is that implied responsibility, that implied willingness to support the release, which a non-binding vote doesn't carry, and I think rightly so. Now, I do however think that in practice it's probably true that most non-members that take the time to vote also take the time to provide support. Speaking for myself, I've certainly answered my share of questions on the lists, offered help many times, have contributed to the Wiki and have supplied some patches and enhancements, so it's pretty clear *for me* that even a non-binding vote has meaning, some implied responsibility. This is probably the case for most voters, but I don't believe there is the same implied expectation (a word I've hesitated to use previously) that there is for binding votes, it's just good community when it happens. Martin Cooper Frank -- Frank W. Zammetti Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution
On Tue, January 15, 2008 1:09 pm, Dale Newfield wrote: > Frank W. Zammetti wrote: >> my feeling is that until a project deprecates a release, then >> no, there would be no expiration. Anyone who +1'd a release is implying >> they are willing to support it until it's officially deprecated. > > Do we ever deprecate any releases except non-current patch-level ones? > (I.E.: is W.X.Y automatically deprecated when W.X.Z (where Z>Y) is > released? Is A.B.C ever deprecated if there exists no A.B.D where D>C?) Not that I'm aware of, no. But I think you were getting at the question of whether a +1 means implicitly that you are willing to support that release in perpetuity, which I doubt too many people would be comfortable saying, and I was just providing an escape clause :) > -Dale Frank -- Frank W. Zammetti Author of "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution
On Tue, January 15, 2008 11:38 am, Dale Newfield wrote: > Frank W. Zammetti wrote: >> Martin Cooper wrote: >>> Should we declare Struts 1 dead? Do we have three PMC members who are >>> still willing to support further releases of it? >> >> That's a loaded question... do we have even three *PEOPLE* still willing >> to support further releases of S1? :) > > Does that mean the "intention"/"willingness"/"pinky swear" implied by a > "+1" vote expires with the next release? Interesting question Dale, I admittedly hadn't considered that. Doing so now though, my feeling is that until a project deprecates a release, then no, there would be no expiration. Anyone who +1'd a release is implying they are willing to support it until it's officially deprecated. Tangentially, to be clear, I for one have *NO* problem with a project deprecating a particular release, if by "deprecate" you mean "we no longer even *imply* that we will support that release". That of course doesn't mean that someone can't use that release, nor does it mean no one will actually support it, but it *does* mean that there's no longer any implied support given to the community at that point. More concretely for instance, if a vote was taken today and it was decided that Struts 1.1 is now deprecated, I personally would be OK with that. You could still get the bits and use them, could still ask questions about it on the mailing list, and would likely continue to get answers from both committers and users at large, but you could no longer at that point say to those that voted +1 years ago: "Hey, can you help me?" and have even the smallest expectation of getting a reply. > -Dale Frank -- Frank W. Zammetti Author of "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Should voting +1 on a release imply that the vote intends to help support the release?
On Tue, January 15, 2008 10:25 am, Antonio Petrelli wrote: > Everything except the "obligation" is fine for me. Probably "promise" > could > be fine :-) I wonder if there's a way to codify a pinky-swear :) LOL > Antonio Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
On Tue, January 15, 2008 4:59 am, Ted Husted wrote: > As it happens, the only outstanding patch for Struts 1 is one of > Frank's, [STR-3006], an IE7 edge case. That's funny, I didn't even remember that one! Frank -- Frank W. Zammetti Author of "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Should voting +1 on a release imply that the vote intends to help support the release?
On Tue, January 15, 2008 5:04 am, Ted Husted wrote: > On Jan 15, 2008 5:00 AM, Antonio Petrelli <[EMAIL PROTECTED]> > wrote: >> What about replacing the term "obligation" with "intention"? > > +1 -- The voter's "intention" was the original point, and the most we > could ever ask. +1 here as well to the principal. One debatable point: there would be a subtle difference between saying "a +1 vote implies *intention* to support the release" versus saying "a +1 vote implies *willingness* to support the release". Especially if you might be talking about writing this down somewhere, I think that subtle difference is worth thinking about. "Willingness" is slightly less of an obligation than "intention", so there's shades of gray to consider. Frank -- Frank W. Zammetti Author of "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
act that projects at Apache do not typically push out release which are not then supported pretty much supports this: I think most Apache members voting +1 are not only saying "I believe the code is ready for public consumption" but are also by implication saying "...and I'm ready to back up that belief with support". They probably are. But that's a long way from that being a requirement, which is the point on which this conversation started. Not to be Clintonesque or anything, but I think it depends on what your definition of "requirement" is :) Should you not be able to cast a vote until you've FAX'd in some notarized certification of your intent to support a release? No, that'd be over the top. But, should it be a safe assumption by all members of the community that your +1 means you are willing to support the release? Yes, I believe so. Further, I believe all the projects that have worked well to this point are evidence that most people feel that way, whether it's ever been written down somewhere or not. Martin Cooper Frank -- Frank W. Zammetti Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
Martin Cooper wrote: However, a +1 vote is *not* an assertion that the voter, specifically, intends to provide such support. Please try re-reading what I wrote. Unless, that is, you are saying that I should be *prohibited* from voting +1 on any release unless I am *personally* committed to fixing the bugs, even if there are a dozen other committers out there who I know for a fact are going to be doing that whether or not I do so myself. No, "prohibited" would probably be too strong (PROBABLY)... And yes, I'd agree that if you know there are dozens of committers ready to provide support, that's a bit of a different story too. But can you really say such a discussion usually takes place before a vote? Is the question: "are there at least a few people ready to support this?" actually asked before a vote is called? That would be atypical in my experience, based on the project I've been involved in. Assuming that's the case then, it's the *implication* of what a +1 means that's important, which I believe was Ted's point. I left the part above where you said "...a +1 vote is *not* an assertion that the voter, specifically, intends to provide such support". I would contend just the opposite is in fact the case, but I'll now qualify it slightly in light of your reply: in the absence of a discussion before a vote where it is determined who will provide support other than the person casting a +1, then that +1 does in fact *imply* that person *specifically* intends to provide support. Stated another way: a person voting +1 cannot *assume* there will be support provided by others, that would potentially be a big disservice to the community at large when they discover no one is in fact willing to support the release. The fact that projects at Apache do not typically push out release which are not then supported pretty much supports this: I think most Apache members voting +1 are not only saying "I believe the code is ready for public consumption" but are also by implication saying "...and I'm ready to back up that belief with support". I dare say that's the underlying belief with most open-source projects, at least the good ones. In fact, I'd love to hear from anyone reading this who DOESN'T feel that way and why. I am *not* saying that we should throw the bits out there and leave them to rot. I *am* saying that, as a PMC member, I have a right to vote +1 for a release even if I, personally, am not in a position to work on the code right now. Now, I *could* choose to be irresponsible, and vote +1 in the knowledge that nobody is going to support it, but I happen to believe that the people we have voted on to the PMC over the years are actually responsible people. I have ZERO doubt that Apache members, by and large, vote responsibly in this regard. The fact that Apache overall has been as successful as it has been pretty much proves you're right and very few members are being irresponsible. But I also believe that's because that for most, a +1 vote does imply they will support the release. Without that implication, and without discussion of support before the vote, who's to say *anyone* will support the release? If that implication doesn't exist, how can the community at large every have any confidence that a project intends to support its releases? Oh, you may have the right to do it, but I don't believe it's RIGHT to do it. Martin Cooper Frank -- Frank W. Zammetti Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
On Mon, January 14, 2008 5:06 pm, Martin Cooper wrote: > On Jan 14, 2008 10:05 AM, Ted Husted <[EMAIL PROTECTED]> wrote: > > >> It's true that we're volunteers, and any of us can walk away whenever >> we like, but it's also true that when we vote +1 on a GA, each voter >> is saying that he or she intends to help support the release. >> > > No, it's not. That is a myth that you have been perpetuating for several > years now, but it's just not true, and quite frankly I'm fed up hearing > it. > > A +1 vote for a GA release is a vote of confidence that the corresponding > bits are suitable for GA release, and hence for consumption by "the > public". > Certainly someone casting such a vote may take into consideration the > likelihood, or otherwise, that the release will be supported by the > community (although in truth that should have been a topic of discussion > before the bits ever came to a vote). However, a +1 vote is *not* an > assertion that the voter, specifically, intends to provide such support. An open-source "community" based on the premise that simply throwing the bits out there once you feel they are ready, and there is no implied responsibility of those throwing the bits out there to offer at least *some minimal degree* of support, is tantamount to a community destined to destroy itself, plain and simple. This would be much like the manufacturer of dynamite saying "here's the sticks, we *believe* they're ready for your use, but don't assume we're going to answer the phone if you come calling for help". I dare say no one would use the explosive from that manufacturer given that statement, nor would too many likely use an open-source project that made such a statement, directly or implied. No, Ted's assertion, as I read it, is that open-source developers should take at least *some* degree of responsibility for the bits they release, and I happen to very much agree with that. The developers *are* the community, isn't that a big part of the Apache Way? If those casting the votes do not intend to support what they are voting for, who is expected to? > -- > Martin Cooper Frank -- Frank W. Zammetti Author of "Practical DWR 2 Projects" (2008, Apress, ISBN 1-59059-941-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) and "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
On Mon, January 14, 2008 1:05 pm, Ted Husted wrote:
>> Retrotranslation seems a pretty fast process to me.
>
> It is fast, but the artifacts add to the clutter and confusion. The
> question is whether it's gaining us active contributors. Not
> freeloaders who just download the software, but volunteers who answer
> mailing list posts and provide patches.
You know Ted, if you and I were on opposite sides of a political campaign,
your choice of words ("freeloaders") would have given me ample ammunition
to attack you for weeks, maybe wind up costing you the election! - LOL
I know what you really meant by it, as did everyone else here, but you
know as well as I do that there are people out there that will take
anything they can find to use to attack a project they don't like... I
wonder how long before this is taken out of context and shows up on
someones' blog? :)
> -Ted.
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: invent way to get dropdown data in JSP not using actions or taglibs?
Adam Hardy wrote: I don't know the JSF architecture with its "page/component state saving", Frank, but I don't think my proposition is along those lines (with state saving). I'm no JSF expert either frankly, but I was basing my thought on the part where you said you were concerned with what happens after a validation failure and the input page being shown again... if you consider the options in a to be part of the state of that component (in a sense), then I think it really is about state-saving... the only difference is that when I say "state-saving", I'm also talking about the possibility of "prepping" a component, i.e., looking up in a database for the list of 's for a , as one example. Adam Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: invent way to get dropdown data in JSP not using actions or taglibs?
Hi Adam, If I'm understanding you, what I think you essentially want is the JSF concept of "page/component state saving" where, talking about an S2 app, the page, and by extension the "components" on each page (dropdowns, testboxes, etc), would know how to get their current state and render themselves. I suppose you could do that today easy enough by storing the values (and data, in the case of dropdowns) in session and always render from there. Maybe not the best answer from a performance/resource utilization POV. Maybe better would be for each tag in each theme to accept an attribute that specified the method of an action to call when rendering itself to populate it's data (default to populateXXX() where XXX is the ID of the element, so maybe the attribute is optional). Then you could do whatever you wanted in that method to provide the tag the data it needs to render the element with the current state. If that method isn't found, just let the tag do whatever it would normally do now, so as to not break backwards-compatibility, and let the developer only write the code they really need to. (for all I know, S2 already offers this, I don't really know) Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Mon, December 31, 2007 11:41 am, Adam Hardy wrote: > Happy New Year everybody. > > > This issue is mostly due to the validation failure mechanism which passes > flow > direct to the 'input' result without giving a chance to code the data > retrieval > needed to get data for dropdowns, associated lists, etc etc which the > view/JSP > will need. > > Currently the assorted solutions to this all seem to be forcing round pegs > into > square holes. For instance, I could make the 'input' result an action > chain to > go onto another action which does the data reading. Or I could fetch the > data > via an or a taglib. > > The S2 documentation says in various places things like: > > "First, we need to change or query the application's state, and then we > need to > present an updated view of the application. The Action class manages the > application's state, and the Result Type manages the view." > > Three or four years ago, this issue with the view was discussed alot. > There was > talk of mechanisms termed 'view-controllers' and concepts such as 'view > logic'. > > I'd love to see this accommodated for in S2. > > There is a certain amount of coding I can do to achieve my goals in the > Results, > but it may not be the best place for it - the name 'Result' implies more > of a > link between the Action and the View, rather than a place for coding data > retrieval. > > Essentially I think there is a strong call for a Class or chain of classes > that > can be tied to each particular View, whether Tile, JSP, velocity or > whatever. > > This is obviously not what Results were designed for. I can do it > currently but > the S2 config allows only one class per ResultType - so effectively I'd > need one > ResultType per JSP, or some pattern for it. > > The sort of operations I'm thinking of: > > - retrieving lists, sometimes parameterized (e.g. a list of items allowed > in a > particular category - requires the categoryId) > > - caching lists (countries in ApplicationScope, personalized data in > session > for example) > > - localization of dropdown beans (i.e. country names) > > > Regards > Adam > > - > 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: Result types for S1
Martin Cooper wrote: And I'm trying to avoid hacks like "special" values (or "special" anythings) that only lead to trouble. People will end up (re)using the same names, not realising that they're already "taken" for something they may not even care about, the end result being debugging hell. And I agree with that... that's why the last iteration of what I suggested to Paul in this thread does away with these "special" values, at least partly for the reason you state. Second, that doesn't sound terribly efficient to me. Having to essentially invoke a whole new request cycle, servlet invocation, all the overhead that involves, sounds like a bad idea to me in terms of performance and scalability. Huh? You're kidding, right? This is *exactly* the same, in terms of efficiency, as forwarding to a JSP or another Struts action. That's the point - it's *exactly* the same mechanism that every Struts developer has been using for years. If that's an unacceptable performance impact, we must have been screwed all along. ;-) Ok, yeah, you got me on that one, I didn't think that through properly. However, I believe my statement is still valid, just not for the reasons I was originally thinking... certainly you would agree that executing a class that is essentially part of the Struts RP chain is more efficient (assuming it's not doing something inefficient!) than forwarding to *any* resource, be it a servlet, JSP or what have you, wouldn't you? I don't see how you could say otherwise. Now, I'd agree that depending on what work is actually being done that the different may not be too great, but I've gotta believe there'd be a difference regardless. What's the point of using a framework like Struts in the first place if it can't provide something (relatively) simple like this? That would be my answer. I don't view returning a special forward, or better still, a new subclass as I suggested to Paul, as more complicated, just the opposite: I see it as clearly less so. You mean "can't provide something [...] like this" automagically, right? I've suggested a way that Struts can provide this very simply, and in a way that will not introduce *any* new concepts to the Struts developer. It's not automagical, but sheesh, S1 has never been automagical. I am not in favour of hacking around with it now just to make it so for some relatively minor enhancement. If you view this as a minor enhancement, then that's the disconnect here. If it is was *just* about JSON or XML, then yeah, that'd be pretty minor and you might convince me. Again I go back to the last iteration of what I'm suggesting, because frankly it's evolved as this discussion has progressed. It opens up the door to much more than just JSON, XML and relatively simple things like that. Think DataVision, JReports, etc. And yeah, I'm trying to make things automagical, you're right. Since when is that not desirable? Isn't the whole point of a framework to remove some work for the developer? To put it another way: why WOULDN'T we want to make things like this automagical if we can? Why WOULDN'T we want to add capabilities to Struts that a developer gets for as close to free as possible? Besides, I think the more the answer to things like this is "add this piece that's not a part of Struts", the less point there is to Struts. At what point did I suggest adding something that wasn't part of Struts? You suggested a servlet to render the JSON. That's not part of the framework. And I bet you're going to point out that JSPs then would be the same thing because after all, they're servlets in the end. The point I'm making though is that what you're suggesting is something additional the developer has to remember to configure, some other component they have to bring into their project (because I presume you wouldn't want such renderer servlets included in the Struts JAR, correct?) And I'm asking, what's the deciding factor as to whether something belongs in the framework or not? Many other frameworks provide this type of thing, S2 as one big example, so why should the answer be different for S1? You're not suggesting results in S2 should be replaced with servlets that are forwarded to, are you? Martin Cooper Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result types for S1
Martin Cooper wrote: Given the following paragraphs, I think we might be on different planets. ;-) Could be... some would say I rent a summer home on some distant world :) I don't see that you need Freemarker or anything like it, nor do I see any reason you couldn't continue to use the json-lib package you're already using. Why not simply add a rendering servlet that does the work of picking up the appropriate bean and rendering it by calling into the library, sending the output to the servlet output stream? If you do that, you need *no* other changes to Struts. Anyone who wants to use it simply adds the rendering servlet to their web.xml, adds a global forward (or more than one, if we want to parameterise things) that forwards to the servlet, and then uses that as the target of their actions. Done. I wouldn't like this for two reasons... first, it's something additional the developer has to do on top of Struts. I'm trying to avoid that. Second, that doesn't sound terribly efficient to me. Having to essentially invoke a whole new request cycle, servlet invocation, all the overhead that involves, sounds like a bad idea to me in terms of performance and scalability. (Although, I think you're right WRT Freemarker... as the idea has evolved from discussion with Paul here, I tend to agree with you on that at this point. Freemarker could well be another result type, just like in S2, but it shouldn't be necessary for the JSON or XML result) Why do we need anything more complicated than that? What's the point of using a framework like Struts in the first place if it can't provide something (relatively) simple like this? That would be my answer. I don't view returning a special forward, or better still, a new subclass as I suggested to Paul, as more complicated, just the opposite: I see it as clearly less so. Besides, I think the more the answer to things like this is "add this piece that's not a part of Struts", the less point there is to Struts. I mean, after all, shouldn't we then have told Musachy that the JSON plugin should be a filter, servlet, or something like that? I haven't seen a single person say that, and rightly so. I don't see it being any different, except that S2 has a plug-in mechanism for things like that... but at the end of the day it's still a part of the framework, if only a loosely-coupled one, not an external piece that I as an application developer then have to manage. Martin Cooper Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result types for S1
Frank W. Zammetti wrote:
>> Another way to do it might be to subclass ActionForward, calling it
>> Result. Then, after the Action executes, we try to cast the result to
>> Result, and if we catch a ClassCastException, then we have a plain old
>> ActionForward and we process it same as always, but if the exception
>> didn't occur then we have a Result and we can go off and do "result
>> things(tm)".
Just to change that slightly and clarify it with an example, we'd wind
up with this:
class Result extends ActionForward {
// Might not be anything here, just a marker in essence
}
class JSONResult extends Result {
// Do JSON generation, whatever that means
}
...then in the Action...
public ActionForward execute(ActionMapping mapping, ActionForm inForm,
HttpServletRequest request, HttpServletResponse response) throws
Exception {
return JSONResult(inForm);
}
...then, in the RP chain, somewhere after the Action execution...
// af is the ActionForward returned by execute()
Result r = null;
try {
r = (Result)af;
processResult(r);
} catch (ClassCastException cce) {
processActionForward(r);
}
I have no doubt I'm screwing up something simple here, since that's my
MO, but if not, that's what I'm describing.
(I just saw your response by the way, so I'm anxious to see what you
think of this, since it's more fleshed out and concrete)
Frank
Because to me, while what you propose isn't exactly rocket science to
implement or make use of, I think this approach is simpler still, and
requires very minimal changes to the codebase, also something I strive
for (not just with Struts either)
...or did you have some other motivation for those changes besides this?
Did you have other plans that hinge on these changes?
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result types for S1
Paul Benedict wrote: I said new method, I didn't say replace the previous method :-) I wouldn't implement anything that didn't allow current Struts actions to work. It's all blue sky thinking so there's a lot you can help me figure out. No, I knew you wouldn't do that... although it wasn't initially clear to me how it would still be compatible, I had no doubt that was just my lack of understanding and you had that answer :) So, let me think this through out loud, make sure I'm on the same page as you... I'm a Struts developer, and I upgrade to 1.4 where all this stuff presumably is. Ok, so none of my existing code breaks, good to go there. But, I want to use this new JSON capability, and let's think simplest case: I just want to render my ActionForm as JSON and return it, no options to fiddle with or anything like that. So, I need to implement this new version of execute(). Not too big a deal. I'm OK with it so far. But what if I want to take an existing Action and do this? Still not a big deal I think: implement the new version of execute(), call the existing execute(), ignore the returned ActionForward and do whatever I need to do to get the JSON output to happen. Not a big deal. I don't care about the ThreadLocal stuff, or the alternate execute() version, unless I want to. The only objection that comes to mind for me is that maybe having two different types of execute() methods is a bit more confusing than it needs to be. I don't think it's the kind of thing you can deprecate over time, there's too big an installed base to do that with. My puny brain needs simplicity :) So, I'm wondering if there's not a simpler answer, which is my roundabout way of asking: what do you think of my suggested approach to this? Just to recap: >> Another way to do it might be to subclass ActionForward, calling it >> Result. Then, after the Action executes, we try to cast the result to >> Result, and if we catch a ClassCastException, then we have a plain old >> ActionForward and we process it same as always, but if the exception >> didn't occur then we have a Result and we can go off and do "result >> things(tm)". Because to me, while what you propose isn't exactly rocket science to implement or make use of, I think this approach is simpler still, and requires very minimal changes to the codebase, also something I strive for (not just with Struts either) ...or did you have some other motivation for those changes besides this? Did you have other plans that hinge on these changes? Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result types for S1
Paul Benedict wrote: I am all for it. I was thinking the framework needs these additional enhancements to support it though: * A new Command to expose the ActionContext as a ThreadLocal variable * New execute() method could then contain no parameters * Allow returning void (equal to null), String (result/forward name), or ActionForward How do you then propose to keep backwards-compatibility? How would existing Actions continue to work without change? Another way to do it might be to subclass ActionForward, calling it Result. Then, after the Action executes, we try to cast the result to Result, and if we catch a ClassCastException, then we have a plain old ActionForward and we process it same as always, but if the exception didn't occur then we have a Result and we can go off and do "result things(tm)". This has the benefit of zero impact on existing application code, and isn't in any way a big change. You might argue it's a little ugly internally, and I'd agree to some extent!, but I don't see it as being too bad. I like the lesser degree of change myself. Paul Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result types for S1
Paul Benedict wrote: I find it more palatable to introduce the tag with a type, Frank and Atonio. Yes, I would agree that a is a shorthand for a . I definitely do not want to build a Struts 2 look-a-like, but it does make sense for a back port for some of its good idea. Well, I wouldn't be at all against that approach either... I didn't suggest anything like that initially because in the past there's always been resistance to changes to the DTD, which this would require. If now though there's consensus that says that's the approach we'd like to take, I'm all for it and will happily go off and implement it. Paul Frank On Dec 13, 2007 2:00 PM, Antonio Petrelli <[EMAIL PROTECTED]> wrote: 2007/12/13, Frank W. Zammetti <[EMAIL PROTECTED]>: if we simply say that if it DOESN'T begin with a slash, then it means something else, be it a template or class, or something else, how would you feel about that? It seems like Tiles definition names... Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.17.1/1182 - Release Date: 12/12/2007 11:29 AM -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result types for S1
Antonio Petrelli wrote: 2007/12/13, Frank W. Zammetti <[EMAIL PROTECTED]>: if we simply say that if it DOESN'T begin with a slash, then it means something else, be it a template or class, or something else, how would you feel about that? It seems like Tiles definition names... Are you saying there would be a conflict then? I admit I'm not at all familiar with the internals of Tiles (or Tiles in general, at least not the most recent versions), so I can't say. Antonio Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result types for S1
What do you think of the idea of a being able to map to a
Freemarker template, or maybe even a class? I wouldn't view this as
repurposing it myself because the destination of a forward is someting
that renders a response... Typically it maps to a URI that is forwarded
or redirected to, but both of those assume the path attribute begins
with a / ... if we simply say that if it DOESN'T begin with a slash,
then it means something else, be it a template or class, or something
else, how would you feel about that? (ignore the specifics of what it
would actually mean or how it would work, just think about it conceptually)
Frank
Paul Benedict wrote:
I don't think it's a good idea to repurpose the attribute. It's
not identical to in s2 with a type. I would truly recommend a
different kind of tag here.
Paul
On Dec 13, 2007 12:43 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Laurie Harper wrote:
Or stick with mapping.findForward(something) but provide a mechanism for
mapping that result type to the appropriate (JSON/XML/etc) rederer in
struts-config.xml. That would eliminate any concern over clashes with
existing action return strings (small though the risk is), and would be
consistent with existing declarative semantics.
With that, it could be easy to make the 'result providers' such as JSON
serialization, XML serialization and so forth plugable/configurable
and/or parameterizable.
For example:
...
I was thinking along those lines too, especially in terms of
parameterization... but, I think Antonio still has a valid point in
terms of findForward() meaning one thing, and doing it this way in a
sense "overloads" that meaning, which arguably isn't as nice.
I re-implemented it now by adding a renderResult() method to
ActionForward, and that works nicely. That code I think is fairly good
now, could create a patch for it. But...
There's two concerns left... one is parameterization. First, let me
show you where I am right now:
return mapping.renderResult("json", response, inForm);
I think that addresses Antonio's concern. Now, for paramerization, I'm
thinking simply using the on the Action might be fine...
then, this call would become:
return mapping.renderResult("json", response, inForm, this);
Each renderer could look for specific attribute of the Action to
configure it.
Also, I just saw Martin's note, and the point about not always using the
ActionForm is a good one, so one of the things the renderers could look
for is an attribute, maybe call it simply "beanToRender". That way, if
the Action wants to return another object as JSON, they just point that
attribute at the object and it's good to go. If that attribute is null,
or not present, the ActionForm is used.
The second concern... well, the second concern I'll skip for now because
I want to go reply to Martin's reply specifically because it might
change all this anyway :)
L.
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.17.1/1182 - Release Date: 12/12/2007 11:29 AM
--
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result types for S1
Martin Cooper wrote: 1) We simply provide servlets / other entry points that can accomplish the rendering to JSON / XML / whatever. The developer can then configure those as global forwards and use them as any other forward. This makes the process identical to what developers do now, but gives them the additional rendering capabilities. This was interestingly exactly what I was thinking originally :) I was thinking about introducing Freemarker into the mix... then, when Struts started up, it would insert some "automatic" global forwards, "json", "xml" for example. Then a Freemarker template is used to render the output. But, I'm not sure how well Freemarker will truly do JSON or XML in a generic way, whereas the json-lib I've been using so far is very simple (I believe it can do XML from JSON too, so we can get XML from it as well, although maybe not as efficiently as possible). But, that means we'd still essentially have "special" values though because somewhere in the processing chain it would have to recognize that the forward name specified maps to a Freemarker template. But, it's a special value within the same overall architecture, so I think it would be OK. I'm also not sure what the most elegant way to detect a Freemarker-based forward would be... maybe it's simply if the path doesn't begin with / then we assume it's a classpath specification, i.e, something like "org.apache.struts.results.JSONResult.ftl". I think doing it this way would also mean that a developer could add a new result type easily because it's just a new global forward entry, with a path pointing to the Freemarker template, and so long as its in the classpath we're good to go. 2) We not limit this to rendering the action form. Rendering the form might be desirable in some situations, but in many others, it would be some other bean that should be rendered, not the form bean. We could define an attribute under which the bean is stored, and the renderers could look for that and perhaps fall back to the form bean if it isn't there. Yeah, that's a good point... maybe the best way to do that is with some elements defined at the action level... that would also address Laurie's point about parameterization. Shouldn't be a big deal to make the ActionContext available to the Freemarker template, so it then has access to the Action, ActionForm, whatever else, and we could look for setting on the action (I think that's the right place). It's a different approach than what I've been discussing so far in some important ways though, so what does everyone think of it? I can probably get it at least working by late tonight and can throw it up somewhere for everyone to look at, I don't think it's much of a leap really effort-wise. -- Martin Cooper Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result types for S1
Laurie Harper wrote:
Or stick with mapping.findForward(something) but provide a mechanism for
mapping that result type to the appropriate (JSON/XML/etc) rederer in
struts-config.xml. That would eliminate any concern over clashes with
existing action return strings (small though the risk is), and would be
consistent with existing declarative semantics.
With that, it could be easy to make the 'result providers' such as JSON
serialization, XML serialization and so forth plugable/configurable
and/or parameterizable.
For example:
...
I was thinking along those lines too, especially in terms of
parameterization... but, I think Antonio still has a valid point in
terms of findForward() meaning one thing, and doing it this way in a
sense "overloads" that meaning, which arguably isn't as nice.
I re-implemented it now by adding a renderResult() method to
ActionForward, and that works nicely. That code I think is fairly good
now, could create a patch for it. But...
There's two concerns left... one is parameterization. First, let me
show you where I am right now:
return mapping.renderResult("json", response, inForm);
I think that addresses Antonio's concern. Now, for paramerization, I'm
thinking simply using the on the Action might be fine...
then, this call would become:
return mapping.renderResult("json", response, inForm, this);
Each renderer could look for specific attribute of the Action to
configure it.
Also, I just saw Martin's note, and the point about not always using the
ActionForm is a good one, so one of the things the renderers could look
for is an attribute, maybe call it simply "beanToRender". That way, if
the Action wants to return another object as JSON, they just point that
attribute at the object and it's good to go. If that attribute is null,
or not present, the ActionForm is used.
The second concern... well, the second concern I'll skip for now because
I want to go reply to Martin's reply specifically because it might
change all this anyway :)
L.
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result types for S1
Hi Antonio,
Antonio Petrelli wrote:
2007/12/13, Frank W. Zammetti <[EMAIL PROTECTED]>:
return mapping.findForward("JSONResultType");
I don't like this syntax, because it mixes the concept of forward (to a
page) with the rendering of the ActionForm. Probably a more specific
ActionMapping method, or different types of ActionForwards, could be better.
So you'd rather see something like:
return mapping.renderResult("JSON");
...or maybe doResult()?
If so, that's not bad at all... I like that better actually because then
I think I just need to modify ActionMapping, none of the chain Commands,
and so long as the class implementing the JSON rendering returns null,
then everything after the Action execution works just like always. It's
actually *less* intrusive in some ways, which was one of my goals.
Antonio
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Result types for S1
So, now that I've gotten my build problems sorted out, I was able to
make some quick progress on what I wanted to work on, enough that I want
to run this by everyone before I spit, polish and submit patches.
Ted and I were discussing some ideas at The Ajax Experience back in
October, specifically on how we could make S1 a little more
AJAX-friendly and useful to developers doing RIA development. One of
the ideas I had was the ability to have, essentially, "result types" in
S1, ala S2.
As a concrete example, say I have an Action that does this at the end:
return mapping.findForward("JSONResultType");
That mapping name would be a value specially recognized by Struts. The
result of doing that would be that the response is a JSON representation
of the appropriate ActionForm. One can easily imagine an XMLResultType,
a FreemarkerResultType, a DataVisionResultType, and so on.
Note that the developer *does not* need to add any configuration to
struts-config, they have only to specify that forward name, and the
ActionForm to JSON conversion is automatic.
I have this JSONResultType working right now, and it turns out it's a
minimally intrusive change to the S1 code base overall, consisting of:
* Some frankly minor changes to two Chain Commands
* The addition of a new package containing one new class (the class that
actually generates the result output, more to follow as new result types
are implemented)
* Some new dependencies: one during build (json-lib), and four at
runtime (if using that result type): Commons Collections, Commons Lang,
JSON-Lib and EZMorph).
To be clear, this code isn't complete and ready immediately, it's POC
grade right now, but it's not too far off either, maybe an hour or two
worth of polishing.
So, does anyone else think this is a worthwhile exercise? I certainly
think it is: the ability to have automatic conversion of an ActionForm
to JSON, XML, or whatever else, means S1 can become a true service
provider for AJAX-based clients with no real effort on the developers'
parts. It's not a huge change to the Struts code base, doesn't break
compatibility in any way (I suppose unless someone happens to have the
exact forward names I'm proposing here in their app already), and aside
from the added dependencies, I don't see a down-side.
Thoughts?
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use the Source, Luke!
Good news: I was in fact missing some updates, and sure enough it's working now. Thanks guys, I can get to work now :) Frank Antonio Petrelli wrote: 2007/12/12, Frank W. Zammetti <[EMAIL PROTECTED]>: It's possible I didn't get that one... I'll try tonight when I get home and let you know. I tested compiling using j2sdk 1.4.2_16 (Kubuntu 7.10) and it worked. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use the Source, Luke!
It's possible I didn't get that one... I'll try tonight when I get home and let you know. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Wed, December 12, 2007 3:06 am, Antonio Petrelli wrote: > 2007/12/11, Frank W. Zammetti <[EMAIL PROTECTED]>: >> >> Hi Antonio... I see the ticket hasn't been updated, and at least as of >> last night, with latest updates, the failure is still present. do you >> have any idea when you might get to this? Just so I know whether I >> should >> >> hack the code somehow to get the build to succeed, at least enough for >> me >> to work on what I wanted to, or just wait for the real fix. > > > > Do you mean that, with of my latest commit r603355, you have problems? > In this case, I have to test it with a real JDK 1.4 (I can do it this > evening CET). > > Ciao > Antonio > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use the Source, Luke!
On Tue, December 11, 2007 4:05 pm, Paul Benedict wrote: > Frank, why not install JDK 5 to do the install? You don't need JDK 5 to > run > Struts, just to build it. I can do that (I have a batch file that flips me to JDK6, so easy enough), but then I have to exercise some care to ensure I don't use any JDK5+ features... I also wasn't sure if there might be some other side-effects I'm not seeing. Frank > On Dec 11, 2007 2:50 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > >> On Fri, December 7, 2007 2:54 am, Antonio Petrelli wrote: >> > 2007/12/7, Frank W. Zammetti <[EMAIL PROTECTED]>: >> >> >> >> Paul Benedict wrote: >> >> > Please try again. >> >> [INFO] Building Struts - Tiles 2 integration >> >> ... >> >> >> >> >> [ERROR] BUILD FAILURE >> >> [INFO] >> >> >> >> >> [INFO] Compilation failure >> >> Failure executing javac, but could not parse the error: >> >> javac: invalid target release: 1.5 >> > >> > >> > >> > Tadah! Here I come! >> > I think it is my "fault", since currently the Struts 1/Tiles 2 plugin >> must >> > be compiled using Java 1.5. >> > I opened an issue for this, and I hope to solve it ASAP: >> > https://issues.apache.org/struts/browse/STR-3120 >> >> Hi Antonio... I see the ticket hasn't been updated, and at least as of >> last night, with latest updates, the failure is still present. do you >> have any idea when you might get to this? Just so I know whether I >> should >> hack the code somehow to get the build to succeed, at least enough for >> me >> to work on what I wanted to, or just wait for the real fix. >> >> > Ciao >> > Antonio >> >> Thanks, >> Frank >> >> >> - >> 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: Use the Source, Luke!
On Fri, December 7, 2007 2:54 am, Antonio Petrelli wrote: > 2007/12/7, Frank W. Zammetti <[EMAIL PROTECTED]>: >> >> Paul Benedict wrote: >> > Please try again. >> [INFO] Building Struts - Tiles 2 integration >> ... >> >> [ERROR] BUILD FAILURE >> [INFO] >> >> [INFO] Compilation failure >> Failure executing javac, but could not parse the error: >> javac: invalid target release: 1.5 > > > > Tadah! Here I come! > I think it is my "fault", since currently the Struts 1/Tiles 2 plugin must > be compiled using Java 1.5. > I opened an issue for this, and I hope to solve it ASAP: > https://issues.apache.org/struts/browse/STR-3120 Hi Antonio... I see the ticket hasn't been updated, and at least as of last night, with latest updates, the failure is still present. do you have any idea when you might get to this? Just so I know whether I should hack the code somehow to get the build to succeed, at least enough for me to work on what I wanted to, or just wait for the real fix. > Ciao > Antonio Thanks, Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use the Source, Luke!
Paul Benedict wrote: > Please try again. Still looks to be something pointing to 1.5... see the end of this dump... (I just *know* the answer is going to be in the POM... I don't know Maven, but I know the POM is the answer to everything! LOL) K:\projects\struts>mvn [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Struts [INFO] Struts Core [INFO] Struts Tiles [INFO] Struts Taglib [INFO] Struts EL [INFO] Struts Extras [INFO] Struts Faces [INFO] Struts Mailreader DAO [INFO] Struts Scripting [INFO] Struts - Tiles 2 integration [INFO] - --- [INFO] Building Struts [INFO]task-segment: [install] [INFO] - --- [INFO] [site:attach-descriptor] [WARNING] Unable to load parent project from repository: Could not find the mode l file 'K:\projects\struts\..\pom.xml'. [INFO] [install:install] [INFO] Installing K:\projects\struts\pom.xml to C:\Documents and Settings\Admini strator\.m2\repository\org\apache\struts\struts-parent\1.4.0-SNAPSHOT\struts-par ent-1.4.0-SNAPSHOT.pom [INFO] - --- [INFO] Building Struts Core [INFO]task-segment: [install] [INFO] - --- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [WARNING] Artifact javax.servlet:servlet-api:jar:2.3:provided retains local scope 'provided' overriding broader scope 'compile' given by a dependency. If this is not intended, modify or remove the loc al scope. [INFO] [compiler:compile] [INFO] Compiling 139 source files to K:\projects\struts\core\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 23 source files to K:\projects\struts\core\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: K:\projects\struts\core\target\surefire-report s --- T E S T S --- Running org.apache.struts.action.TestActionMessage Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec Running org.apache.struts.chain.commands.generic.TestWrappingLookupCommand Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec Running org.apache.struts.chain.commands.servlet.TestSetOriginalURI Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec Running org.apache.struts.action.TestActionRedirect Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running org.apache.struts.util.TestRequestUtils Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 sec Running org.apache.struts.chain.commands.servlet.TestAuthorizeAction Dec 7, 2007 12:29:05 AM org.apache.struts.util.PropertyMessageResources loadLoca le WARNING: Resource org/apache/struts/action/ActionResources_en_US.properties No t Found. Dec 7, 2007 12:29:05 AM org.apache.struts.util.PropertyMessageResources loadLoca le WARNING: Resource org/apache/struts/action/ActionResources_en.properties Not F ound. Dec 7, 2007 12:29:05 AM org.apache.struts.util.PropertyMessageResources loadLoca le WARNING: Resource org/apache/struts/action/ActionResources_en_US.properties No t Found. Dec 7, 2007 12:29:05 AM org.apache.struts.util.PropertyMessageResources loadLoca le WARNING: Resource org/apache/struts/action/ActionResources_en.properties Not F ound. Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec Running org.apache.struts.action.TestDynaActionFormClass Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running org.apache.struts.validator.TestValidWhen Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.062 sec Running org.apache.struts.config.TestModuleConfig Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.141 sec Running org.apache.struts.config.TestActionConfig Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running org.apache.struts.config.TestFormBeanConfig Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.struts.config.TestActionConfigMatcher Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running org.apache.struts.action.TestActionMessages Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec Running org.apache.struts.chain.commands.servlet.TestPerformForward Dec 7, 2007 12:29:05 AM org.apache.struts.util.PropertyMessageResources loadLoca le WARNING: Resource org/apache/struts/action/ActionResources_en_US.properties No t Found. Dec 7, 2007 12:29:05 AM org.apache.struts.util.PropertyMessageResources loadLoca le WARNING: Resourc
Re: Use the Source, Luke!
Hi Paul... I just tried again and still had a build failure... any thoughts? ... Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. K:\projects\struts>mvn [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Struts [INFO] Struts Core [INFO] Struts Tiles [INFO] Struts Taglib [INFO] Struts EL [INFO] Struts Extras [INFO] Struts Faces [INFO] Struts Mailreader DAO [INFO] Struts Scripting [INFO] Struts - Tiles 2 integration [INFO] - --- [INFO] Building Struts [INFO]task-segment: [install] [INFO] - --- [INFO] [site:attach-descriptor] [WARNING] Unable to load parent project from repository: Could not find the mode l file 'K:\projects\struts\..\pom.xml'. [INFO] [install:install] [INFO] Installing K:\projects\struts\pom.xml to C:\Documents and Settings\Admini strator\.m2\repository\org\apache\struts\struts-parent\1.4.0-SNAPSHOT\struts-par ent-1.4.0-SNAPSHOT.pom [INFO] - --- [INFO] Building Struts Core [INFO]task-segment: [install] [INFO] - --- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [WARNING] Artifact javax.servlet:servlet-api:jar:2.3:provided retains local scope 'provided' overriding broader scope 'compile' given by a dependency. If this is not intended, modify or remove the loc al scope. [INFO] [compiler:compile] [INFO] Compiling 139 source files to K:\projects\struts\core\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure K:\projects\struts\core\src\main\java\org\apache\struts\action\DynaActionFormCla ss.java:[253,18] cannot resolve symbol symbol : constructor IllegalArgumentException (java.lang.String,java.lang.Throw able) location: class java.lang.IllegalArgumentException K:\projects\struts\core\src\main\java\org\apache\struts\chain\commands\generic\C opyFormToContext.java:[254,18] cannot resolve symbol symbol : constructor IllegalStateException (java.lang.String,java.lang.ClassCas tException) location: class java.lang.IllegalStateException [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 7 seconds [INFO] Finished at: Thu Dec 06 19:01:29 EST 2007 [INFO] Final Memory: 9M/27M [INFO] K:\projects\struts>java -version java version "1.4.2_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_13-b06) Java HotSpot(TM) Client VM (build 1.4.2_13-b06, mixed mode) Frank Paul Benedict wrote: STR-3118 has been opened to track this issue: https://issues.apache.org/struts/browse/STR-3118 You should have no problems now, but you never know. :) Paul On Dec 5, 2007 10:25 AM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Thanks Paul. No rush, I have a DataVision build to roll today anyway, not to mention a really hairy prod LDAP issue at work, so it's not like I have nothing else to do :o Frank Paul Benedict wrote: Well this is a definite oversight and so mea culpa. I am surprised neither my Maven build picked this up nor Continuum which is running the Struts 1.4build at Apache. When I get home, Frank, I will fix this for you. Paul On Dec 5, 2007 7:55 AM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: I *definitely* say no... I know in my shop, we're going to be stuck with JDK 1.4 for nearly another year because of Websphere, so it would keep me from moving up the Struts 1.x ladder (although, we're still on 1.2.8 I believe, so we're back a ways regardless). My feeling is that S1 should pretty much always stay on 1.4... I think with the large installed base, and many in shops that haven't and don't plan to bump to JDK 1.5, the 1.x track should remain accessible to them. I'd like to see the JDK line be S1 vs. S2... those that are stuck on 1.4 for whatever reason know that the 1.x track is for them, those on 1.5+ can choose either track. Frank Paul Benedict wrote: I didn't unilaterally decide to use JDK 1.5 features. No worries. This is just an oversight, but what bugs me is that the Maven compiler (at least on my side) didn't set the right compiler version and catch the error. Bummer. Anyway, AFAIK, 1.4 is still a JDK 1.4 project. But since Frank tried this out, I guess we should ask if 1.5 should
Re: Use the Source, Luke!
Thanks Paul! I'll update and try a build when I get home from work tonight. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Thu, December 6, 2007 1:58 am, Paul Benedict wrote: > STR-3118 has been opened to track this issue: > https://issues.apache.org/struts/browse/STR-3118 > > You should have no problems now, but you never know. :) > > Paul > > On Dec 5, 2007 10:25 AM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > >> Thanks Paul. No rush, I have a DataVision build to roll today anyway, >> not to mention a really hairy prod LDAP issue at work, so it's not like >> I have nothing else to do :o >> >> Frank >> >> Paul Benedict wrote: >> > Well this is a definite oversight and so mea culpa. I am surprised >> neither >> > my Maven build picked this up nor Continuum which is running the >> > Struts 1.4build at Apache. When I get home, Frank, I will fix this for >> > you. >> > >> > Paul >> > >> > On Dec 5, 2007 7:55 AM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> > >> >> I *definitely* say no... I know in my shop, we're going to be stuck >> with >> >> JDK 1.4 for nearly another year because of Websphere, so it would >> keep >> >> me from moving up the Struts 1.x ladder (although, we're still on >> 1.2.8 >> >> I believe, so we're back a ways regardless). >> >> >> >> My feeling is that S1 should pretty much always stay on 1.4... I >> think >> >> with the large installed base, and many in shops that haven't and >> don't >> >> plan to bump to JDK 1.5, the 1.x track should remain accessible to >> them. >> >> I'd like to see the JDK line be S1 vs. S2... those that are stuck on >> >> 1.4 for whatever reason know that the 1.x track is for them, those on >> >> 1.5+ can choose either track. >> >> >> >> Frank >> >> >> >> Paul Benedict wrote: >> >>> I didn't unilaterally decide to use JDK 1.5 features. No worries. >> This >> >> is >> >>> just an oversight, but what bugs me is that the Maven compiler (at >> least >> >> on >> >>> my side) didn't set the right compiler version and catch the error. >> >> Bummer. >> >>> Anyway, AFAIK, 1.4 is still a JDK 1.4 project. But since Frank tried >> >> this >> >>> out, I guess we should ask if 1.5 should be used or not? At the >> moment, >> >> I >> >>> say no. Thoughts? >> >>> >> >>> Paul >> >>> >> >>> >> >>> On Dec 5, 2007 7:14 AM, Frank W. Zammetti <[EMAIL PROTECTED]> >> wrote: >> >>> >> >>>> Niall Pemberton wrote: >> >>>>> Looks like core uses JDK 1.5 features - for example the >> >>>>> IllegalStateException constructors which take a "Throwable" cause >> were >> >>>>> only added in JDK 1.5: >> >>>>> >> >>>>> >> >> >> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IllegalStateException.html >> >>>>> I don't remember agreeing to move to JDK 1.5 (from JDK 1.4) for >> the >> >>>>> next Struts (1.4) version - but perhaps we did? >> >>>> I had a feeling that might have been the case, but I too don't >> remember >> >>>> even discussion of requiring 1.5 at any point so I figured I must >> be >> >>>> wrong. >> >>>> >> >>>> And I can confirm that switching to java5 works, got a successful >> build >> >>>> now... actually, I have java6 installed so I used that, but I >> assume >> >>>> java5 would work too. >> >>>> >> >>>> Frank >> >>>> >> >>>>> Niall >> >>>> Frank >> >>>> >> >>>> -- >> >>>> Frank W. Zammetti >> >>>> Founder and Chief Software Architect >
Re: Use the Source, Luke!
Thanks Paul. No rush, I have a DataVision build to roll today anyway, not to mention a really hairy prod LDAP issue at work, so it's not like I have nothing else to do :o Frank Paul Benedict wrote: Well this is a definite oversight and so mea culpa. I am surprised neither my Maven build picked this up nor Continuum which is running the Struts 1.4build at Apache. When I get home, Frank, I will fix this for you. Paul On Dec 5, 2007 7:55 AM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: I *definitely* say no... I know in my shop, we're going to be stuck with JDK 1.4 for nearly another year because of Websphere, so it would keep me from moving up the Struts 1.x ladder (although, we're still on 1.2.8 I believe, so we're back a ways regardless). My feeling is that S1 should pretty much always stay on 1.4... I think with the large installed base, and many in shops that haven't and don't plan to bump to JDK 1.5, the 1.x track should remain accessible to them. I'd like to see the JDK line be S1 vs. S2... those that are stuck on 1.4 for whatever reason know that the 1.x track is for them, those on 1.5+ can choose either track. Frank Paul Benedict wrote: I didn't unilaterally decide to use JDK 1.5 features. No worries. This is just an oversight, but what bugs me is that the Maven compiler (at least on my side) didn't set the right compiler version and catch the error. Bummer. Anyway, AFAIK, 1.4 is still a JDK 1.4 project. But since Frank tried this out, I guess we should ask if 1.5 should be used or not? At the moment, I say no. Thoughts? Paul On Dec 5, 2007 7:14 AM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Niall Pemberton wrote: Looks like core uses JDK 1.5 features - for example the IllegalStateException constructors which take a "Throwable" cause were only added in JDK 1.5: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IllegalStateException.html I don't remember agreeing to move to JDK 1.5 (from JDK 1.4) for the next Struts (1.4) version - but perhaps we did? I had a feeling that might have been the case, but I too don't remember even discussion of requiring 1.5 at any point so I figured I must be wrong. And I can confirm that switching to java5 works, got a successful build now... actually, I have java6 installed so I used that, but I assume java5 would work too. Frank Niall Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.14/1171 - Release Date: 12/4/2007 7:31 PM -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.14/1171 - Release Date: 12/4/2007 7:31 PM -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use the Source, Luke!
I *definitely* say no... I know in my shop, we're going to be stuck with JDK 1.4 for nearly another year because of Websphere, so it would keep me from moving up the Struts 1.x ladder (although, we're still on 1.2.8 I believe, so we're back a ways regardless). My feeling is that S1 should pretty much always stay on 1.4... I think with the large installed base, and many in shops that haven't and don't plan to bump to JDK 1.5, the 1.x track should remain accessible to them. I'd like to see the JDK line be S1 vs. S2... those that are stuck on 1.4 for whatever reason know that the 1.x track is for them, those on 1.5+ can choose either track. Frank Paul Benedict wrote: I didn't unilaterally decide to use JDK 1.5 features. No worries. This is just an oversight, but what bugs me is that the Maven compiler (at least on my side) didn't set the right compiler version and catch the error. Bummer. Anyway, AFAIK, 1.4 is still a JDK 1.4 project. But since Frank tried this out, I guess we should ask if 1.5 should be used or not? At the moment, I say no. Thoughts? Paul On Dec 5, 2007 7:14 AM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Niall Pemberton wrote: Looks like core uses JDK 1.5 features - for example the IllegalStateException constructors which take a "Throwable" cause were only added in JDK 1.5: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IllegalStateException.html I don't remember agreeing to move to JDK 1.5 (from JDK 1.4) for the next Struts (1.4) version - but perhaps we did? I had a feeling that might have been the case, but I too don't remember even discussion of requiring 1.5 at any point so I figured I must be wrong. And I can confirm that switching to java5 works, got a successful build now... actually, I have java6 installed so I used that, but I assume java5 would work too. Frank Niall Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.14/1171 - Release Date: 12/4/2007 7:31 PM -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use the Source, Luke!
Niall Pemberton wrote: Looks like core uses JDK 1.5 features - for example the IllegalStateException constructors which take a "Throwable" cause were only added in JDK 1.5: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IllegalStateException.html I don't remember agreeing to move to JDK 1.5 (from JDK 1.4) for the next Struts (1.4) version - but perhaps we did? I had a feeling that might have been the case, but I too don't remember even discussion of requiring 1.5 at any point so I figured I must be wrong. And I can confirm that switching to java5 works, got a successful build now... actually, I have java6 installed so I used that, but I assume java5 would work too. Frank Niall Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use the Source, Luke!
Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation fail ure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompiler Mojo.java:516) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Tue Dec 04 23:08:26 EST 2007 [INFO] Final Memory: 8M/15M [INFO] Also, FYI: K:\projects\struts>java -version java version "1.4.2_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_13-b06) Java HotSpot(TM) Client VM (build 1.4.2_13-b06, mixed mode) K:\projects\struts>mvn -v Maven version: 2.0.4 Frank W. Zammetti wrote: Thanks, will do. Once I have things fleshed out a little I'll bring it up for discussion here. I want to make sure *I* think the ideas are good first, and have some actual code to show for it. Frank Paul Benedict wrote: If I can help with anything, let me know! On Dec 4, 2007 7:50 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: On Dec 4, 2007 5:24 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: At The Ajax Experience back in October, Ted and I tossed around a few ideas for new S1 features (Ajax only being one, contrary to the location of the discussions!), and since I've just completed writing on my most recent book I had some time and was hoping to test some things out. But, I'm embarrassed to admit, I can't seem to find the correct SVN path to check out S1 TRUNK! I found the web viewer just fine, and from it I guessed that http://svn.apache.org/struts/struts1/trunk/ seemed reasonable, but no good (error 403). I tried a couple of variations of that URL before I decided I must have guessed wrong. Is this what you're looking for? http://svn.apache.org/repos/asf/struts/struts1/trunk -- Martin Cooper Can someone point me in the right direction? Thanks! Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.14/1171 - Release Date: 12/4/2007 7:31 PM -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use the Source, Luke!
Thanks, will do. Once I have things fleshed out a little I'll bring it up for discussion here. I want to make sure *I* think the ideas are good first, and have some actual code to show for it. Frank Paul Benedict wrote: If I can help with anything, let me know! On Dec 4, 2007 7:50 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: On Dec 4, 2007 5:24 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: At The Ajax Experience back in October, Ted and I tossed around a few ideas for new S1 features (Ajax only being one, contrary to the location of the discussions!), and since I've just completed writing on my most recent book I had some time and was hoping to test some things out. But, I'm embarrassed to admit, I can't seem to find the correct SVN path to check out S1 TRUNK! I found the web viewer just fine, and from it I guessed that http://svn.apache.org/struts/struts1/trunk/ seemed reasonable, but no good (error 403). I tried a couple of variations of that URL before I decided I must have guessed wrong. Is this what you're looking for? http://svn.apache.org/repos/asf/struts/struts1/trunk -- Martin Cooper Can someone point me in the right direction? Thanks! Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.14/1171 - Release Date: 12/4/2007 7:31 PM -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use the Source, Luke!
Yep, that's it, thanks Martin! And yeah, I just took another look and missed the obvious Source Code link... Typically I keep the text in my browser bigger than usual, which makes the menu on the left of the site a littler overlapping, so I just missed it. Thanks though, all set now. Frank Martin Cooper wrote: On Dec 4, 2007 5:24 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: At The Ajax Experience back in October, Ted and I tossed around a few ideas for new S1 features (Ajax only being one, contrary to the location of the discussions!), and since I've just completed writing on my most recent book I had some time and was hoping to test some things out. But, I'm embarrassed to admit, I can't seem to find the correct SVN path to check out S1 TRUNK! I found the web viewer just fine, and from it I guessed that http://svn.apache.org/struts/struts1/trunk/ seemed reasonable, but no good (error 403). I tried a couple of variations of that URL before I decided I must have guessed wrong. Is this what you're looking for? http://svn.apache.org/repos/asf/struts/struts1/trunk -- Martin Cooper Can someone point me in the right direction? Thanks! Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.14/1171 - Release Date: 12/4/2007 7:31 PM -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Use the Source, Luke!
At The Ajax Experience back in October, Ted and I tossed around a few ideas for new S1 features (Ajax only being one, contrary to the location of the discussions!), and since I've just completed writing on my most recent book I had some time and was hoping to test some things out. But, I'm embarrassed to admit, I can't seem to find the correct SVN path to check out S1 TRUNK! I found the web viewer just fine, and from it I guessed that http://svn.apache.org/struts/struts1/trunk/ seemed reasonable, but no good (error 403). I tried a couple of variations of that URL before I decided I must have guessed wrong. Can someone point me in the right direction? Thanks! Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Plugin and auto-generated XHTML Views
Antonio Petrelli wrote: 2007/12/2, Tom Schneider <[EMAIL PROTECTED]>: Personally, I !!HATE!! writing xsl. I try to avoid it at all costs +1 XSLT is horrible, counter-intuitive, verbose and probably useless for webapps. In Struts 1, projects like StrutsCX and STXX are failing miserably. +1... a few years ago I was involved in a project that was 100% XSLT-based, and that wasn't even client-side processing, which is 100x worse (performance-wise if nothing else)... it just did some database queries, constructed some XML from the results and then ran it through a transformation engine with an appropriate XSLT template to generate the HTML sent to the client... seemed like a good, flexible idea at the time, but once it was done we couldn't switch technologies fast enough... difficult to develop, difficult to maintain and ultimately nowhere near as flexible as we thought it would be. I think XSLT still has its place when dealing with systematic transmissions where there's an XML format mismatch, or when transforming from say XML to CSV or something like that, which I've done too with better results, but for a webapp front-end generation system? Not something I'd be interested ever doing again, whether I had to write the code or not, that's for sure. Antonio Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 "Getting Started" buttons do not render under IE (was GoogleCode Maven ...)
I agree with Jim... a quick test shows that using height instead of min-height causes the buttons to appear, at least in isolation. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Tue, November 27, 2007 1:10 pm, Ted Husted wrote: > The images are blank buttons that are being styled to add the captions. > > http://cwiki.apache.org/S2PLUGINS/home.html";> > > style="top:15px;position:absolute;color:white;padding-left:10px"> > Plugin > Registry > > > > > I'm not much of HTML guru. Does anyone have an IE fix for this, or > should we use a different set of images? (The current approach also > works with Safari and Opera, just not IE.) > > -Ted. > > On Nov 27, 2007 12:49 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> Ok, there appears to be an issue with the site then... when I view it in >> Macthon, my browser of choice, I don't see the buttons. In FF I see >> them >> just fine. I tried in IE7 as well and I see the same thing as Maxthon >> (which makes sense, since Maxthon is just a wrapper around IE). I >> fiddled >> with zoom factors and font size, since that's typically what causes >> things >> like this, but even at default font size and zooming, the buttons are >> not >> there (I can send a screenshot if anyone would like). It looks like, >> for >> whatever reason, the button graphics are not there, all I see is the >> text >> in white, so it blends with the background (partially... it slightly >> overlaps the gray bar there). >> >> Frank >> >> -- >> Frank W. Zammetti >> Founder and Chief Software Architect >> Omnytex Technologies >> http://www.omnytex.com >> AIM/Yahoo: fzammetti >> MSN: [EMAIL PROTECTED] >> Author of "Practical Ajax Projects With Java Technology" >> (2006, Apress, ISBN 1-59059-695-1) >> and "JavaScript, DOM Scripting and Ajax Projects" >> (2007, Apress, ISBN 1-59059-816-4) >> Java Web Parts - http://javawebparts.sourceforge.net >> Supplying the wheel, so you don't have to reinvent it! >> >> >> On Tue, November 27, 2007 12:40 pm, Philip Luppens wrote: >> > On 11/27/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> >> On Tue, November 27, 2007 12:15 pm, Philip Luppens wrote: >> >> > On 11/27/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> >> >> I don't disagree with most of what you say here, and what Phillip >> >> says >> >> >> in >> >> >> his reply, so let me make a more concrete suggestion: make the >> plugin >> >> >> registry much more prominent on the Struts home page (that is to >> say, >> >> >> mention it at all, since I don't see it on the front page anywhere >> at >> >> >> present). >> >> > >> >> > It has a 150px wide button in yellow on the homepage [1] ;-) >> >> > But I agree that it might need a bit more 'marketing'. >> >> >> >> Really?!? I'm either the biggest idiot on the face of the planet >> (which >> >> some might say is true regardless, but I digress) or I'm a lot >> blinder >> >> than I thought... I don't see it. It's not out of the realm of >> >> possibility that the proxy here at work has an older version of the >> page >> >> cached, I've seen that happen before, but I'm not seeing a big yellow >> >> button anywhere on struts.apache.org. What part of the page >> >> specifically >> >> is it in? >> > >> > It's on the Struts 2 homepage [1], not the struts.apache.org one. >> > >> > [1] http://struts.apache.org/2.x/ >> > >> > - Phil >> > >> >> >> >> > - Phil >> >> >> >> Frank >> >> >> >> -- >> >> Frank W. Zammetti >> >> Founder and Chief Software Architect >> >> Omnytex Technologies >> >> http://www.omnytex.com >> >&g
Re: Googlecode Maven Repository for External Struts 2 Plugins
Ok, there appears to be an issue with the site then... when I view it in Macthon, my browser of choice, I don't see the buttons. In FF I see them just fine. I tried in IE7 as well and I see the same thing as Maxthon (which makes sense, since Maxthon is just a wrapper around IE). I fiddled with zoom factors and font size, since that's typically what causes things like this, but even at default font size and zooming, the buttons are not there (I can send a screenshot if anyone would like). It looks like, for whatever reason, the button graphics are not there, all I see is the text in white, so it blends with the background (partially... it slightly overlaps the gray bar there). Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Tue, November 27, 2007 12:40 pm, Philip Luppens wrote: > On 11/27/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> On Tue, November 27, 2007 12:15 pm, Philip Luppens wrote: >> > On 11/27/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> >> I don't disagree with most of what you say here, and what Phillip >> says >> >> in >> >> his reply, so let me make a more concrete suggestion: make the plugin >> >> registry much more prominent on the Struts home page (that is to say, >> >> mention it at all, since I don't see it on the front page anywhere at >> >> present). >> > >> > It has a 150px wide button in yellow on the homepage [1] ;-) >> > But I agree that it might need a bit more 'marketing'. >> >> Really?!? I'm either the biggest idiot on the face of the planet (which >> some might say is true regardless, but I digress) or I'm a lot blinder >> than I thought... I don't see it. It's not out of the realm of >> possibility that the proxy here at work has an older version of the page >> cached, I've seen that happen before, but I'm not seeing a big yellow >> button anywhere on struts.apache.org. What part of the page >> specifically >> is it in? > > It's on the Struts 2 homepage [1], not the struts.apache.org one. > > [1] http://struts.apache.org/2.x/ > > - Phil > >> >> > - Phil >> >> Frank >> >> -- >> Frank W. Zammetti >> Founder and Chief Software Architect >> Omnytex Technologies >> http://www.omnytex.com >> AIM/Yahoo: fzammetti >> MSN: [EMAIL PROTECTED] >> Author of "Practical Ajax Projects With Java Technology" >> (2006, Apress, ISBN 1-59059-695-1) >> and "JavaScript, DOM Scripting and Ajax Projects" >> (2007, Apress, ISBN 1-59059-816-4) >> Java Web Parts - http://javawebparts.sourceforge.net >> Supplying the wheel, so you don't have to reinvent it! >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Software Architect - Hydrodesk > "Always code as if the guy who ends up maintaining your code will be a > violent psychopath who knows where you live." - John F. Woods > > - > 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: Googlecode Maven Repository for External Struts 2 Plugins
On Tue, November 27, 2007 12:15 pm, Philip Luppens wrote: > On 11/27/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> I don't disagree with most of what you say here, and what Phillip says >> in >> his reply, so let me make a more concrete suggestion: make the plugin >> registry much more prominent on the Struts home page (that is to say, >> mention it at all, since I don't see it on the front page anywhere at >> present). > > It has a 150px wide button in yellow on the homepage [1] ;-) > But I agree that it might need a bit more 'marketing'. Really?!? I'm either the biggest idiot on the face of the planet (which some might say is true regardless, but I digress) or I'm a lot blinder than I thought... I don't see it. It's not out of the realm of possibility that the proxy here at work has an older version of the page cached, I've seen that happen before, but I'm not seeing a big yellow button anywhere on struts.apache.org. What part of the page specifically is it in? > - Phil Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). That way, it looks much more "official" and "endorsed", but still retains the benefits you outline here. Again, it's really just a matter of perception in the end, and if this helps make it look like something more than just some outside and yet completely independent entity, as does the Sourceforge project (which is at least mentioned on the home page), then that might be all that's needed to make it work. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Tue, November 27, 2007 11:54 am, Ted Husted wrote: > On Nov 27, 2007 11:22 AM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> It may be nothing more than a matter of perception and nothing more, but >> I >> think externally-hosted projects will automatically have a connotation >> of >> not being "golden" as you say, no matter what else is done to say >> otherwise, as I believe happened with the Sourceforge-hosted items. I >> may >> be wrong, but that's what I believe to be the case. > > Not all ASF projects are "golden", and there are many "golden" > projects that have not joined the ASF. Though, quite a few ASF > projects are popular; certainly more than the average open-source > startup. One reason is probably the ASF project management style, or > the "Apache Way". > > One effect of the Apache Way is that it tends to favor a conservative > approach. We need multiple people to agree to an implementation, or at > least agree to a release, and forging that agreement can work against > innovation. > > To help promote innovation at the ASF, we even started an Apache Labs > project, so that ASF committers could experiment with new code before > proposing an actual project. But, the Apache Labs are only open to > committers, and sometimes, we want to collaborate on a codebase with > someone who isn't a committer (at least, not yet). > > An important aspect of an external project is that it makes it easier > for Struts committers to work with other volunteers, without fussing > with the ASF brouhaha. The Apache Way is a great way to manage a > mature stable project, but it is not a great way to experiment with > new plugins. > > As an Struts PMC member, I am *very* concerned about plugin > proliferation in the standard distribution, mainly because the kids > need shoes, and we don't have enough volunteer hours to apply all the > patches that people already submit. I would like to encourage a plugin > commuity, and a shared external project seemed like one way to do > that. > > -Ted. > > - > 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: Googlecode Maven Repository for External Struts 2 Plugins
The other fairly obvious concern that I thought of after that last reply is how to deal with plugin authors... if these third-party plugins are hosted at Apache, their authors clearly would need some degree of commit priveleges to their own code bases. There's two ways I could see to deal with that. First, assuming there is infrastructure to do this (which I don't know to be the case), is to go ahead and make them commiters for their particular plugin only. This might be a nice way for people to gradually get more involved in Struts and Apache in general. Could actually foster the community even more in the long-run. I'm not aware of any project that's a precedent for this, maybe Commons? But just because something has never been done before doesn't mean it shouldn't be tried. Second, only host binaries at Apache and leave source code somewhere else. When an updated plugin is to be released, the author has to go through an existing committer to get it into the registry. This has the benefit of not introducing X number of new committers, even if of a limited variety, and keeps more control with the existing team. To be clear, I'm just tossing ideas out here. Most of you have known me for a while and know I have no problem suggesting things that rock the boat a bit :) This all stems from the premise that to be of as much use as possible, the plugin registry should look as "official" as possible, and I'm just thinking aloud about how that might be accomplished. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Tue, November 27, 2007 11:22 am, Frank W. Zammetti wrote: > On Tue, November 27, 2007 11:02 am, Dave Newton wrote: >> Licensing? > > The licensing issue, which Phil mentioned too, could be... I'm not sure > what the policy is around that, i.e., can a project hosted at Apache have > a non-ASL license? I'm not at all sure that's insurmountable though even > if it's not allowed... how many of the existing third-party plugins > currently aren't under the ASL (I'd bet few if any), and of those that > aren't, how many of those authors would have an issue with switching to > the ASL (also would bet not many)... I wouldn't think it would be too > onerous to say, as a policy statement, that if you want your plugin to be > in the Apache-hosted registry then you have to be under the ASL (if that's > actually a foundation requirement in the first place), and those that > don't want to be under that license can host externally but at least still > be listed in the Apache-hosted registry (with an asterisk next to it, ala > Barry Bonds- LOL). > >> I don't want to encourage a situation where there's a >> perception of "golden" plugins vs. everything else, >> and I'd assume (perhaps incorrectly) that projects >> hosted under the Apache umbrella would have to be >> Apache-licensed. > > This is my concern too, but I have a hard time believing that won't > automatically happen simply by being hosted outside Apache... I mean, how > many people, when I released the Ajax-enabled HTML taglib years ago, > thought it was second-class simply because it was on the Sourceforge site > and not under Apache itself? Would it have gotten more uptake if it was > in some "add-ons" subproject (for lack of a better term) of Struts? I > don't know, but I don't think it's a crazy thought. I'd hate to see any > third-party plugin, mine, yours or anyone's, not get the same sort of > attention as those entirely under the Struts umbrella, which it seems > everyone agrees with so far. > > It may be nothing more than a matter of perception and nothing more, but I > think externally-hosted projects will automatically have a connotation of > not being "golden" as you say, no matter what else is done to say > otherwise, as I believe happened with the Sourceforge-hosted items. I may > be wrong, but that's what I believe to be the case. > >> d. > > f(rank) :) > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > AIM/Yahoo: fzammetti > MSN: [EMAIL PROTECTED] > Author of "Practical Ajax Projects With Java Technology" > (2006, Apress, ISBN 1-59059-695-1) > and "JavaScript, DOM Scripting and
Re: Googlecode Maven Repository for External Struts 2 Plugins
On Tue, November 27, 2007 11:02 am, Dave Newton wrote: > Licensing? The licensing issue, which Phil mentioned too, could be... I'm not sure what the policy is around that, i.e., can a project hosted at Apache have a non-ASL license? I'm not at all sure that's insurmountable though even if it's not allowed... how many of the existing third-party plugins currently aren't under the ASL (I'd bet few if any), and of those that aren't, how many of those authors would have an issue with switching to the ASL (also would bet not many)... I wouldn't think it would be too onerous to say, as a policy statement, that if you want your plugin to be in the Apache-hosted registry then you have to be under the ASL (if that's actually a foundation requirement in the first place), and those that don't want to be under that license can host externally but at least still be listed in the Apache-hosted registry (with an asterisk next to it, ala Barry Bonds- LOL). > I don't want to encourage a situation where there's a > perception of "golden" plugins vs. everything else, > and I'd assume (perhaps incorrectly) that projects > hosted under the Apache umbrella would have to be > Apache-licensed. This is my concern too, but I have a hard time believing that won't automatically happen simply by being hosted outside Apache... I mean, how many people, when I released the Ajax-enabled HTML taglib years ago, thought it was second-class simply because it was on the Sourceforge site and not under Apache itself? Would it have gotten more uptake if it was in some "add-ons" subproject (for lack of a better term) of Struts? I don't know, but I don't think it's a crazy thought. I'd hate to see any third-party plugin, mine, yours or anyone's, not get the same sort of attention as those entirely under the Struts umbrella, which it seems everyone agrees with so far. It may be nothing more than a matter of perception and nothing more, but I think externally-hosted projects will automatically have a connotation of not being "golden" as you say, no matter what else is done to say otherwise, as I believe happened with the Sourceforge-hosted items. I may be wrong, but that's what I believe to be the case. > d. f(rank) :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote: > >> I was involved with the Sourceforge project Ted >> mentioned, as well as >> having a couple of S2 plugins in the registry now... >> my question, which I >> had for the Sourceforge project too, was why not >> host this at Apache and >> have it under Struts itself? If we're talking about >> CLAs for GC >> contributions now too, I'm not sure I see the >> difference. If it's a >> question of perception, i.e., if it's external than >> no plugin is >> officially endorsed or anything, that seems to run >> contrary to listing >> developers and all that's being talked about here. >> I can't imagine >> there's infrastructure issues that couldn't be dealt >> with. >> >> Why wouldn't/couldn't/shouldn't/*dn't this be put >> officially under the >> Struts umbrella and hosted alongside Struts itself? >> >> Frank >> >> -- >> Frank W. Zammetti >> Founder and Chief Software Architect >> Omnytex Technologies >> http://www.omnytex.com >> AIM/Yahoo: fzammetti >> MSN: [EMAIL PROTECTED] >> Author of "Practical Ajax Projects With Java >> Technology" >> (2006, Apress, ISBN 1-59059-695-1) >> and "JavaScript, DOM Scripting and Ajax Projects" >> (2007, Apress, ISBN 1-59059-816-4) >> Java Web Parts - http://javawebparts.sourceforge.net >> Supplying the wheel, so you don't have to reinvent >> it! >> >> On Tue, November 27, 2007 8:48 am, Tom Schneider >> wrote: >> > I think having separate googlecode projects for >> each plugin has worked >> > well up to this point. Creating a googlecode >> project is quick and >> > easy. Googlecode seems to be designed to have a >> lot of really small >> > projects, rather than one big projects with many >> subprojects. The one >&g
Re: Googlecode Maven Repository for External Struts 2 Plugins
I was involved with the Sourceforge project Ted mentioned, as well as having a couple of S2 plugins in the registry now... my question, which I had for the Sourceforge project too, was why not host this at Apache and have it under Struts itself? If we're talking about CLAs for GC contributions now too, I'm not sure I see the difference. If it's a question of perception, i.e., if it's external than no plugin is officially endorsed or anything, that seems to run contrary to listing developers and all that's being talked about here. I can't imagine there's infrastructure issues that couldn't be dealt with. Why wouldn't/couldn't/shouldn't/*dn't this be put officially under the Struts umbrella and hosted alongside Struts itself? Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Tue, November 27, 2007 8:48 am, Tom Schneider wrote: > I think having separate googlecode projects for each plugin has worked > well up to this point. Creating a googlecode project is quick and > easy. Googlecode seems to be designed to have a lot of really small > projects, rather than one big projects with many subprojects. The one > thing that ties everything together is the plugin registry. If > anything, I'd rather see that expanded. Maybe add a list of developers > to the plugin registry. I think the apache developers would feel more > obligated to maintain something hosted on Apache as opposed to something > hosted on googlecode. As you may be able to tell, not a lot of the > googlecode plugin sites have a ton of content. The only reason I > created a common maven repository is so that end users only have to add > one plugin repository to get access to most of the plugins. > > Ted Husted wrote: >> Very cool, Tom. >> >> Has anyone started a shared GoogleCode project for Struts 2 plugins yet? >> >> The notion being that instead of everyone starting up one-off >> projects, we could have one GC project that anyone with a Google ID >> could join and use to maintain a "third-party" Struts 2 plugin -- a >> Struts 2 Plugin Commons. >> >> Of course, the group could still have a select group of owners that >> could remove someone who joined and then turned out to be a troll. >> >> -Ted. >> >> On Nov 25, 2007 10:12 AM, Tom Schneider <[EMAIL PROTECTED]> wrote: >> >>> Hey all, >>> I finally figured out a way to host a maven repository on googlecode. >>> This should greatly simplify using googlecode hosted plugins in Struts >>> 2. For me, it's also much nicer to use maven to deploy than trying to >>> get a jar manually uploaded into the central repository. Instructions >>> on how to use this repo for Struts 2 projects are at: >>> http://code.google.com/p/struts2plugin-maven-repo/ >>> >>> Anyone who has a plugin hosted at googlecode can use this maven >>> repository to host their plugin. (I've already added several >>> developers >>> that I know of, if your not in the list let me know) I've also already >>> added several of my more popular plugins. I plan on adding the rest as >>> time permits. Please look at the scope plugin (on googlecode) for an >>> example of how to configure maven to deploy to this repository. >>> Tom >>> >> >> - >> 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: Confluence Rate Plugin for the Plugin Registry
On a related note, what's the policy WRT putting plug-ins in the main list (the section after the news items)? I see the note on the page saying plug-ins hosted externally should be listed as news items, which I've done for my two plug-ins, but it seems there's a number of them in the main list that are hosted at Google code and elsewhere... I'd like to have my plug-ins in the main list so they are available for voting too (I'd think we'd want all plug-ins to have voting available so that those that become popular might be considered for addition to the main Struts distro down the road). Any objections to me adding mine to the list? If not, should that note be removed from the page altogether? Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! Tom Schneider wrote: Thanks for doing this Don, I appreciate you taking the lead on this. Did you vote for all your own plugins? :) Tom On Nov 14, 2007 4:17 PM, Don Brown <[EMAIL PROTECTED]> wrote: Done. Unfortunately, the latest version requires a newer version of Confluence, so I installed an older version. I placed the macro on each plugin page, but found a couple of issues: * Anyone can reset the ratings * The table report doesn't seem to work right, so I didn't put that report on the home page * New votes won't kick off an export of the page, so users using the static page won't see the new votes Still, I think it is better than nothing, so vote away. Don On 11/11/07, Tom Schneider <[EMAIL PROTECTED]> wrote: I know I've mentioned this before, but I was wondering if we could use this plugin: http://www.atlassian.com/software/confluence/plugins/rate.jsp To provide user rating capabilities for the plugin registry. As more and more of the core functionality becomes plugins, I think it makes sense to let people vote on the plugins so new users have an idea of which plugins are the most popular. Tom - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Plugins gone wild!
Ted Husted wrote: On 10/22/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: I'm still not 100% convinced there's a ton of benefit to this plugin frankly, other than perhaps visibility, but it's there now in any case. The benefit of the Dojo plugin isn't that it enables Dojo, but that it enables some of the Struts tags to use Dojo transparently. True, but I was talking about APT, and in that case it's not really making anything easier as far as I can tell... APT is already pretty close to plug-and-play as you know... aside from making the config file name a default, which would benefit both the plugin and APT outside of S2, can you see any way to make it more useful as a plugin? -Ted. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Plugins gone wild!
On Mon, October 22, 2007 6:48 am, Ted Husted wrote: > Arguably, we could also include an Ajax plugin in the "standard > array", but I would like to explore alternatives to the Dojo plugin. I > think we should maintain a Dojo plugin, just as we plan to maintain a > Spring plugin, but I'd also like to try an AjaxParts or a (complete) > YUI plugin before we pull the trigger. FYI, I just posted an APT plugin and example aoo. I think there's one thing that I need to change in APT, and that's a default config file name. That way, there would be no web.xml context param to set, you could truly just drop this in and go. I'll see about doing that this week and updating the plugin. I'm still not 100% convinced there's a ton of benefit to this plugin frankly, other than perhaps visibility, but it's there now in any case. > We might also want to consider whether we should grow the JSON plugin > into a web-services plugin. Starting next month, I'll be doing a lot > more work with web services myself. > > -Ted. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rest vs DWR was (Proposal: Rest Plugin)
Don Brown wrote: 3. Your private remote API is your public API - your Ajax app is just another consumer of your remote api. This makes tools like mashups possible with no extra work. DWR endpoints aren't meant to be consumed externally. I think this point especially is where the value of this plugin lies IMO... I think I could probably debate the others, but this one I think is a really good point. Thanks Don, I appreciate your insight! Don Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Proposal: Rest Plugin
Don Brown wrote: Completely agree. A lot of Struts developers have started moving to more Ajax-centric approaches where the server-side is mostly static html and DWR. I think that Rest provides a more useful and ultimately flexible solution, especially if you get things like XML and JSON encoding for free like in this plugin. I'm one of those developers, so I'm curious to hear, how do you find the RESTful approach to be more useful and flexible? I'm not saying I disagree or anything, the fact is I've done the REST approach as well and have been quite happy with it... in fact, I could argue they are just different forms of the same underlying concept.. but being one of those doing the DWR thing now, I'm more and more feeling like it's really the best answer (the basic idea is I mean, whether DWR is the best implementation or not might be debatable). I'd love to hear why you view a REST-based approach as being better, and especially how you see it as being more flexible. Frank P.S., I don't want to hijack your thread Don, so if you feel this is a bit too tangential please do change the subject for any reply you may make to avoid that. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] [ANN] Three Struts Tutorials or Presentations at ApacheCon US 2007 Atlanta GA
On Wed, October 3, 2007 1:33 pm, Dale Newfield wrote: > ...is this the type of convention where people spend the evenings out > having nice meals/drinks with colleagues, or where people spend the > evenings quietly hacking away on laptops? You say that as if they're mutually exclusive :) True geeks can do both at the same time without a problem! LOL > -Dale Newfield > [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Jira Spam
.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 Defaced by an0de - D.O.M Team - # Spain 2007 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S1 makes history: 90% of all reported issues closed!
On Wed, September 19, 2007 10:46 am, Martin Cooper wrote: > On 9/19/07, Paul Benedict <[EMAIL PROTECTED]> wrote: >> >> Ted, >> >> You can come up with the wording. I am not Mr. Prose :-) If you need >> numbers, we have over 2500+ closed defects. > > > Yeah, but that makes it sound like Struts was buggy as hell, if we had > that > many to "fix"... That was my thought when I saw this too, and I think it highlights the problem well... I'm not sure there's really a way to write such a release that can't very easily be spun negatively (or simply taken negatively without any real spinning involved), and my advice would be to not try. I'd say make an announcement on the @dev list, because I know your proud of the accomplishment Paul, and that's cool, but beyond the Struts developers (and those of us that watch that list as well), I'm not sure this is the type of thing you should make a big fuss about anyway. I don't recall ever having seen another reasonably-sized project make an announcement because they did, frankly, what is kind of expected of any active project anyway. Pat yourself on the back with your fellow developers on @dev, you deserve that much certainly, but leave it there. That's my opinion anyway. > -- > Martin Cooper > > Paul Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] [2.1.x] Bundled Plugins
Martin Cooper wrote: I honestly don't see that we could point at some other project outside the ASF and say that we "endorse" the plugins produced by that project when what we are really saying is that we don't consider those plugins to be sufficiently worthy to live at the ASF. I suppose that's one interpretation. I'd see it more like struts.sourceforge.net though... it's just an external location where things can live and develop. Maybe saying it's "endorsed" does go too far, but just pointing it out and saying "there's some plugins that may or may not eventually make it into the mainline distribution", wouldn't that be OK? I mean, I haven't looked in a while, but I recall there being a link to struts.sourceforge.net on the main Struts site... does that qualify as an endorsement? I wouldn't think so, but maybe I'm wrong there. > Plus, I personally would have a pretty fundamental problem with "endorsing" any one specific project outside the ASF in preference to any other. I would too from the perspective of Struts as a project endorsing something, no question. But I think it's a question of semantics: calling something a project carries certain connotations, so maybe that's the wrong word to use... Repository? Registry? Catalog? I don't think these carry the same connotations, but all could equally describe such an external entity. > I suspect we could get into legal trouble over that sort of thing. You may be right about that, my Bar card hasn't arrived yet so I can't say ;) -- Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ajax Theme
Musachy, are you talking 10%-15% difference between the Ajax tags in 2.0.x and 2.1.x, or in versions of Dojo? Frank Musachy Barroso wrote: There aren't many differences, lots of bug fixes and some new features based on user request from the user list, I would say 10%-15%. musachy On 8/19/07, Ian Roughley <[EMAIL PROTECTED]> wrote: My personal preference would be out of Struts - unless, the plugins within Struts2 can have independent life cycles (which at the moment doesn't seem to be the case). And, once again, this is biased on the implementation of the ww2 tags where the dojo API was rapidly changing :) If the dojo API has settled to a point where s2 can be one or two point release behind the most recent, or user can easily swap out the s2 dojo scripts for the most recent dojo scripts and have the plugin functionality work, I would be okay with the dojo plugin staying in the struts2 core as a plugin. Musachy, - what is the percentage of code that has changed between 2.0.x and 2.1.x as far as the Ajax tags implementation goes? /Ian Musachy Barroso wrote: do you mean to move the plugin out of Struts? Because Dojo is already on its own plugin in trunk. musachy On 8/18/07, James Holmes <[EMAIL PROTECTED]> wrote: +1 on moving Dojo out of the core to a plugin. -Original Message- From: Ian Roughley [mailto:[EMAIL PROTECTED] Sent: Saturday, August 18, 2007 1:34 PM To: Struts Developers List Subject: Re: Ajax Theme So let me ask this - what is the percentage of code that has changed between 2.0.x and 2.1.x as far as the Ajax tags go? To answer Ted's questions, my feeling to is move them out the core and into a plugin. There have been quiet a few headaches with dojo upgrades during the initial ww2 implementation. If nothing else, it would allow the dojo and s2 release schedules to proceed independently (i.e. s2 users would not be forced to use an old version of dojo until the new s2 release, because of a dojo API change). /Ian Musachy Barroso wrote: On 2.1 ajax validation will be provided by Dojo by default, but other libraries can be used easily, (with prototype example): http://struts.apache.org/2.x/docs/ajax-validation.html musachy On 8/17/07, Ted Husted <[EMAIL PROTECTED]> wrote: I haven't dived into this part of the source code, but I've beent taking "The ajax validation depends on DWR" to mean that we use DWR to call the usual server-side validators from client-side ajax code. Is that correct? Is the use of DWR changing from 2.0.x to 2.1.x? Does the YUI Ajax plugin support validation? Has anyone tried the YUI plugin against the head? (And just to make our question day complete:) Do we want to bundle the Dojo plugin with Struts 2.1.x, or do we want to consider moving it to a Google Code site (perhpas with YUI), while it is still "experimental": -Ted. On 8/15/07, Musachy Barroso <[EMAIL PROTECTED]> wrote: The ajax validation depends on DWR musachy On 8/15/07, Ian Roughley <[EMAIL PROTECTED]> wrote: Is the ajax theme in the 2.0.x branch completely Dojo driven now? If so, there seems to be a lot of DWR code that could be removed (i.e. from the web.xml and form.ftl). I can open a ticket if this is the case. /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted <http://www.husted.com/ted/blog/> - 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] -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] [2.1.x] Bundled Plugins
Martin Cooper wrote: Perhaps. Perhaps not. But it's pretty much guaranteed that we would lower the base of people who _could_ use them if they're not here. Some companies (my current employer included) require approval for each and every open source component before it can be used within the company. FYI, I'm in the same boat where I am, and I know the hassles we go through sometimes to get various libraries/components/whatever approved, so I definitely know where your coming from with this point. In talking to other folks, this doesn't seem to be unusual at all. I disagree. I think it is just fine to distribute such code. If people start to use it and have problems with it, then perhaps this will drive additional contributors to it. Gaining additional contributors to it as part of Struts seems much more likely to me than if it's off in the weeds somewhere. You mentioned the "...respected source such as the ASF" in the previous paragraph, and I certainly agree. I think however that if the approach was as you say, that potentially untested code, or more accurately code not used to a great extent by active committers, which I believe is what Ted was talking about, was coming out of a respected ASF project, it's not hard to imagine that respect declining when a lot of bug reports are opened for a particular plugin. One plugin could wind up ruining the good reputation of the larger project. And if no one was maintaining and using that code to begin with, I think it's a bit of a gamble to hope someone will be spurred into action by some negative feedback. Maybe someone will be, but I don't think that's a risk worth taking if you want to keep a good reputation and keep being a respected project :) I for one see Ted's suggestion as a good compromise... you could almost in a sense view the external location, wherever that happens to be, as something of a plugin incubator... assure the code has a community of developers willing to maintain it and ensure it's at a level of quality that fits in with the rest of the S2 distro proper, and *then* roll it in to the distro later. For any plugin that there's any doubt about today (and I don't know which those are), they can be shifted there and allowed to grow that community. And if some never do, it's not the end of the world: they're still there for anyone that wants them. To address the concern you raised about approvals, I think it would be important to make the external location an endorsed source of plugins. Maybe it makes more sense to have a plugins subproject under Struts, I don't know, but whatever the case, so long as people understood that yes, this plugin repository/incubator/whatever was *the* approved place to get plugins from, I believe the approval process would be eased a bit for most users in that same situation as we are. At the end of the day, it's always said that an ASF project depends on developers who themselves are using the code. It's supposed to be code for themselves that they happen to share with others, that's how I've come to understand the underlying concept anyway. If that's true, then it seems like keeping code in S2 that might not be maintained and actually used by active commutters is a contradiction of that, and Ted's suggestion offers a viable alternative that keeps the code alive, and in fact presents (possibly) a better chance for it to succeed. -- Martin Cooper Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts 2 OSGi Plugin
Cool, I look forward to either of those... even though I'm not using S2 in production yet, it'd be a nice feature to see, really true hot-loading. Thanks Don! Frank Don Brown wrote: At this point, the /bundles directory is only read on startup, however, it wouldn't be too hard to add a polling scanner. The better solution will be to write a GUI that will let you install, uninstall, and upgrade bundles at runtime. Don On 7/30/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Don, could you clarify something for me? You say "Drop the jar into the /WEB-INF/classes/bundles directory and it will automatically be installed when the application starts up" ... so if I have a running application, I have to restart it for the deploy to happen... is that restart always going to be necessary, or is that just a side-effect of this being an early release? Frank Don Brown wrote: Writing an OSGi plugin for Struts 2 has been something I've been playing with on and off since I put in place the Struts 2 plugin architecture, and I finally completed an end-to-end functional spike of such a beast. My motivation for a Struts 2 OSGi plugin is to easily allow Struts 2 developers to write their applications such that they can install, upgrade, and uninstall sections of it at a time without restarting or reloading the whole application or application server. Think how nice it would be to install a new admin tool in your public, heavily-used web application without affecting any users, or fixing a critical bug without, again, taking the application down even for a few seconds. The Struts 2 OSGi plugin allows you to separate your application into jars (called bundles), each containing a struts.xml file, Action classes, and Velocity (for now) files. Just by adding a few lines in the jar's manifest.mf: Bundle-Activator: org.apache.struts2.osgi.StrutsActivator Export-Package: com.mycompany.myapp.actions Bundle-Version: 1.0.0 Bundle-SymbolicName: foo.actions The jar is ready to be deployed. Drop the jar into the /WEB-INF/classes/bundles directory and it will automatically be installed when the application starts up. As this was a spike, there are a bunch of limitations and missing features such as: * Only Velocity templates are supported * Application classes, including third-party jars such as Spring, will probably not be available in bundles * No GUI to install, upgrade, and uninstall bundles at runtime * Bundles cannot contain beans or constants (will probably never be allowed) * Most likely improper OSGi usage Still, the code is functional and available in the Struts sandbox: http://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-osgi-plugin/ One of my side goals in this project is to hide as much of OSGi from the Struts 2 developer as possible, so that bundles will be easy to write and deploy. Therefore, there is probably a lot of OSGi that is hidden, which OSGi experts would lament, but the main goal is to allow Struts actions to be hot deployable, and I think this plugin could make it happen. Don -- copied from my blog post for those too lazy to click links: http://www.jroller.com/mrdon/entry/struts_2_osgi_plugin_spike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007 3:50 PM -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts 2 OSGi Plugin
Don, could you clarify something for me? You say "Drop the jar into the /WEB-INF/classes/bundles directory and it will automatically be installed when the application starts up" ... so if I have a running application, I have to restart it for the deploy to happen... is that restart always going to be necessary, or is that just a side-effect of this being an early release? Frank Don Brown wrote: Writing an OSGi plugin for Struts 2 has been something I've been playing with on and off since I put in place the Struts 2 plugin architecture, and I finally completed an end-to-end functional spike of such a beast. My motivation for a Struts 2 OSGi plugin is to easily allow Struts 2 developers to write their applications such that they can install, upgrade, and uninstall sections of it at a time without restarting or reloading the whole application or application server. Think how nice it would be to install a new admin tool in your public, heavily-used web application without affecting any users, or fixing a critical bug without, again, taking the application down even for a few seconds. The Struts 2 OSGi plugin allows you to separate your application into jars (called bundles), each containing a struts.xml file, Action classes, and Velocity (for now) files. Just by adding a few lines in the jar's manifest.mf: Bundle-Activator: org.apache.struts2.osgi.StrutsActivator Export-Package: com.mycompany.myapp.actions Bundle-Version: 1.0.0 Bundle-SymbolicName: foo.actions The jar is ready to be deployed. Drop the jar into the /WEB-INF/classes/bundles directory and it will automatically be installed when the application starts up. As this was a spike, there are a bunch of limitations and missing features such as: * Only Velocity templates are supported * Application classes, including third-party jars such as Spring, will probably not be available in bundles * No GUI to install, upgrade, and uninstall bundles at runtime * Bundles cannot contain beans or constants (will probably never be allowed) * Most likely improper OSGi usage Still, the code is functional and available in the Struts sandbox: http://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-osgi-plugin/ One of my side goals in this project is to hide as much of OSGi from the Struts 2 developer as possible, so that bundles will be easy to write and deploy. Therefore, there is probably a lot of OSGi that is hidden, which OSGi experts would lament, but the main goal is to allow Struts actions to be hot deployable, and I think this plugin could make it happen. Don -- copied from my blog post for those too lazy to click links: http://www.jroller.com/mrdon/entry/struts_2_osgi_plugin_spike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1/2 and Logging
FWIW, my opinion would be go ahead and change it... unless someone can show where it would cause trouble, I'm in the better safe than sorry camp. I know of a number of instances where I've seen Struts installed in a shared way, either at EAR-level or something like Tomcat's shared libs directory... I've never heard any trouble reported from those cases though to be fair. I think the performance/memory implications are the only thing that might stop you from wanting to do this... perhaps some benchmarking is in order? Frank Paul Benedict wrote: I use WAS 6.0 at work and it took me 3 full days to figure out how to get log4j working with it. Ugh. Yes, the software is an elephant. Anyway, despite the fact that Struts 1 supports only static logging, I believe this position could be evaluated. Correct me when wrong, but the article states that instance logging should belong in libraries that could be shared. What if a company wants to integrate Struts or XWork into their application server software? Perhaps a typically user wouldn't want to share Struts libraries in the parent classloader, but what about in J2EE server? It's just a thought. It wouldn't be too hard to convert the static loggers. Paul Frank W. Zammetti wrote: Martin Cooper wrote: It would be the same thing in the sense of the "direction" of the class loader, and I would expect the same screwy things to happen. And if you're using WebFear, then I'd fully expect other screwy things to happen as well, as a free bonus. ;-) Hehe, I know *exactly* what you mean :) Between WS and RAD, my hair is starting to look like Bill Clinton's, but at a much younger age! Martin Cooper Frank - 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] -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1/2 and Logging
Martin Cooper wrote: It would be the same thing in the sense of the "direction" of the class loader, and I would expect the same screwy things to happen. And if you're using WebFear, then I'd fully expect other screwy things to happen as well, as a free bonus. ;-) Hehe, I know *exactly* what you mean :) Between WS and RAD, my hair is starting to look like Bill Clinton's, but at a much younger age! Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1/2 and Logging
How about Struts JARs at the EAR level? Wouldn't that be loaded (by default anyway) by a higher-level classloader than individual apps and shared across all WARs in the EAR? Not sure that's quite the same thing though (and I'm basing this on Websphere, which as we all know has some of the most convoluted classloader schemes around, version 5.x and prior at least). Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! Rene Gielen wrote: Very interesting article, indeed. Both WW and S2 use static loggers, as it was always considered best practice... On the other hand, the problem only applies if a shared classloader is used, and I can hardly imagine a setup where struts jars are deployed eg. in $CATALINA/commons/lib rather than being provided with the deployed webapp. Is there any situation where we would recommend sharing s1/s2/xw among applications, or where it really makes sense? Even if calling Logger.getLog is not a real performance killer, I would prefer to call it not on every single object instance creation if there is no serious, non-exotic reason... Regards, Rene Paul Benedict schrieb: Simon was correct and I believe this should be addressed. Does anyone have objections or advice on this issue? How about you WW guys? Have you been doing the same static logging? Wendy Smoak wrote: On 7/6/07, Paul Benedict <[EMAIL PROTECTED]> wrote: Has anyone ever read this? http://wiki.apache.org/jakarta-commons/Logging/StaticLog Did you check the archives? Simon mentioned it well over a year ago, with no replies: http://www.nabble.com/commons-logging-and-static-log-members-t1244201.html - 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: Has the WebWork rebranding to Struts2 been a failure?
It's been amusing to me that the people slamming Struts (not saying you Martin, talking generically) for this, that and the other thing are the same people making their living developing applications on it... it's also amusing that those same people won't get off their collective arses and come up with something better themselves. It's funny to me sitting here because I understand asking the question you've asked because I used to have the same frame of mind, and that's really what this is about, as Don and Ted have succinctly said. Struts, or any other open-source project (generally, always some exceptions) aren't about market share, or making a name for anybody, it's about a group of people with similar goals developing software that THEY THEMSELVES want to use. If 100,000 people see it and say "hey, that's cool" and use it, that's great. If absolutely nobody likes and and nobody decides to use it, as long as the original creators like it and use it, than that project can rightly be deemed a success. Such is the case for Struts2. So long as there are developers willing to work on S2, who are using it themselves (to some degree... for example, I've only used it a little bit myself yet I've contributed a plugin already) then it's doing exactly what its supposed to be doing. Whether the download count is high or low, whether this blog or that said good things or bad things about it, whether everyone is using it or no one is, there's an active, thriving developer community made up of people who are using S2 themselves and helping each other, so everything is as it should be. And about those who have a negative impression of Struts... people are quick to try and knock down what's on top. There has been a growing backlash against Struts for some time, for whatever reasons... lots more people making negative comments about it. But, as I said at the beginning, it's amazing to me that those same people very often are using Struts all the time to make a living, and not themselves trying to jump in and make it better, or coming up with something else entirely that's better. Also, I dare say a great many of the people complaining about S2 now haven't given it much time or attention and have simply assumed it's S1++. That's just foolish. Finally, having all these alternative frameworks is fantastic, but until one of them has more than a trivial user base, comparing them to Struts in terms of success or failure isn't even a reasonable thing to do IMO. It's kind of like saying one of Jupiter's moons has a greater gravitational pull than Jupiter just because the moon looks prettier! Let the moon gain *significant* mass first, then we'll compare :) (hehe, interestingly, the mass-gaining analogy works equally as well if you replace Jupiter with your wife and the moon with that hot blond down the street that hasn't had 4 kids yet! ... and for the women on the list, replace Jupiter with your husband and the moon with Brad Pitt before he settles down, loses his money and gets a beer gut!) A while back, I learned to just shut my mouth, not bitch about everything and just write the code I wanted to write, that I wanted to use, put it out there and let whatever happens just happen. I'm actually developing my own framework for precisely this reason. This is a lesson the people complaining all the time need to learn, and this is also ultimately what the Struts community is actually doing, just under a more well-known name and with greater visibility than most. So, I understand the thought process that goes into asking the question you asked, and I also understand now why it's a fundamentally flawed question to ask in the first place. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! Martin Gilday wrote: This is something I have been thinking about for a while, but has been highlighted by Wicket recently graduating from the Apache Incubator. When checking out blogs, newsgroups, theserverside, infoq etc it has become apparent to me that Struts 2 is still very much thought of as just Struts 1++, in a negative sense. When you see posts by people saying which web frameworks they have tried out because they were unhappy with Struts 1 then Wicket, Click, Tapestry are mentioned. Struts 2, however, is always seemingly dismissed without a look, as they feel all the problems they have with Struts 1 must sti
Re: [S2] Releasing a plugin
Ah ok, I think Ted actually pointed that out to me as well, but I don't think it really registered in my brain until now. Thanks for the explanation Tom! Frank Tom Schneider wrote: Frank, Everything looks good to me. With the plugin registry, there is the main website and the wiki for editing the plugin registry. Your announcement won't show up on the website until it's synced up with the wiki overnight. Right now it's showing up on the wiki, but not on the main website. After a day or so it should show up on the main website as well. It took me a bit to figure this out myself. Tom Frank W. Zammetti wrote: Can anyone lend me a hand with something? I posted a news item on the plugin registry page announcing the beta release of this plugin, and I thought I saw it there initially, but now it's not showing up... what's weird is that if I hit the Browse Space link, it does show up there... any ideas what I borked? Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Releasing a plugin
Can anyone lend me a hand with something? I posted a news item on the plugin registry page announcing the beta release of this plugin, and I thought I saw it there initially, but now it's not showing up... what's weird is that if I hit the Browse Space link, it does show up there... any ideas what I borked? Frank Frank W. Zammetti wrote: Ok Don, good enough, thanks. I just wasn't sure if there was any sort of actual procedure in place. Look for it to be up in the next day or two (just have some final checks to do). And I'll definitely announce it. Take care, Frank Don Brown wrote: Just copy what others have done: add a page with your plugin docs, probably using the page template that's available. It wouldn't hurt to announce it in user@ either. Don On 6/8/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Hi everyone... I'm just about finished putting together my first plugin, allowing for usage of the DataVision reporting package with S2 (was a great learning experience, and I'm pushing some folks at work to move to S2 sooner than later, and I know I'm going to need this for one project). My question is about releasing it... I know there is the plugin registry, and I'd like to put it up there, but I'm not sure the procedure involved. Can anyone provide some guidance? Or should I just post it someone else and announce it on @user? TIA, Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.11/838 - Release Date: 6/7/2007 2:21 PM -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Releasing a plugin
Ok Don, good enough, thanks. I just wasn't sure if there was any sort of actual procedure in place. Look for it to be up in the next day or two (just have some final checks to do). And I'll definitely announce it. Take care, Frank Don Brown wrote: Just copy what others have done: add a page with your plugin docs, probably using the page template that's available. It wouldn't hurt to announce it in user@ either. Don On 6/8/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Hi everyone... I'm just about finished putting together my first plugin, allowing for usage of the DataVision reporting package with S2 (was a great learning experience, and I'm pushing some folks at work to move to S2 sooner than later, and I know I'm going to need this for one project). My question is about releasing it... I know there is the plugin registry, and I'd like to put it up there, but I'm not sure the procedure involved. Can anyone provide some guidance? Or should I just post it someone else and announce it on @user? TIA, Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.11/838 - Release Date: 6/7/2007 2:21 PM -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[S2] Releasing a plugin
Hi everyone... I'm just about finished putting together my first plugin, allowing for usage of the DataVision reporting package with S2 (was a great learning experience, and I'm pushing some folks at work to move to S2 sooner than later, and I know I'm going to need this for one project). My question is about releasing it... I know there is the plugin registry, and I'd like to put it up there, but I'm not sure the procedure involved. Can anyone provide some guidance? Or should I just post it someone else and announce it on @user? TIA, Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] JARs in plugins
Thanks Ted! Very minor update done now as well :) Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Wed, June 6, 2007 2:18 pm, Ted Husted wrote: > On 6/6/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> I'd be happy to... I don't seem to have permissions to edit the guides >> pages though > > Done. > >> (or are these docs auto-generated by the build process?) > > The ones to edit are here: > > * http://struts.apache.org/2.x/index.html > > The static HTML pages are autogenerated on every change, but they need > to make it over from another server, so there is some latency before a > change makes it back to the main Struts site. But, if you select the > edit link, it will take you to the right place. :) > > -Ted. > > - > 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] JARs in plugins
On Wed, June 6, 2007 1:07 pm, Ted Husted wrote: > On 6/6/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> All this does however, to me anyway, mean that plugins can't really be >> called self-contained, and saying "...can extend the framework just by >> adding a JAR to the application's classpath" in the documentation isn't >> 100% accurate (99% maybe). > > They are self-contained in the sense that all the Struts configuration > is included, and that we do not need to do anything except drop in the > JAR and ensure that any of the JARs dependencies are available to the > container. (Otherwise, we end up reinventing Maven!) Yep, fair enough... perhaps worth clarifying though, because although I haven't done it, I could certainly see where I would have dropped a plugin JAR in, expecting it to work, and wondering why it blew up instead :) > Feel free to update the documentation with that clarification :) I'd be happy to... I don't seem to have permissions to edit the guides pages though (or are these docs auto-generated by the build process?) > -Ted. Frank > - > 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] JARs in plugins
On Wed, June 6, 2007 12:57 pm, Musachy Barroso wrote:
> The whole auto-unpacking thing could quickly become a nightmare, not a
> good
> idea IMO.
Yeah, your probably right... If there was a way to ensure you didn't have
two versions of the same class in two different JARs I might feel
differently, but I suspect that's not possible, not without something a
bit drastic like writing a custom classloader... I for one certainly don't
want to go there :)
All this does however, to me anyway, mean that plugins can't really be
called self-contained, and saying "...can extend the framework just by
adding a JAR to the application's classpath" in the documentation isn't
100% accurate (99% maybe).
Ok, well, doesn't matter, I made my changes and have things working now,
so thanks for the clarification on this guys.
Frank
> @Phil: last time I tried to get OSGi and Struts together I failed
> miserably,
> I even feel dumber after that :). Someday I will try again, but that time
> I
> will actually read OSGi documentation first.
>
> musachy
>
> On 6/6/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>>
>> No, I wouldn't want to repack JARs... we actually do that with Java Web
>> Parts with a couple of Commons packages, but what I'm working on now has
>> a
>> larger number of dependencies and they are a little more complex.
>> Definitely wouldn't want to do any bytecode manipulation either, or any
>> other voodoo for that matter ;)
>>
>> If a plugin is to be truly "drop in and go", that kind of implies all
>> dependencies are included, doesn't it? That's what my naive little mind
>> had in its brain LOL... if that's not the case, so be it, I'll just need
>> to document the dependencies and modify my build script a little, not
>> the
>> end of the world.
>>
>> That wouldn't make a terrible S2 enhancement though, the ability to
>> (optionally) unpack any JARs in a plugin JAR and add them to the
>> classpath
>> (not even sure you can do that dynamically). Would let developers make
>> plugins truly self-contained and also ensure proper versioning of
>> dependent libraries... of course, there's that nagging conflicting
>> versions issue, so maybe not such a great idea :(
>>
>> Thanks,
>> Frank
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>> AIM/Yahoo: fzammetti
>> MSN: [EMAIL PROTECTED]
>> Author of "Practical Ajax Projects With Java Technology"
>> (2006, Apress, ISBN 1-59059-695-1)
>> and "JavaScript, DOM Scripting and Ajax Projects"
>> (2007, Apress, ISBN 1-59059-816-4)
>> Java Web Parts - http://javawebparts.sourceforge.net
>> Supplying the wheel, so you don't have to reinvent it!
>>
>> On Wed, June 6, 2007 11:59 am, Dave Newton wrote:
>> > You can also consider using Jar Jar Links ("o,
>> > me-sa gonna muck witha your bytecodes", or if you
>> > prefer a more recent meme, "IM UP IN UR JARZ TWEAKIN
>> > UR PKGS") if you are coupled to a specific release and
>> > want to ensure there's no possibility of library
>> > conflict with webapp libs.
>> >
>> > Dave
>> >
>> > --- Philip Luppens <[EMAIL PROTECTED]> wrote:
>> >
>> >> On 6/6/07, Frank W. Zammetti <[EMAIL PROTECTED]>
>> >> wrote:
>> >> > Hi everyone... I'm writing my first S2 plugin and
>> >> I'm running into a
>> >> > problem, which may well just be one of
>> >> understanding.
>> >> >
>> >> > I had thought that any JAR placed in the root of
>> >> the plugin JAR would be
>> >> > added to the path, but this seemingly isn't the
>> >> case. My understanding is
>> >> > that a plugin JAR is a self-contained entity, and
>> >> this to me means it
>> >> > should include any JARs it is itself dependant on.
>> >> >
>> >> > So, is my understanding correct, and assuming so,
>> >> how can I get those
>> >> > internal JARs available? I should note that I'm
>> >> looking for the included
>> >> > JARs to be available not only to my plugin code
>> >> but *also* to code in the
>> >> > webapp its a part of, which maybe isn't possible?
>> >> If it isn't, is there
>> >> > any potential for conflict by having the same
Re: [S2] JARs in plugins
No, I wouldn't want to repack JARs... we actually do that with Java Web
Parts with a couple of Commons packages, but what I'm working on now has a
larger number of dependencies and they are a little more complex.
Definitely wouldn't want to do any bytecode manipulation either, or any
other voodoo for that matter ;)
If a plugin is to be truly "drop in and go", that kind of implies all
dependencies are included, doesn't it? That's what my naive little mind
had in its brain LOL... if that's not the case, so be it, I'll just need
to document the dependencies and modify my build script a little, not the
end of the world.
That wouldn't make a terrible S2 enhancement though, the ability to
(optionally) unpack any JARs in a plugin JAR and add them to the classpath
(not even sure you can do that dynamically). Would let developers make
plugins truly self-contained and also ensure proper versioning of
dependent libraries... of course, there's that nagging conflicting
versions issue, so maybe not such a great idea :(
Thanks,
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
On Wed, June 6, 2007 11:59 am, Dave Newton wrote:
> You can also consider using Jar Jar Links ("o,
> me-sa gonna muck witha your bytecodes", or if you
> prefer a more recent meme, "IM UP IN UR JARZ TWEAKIN
> UR PKGS") if you are coupled to a specific release and
> want to ensure there's no possibility of library
> conflict with webapp libs.
>
> Dave
>
> --- Philip Luppens <[EMAIL PROTECTED]> wrote:
>
>> On 6/6/07, Frank W. Zammetti <[EMAIL PROTECTED]>
>> wrote:
>> > Hi everyone... I'm writing my first S2 plugin and
>> I'm running into a
>> > problem, which may well just be one of
>> understanding.
>> >
>> > I had thought that any JAR placed in the root of
>> the plugin JAR would be
>> > added to the path, but this seemingly isn't the
>> case. My understanding is
>> > that a plugin JAR is a self-contained entity, and
>> this to me means it
>> > should include any JARs it is itself dependant on.
>> >
>> > So, is my understanding correct, and assuming so,
>> how can I get those
>> > internal JARs available? I should note that I'm
>> looking for the included
>> > JARs to be available not only to my plugin code
>> but *also* to code in the
>> > webapp its a part of, which maybe isn't possible?
>> If it isn't, is there
>> > any potential for conflict by having the same JAR
>> within the plugin JAR
>> > and also in WEb-INF/lib of the webapp?
>>
>> Well, I've written some plugins, and I never pack
>> dependencies in the
>> same jar, for precisely that reason. But if you
>> really want, you can
>> always repack jars, but I really see no good reason
>> for it. OSGi,
>> anyone ?
>>
>> Phil
>>
>> >
>> > Guidance is appreciate whataver the answer(s).
>> Thanks all!
>> >
>> > Frank
>> >
>> > --
>> > Frank W. Zammetti
>> > Founder and Chief Software Architect
>> > Omnytex Technologies
>> > http://www.omnytex.com
>> > AIM/Yahoo: fzammetti
>> > MSN: [EMAIL PROTECTED]
>> > Author of "Practical Ajax Projects With Java
>> Technology"
>> > (2006, Apress, ISBN 1-59059-695-1)
>> > and "JavaScript, DOM Scripting and Ajax Projects"
>> > (2007, Apress, ISBN 1-59059-816-4)
>> > Java Web Parts -
>> http://javawebparts.sourceforge.net
>> > Supplying the wheel, so you don't have to
>> reinvent it!
>> >
>> >
>>
> -
>> > To unsubscribe, e-mail:
>> [EMAIL PROTECTED]
>> > For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> >
>> >
>>
>> --
>> Software Architect - Memenco Consulting
>> "Always code as if the guy who ends up maintaining
>> your code will be a
>> violent psychopath who knows where you live." - John
>> F. Woods
>>
>>
> -
>> To unsubscribe, e-mail:
>> [EMAIL PROTECTED]
>> For additional commands, e-mail:
>> [EMAIL PROTECTED]
>>
>>
>
>
>
>
>
> It's here! Your new message!
> Get new email alerts with the free Yahoo! Toolbar.
> http://tools.search.yahoo.com/toolbar/features/mail/
>
> -
> 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]
[S2] JARs in plugins
Hi everyone... I'm writing my first S2 plugin and I'm running into a problem, which may well just be one of understanding. I had thought that any JAR placed in the root of the plugin JAR would be added to the path, but this seemingly isn't the case. My understanding is that a plugin JAR is a self-contained entity, and this to me means it should include any JARs it is itself dependant on. So, is my understanding correct, and assuming so, how can I get those internal JARs available? I should note that I'm looking for the included JARs to be available not only to my plugin code but *also* to code in the webapp its a part of, which maybe isn't possible? If it isn't, is there any potential for conflict by having the same JAR within the plugin JAR and also in WEb-INF/lib of the webapp? Guidance is appreciate whataver the answer(s). Thanks all! Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.3.7 Quality
Good info, thanks Ted and Jenri. Frank Ted Husted wrote: We choose not to re-use a tag after a build has been released, where "released" means the PMC has voted on the build. But, if it's still a test-build, and it would be helpful to retag it for some reason, then "no harm, no foul". I've been known to reset a tag up to three times before calling a vote. This situation is nebulous, since there is a vote thread, but no actual votes :) If a tag is reused, it's important to delete the old one first. * svn delete https://svn.apache.org/repos/asf/struts/struts1/tags/STRUTS_#_#_# -m "STR-### Removing first try at #.#.#." -Ted. On 2/28/07, Paul Benedict <[EMAIL PROTECTED]> wrote: Michael Jouravlev wrote: > Paul, do you think that STR-3009 -- ActionRedirect from ForwardConfig > not redirecting properly -- should be fixed for 1.3.7 to minimize the > impact of 1.3.5 ActionRedirect behavior? > I believe once a release is tagged, it cannot be undone. There is a ticket list for 1.3.8 which you can work on. If you believe the 1.3.5 forwarding behavior is an issue, you can give your unbinding -1. What do you think? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.3.7 Quality
Michael Jouravlev wrote: I believe once a release is tagged, it cannot be undone. Is this a consequence of the release process? Just curious because I don't think it's a limitation of SVN. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Action, dispatch, etc.
On Tue, February 20, 2007 5:20 pm, Michael Jouravlev wrote: > Oops, did not mean it to sound like that, I am sorry. I forgot that > you've proposed the same thing for s1. That's alright because I forgot too :) > On the other hand, you think that adding new functionality > to v. 1.4 instead of v. 2.0 may break compatibility or add unnecessary > strain on developers' brains or incur excessive overhead and you are > worried. Well, it will incur additional overhead. Struts was > originally designed in 2001, and since then computers have become at > least three times faster. I haven't timed the modified action, so I > cannot tell you how slower it will be. Let me make clear, I only mentioned overhead from the point of view of considering all the angles... I don't for a second think what your proposing will add any overhead that anyone will consider significant. But it *is* a reasonable thing to consider, along with other things, that's all I'm saying. As a side note, I'm not a fan of the "but machines are so much faster today" argument... there's no excuse IMO for sloppy, inefficient coding just because the hardware can make up for it (and I'm in no way implying your code is sloppy or inefficient, I'm just making a generalization here). > By the way I already have made another change to future 1.4 codebase, > now it is possible to configure when reset and populate are performed. > This change adds about the same amount of overhead as adding check for > action type (dispatching or not). Want me to take it out? Again, I didn't mean to say I had any great concern about overhead... and in fact I'm in favor of that particular modification so no, I wouldn't want you to pull it out... trolling through the archives you'll find I made that suggestion 2+ years ago as well :) (I think it's on the Wiki as a matter of fact). > You are correct that from purely technical perspective there is no > reason of adding dispatching into Action. But from the mindset > perspective I think there is. People will be able to learn right off > the bat that they can either use execute, or use event handlers. Many > do not bother reading about some obscure enhanced classes once they > got their first app running. Well, maybe one reason is upgrading from > prior versions and adding event handlers into existing classes instead > of rewriting class hierarchy and inheriting from another uberaction. Here's the problem I see here... by saying they'll "learn right off the bat" about something, no matter what it is, your making a decision for them that they should be thinking that way. I'm not in favor of that, *especially* when we're talking about an established, well-understood framework (I might feel differently if Struts was something brand-spankind new). Now, if there was another type of Action, and they later discovered your way of thinking and liked it (and by all means, promote the concept!), then the framework has the ability to support them. A framework should be like an onion: the outer layer(s) should be quick and simple to grasp, but the "advanced" options and capabilities should be revealed as you peel away the layers, there for you when you need/want them. Thrust too much to the surface and you just make it harder to ingest :) (how's that for a stretched analogy?!?) > I cannot make a better argument now, so in technical terms I guess you > are right. But having it all together in one class simply makes the > framework more cohesive to my mind. Well, as you've said, your a committer, you can make that judgement and act upon it. I'm not, so all I can do is voice my concerns. > I just want to clean s1 up a bit. > People say that s1 is way too complex for what it does, and I want to > reduce this complexity for new users of s1 if there will be ones. I just don't see how what your proposing does that. I think it adds power, which is great, but I can't see how it makes anything simpler, most especially for new Struts developers. > I will think on what you said. Maybe I will change my mind indeed. Fair enough, that's all I can ask. At the end of the day, it's your (and the other committers') decision. I just wanted to put my thoughts out there for your consideration. Mission accomplished :) > Thanks. > > Michael. No, thank you Michael, your efforts are recognized and appreciated, at least by me! :) Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have
Re: Fwd: Action, dispatch, etc.
On Tue, February 20, 2007 4:54 pm, Michael Jouravlev wrote: > Oh, and by the way while we are on the s2 topic: combining action + > form in one class which reinstantiates every request is a pretty > stupid thing if you ask me and is much farther from original Struts > session-scoped-by-default ActionForm than my subtle :) changes to > Action. I'm not sure what exactly this has to do with anything Michael. I can only assume your referring to me having made that suggestion in the past, and yeah, you'd probably be right to make the comparison, but here's the very important difference: I'm not a committer. I can't go off and do what I want with the code that everyone else is (generally speaking) going to use. You can. Therefore, it's not at all unreasonable for me to ask the questions I've asked in my estimation. Frank > -- Forwarded message -- > From: Michael Jouravlev <[EMAIL PROTECTED]> > Date: Feb 20, 2007 1:42 PM > Subject: Action, dispatch, etc. > To: "Frank W. Zammetti" <[EMAIL PROTECTED]> > > > Hi Frank, I've taken this discussion offline if you don't mind, but if > you like we can bring ig back to the list. We had this argument > before, my reasons are the same. > > With current shift from s1 to s2 Paul and me are free (well, not > completely, but we have more leeway) to implement features we like, > features we always wanted but could not add to the core because of > resistance of several core committers. > > Whether s1 will stay viable after 1.4 release or not I want to make > changes I always wanted, and now I can do this being a committer :-) > > My changes do not break backward compatibility so I don't see why you > or anyone else should be worried. If 1.4 won't be used in the field > then why would one care about its features? > > On 2/20/07, Frank W. Zammetti (JIRA) <[EMAIL PROTECTED]> wrote: >> >> [ >> https://issues.apache.org/struts/browse/STR-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40222 >> ] >> >> Frank W. Zammetti commented on STR-2940: >> >> >> I'm not arguing what your trying to do... I'm simply asking two >> intermingled questions here: >> >> Why does what your trying to do have to involve modifying Action? Why >> isn't simply creating a new kind of Action sufficient? >> >> I imagine that when DispatchAction was first introduced, a similar >> question was asked... why not just add dispatching functionality to >> Action and be done with it? Well, somewhere along the line, someone >> decided a second kind of Action was the better answer. I'm asking the >> same question here, not debating whether what your proposing is a good >> idea or not. It seems to me, if it's a new descendant of Action, then >> that question is moot anyway. >> >> If your only goal is to push a new mindset on people, which frankly >> seems to be the case based on what you said in the previous comment, I >> would contend that's not the right reason to do this, considering the >> tremendous number of existing Struts apps that have to be maintained. >> >> A related piont, although one I hesitate to make frankly... One could >> certainly make the argument that S1 is quickly becoming legacy given the >> advent of S2, and in that frame of mind, I don't think major >> architectural changes (which this is, whether developers are forced to >> deal with it or not) should be undertaken lightly. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action, dispatch, etc.
On Tue, February 20, 2007 4:42 pm, Michael Jouravlev wrote: > Hi Frank, I've taken this discussion offline if you don't mind, but if > you like we can bring ig back to the list. We had this argument > before, my reasons are the same. Let's go ahead and bring it back to the list, ok? It's a worth-wild discussion for public consumption I think. > With current shift from s1 to s2 Paul and me are free (well, not > completely, but we have more leeway) to implement features we like, > features we always wanted but could not add to the core because of > resistance of several core committers. That's cool, I'm glad you have that leeway. But your not answering the question I've asked, which again is simply why not just create a subclass of Action that does what you want? If there's some technical reason this isn't viable, I'm all ears. But so far I haven't heard that. Isn't it still "in the core" if it's included with S1? I don't think it has to be a modified Action class to be in the core, does it? This is my only point, I AM NOT arguing with the basic concept of what your trying to do, and I get the feeling you think I am. > Whether s1 will stay viable after 1.4 release or not I want to make > changes I always wanted, and now I can do this being a committer :-) But your dealing with a code base that has a huge legacy of applications written on it, so you have to be especially careful what you do with it, right? That means considering all angles that you can, and I'm simply bringing up another. > My changes do not break backward compatibility so I don't see why you > or anyone else should be worried. If 1.4 won't be used in the field > then why would one care about its features? I'm not worried... I fully understand what your proposing doesn't break compatibility, I completely take your word for it that that's the case. But, I don't think compatibility is the only concern. For instance, isn't there, even if a miniscule, amount of overhead added to each request? If I understood the flow you posted on the JIRA ticket, there would have to be... even if it's a minute amount, you have to remember how many high-volume sites out there count on the level of performance the base Action class provides now. If you go and add to that, you conceivably impact them., whereas a new Action type doesn't. That's just one thing, but that's my point: why not simply a new type of Action? Why is it so important to modify the Action class itself? That is, and has been, my only question here. Frank > On 2/20/07, Frank W. Zammetti (JIRA) <[EMAIL PROTECTED]> wrote: >> >> [ >> https://issues.apache.org/struts/browse/STR-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40222 >> ] >> >> Frank W. Zammetti commented on STR-2940: >> >> >> I'm not arguing what your trying to do... I'm simply asking two >> intermingled questions here: >> >> Why does what your trying to do have to involve modifying Action? Why >> isn't simply creating a new kind of Action sufficient? >> >> I imagine that when DispatchAction was first introduced, a similar >> question was asked... why not just add dispatching functionality to >> Action and be done with it? Well, somewhere along the line, someone >> decided a second kind of Action was the better answer. I'm asking the >> same question here, not debating whether what your proposing is a good >> idea or not. It seems to me, if it's a new descendant of Action, then >> that question is moot anyway. >> >> If your only goal is to push a new mindset on people, which frankly >> seems to be the case based on what you said in the previous comment, I >> would contend that's not the right reason to do this, considering the >> tremendous number of existing Struts apps that have to be maintained. >> >> A related piont, although one I hesitate to make frankly... One could >> certainly make the argument that S1 is quickly becoming legacy given the >> advent of S2, and in that frame of mind, I don't think major >> architectural changes (which this is, whether developers are forced to >> deal with it or not) should be undertaken lightly. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 & AJAX only with dojo?
On Mon, November 6, 2006 12:24 pm, Rene Gielen wrote: > Right now this switch already present. DWR is utilized for that, not > depending on which AJAX UI framework is used - so if we would add > sciptaculous support or such, we would not need to change the remoting > based validation solution. > > WW2 already had support for JS client side validation, but the trouble > is that you always have to code two different validation logics (Java / > Expression language vs. JavaScript) for one validation. The current > solution using DWR utilizes the full server side validation framework, > by that having one single source for definition and/or custom > implementations of validators, both for full request (classic) server > side validation and "client side style" validation on focus changes in > the webform, using half requests via DWR. Cool, I wasn't aware of that. I suppose some could have a problem with DWR being used... I'm not one of them, I'm quite a big fan of DWR :) ... but the core concept is absolute a good one. > To be honest, I would not want to miss this any more ;) Hehe, me neither... ironically, my current project still uses S1, and I wrote some code to call Commons Validator on the server via AJAX, so we use the exact same validations for the "client-side" validations as the server-side ones. Works really nice, and like you say, it's very nice having the validation definitions (and logic, since we have quite a few custom validators) all in one place. > Regards, > Rene Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 & AJAX only with dojo?
I for one tend to agree... anything included in the core product inherently makes people think that's what they should be using, the way things should be done... for all Dojo's good points, there's hundreds of other options out there, people should understand they have a choice. This isn't just a Dojo thing, I'd say the same thing if it was Prototype, APT, DWR, etc. That being said, I do very much believe the various themes should be kept close to the core, i.e., some sort of endorsed add-ons or something of that nature, right there on the download page next to S2 itself... I definitely do think it should be as easy as possible for someone to drop in a scriptaculous theme, or an AjaxTags theme, or whatever else, and get to work very quickly. Validation is a tough question because ideally you'd want to be able to flip a switch and use AJAX to do validations if you want to, but then you right away have to ask what library do you use? Maybe that's a place to just write some simple Javascript and not use a library at all, much like valdator emits its own JS (debatable). Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Mon, November 6, 2006 9:48 am, Ian Roughley wrote: > We've talked about this a lot, and I'm still not sure what the correct > answer is. > > At the moment we have a dojo theme (not going to go into the history > here - check the webwork mailing list if you're interested). Like any > other product it has it's advantages and disadvantages - the same as > prototype. However, I'm still not convinced that the ajax themes belong > in the core product. There may be particular core elements (i.e. ajax > validation) that we include, but others I think should be separate > project. > > What does everyone else think? > > /Ian > > -- >>From Down & Around, Inc. > Innovative IT Solutions > Software Architecture * Design * Development > ~ > web: www.fdar.com > email [EMAIL PROTECTED] > phone: 617.821.5430 > ~ > > > > Rene Gielen wrote: >> Hi Frank, others, >> >> Am Sa, 4.11.2006, 21:49, schrieb Frank W. Zammetti: >> >>> [...] >>> ... indeed, there is active >>> work being done to integrate DWR that I'm aware of, and also I believe >>> I've seen discussion of AjaxTags integration (although I think that >>> depends on Dojo as well, I may be mistaken there, I haven't kept up >>> lately >>> as well as I'd like). >>> >>> >> >> For DWR, it is that the "client side" validation in Struts2/WW is done >> with DWR (it feels client side because no full request is needed, while >> in >> fact it is a server side validation). This integration is already fully >> functional. In addition, DWR 2 now seems to support direct action >> invocation for S2/WW. >> >> >>> And yes, I think the approach you'd want to take is create a >>> scriptaculous >>> theme (and again, someone will correct me if I'm wrong)... whether it >>> should extend xhtml theme or not I can't really answer because I >>> haven't >>> looked at the theme support in enough detail to know... it doesn't >>> *sound* >>> wrong to me though :) >>> >>> >> >> Yes, this should be the way to go, and xhtml would be the right parent >> to >> start with. I remember this is not the first time hearing about someone >> having scriptaculous tag support on his wishlist... if someone would >> kick >> this off, maybe others would join the effort? >> >> Regards, >> Rene >> >> >> > > - > 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]
