Lincoln Baxter

Thanks for your help, email address added to contacts ;)

Could you explain why? What's wrong with this piece? Thanks...

For example: https://www.destroyallsoftware.com/talks/wat

JavaScript is not designed for Server / runtime application programming. It is and always shall remain a UI language, and applications of JavaScript in other realms are not going to be able to offer the stability and reliability that could be offered by a dedicated programming language like Java, Perl, PHP, Ruby, Python, C, etc... JavaScript may be the future of the web (sadly), but it is not the future of everything as this article may try to imply.

It's all in the interpretation. Context for "$#@%" is the AS7 marketing and T-shirts that came out around the release, but it is (as you imply) intentionally ambiguous :)

It stands for Light'ning - https://www.jboss.org/coolstuff/desktopwallpapers/jbossas7.html

@Grzegorz - Not entirely true. You can directly control which beans are and are not scanned simply by using @Veto or by not including beans.xml in your jar, then adding beans one-by-one as you please. This is not hard to do, and is actually not a difference worth mentioning because with a trivial amount of configuration (yes, I said trivial!), Spring can do the same thing as CDI, and visa versa, perhaps with a few minor exceptions on both sides.

However, more importantly, this article ignores the more relevant subject of CDI extensions, which can change or control the entire function of the dependency injection container; it also ignores the Contexts (C in CDI) which are a huge differentiation between the two. Spring does have this concept, but it does not have the concept of binding beans, interceptors, and decorators to contexts and beans in a type-safe way.

Interceptors and Decorators are yet another difference between CDI and Spring. In addition to that, CDI provides a built-in lightweight publish-subscribe event bus which is *extremely* powerful.

You cannot ignore the differences if you are going to compare the similarities.

I'll try to do this question justice, since Forge has many potential applications and my blog entry was somewhat vague. 1. Forge will provide Rails, Grails, Roo, Play-like scaffolding and application development for Java EE 2. Forge will provide database reverse-engineering for creating JPA entities/scaffolding from an existing database 3. Forge will integrate with Eclipse via JBoss Tools 4. Forge will also provide a spread of developer utilities that go beyond what I've mentioned above (controlling application servers and deployments, managing source headers, managing maven repositories, browsing JNDI registries, and more - if you have crazy/cool ideas: http://bit.ly/forgestorm add them there.) Trust me, we would love to call Forge 1.0.0.Final, but everything has to be Alpha at some point. Since Forge is OpenSource as opposed to many other tools, you simply won't see their products until they are final (or if you are selected to participate in a Beta), whereas we try to be as open as possible, and give people the chance to contribute ideas / change the direction we are going if they feel we are making mistakes. So by all means, please, now is the time to give feedback! To take the other spin on "There are so many JBoss Projects in Alpha", the fact that there are many projects in the pipe means that the next few months/year should be pretty sweet ;) But keep us honest! Let us know what we can improve on.

PS. When I said I agreed with Henk, this was not meant to be a slight on you. The state of documentation (or lack thereof) is the biggest failing of Java EE, and leads to tons of confusion with "how am I supposed to do this?" or "this is too hard!" It's not your fault, it's our fault. I will always push for more centralized, portable EE documentation.

Also, be aware this article was written about Java EE 5 - which is over 4 years ago, since it was released on May 16, 2006. This article is not written about current state technology.

I have to agree with Henk - ">The worst thing is that the principle that at least JBoss follows is the “principle of most surprise”. Things just don’t work the way one expects them to. Maybe those things don't work the way -you- expect them? To me they actually do work they way I expect them to be. Sure, occasionally things don't work, but that's true for Spring too. On the whole I would say the amount of quirks in both these great platforms is fairly equal. Of course, there are also things that are plain bugs. JBoss Hibernate for instance has quite a lot of them really, but let's not forget that Spring applications depend just as much on Hibernate as most Java EE applications do."

I was told at one point by Juergen Holler that Spring cannot implement CDI because of fundamental differences in the underlying architecture. Spring is not a "standard" in the sense that it is not an implementation of any JSR, and there is only one vendor from which it can be procured, for free or otherwise. It's up to you to decide if that's a good or bad thing.

Thanks, Henk!

Hah! Well I'm glad I'm quick and easily catch on to sarcasm ;)

Again, it is a nice comparison of Guice and Spring, just missing some recent events :)

I think "flash in the pan" might be a bit strong. CDI is arguably the best thing to come to Java EE in the last 6 years, and I think that's what future technologies in the EE arena will be centralized on. It's also difficult for anything in EE to vaporize, since it is a "standard" and will be likely adopted by most corporate players already using Java EE in some form or another - Java EE is still the industry leader in terms of adoption and market-share. Even if people use Spring, they still use Java EE in some form or another, and now with CDI, that's not really necessary at all. I agree on it being an evolution, but CDI is more that an extension of Java EE, since it is a completely independent bean-container and dependency injection framework that can be used all the way from Java SE to Servlet Containers to full-blown EE. It's true that it was an EE JSR, but CDI represents a major contender in the DI market. In fact, CDI was created in a combined effort from all of the Google Guice, Spring, and led by JBoss Seam dependency injection gurus. I'm just saying that I think it's misleading to omit the most recent major player in dependency injection and inversion of control :) No complaints about the article itself, of course, other than that.

http://seamframework.org/Weld

Where's CDI/Weld?

JMS - 1097 EJB - 977 JSF - 692 JPA - 182 JTA - 35 Hibernate (Implements JPA2 btw) - 1865 Wicket - 45 Grails - 85 Rails - 391 Ok...

Dice.com search results: "Tomcat" - 1307 results "GlassFish" - 78 results :-o "JBoss" - 1139 results :) "WebLogic" - 1746 results???? "WebSphere" - 2322 results???? darn "Spring" (Which runs on all of these BTW...) - 2480 results Next comment? ;)

