vi plugin for Eclipse
I found this this vi plugin for Eclipse, thanks to the previous URL trail. It's kinda cool - it works - but it's a pain that you have to "load vi" each time you open a new file.
The Angular Mini-Book is a
guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and
deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.
Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.
For book updates, follow @angular_book on Twitter.
The JHipster Mini-Book is a
guide to getting started with hip technologies today: Angular, Bootstrap, and Spring
Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.
This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.
For book updates, follow @jhipster-book on Twitter.
I found this this vi plugin for Eclipse, thanks to the previous URL trail. It's kinda cool - it works - but it's a pain that you have to "load vi" each time you open a new file.
Not much new in this sucker ~ the main reason for this release is to demonstrate self-registration (and auto-login) in a CMA (Container Managed Authentication) environment. I also upgraded most of the dependent packages (i.e. Struts, Hibernate) to their latest releases, and added a binary release as an optional download. [More, Download, Release Notes]
For those of you that might not know, AppFuse is a project I created in order to help me ramp up web development projects faster. I've found it takes a long time to start a project and get the directory structure, build files (incl. ant tasks for junit/cactus/canoo) and all that jazz in place - so I created appfuse. I created it for myself, I'm using it currently at Comcast, and it works great. You might say that "Maven already does this" - and you're right, but I wanted to do it the Erik Hatcher way (after reading his book). I may make an attempt to mavenize the project in the future, but I currently don't see the need.
I think XDoclet is the best thing since Ant but that's probably because I use it daily (and nightly on on other projects). If you're not using XDoclet now, chances are you soon will be - and then you'll wonder - What took me so long? Calvin Yu gives his take on JSR 175.
I'm very excited about the new Metadata feature that's going to be in 1.5. I'm usually in agreement with the view that adding new language features is just making Java more complex, but I think metadata is going to put a whole new emphasis in automating repetitive tasks. This should also bring xDoclet to the forefront as a necessary tool for Java development.
(emphasis mine) Let's just hope that Sun tries to use some of the goodness that the XDoclet team has put together. XDoclet rocks - if you don't believe me, you must like editing your web.xml and struts-config.xml (among other deployment descriptors) by hand. I did that for years - and my opinion is that using XDoclet is easier.
From Gavin on the hibernate-devel mailing list:
If JDO becomes an accepted standard, Hibernate will provide an implementation. That is what I have always said. At present there are simply too much problems / limitations with JDO for it to become accepted. JDO 2.0 may fix that, but thats pure speculation since no-one knows what JDO 2.0 might look like. But we will continue to support and improve our own APIs since they will always be more appropriate to the problem we are trying to solve: ORM. JDO is a generic databinding API. Hibernate is not.
To me this says "You don't have to choose between JDO and Hibernate." You can chooose Hibernate and if JDO ever becomes good enough (as a standard), then you can (hopefully) find comfort in the fact that Hibernate will support it.
Dave asked earlier today if we should move Roller to be hosted at java.net rather than sourceforge.net. I responded with "SourceForge works for me" and didn't see any reason for a move. But after dealing with trying to release 0.8 of appfuse all night, I'm ready for something better. The release process sucks. I have to FTP files to upload.sourceforge.net (anonymously) and then, when the files are completed, selected them as files to release through the web UI.
The problem is that I've been trying to upload for the last 24 hours, and it keeps failing at different points in the upload process. So, here's the worst part - you can't "delete" from the FTP site - you have to release the file, and then delete it. What a pain in the ass - I've done this about 10 times now. My XP machine seems to be the source of my ftp-connection-dropping problem, so I've moved over to my Linux box. So now I'm ready to upload all my files, and look what SF gives me:
Fuckers.
I get this question a lot when folks check out my struts-resume application - so I figured I'd document it here - and then I can just send future developers a URL. The question is this:
Why do you tie your View to your Model Implementation by putting a Hibernate Session in your Service Interfaces?
I have a couple of reasons. The first reason is that I initially had ses.currentSession()
and ses.closeSession()
at the beginning and end of each DAO
method. In fact, I found this old
e-mail where you can see an example. This seemed to work for me and
I was happy with it. However, I got an e-mail from Gavin
(Hibernate's Lead Developer) that I was doing it all wrong. He said that I
should use one session per request, rather than one on each method. Why? For
performance reasons and to allow rolling back the entire session, rather
than just a method. At least that's why I remember him saying.
So I refactored and implemented the Open Session in View pattern
in conjunction with the Thread Local Session. You
can checkout my ActionFilter and ServiceLocator for the View and
ThreadLocal, respectively.
The problem now is that I pass my the Session object from my View ->
Business Layer [example: UserManager]
-> DAO Layer. So I'm tightly coupled with Hibernate, which I don't mind,
because I really, really like Hibernate and have no plans to
implement an alternate DAO (even though the architecture allows it). Even
if I did choose to implement a new plain ol' JDBC DAO Layer, I can always
get a java.sql.Connection
from the Session using
ses.connection()
. Another option I've thought of is to just
pass the ServiceLocator between the different layers, and call
ses.currentSession()
or ses.connection()
when it's
needed. But that seems to be the same thing I was doing before when I was
opening/closing at the method level.
Comments and suggestions, as always,
are welcomed and encouraged.
Mike Clark does a little to answer my earlier questions regarding java.net's weblogs.
In addition to this personal blog, I'm also writing a
blog on
java.net, unveiled today at the opening of JavaOne.
How to maintain two blogs? Duplication is icky. So frankly, I'm
not sure how this will work out yet. There will be entries on this
blog that aren't relevant to the java.net audience, and vice versa.
Javaish things are a subset of the entries on my personal blog. At any
given time I'm fiddling with multiple languages and tools. I may
actually post all blog entries here, then copy relevant entries to the
java.net space. Better yet, I suspect that eventually java.net will be
able to automatically slurp specific RSS category feed.
What I do know is that this will be my primary blog. If I
write something on java.net, I'll let ya'll know. You can also snag my java.net RSS feed just to keep me honest.
Hmmm, java.net's weblogs seem to have some pretty good authors. They get a real big thumps up from me now that I see they have a Native Montanan blogging there!
Update: More good answers were left in a comment by James:
Some answers to your questions on both the Java.net site and on my blog.
Just the answers I wanted to hear I might add!