Discussions

News: Are All Stateful Web Applications Broken?

  1. Are All Stateful Web Applications Broken? (40 messages)

    Brian Goetz asks this question after describing how the session state management mechanism provided by the Servlets framework, HttpSession, makes it easy to create stateful applications, but it is also quite easy to misuse. Many Web applications that use HttpSession for mutable data (such as JavaBeans classes) do so with insufficient coordination, exposing themselves to a host of potential concurrency hazards. While there are many Web frameworks in the Java ecosystem, they all are based, directly or indirectly, on the Servlets infrastructure. The Servlets API provides a host of useful features, including state management through the HttpSession and ServletContext mechanisms, which allows the application to maintain state that persists across multiple user requests. However, some subtle (and largely unwritten) rules govern the use of shared state in Web applications, of which many applications unknowingly fall afoul. The result is that many stateful Web applications have subtle and serious flaws.

    Threaded Messages (40)

  2. It depends. May be broken if we'are talking about applications based on page navigation. Though if we are talking about an AJAX application running in one single web page (no navigation, no reload), you don't need the HttpSession anymore. For instance in ItsNat every AJAX event is received by event listeners attached to the ItsNatDocument object in the server, this document object is bound to the user page, many pages can be open attached to the same web session with no problem because by default there is no data shared between, they can be seen as several instances of the same application. Think for a minute if the session concept is present in a desktop application, in applications based on a single web page the same pattern is applied. Yes, the HttpSession is used behind the scenes by the framework, but only one attribute is used to bind the session wrapper ItsNatHttpSession to the servlet session, this binding is done when the session is created and of course this binding is thread safe.
  3. I am opposed to using Session variables for various reasons mentioned. In a single page AJAX app, one thing I am noticing is when there are cases where there is a lot of DOM manipulations involved, and the page has a lot of operations / actions to be performed (Example line by line remove , + save and a multiline update etc), Do we maintain so many hidden fields (esp in looped tabular contexts) or have one object in session and use it? Having tonnes of hidden makes 1. Dom heavy 2. Maintenence of jsp heavy etc. How do we come to a design decision in this case?
  4. In a single page AJAX app, one thing I am noticing is when there are cases where there is a lot of DOM manipulations involved, and the page has a lot of operations / actions to be performed (Example line by line remove , + save and a multiline update etc), Do we maintain so many hidden fields (esp in looped tabular contexts) or have one object in session and use it?

    Having tonnes of hidden makes
    1. Dom heavy
    2. Maintenence of jsp heavy etc.

    How do we come to a design decision in this case?
    I don't understand your problem very much. If you're going to code a single page AJAX application you should be using a framework ready for this task because DOM manipulation by hand is hard, there are some inconsistencies between browsers. There are two strategies: 1) Client centric: using a JavaScript framework. 2) Server centric: using a server centric framework with AJAX and the capability of changing big parts of the page without reloading. In regard to "a lot of DOM manipulations" it depends on the framework you are using. For instance in ItsNat the JavaScript code automatically generated uses innerHTML when is possible. Using innerHTML a big chunk of HTML code can be inserted in the client with the same performance as normal page load because parsing and insertion into DOM is done in C++, several times faster than JavaScript (may be V8 engine has changed this scenario).
  5. In a single page AJAX app, one thing I am noticing is when there are cases where there is a lot of DOM manipulations involved, and the page has a lot of operations / actions to be performed (Example line by line remove , + save and a multiline update etc), Do we maintain so many hidden fields (esp in looped tabular contexts) or have one object in session and use it?

    Having tonnes of hidden makes
    1. Dom heavy
    2. Maintenence of jsp heavy etc.

    How do we come to a design decision in this case?


    I don't understand your problem very much. If you're going to code a single page AJAX application you should be using a framework ready for this task because DOM manipulation by hand is hard, there are some inconsistencies between browsers.

    There are two strategies:

    1) Client centric: using a JavaScript framework.
    2) Server centric: using a server centric framework with AJAX and the capability of changing big parts of the page without reloading.

    In regard to "a lot of DOM manipulations" it depends on the framework you are using. For instance in ItsNat the JavaScript code automatically generated uses innerHTML when is possible. Using innerHTML a big chunk of HTML code can be inserted in the client with the same performance as normal page load because parsing and insertion into DOM is done in C++, several times faster than JavaScript (may be V8 engine has changed this scenario).
    I agree to what you say. The frameworks take care of dom manipulations. Lets consider the scenario, I gave, where you have a table having rows of checkbox and 's of textboxes and each row has a remove operation and a save to perform save of all rows at the end. So what should happen is , there should be a form associated to each of the remove, and a form associated to the save. and what ever variables u need to be there to perform the remove and save operations should all be part of the induvidual form(s). As nested forms are a NO NO in general, so common variables might have to be part of hidden variables in all the forms. This makes the dom very heavy. The frameworks I have tried to use, seems to create these forms and Dom manipulations internally and if we have to many things going on, it seems to hang up on the client side and the browser tends to crash sometimes. Is it better to persist the variable in session for these cases? If we consider a huge application,having loads pages like this, then wouldnt it have too many session variables hanging lose in this case? What do we do? If newer frameworks tackle this, Do we know how? What are the server centric frameworks you were talking about?
  6. Form? What is a form? Do you mean an HTML form? I'm kidding :) In a (pure) AJAX application using a component based AJAX framework you don't need the form element anymore. When any form control (checkboxes, text boxes) is changed by the user the new state is automatically updated in the server, so when you click the "save" button the current state of the controls in the client is in the server too. There is no form submitting. A pure AJAX application must be seen with the same patterns of a desktop application. For instance this example shows a list of controls, a similar example to your problem. See the source code too, as you can see there is no forms.
  7. I don't see the difference between the definitions of atomicity failure and visibility failure as mentioned by the author. " * An atomicity failure, where one thread is updating multiple data items and another thread reads the data while they are in an inconsistent state * A visibility failure between a reading thread and a writing thread, where one thread modifies the cart but the other sees a stale or inconsistent state for the cart's contents". Can anyone help me with this?
  8. I don't see the difference between the definitions of atomicity failure and visibility failure as mentioned by the author.

    " * An atomicity failure, where one thread is updating multiple data items and another thread reads the data while they are in an inconsistent state
    * A visibility failure between a reading thread and a writing thread, where one thread modifies the cart but the other sees a stale or inconsistent state for the cart's contents".

    Can anyone help me with this?
    Atomicity: Say you have a HashMap instance. One thread adds an item to the hashmap and in the process, updates the size. The second one does the same thing. If you don't make sure the add is atomic, you might end up with both items in the map but get the size that resulted from adding only the first. At that point the object is internally inconsistent. Visibility: The Java threading model doesn't require that two threads ever see the same value for a variable unless you use some sort of synchronization around access to that variable. So you could have one thread go in and set a variable and have the other thread continue to use an older copy of that value indefinitely.
  9. Stateful != HttpSession[ Go to top ]

    HttpSession, makes it easy to create stateful applications, but it is also quite easy to misuse. ... The result is that many stateful Web applications have subtle and serious flaws.
    Takeing a look at Apache Wicket and the like would correct perspectives. Stateful just does not necessarily mean HttpSession, even though it may fundamentally be base on the ContainerĀ“s Session-ID.
  10. Scoped services[ Go to top ]

    I thought the author would have mentioned frameworks like Spring, Seam and Grails that use scoping to avoid directly manipulating the session. I haven't had to directly use the SessionContext in... Forever, thanks to the advent of modern web frameworks.
  11. Re: Scoped services[ Go to top ]

    I thought the author would have mentioned frameworks like Spring, Seam and Grails that use scoping to avoid directly manipulating the session.
    Actually, the author does mention Spring and scoping. It doesn't matter that you're not directly using the Session. The concepts still apply because Spring, JSF, JSP, etc. all use the HttpSession behind the scenes:
    Web frameworks built atop servlets (such as JSP, JSF, SpringMVC, and so on) hide the details but essentially perform this same sort of operation on your behalf for data that is tagged as session-scoped.
    Also, later on, the author mentions that Spring has an option for synchronizing http requests to circumvent all of the threading issues (maybe Grails and Seam also have this, I don't know):
    Unfortunately, there's no option in the servlet specification to say "force requests on the same session to be serialized." However, the SpringMVC framework offers a way to ask for this, and the approach can be reimplemented in other frameworks easily. The base class for SpringMVC controllers, AbstractController, provides a boolean variable synchronizeOnSession; when this is set, it will use a lock to ensure that only one request on a session executes concurrently.
  12. Re: Scoped services[ Go to top ]

    Also, later on, the author mentions that Spring has an option for synchronizing http requests to circumvent all of the threading issues (maybe Grails and Seam also have this, I don't know)
    Which caused me to take a peek at the Spring code and make the following post to the concurrency-interest list. It didn't generate much interest, but at least it's there for someone to google upon and make their own decision: http://cs.oswego.edu/pipermail/concurrency-interest/2008-September/005512.html
  13. Re: Scoped services[ Go to top ]

    Also, later on, the author mentions that Spring has an option for synchronizing http requests to circumvent all of the threading issues (maybe Grails and Seam also have this, I don't know)

    Which caused me to take a peek at the Spring code and make the following post to the concurrency-interest list. It didn't generate much interest, but at least it's there for someone to google upon and make their own decision:

    http://cs.oswego.edu/pipermail/concurrency-interest/2008-September/005512.html
    With regard to your link there, another question I have is whether there are any guarantees that session.getAttribute() is threadsafe or that it returns the same object on each call with the same parameter.
  14. Re: Scoped services[ Go to top ]

    With regard to your link there, another question I have is whether there are any guarantees that session.getAttribute() is threadsafe or that it returns the same object on each call with the same parameter.
    The Javadoc for HttpSession.getAttribute states: Returns the object bound with the specified name... I don't think there's a more explicit guarantee in the spec, but it's hard to imagine a sane implementation that wouldn't return the same object. As for thread safety, I don't believe there's an explicit requirement to create a happens-before relationship. Here's a snippet from the article: While the servlet specification does not adequately describe the happens-before guarantees that a servlet container must provide, one is forced to conclude that placing an attribute in a shared scoped container (HttpSession or ServletContext) happens before another thread retrieves that same attribute. (See JCiP 4.5.1 for the reasoning behind this conclusion. All the specification says is "Multiple servlets executing request threads may have active access to a single session object at the same time. The Developer has the responsibility for synchronizing access to session resources as appropriate.")
  15. Re: Scoped services[ Go to top ]

    I don't think there's a more explicit guarantee in the spec, but it's hard to imagine a sane implementation that wouldn't return the same object.
    I can imagine code adding wrapper objects around these objects where each wrapper is a unique object say for a number of purposes. I suppose if you realize people are using these objects for synchronization you could always return the same wrapper but I think your initial point is an important one. None of this is guaranteed. When things are assumed outside of the spec, there's danger lurking.
    As for thread safety, I don't believe there's an explicit requirement to create a happens-before relationship. Here's a snippet from the article
    It seems like it's implying that you can count on there being no race conditions in the getAttribute() method. Is that how you read it? And again all of the presumptions and assumptions that make me uncomfortable.
  16. Broken in a clustered context[ Go to top ]

    It's a good article - and the premise is spot on. But I agree with James. We aren't seeing the whole picture. Don't get me wrong - in one respect, Goetz is 100% correct - the Servlet spec is horribly broken. But as James asserts, especially given the propensity for implementors of specs to provide their own definitions of implicit assumptions, one must assume that there is at least one and very likely more than one Servlet implementation that does *not* return the same object. Furthermore, as I pointed out in the DZone post of this same article, Goetz fails to address the situation in a clustered context. You can be nearly 100% certain that in a clustered context, no native container implementation will be returning the same object instance upon subsequent calls to getAttribute() - nevermind that without something else in the picture synchronized across JVMs ain't gonna work. So while Goetz is absolutely correct the Servlet spec is most definitely broken, there is no way his solution to rely on POJO synchronized could possibly work....or could it? ;-)
  17. Well...[ Go to top ]

    It's a good article - and the premise is spot on. But I agree with James. We aren't seeing the whole picture.

    Don't get me wrong - in one respect, Goetz is 100% correct - the Servlet spec is horribly broken. But as James asserts, especially given the propensity for implementors of specs to provide their own definitions of implicit assumptions, one must assume that there is at least one and very likely more than one Servlet implementation that does *not* return the same object.

    Furthermore, as I pointed out in the DZone post of this same article, Goetz fails to address the situation in a clustered context. You can be nearly 100% certain that in a clustered context, no native container implementation will be returning the same object instance upon subsequent calls to getAttribute() - nevermind that without something else in the picture synchronized across JVMs ain't gonna work.

    So while Goetz is absolutely correct the Servlet spec is most definitely broken, there is no way his solution to rely on POJO synchronized could possibly work....or could it? ;-)
    Well in regards to clustered environment, thats where sticky sessions come into play. If a session sticks to a particular node in the cluster, it wouldnt be cross VM and thus synchronization still works. Of course if whatever HA/Cluster appliance/software/system you use doesnt support sticky http sessions, then you're out of luck.
  18. Re: Scoped services[ Go to top ]

    Which caused me to take a peek at the Spring code and make the following post to the concurrency-interest list. It didn't generate much interest, but at least it's there for someone to google upon and make their own decision:

    http://cs.oswego.edu/pipermail/concurrency-interest/2008-September/005512.html
    Quick response from my side, since I've authored the code in question: Setting bean properties during the configuration phase is not an issue within the Spring container since the container will appropriately synchronize on bean creation, guaranteeing a happens-before relationship between the bean configuration phase and subsequent access to the bean at runtime. As a consequence, when obtaining the bean from the Spring container, you'll always get a fully configured instance with full visibility of all its configuration state. This applies to Spring MVC as well, since all MVC beans are obtained from a Spring container at runtime. As for the session mutex problem: Our general recommendation for a portable and safe solution is to use the provided HttpSessionMutexListener, as you've noticed. Otherwise we do fallback to the HttpSession as mutex object simply because most single-node servlet containers always return the same reference there anyway. Since "synchronizeOnSession" is an optional feature to begin with, we leaned towards the convenient fallback assuming that the HttpSession is safe if the user didn't bother to explicitly register the HttpSessionMutexListener. Juergen
  19. Re: Scoped services[ Go to top ]

    Setting bean properties during the configuration phase is not an issue within the Spring container since the container will appropriately synchronize on bean creation, guaranteeing a happens-before relationship between the bean configuration phase and subsequent access to the bean at runtime.
    Thanks for clarifying the implication from the mailing list thread. Yet there's still a visibility issue post-creation: there's no guarantee that the result of calling setSynchronizeOnSession will be seen by a call to isSynchronizeOnSession on a different thread.
    ...most single-node servlet containers always return the same reference there anyway.
    I assume you're referring to HttpServletRequest.getSession. I haven't tested it lately, but that didn't used to be true. If it is true now, it's still an implementation detail. In addition, there are a number of other ways for application code to get a reference to a session object: PageContext.getSession(), HttpSessionBindingEvent.getSession(), HttpSessionEvent.getSession(), and the "session" implicit object in a JSP (and maybe others). Again, no guarantees that all those paths lead to the same object for the lifetime of a single request (on the same thread) let alone for multiple requests on different threads. BTW, I don't want to imply that Spring is the only place this kind of thing exists. The article just provided a jumping-off point for looking at the code. Maybe someone else can check out some Wicket code to see if Erik is entitled to feel so comfy ;-).
  20. Re: Scoped services[ Go to top ]

    Thanks for clarifying the implication from the mailing list thread. Yet there's still a visibility issue post-creation: there's no guarantee that the result of calling setSynchronizeOnSession will be seen by a call to isSynchronizeOnSession on a different thread.
    Well, those bean property setters - like most typical setter methods in a Spring environment - are designed for use during the configuration phase only. They are effectively a post-construction facility. The container will never call them outside of the configuration phase. If setters are supposed to be used to change values during runtime as well, then - and only then - the bean needs to internally synchronize the property accordingly. "setSynchronizeOnSession" is a traditional configuration-time-only setter, though, like many other setter methods in Spring-provided components. This is well-understood in the Spring universe. FWIW, this is also largely equivalent to EJB3 setter injection, with similar (non-)implications in terms of coding the components. Many DataSource / ConnectionFactory / etc implementations are designed that way as well, putting the synchronization onus on the container in terms of calling setters before putting the factory into service. For a different example, take Spring's DefaultMessageListenerContainer: Many of the bean properties there, such as "maxConcurrentConsumers", do operate in a synchronized fashion. Those settings are by their very nature candidates for being changed at runtime (e.g. through JMX exposure). In contrast, changing AbstractController's "synchronizeOnSession" at runtime doesn't make any sense. This is a static configuration setting for any given web application. Changing such a value post-creation qualifies as misuse. Point taken about the HttpSession reference potentially differing. Please do note that we clearly recommend HttpSessionMutexListener to be on the safe side. We just decided to allow for the HttpSession reference fallback for setup convenience only - on servlet containers where this is safe. Also, note that Spring is consistenly calling "HttpServletRequest.getSession" for synchronization purposes; so the sole actual requirement is for that reference to be the same across all requests of the same logical session. Juergen
  21. Re: Scoped services[ Go to top ]

    Also, later on, the author mentions that Spring has an option for synchronizing http requests to circumvent all of the threading issues.
    That kind of feature can only protect you when you use immutable objects so that's not really 'all' of the issues described. If you start using mutable objects, synchronizing gets and sets to the session isn't enough. This is a great example of why immutability should be preferred. One thing that I didn't like about this article is that he states that using the AtomicReference is better than synchronization without any explanation. I've recently observed a much higher overhead using the concurrent libraries as opposed to standard synchronization (throughput increased by upwards of 250% using synchronization). The concurrent libraries are better when you have a lot of contention but I'm not convinced it's always faster aside from how much simpler the synchronized version is.
  22. Re: Scoped services[ Go to top ]

    That kind of feature can only protect you when you use immutable objects so that's not really 'all' of the issues described.
    Looking at Kris' post above I see that it's actually synchronizing the whole request so my comment above appears to be incorrect. I'll not address whether it's correctly synchronized in this sub-thread. If it is indeed synchronizing the whole request, then that sees very heavy-handed. Mr. Goetz asserts that this shouldn't an issue but I'm not so sure. Isn't it possible to use the same session across tabs in a browser? I often will do an operation and quickly jump to the next tab and submit something else especially if the requests take a while. And if it is so benign, why not do it by default?
  23. Re: Scoped services[ Go to top ]

    Look at the books he published and you will understand why.
  24. Re: Scoped services[ Go to top ]

    Actually, this still isn't a problem for Seam because Seam can use outjection. When a method is called on a bean that has another bean injected, if the injected bean is marked for outjection it is pushed back out to the session when the method ends. This means the modified bean is automatically pushed out to the session. With just the HttpSession, you have to manually push the modified object out to the session at the end of the method. I believe that in this Gavin King podcast from this serverside thread in 2006, Gavin talks about this very problem. In it he describes how the HttpSession model is broken and it was one of the problems that Seam sought to resolve.
  25. I think it was a really good article. Not every one use Spring, Grails or other frameworks. Secondly, even now there are many applications which use Servlet API's and we, as developers, have to maintain those as well.
  26. No problem with Wicket[ Go to top ]

    Of course I am using Wicket so the majority of these pain points do not apply.
  27. Re: No problem with Wicket[ Go to top ]

    I know next to nothing about Wicket, but it sure looks like it includes scoped containers. For example, there's its own abstraction of a session object. So, using Wicket, how would you handle multiple changes to a mutable attribute that must be atomic and visible across threads: Session s = ...; User u = (User)s.getAttribute("user"); // these need to be atomic and visible u.setLastAccess(...); u.setAccessCount(...); Of course, having to deal with every interface name starting with "I" is worse than any potential concurrency issue! ;-)
  28. Re: No problem with Wicket[ Go to top ]

    Kris, Wicket supports detachable models. You might want to look at this.
  29. Re: No problem with Wicket[ Go to top ]

    Of course, having to deal with every interface name starting with "I" is worse than any potential concurrency issue! ;-)
    Kris - couldn't agree more! :)
  30. Re: No problem with Wicket[ Go to top ]

    Of course, having to deal with every interface name starting with "I" is worse than any potential concurrency issue! ;-)


    Kris - couldn't agree more! :)
    Gosh, I really thought people had gotten over themselves and accepted there are a few differences in taste out there by now. As you can read in the comments on your blog, many people disagree and feel that alternatives like FooImpl are even worse. Seriously, can we just burry this boring topic for once and for all? :-)
  31. Re: No problem with Wicket[ Go to top ]

    Of course, having to deal with every interface name starting with "I" is worse than any potential concurrency issue! ;-)


    Kris - couldn't agree more! :)


    Gosh, I really thought people had gotten over themselves and accepted there are a few differences in taste out there by now.

    As you can read in the comments on your blog, many people disagree and feel that alternatives like FooImpl are even worse. Seriously, can we just burry this boring topic for once and for all? :-)
    I don't want to get into a fight or anything but I think that it's not just a matter of taste. As far as working with code that uses this idiom goes, it's no worse than using code that uses other derivatives of hungarian notation in contexts where it provides no value: annoying and distracting to the eye. But the real issue is why do developers feel that it's important to do this? Kris did a good job so I won't reiterate all his points but why is it important to know that a type is an interface in code that uses it? It's irrelevant at the call site whether the type of your variable is an interface or not. And the only argument to the contrary that doesn't miss the point above completely: 'being able to tell where your interfaces are' and that's far from convincing. JavaDoc already italicizes interfaces in the class list and any decent IDE gives you this information at a glance. Even if you don't use an IDE, the you won't get very far if you try to make a class extend an interface which is the only time it actually matters whether the type is an interface or not. And why would you be extending things without knowing what they are?
  32. Re: No problem with Wicket[ Go to top ]

    I don't want to get into a fight or anything but I think that it's not just a matter of taste.
    It's either a matter of taste, or you think that many people, including yours truly, are plain wrong :-) Seriously, the thing that got old for me is that it really isn't that important. It's like people using _ in front of members. Personally I find it ugly, but it doesn't make it much more difficult to follow the code. I like the I prefix for interfaces because 90% of the time, I'm locating classes and interfaces through searching (cmd + shift + t in eclipse), and it shows immediately I'm talking to an interface even when I have no tooling in hand (nice for e.g. bug fix attachments). I don't like the alternative of e.g. using FooImpl a single bit, but... it is more important to define a code style and keep to it, than to keep fussing about individual taste. For Wicket we're using the 'I', and for the day job, we're not (instead we're using Abstract, Impl and more). The end of the day, they both work, and I believe there are more interesting things to talk about :-)
  33. Re: No problem with Wicket[ Go to top ]

    It's either a matter of taste, or you think that many people, including yours truly, are plain wrong :-)
    I do think it's plain wrong to use this naming convention. Just as I think it's plain wrong to use hungarian notation for variables in Java. It's distracting while providing no real value.
    Seriously, the thing that got old for me is that it really isn't that important. It's like people using _ in front of members. Personally I find it ugly, but it doesn't make it much more difficult to follow the code. I like the I prefix for interfaces because 90% of the time, I'm locating classes and interfaces through searching (cmd + shift + t in eclipse), and it shows immediately I'm talking to an interface even when I have no tooling in hand (nice for e.g. bug fix attachments). I don't like the alternative of e.g. using FooImpl a single bit, but...
    Like I mentioned earlier, I don't like using FooImpl either. The only time that it makes sense to use FooImpl is if you only plan to have one implementation and if so, why do you need an interface? I often have no public or protected implementations of an interface. I usually use private nested or inner classes, and anonymous classes to implement interfaces. I've used AbstractFoo but I now prefer BaseFoo for helper implementations. Why does it help you to know that you are 'talking to an interface'? This is the key point here. Do you find you have issues when using the collections interfaces in the JDK or any other interface in the JDK? And when do you find yourself working on code with no tooling in hand. Ultimately, I agree this is a minor issue but not an uninteresting one. I think it's interesting because it suggests that some people think about OO in much different ways. Would you support prefixing all concrete types with 'C' or all abstract types with 'A' and perhaps we should add a second letter 'I' for inner, 'N' for nested, 'L' for local 'T' for top-level and then we can add 'PU' for public and 'PK' for package and 'PR' for private. Eventually everyone can just look at the name of the class and no everything about it. It's worked so well in the past.
  34. Re: No problem with Wicket[ Go to top ]

    Would you support prefixing all concrete types with 'C' or all abstract types with 'A' and perhaps we should add a second letter 'I' for inner, 'N' for nested, 'L' for local 'T' for top-level and then we can add 'PU' for public and 'PK' for package and 'PR' for private. Eventually everyone can just look at the name of the class and no everything about it. It's worked so well in the past.
    But the thing that is different and that makes that I slightly prefer using I for interfaces, is that you typically have an interface and a default or a base (abstract) implementation. I like IFoo for an interface and Foo for the default implementation in that case better than putting them in different packages with the same name, appending Impl or prepending Abstract or Default to them. That a very practical concern we run into daily, and which isn't relevant for private, inner, etc. It's all arbitrary of course, like any naming is. I feel that naming is important, so I guess I have to backtrack and agree with you that this issue is important enough to keep bringing up :-) Look, the thing that really matters when you name things is that it communicates what it represents/ does, agreed? In that sense, e.g. prepending Abstract to a class communicates that it is designed for extending. Otoh, the abstract modifier does that too, so why bother? Well, why bother saying that you have a DAO that is implemented using iBatis and another one using Hibernate, by stating that in their names? You could use different packages, but that isn't as direct. But more neat. What I'm trying to say with my rambling here is that you can a whole bunch of opinions on naming, and we'll never all agree on the details. So I don't see much use in stating that for instance using I for interfaces or A/ Abstract for abstract classes is bad per se, because I think that as long as it is consistently applied, it's all fine. The only thing that using that I will result in is that a bunch of people will think it is ugly, like they will think with any of the naming choices you can have (do you use newFoo or createFoo, or something else for factory methods, etc, etc), but the end of the day, consistency is what matters, and details like that dreaded I won't be in anyones way of understanding and quickly navigating code.
  35. Re: No problem with Wicket[ Go to top ]

    It's all arbitrary of course, like any naming is. I feel that naming is important, so I guess I have to backtrack and agree with you that this issue is important enough to keep bringing up :-) Look, the thing that really matters when you name things is that it communicates what it represents/ does, agreed? In that sense, e.g. prepending Abstract to a class communicates that it is designed for extending. Otoh, the abstract modifier does that too, so why bother? Well, why bother saying that you have a DAO that is implemented using iBatis and another one using Hibernate, by stating that in their names? You could use different packages, but that isn't as direct. But more neat. What I'm trying to say with my rambling here is that you can a whole bunch of opinions on naming, and we'll never all agree on the details. So I don't see much use in stating that for instance using I for interfaces or A/ Abstract for abstract classes is bad per se, because I think that as long as it is consistently applied, it's all fine. The only thing that using that I will result in is that a bunch of people will think it is ugly, like they will think with any of the naming choices you can have (do you use newFoo or createFoo, or something else for factory methods, etc, etc), but the end of the day, consistency is what matters, and details like that dreaded I won't be in anyones way of understanding and quickly navigating code.
    I think we've talked this into the ground and I don't think I will convince you. My last point to make is that my main tenet of naming is that names should tell you what the class does and not how it does it (usually). I would say naming a class based on the underlying framework it depends on is way out-of-line but it makes sense in certain scenarios. I would definitely never let that name become a dependency in the core system. Where I work now we have names that have no meaning because they were based on the version number of 3rd party tools that was being used at the time of naming. We have some other code were the version of the release was prefixed to all variables. Implementation details should not be part of a public API, IMO. Again, I think Wicket is awesome and the 'I' doesn't at all dissuade me from using it. I think that the controversy is mainly that the use of this prefix implies something about how developers are thinking about interfaces to some people (myself included). Perhaps we are assuming things that are not true about the implications of this naming approach. I still remain unconvinced that this is a useful paradigm, however.
  36. Re: No problem with Wicket[ Go to top ]

    I think we've talked this into the ground and I don't think I will convince you.
    Yep. At least we agree that naming classes and methods is something that should be taking seriously :-)
  37. Re: No problem with Wicket[ Go to top ]

    And people say TSS is dead! :)
  38. Re: No problem with Wicket[ Go to top ]

    I would say naming a class based on the underlying framework it depends on is way out-of-line
    Many cocoa programmers probably disagree with that notion. For instance, an example taken from one of the iPhone developer videos: UIImageView, because: UI -> part of UIKit framework, Image -> works with UIImages, View -> subclass of UIView. Again, I'm not saying such conventions are holy by themselves, but I believe consistently following 'a' standard is probably more important than what that standard exactly is. Last remark from me in this thread, I promise! ;-)
  39. Re: No problem with Wicket[ Go to top ]

    Of course, having to deal with every interface name starting with "I" is worse than any potential concurrency issue! ;-)
    I agree that it's asinine to name interfaces IFoo (naming classes FooImpl is nearly as bad) but Wicket makes up for this error in spades.
  40. Hmmm...can't see any reference to Spring Webflow here, so here goes. Spring Webflow builds on top of the Servlet spec to provide what ends up being a great platform, hiding the brokenness underneath. Couple of features... - Post-Redirect-Get out of the box, so that hitting the Back button doesn't ask you if you want to resubmit (if you've just done a post). - Continuations, so that hitting the back button correctly restores server state ... several new scopes to add to the basic Request and Session scopes in the servlet spec. Due to the new scopes, Request and Session scope typically don't get used directly by the developer since they're more or less useless. - New scope. Flash scope, which is like request scope, but will survive a redirect and needed to support Post-Redirect-Get. - New scope. Conversation scope, which covers navigation across multiple flows (pages) - New scope. Flow scope, which covers multiple request/responses. Allows you to have more than 1 copy of a page open without clobbering session state. - Ability to pass multiple named parameters easily to and from flows (pages) e.g. simple example is multiple pages sharing a 'find' page. This takes a gigantic amount of load off the developer. Additionally, the notion of a 'flow' is kind of close to how a lower level use-case might be specified, so inspecting the flow XML document tells you a lot about how the UI works, and how services are called to support it. I still need to take a closer look at Wicket, and probably SEAM, although I've read a lot on SEAM / Wicket, just not used them. I think rich navigation is more important than a rich UI (read: rich single page). I'd rather use Spring Webflow + JSP .tag files + CSS + Sitemesh + jQuery than something like JSF.
  41. Flash scope...Conversation scope...Flow scope
    Just because a framework allows a developer to avoid dealing directly with HttpSession or ServletContext, doesn't mean that it's solved the general issues presented in the article.