You read what you want to :) I think it bleeds new hope, but hey, different perspectives right? Enjoy ;)

[moved]

I'd rather say, "the title of the article is sarcastic" ;) ,

That's a good solution if those parameter values never change, but if you need to add dynamic parameters, you'll need something more :)

I don't think that removing interfaces from sub-classes should be legal. That would violate the Liskov Substitution Principle, which as far as I know, is generally well understood to be a good thing :) Subclasses must provide the same behavior as their supers, so un-implementing an interface would violate that contract. In a strongly typed language, that can mean death. Then we'd have lots of: java.lang.MethodNotFoundException popping up everywhere ;)

I don't think that removing interfaces from sub-classes should be legal. That would violate the Liskov Substitution Principle, which as far as I know, is generally well understood to be a good thing :) Subclasses must provide the same behavior as their supers, so un-implementing an interface would violate that contract. In a strongly typed language, that can mean death. Then we'd have lots of: java.lang.MethodNotFoundException popping up everywhere ;)

If you do not specify any orderin in web-fragment.xml or web.xml, then by default it will be loaded by the order in which it falls on the build path --- that sounds like convention to me. Want it to come later? Move it down in the build path. No different from .rb file naming, there's just another method for finer grained detail. You SHOULD be thinking about and controlling these things, otherwise you will get unexpected behavior.

Finally? ;)

JSF2 is an entirely new breed, and has really listened to what users wanted. Want something changed? Let us know. That's what this article is all about. Making everyone's life easier with JSF2.

lame...

JSF has a lot of benefits that come with actually taking the time to learn how it works. Just because you've had a bad time trying to figure it out, doesn't make it a bad framework, it just means that it takes more learning to understand. Many people think that's the most important quality of a framework, ease of use, but that's why there's JSF2. Problems were recognized, addressed, and implemented. And like others have said, 3rd party libraries further enhance usability of JSF. JSF has a basic concept that is very powerful, it's up to the user to figure out how to leverage that. It's not going to do everything for you like Rails does. You have to think and solve problems in the way that suits your needs best.

Two words... DISK SPACE!?!?!?

I completely agree. "Guideline not rule"

What problems did you encounter? If you're experiencing a bug, let us know and we will address it. Thanks.

[deleted]

Groovy allows type hinting, but that's consistent with PHP. The behavior around method overloading is slightly misleading at times, but it's a dynamic language. Some things are expected ;) Loose typing is generally part of a dynamic language. I personally consider loose typing a benefit rather than a curse;)

I'm not sure there's really much to demonstrate. Prettyfaces maps URLs to JSF views. So if you were to type the url: www.mysite.com/store/viewitem/N23Z8744 PrettyFaces will parse that URL (based on your mapping), populate the parsed values into a managed bean, and call an action method to do more work before the view (something like /faces/store/view.jspx) renders. So the example mapping would be: [code lang="xml"] <url-mapping> <pattern>/store/viewitem/#{itemBean.itemNumber}</pattern> <view-id>/faces/store/view.jsf</view-id> <action>#{itemBean.loadFromDB}</action> </url-mapping> [/code] More examples can be found in the PrettyFaces documentation here: http://ocpsoft.com/prettyfaces#configuration

Fixing generics, providing a modular JVM for faster startup and smaller memory footprint. If you want closures, groovy is a good option, compiles and runs on the JVM with any other java libraries.

The effect of closures can easily be achieved through normal syntax. There are more important things to focus on.

I'm biased, but there are several ways in which it is at least different from RestFaces and other URL mapping tools such as Seam. A short list: 1. JSF view ID is never revealed to the client, whereas in Seam and RestFaces the client source code will display the view Id in the form action string. 2. PrettyFaces submits to the same URL as the bookmark, so you don't need to redirect to preserve the bookmarkability (but it is recommended anyway.) 3. Since PrettyFaces submits to the same URL as the bookmark, you don't have to pass extra parameters in to the form, or save extra parameters in a session scoped bean. They can be taken directly out of the URL again. A full article on this can be found here: http://ocpsoft.com/uncategorized/jsf-get-bookmarkable-and-pretty-urls/ or on Dzone here: http://www.dzone.com/links/make_jsf_faster_cleaner_with_bookmarkable_and_pre.html

Why would you vote this down? :) How can I improve?

C++ wasn't designed to save man-hours. It was designed to be a relatively low-level (high level at the time) language that runs natively on the CPU of whatever it is compiled for (unlike Java and interpreted languages). C and C++ were designed to be the fastest, most powerful, "you can do anything you want", even tough the hardware directly, languages.

I forgot to mention. Really please post your suggestions, I'm interested to see how I can improve what is there now. I've read the discussions on equals and hashcode, but it's possible I've made a mistake?

This tutorial does not recommend that properties of the object be used in the object's identity; however, it does demonstrate that you can choose to implement at least partial behavior for these methods in the super class so that comparing object id fields can be done with the super.equals() or super.hashcode() methods instead of redefining this behavior in each mapped object class. Please feel free to post your suggested changes.,

I did feel slightly foolish, but it's also a slightly different perspective ;)

That's a good point. It would be a VERY safe practice to pull out the user credentials into a secured configuration file, but it's not really in the scope of the tutorial. Someone want to add on? :),

Lol! Nice :)

Join CPAACTC (Computer Programmers Against Adding Comments To Code) -- I find that comments are more frequently lies than truths. All it takes is one automated refactoring to destroy the legitimacy of your comments. Comment where it makes sense, like in interfaces, or when you need to record business reasoning, but write code that documents itself! You will be much happier in the end! I've seen what happens when comments are used to describe behavior, and over time it is very ugly.