|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 43
Messages: 43
Messages: 43
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Tech Talk - Rod Johnson on The Spring Framework, AOP
In this interview, Rod Johnson talks about the Spring framework, its positioning and how its dependency injection compares to that of Hivemind and PicoContainer. He looks at what's different in the Spring Petstore, how Spring ties into Hibernate and how scripting might fit into Spring. Rod also gives his thoughts on AOP standardization, TDD, and talks about his new book, 'J2EE without EJB'.
Rod Johnson on what's upcoming in Spring 1.1 and future versions"The feature set for Spring 1.1 is pretty much set now. We're looking at JMS support, which will be focused primarily around publishing messages very easily. We're also looking at dynamic reconfiguration features. For example, Spring may be able to pull configuration held in an XML file on the network or in the database and objects will be updatable in a threadsafe way. So for example, if object A depends on object B, you will actually be able to change in your definitions, the implementing class of object B, and yet the reference that A holds to B, will still be honoured. I think that's a really interesting feature. We're also looking at the pointcut expression language and some other AOP enhancements. We're looking at JSF integration . I think that will make 1.1 and possibly portlet integration." Watch Rod Johnson's Interview
|
|
|
Message #129050
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Missing question - Spring and EJB 3?
Interesting interview, especially on future plans. However, it would be nice to hear about Rod's thoughts on EJB 3. The spec takes on many of the IOC/Dependency Injection concepts facilitated by Spring and its "competitors", so surely closes the gap somewhat.
So does Spring IOC still add enough value to justify substituting - or building on top of - the soon-to-be industry standard IOC, thus adding an extra layer of complexity and adding to a typical project's learning curve? For Spring and others to be taken on in light of EJB 3, they will need to be able to justify that the value-add is substantial.
|
|
|
Message #129051
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
to fix again and again and again and…
for every time getting more and more complicated and error prone.
With EJB 3.0 there is even more reason to use Spring. They had the chance to make a whole new concept, calling it something new and fresh, a new start!leaving the EJB Zombies from Night of The Living Dead to its destiny.
But no, the "new" EJB will still maintain all backwards compability to shoot itself in the foot being kept alive long after they should be dead and buried.
Is the J2EE vendors that much desperate?
Millions of lines of dead weight :(
"How much can a being mutate before it wants to die?"
The EJB 3.0 spec reminds me of is the old american cars in Cuba.
Regards
Rolf Tollerud
|
|
|
Message #129052
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Missing question - Spring and EJB 3?
That seems like a good opportunity for me to highlight some positive sides of Spring :-)
I am pretty sure that value proposition of lightweight containers (as we understand them right now), and specifically Spring as probably the best known open source lightweight container, will remain clear and will actually grow with introduction of EJB 3. The fundamental promise of lightweight containers is to go beyond J2EE and .NET functionality, and go there in multiple directions: simplification of often used APIs, providing functionality that is not available from specs, providing improved usability patterns for existing APIs, etc. In my opinion, the introduction of EJB3 (or J2EE 1.4), .NET 2.0 or any other technologies would not change the underlying “formula” behind lightweight containers (again, as a current collective term for frameworks like Spring); these frameworks will promptly adopt and grow to continuously provide substantial added value to a verity of J2EE/.NET based projects.
Regards,
Nikita Ivanov.
|
|
|
Message #129057
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Missing question - Spring and EJB 3?
Michael, you might want to read my posting from another recent TSS thread on Spring and EJB 3:
http://theserverside.com/news/thread.tss?thread_id=27104#128843
As I elaborated there, Spring's scope is significantly wider than EJB 3's. Spring addresses logical reuse of business logic in any environment (J2EE server, Tomcat, standalone application, test suite, etc), also being able to provide its container services like dependency injection and declarative transactions in any such environment (in contrast to EJB 3).
Of course, Spring can also nicely be used for accessing or implementing EJBs. This is already the case with EJB 2.x; this will still be the case with EJB 3. Spring typically manages fine-granular application objects there, while EJBs are just used as facades (for example, remote entry points). Spring provides explicit EJB support classes for this usage style.
Juergen
|
|
|
Message #129067
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Missing question - Spring and EJB 3?
"Spring's scope is significantly wider than EJB 3's"
As I understand spring provides/implements no services and is wrapper for j2ee services and it is more design pattern than container, why it can not be a wrapper for EJB 3 too ?
|
|
|
Message #129071
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
in class with P.G.Wodehouse
Don't forget the entertainment value of pitting JSR - the epitome of bureaucratic committee management against two super-gifted talents from the upper atmosphere of the world's programmer elite.
The world is such a boring place according to Schopenhauer so we are forced to take every opportunity to get some amusement.. :)
Let the fun begin!
Regards
Rolf Tollerud
(Wodehouse admirer)
|
|
|
Message #129072
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
to fix again and again and again and…
Container and Spring are two very different things and they do not conflict.
Spring is application development framework, j2ee container is a container for applications and services, but EJB tries to be standard application development framework too. I think this is the main EJB problem, there is no the best framework for all use cases and it can not be stable, I do not believe it can be possible to invent stable,standard framework. It is like art or fation and it can die or become obsolete at any time like SQLj, EJB, CCM, ... .
|
|
|
Message #129073
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Missing question - Spring and EJB 3?
"Spring's scope is significantly wider than EJB 3's"As I understand spring provides/implements no services and is wrapper for j2ee services and it is more design pattern than container, why it can not be a wrapper for EJB 3 too ? Sure, you can access EJB3s easily from a Spring context; Spring can provide the same means of access there as for current EJBs. For example, Spring can host the local middle tier of a web application within a WAR, linking in EJB3 facades from a (local or remote) EJB tier to delegate to.
The EJB3 EntityManager will also nicely integrate with Spring's DAO abstraction. Effectively, EJB3 entity beans will simply be one more option alongside the other data access strategies that Spring supports (JDBC, Hibernate, JDO, OJB, iBATIS SQL Maps).
What I meant regarding scope is that EJB still focuses on a component model for use within an EJB container, while Spring does not impose any restrictions in terms of target environments. In that respect, the scope of Spring IoC is significantly wider: It allows you to host components in any environment.
Beyond the target environment issue, Spring also provides much more sophisticated means for dependency injection, and lots of functionality completely beyond the scope of the EJB spec. EJB 3's IoC capability for Session Beans is effectively a small subset of Spring's IoC features.
Juergen
|
|
|
Message #129079
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
to fix again and again and again and…
Rolf,
> But no, the "new" EJB will still maintain all backwards compability to
> shoot itself in the foot being kept alive long after they should be dead
> and buried.
Err, what then would the options be for existing applications built using the
EJB 1.1 and 2.x specifications?
Backwards compatibility is important to customers. An answer from a J2EE
Application Server vendor along the lines of "Yes, when our product supports
spec version x, you either have to migrate (months/years of effort?) - or
continue using an older version of our product" is wholly unacceptable.
IMO, it is very reasonable for an AppServer to continue to support applications
built on existing/older specs while allowing side-by-side deployments on newer
versions of the specs. As an example - I could state some of the new features
introduced in the J2SE 1.5 (or 5.x). The intentions is that the bytecode
produced say, by using generics/auto-boxing will still continue to work on
older VMs. Would that decision by Sun to have backwards compatibility also
consitute a "shooting oneself in the foot"?
-krish
|
|
|
Message #129081
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Missing question - Spring and EJB 3?
MichaelInteresting interview, especially on future plans. However, it would be nice to hear about Rod's thoughts on EJB 3. The spec takes on many of the IOC/Dependency Injection concepts facilitated by Spring and its "competitors", so surely closes the gap somewhat.So does Spring IOC still add enough value to justify substituting - or building on top of - the soon-to-be industry standard IOC, thus adding an extra layer of complexity and adding to a typical project's learning curve? For Spring and others to be taken on in light of EJB 3, they will need to be able to justify that the value-add is substantial. Good question.
Firstly, it's important to differentiate between a component model that adds some limited Dependency Injection features to help simplify its programming model (EJB3) with a true IoC container (Spring, Pico, HiveMind etc.). EJB3 does not standardize a general Dependency Injection mechanism. It's mainly a way of getting rid of verbose JNDI lookups (judging by section 8.1.3, "Injection and Lookup"). This is worthwhile, but it provides only a small part of the benefits that can flow from Dependency Injection overall.
Spring does provide a general IoC mechanism, with both Setter and Constructor Injection, Method Injection (in Spring 1.1), and the ability to manage object graphs of POJOs. It's possible to differentiate between "singleton" objects (shared instance, as with JNDI) or "non-singleton" objects (instance created on reference), supporting more advanced scenarios. Not to mention support for lists, maps (even nested), property type conversion etc... There's a lot more to a true IoC container than the EJB3 subset.
The Spring IoC container is also highly extensible, with the FactoryBean concept etc. It also integrates with AOP (Spring's own AOP framework and, as an additional option, AspectJ in Spring 1.1), whereas EJB3 does not provide an open AOP model...
In short: EJB3 may "narrow the gap," but in terms of programming model, the gap is still very wide. And Spring 1.1 (due out next month) and subsequent Spring releases should widen it...
Secondly, the Spring IoC container, like Pico and co, is usable in a wider range of scenarios than I would expect an EJB container ever will. (I have heard the aim expressed of making the EJB container "ubiquitous". Maybe it will happen, but I doubt it.) An IoC container distinct from the EJB container can be used anywhere: not just in a J2EE context. (J2EE != Java.) For example, the Spring RCP (Rich Client project) is generating a lot of interest now, and we have some users using Spring IoC in applets and standalone non-J2EE Java applications. A consistent model across all those environments is valuable.
Thirdly, I think we have to be realistic about applying the word "soon" to EJB3. We're a long way from a Proposed Final Draft, let alone the completion of the JCP process and production-ready containers actually supporting EJB3. The market leader in the application server space is now WebSphere. WebSphere 6 will be released at the end of this year, and will support J2EE 1.4, not 1.5. Thus it's reasonable to assume that WebSphere will support EJB3 in late 2005. Obviously people can't migrate to a new app server version overnight, so we'll see the user base come over in 2006. (And I doubt those guys are going to switch to another server to get EJB3 quicker.) It's clear from presentations I've seen at IBM user groups that IBM are focusing on today's technology set (quite reasonably). Thus EJB3 is just not an option now, and won't be for a while.
Fourth, Spring does a lot of things EJB3 does not seek to address. If I were programming EJB3 now (if I could program it now), I would be likely to use Spring for true IoC capability, interception that can't be done with EJB, superior JDBC usability, client-side access to remote EJBs etc... So the two things are not mutually exclusive. A better EJB would be good, but it won't displace good J2EE frameworks.
So, I think the value add is very substantial.
Rgds,
Rod
J2EE Without EJB
Spring Framework
|
|
|
Message #129082
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
the Spring bookshelf
Please explain how the ability to treat POJOs as first class citizen would break backwards compability when no one is proposing to remove the old 2.x EJB. New functionality with a new cool name is the way to go.
Anyway I doubt that even that would help. Spring is like a empty rack only, where you can insert and remove "black boxes" at will, with an amazingly compact implementation. That is an unbeatable concept.
Regards
Rolf Tollerud
|
|
|
Message #129083
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
to fix again and again and again and…
IMO, it is very reasonable for an AppServer to continue to support applications built on existing/older specs Of course, but there is a rather large distinction between application servers supporting each of the different EJB specifications and having the specifications mandate this backwards compatibility.
Given the fundemental changes that are occuring in EJB 3.0 it is reasonable that a new generation of application servers may emerge, but to be considered 'compliant' they would have to support previous versions of the specifications. By the time we get into 4.0 or 5.0 it will be practically impossible for a new application server to enter the market. This would be unfortunate.
IMHO, Sun should release the specifications as distinct and let the vendors decide which specs to support. It is not the specification author's responsibility to ensure that the app server vendors can continue to support their existing clients.
|
|
|
Message #129088
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
to fix again and again and again and…
IMHO, Sun should release the specifications as distinct and let the vendors decide which specs to support. It is not the specification author's responsibility to ensure that the app server vendors can continue to support their existing clients. +1
User decides, hi needs this stuff or not and hi pays for everything,
clever vendors work for user, not for specification.
|
|
|
Message #129093
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Books
I would love to know which TDD book gets mentioned by Rod in the interview. I've been looking for books on the topic for a longer time, but was unable to choose one yet..
Also, is there *any* possibility to receive the recent 'J2EE without EJB' book in PDF format? There are countries, where snail mail has some real serious difficulties, and an electronic format would be very much preferred.
|
|
|
Message #129097
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Books
Also, is there *any* possibility to receive the recent 'J2EE without EJB' book in PDF format? There are countries, where snail mail has some real serious difficulties, and an electronic format would be very much preferred. The publisher are reluctant, and have had piracy problems in the past. I have raised the idea of a PDF with them, and will do so again.
Regarding TDD books--I liked Vincent Massol's JUnit book, and Rick Hightower's book. But ultimately I think you learn TDD by doing...
|
|
|
Message #129103
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Looking Forward To "J2EE Without EJBs"
I just finished reading Rod's "Expert One-On-One J2EE Design And Development" for the first time. I'd heard it was excellent, but it exceeded my expectations. I'm poring through it more carefully a second time. If I'd read it two years ago my projects would have been the better for it.
Looking forward to "J2EE Without EJBs" now. I don't have an EJB ax to grind. But if this book is as good as "Expert" it'll be worth studying. Thanks - MOD
|
|
|
Message #129105
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Books
I would love to know which TDD book gets mentioned by Rod in the interview. I've been looking for books on the topic for a longer time, but was unable to choose one yet. Not a book, but this "XP Episode" from Object Mentor is a very good introduction to the principles of TDD and working with JUnit (as well as pair programming, incidentally).
|
|
|
Message #129122
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Books
Nice one. It would really be very very nice if one could purchase a pdf of Rod's book. The last time I tried to try to purchase a printed copy on-line, it tooks about 2 months to arrice.
|
|
|
Message #129127
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Missing question - Spring and EJB 3?
Sure, you can access EJB3s easily from a Spring context; Spring can provide the same means of access there as for current EJBs. For example, Spring can host the local middle tier of a web application within a WAR, linking in EJB3 facades from a (local or remote) EJB tier to delegate to.The EJB3 EntityManager will also nicely integrate with Spring's DAO abstraction. Effectively, EJB3 entity beans will simply be one more option alongside the other data access strategies that Spring supports (JDBC, Hibernate, JDO, OJB, iBATIS SQL Maps). I see we started to talk about data access not about persistence :) I am sure all strategies are equal for data access code and all can be generated (DAO), it needs some metadata like "query string", but if you use DAO then you do not need nothing more than code generator and metadata. It is very trivial to generate all DAO's from iBATIS xml files, is not it ?
SQLj was the same idea, but it is dead for some reason, probably it is to "compex" :)
|
|
|
Message #129136
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SQLJ is not dead
blockquote>SQLj was the same idea, but it is dead for some reason, probably it is to "compex" :)SQLJ is not dead. It is used a lot in mainframe environments. We're using it in a project which uses DB2 on z/OS. Moving from plain JDBC to SQLJ gave us a big performance improvement.
The WebSphere Studio (WSAD) development environment from IBM has build in support for SQLJ. It would be great if other development tools like Ant and frameworks like Spring and iBATIS supported SQLJ.
|
|
|
Message #129137
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SQLJ is not dead
SQLJ does appear to be dead, as far as Oracle are concerned: JDBC and SQLJ:
"Starting with Oracle Database 10g, we are desupporting the SQLJ translator... We will shortly provide (and post here) a utility to ease the migration of SQLJ applications to pure JDBC applications."
From time to time I actually considered Spring support for SQLJ, and even considered using SQLJ for a current client project (on Oracle), but this finding this ruled it out.
R
|
|
|
Message #129158
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SQLJ is not dead
I think it was not so bad idea, but problem is preprocessor, it generates unreadable code and breaks error diagnostic. Data access languages like plsql are better, but for data access only. I hope to "sell" SQLJ idea again and to use embedded SQL in anotations. SQL or procedure maps very good to DAO method and as I undersnad most developers use DAO with all persistence frameworks, I see no meaning for persistence if it is converted to data access again. Data access method can do more than SQL execution it is a very good subject for AOP.
It can be implemented manualy:
@Query "SELECT * FROM MY_TABLE WHERE id = $1"
SomeResult findById(int id){
ResultSet rs = getResultSet();
while(rs.next()){
//process it
......
}
}
Simple method can be abstract too:
@Query "SELECT * FROM MY_TABLE WHERE id = $1"
@Callback SomeResultCopier.class
abstract SomeResult findById(int id);
Add more anatotions like @Role,@Validate,@Log and it will be complete solution for enterprise application and it will be *declarative*.
|
|
|
Message #129169
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
picocontainer
with an amazingly compact implementation. That is an unbeatable concept.RegardsRolf Tollerud Actually Picocontainer beats it in terms of compactness. Picocontainer is about 50k wheras Spring is over 900k. Then again, you get a helluvalot more with Spring. :D
|
|
|
Message #129187
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
picocontainer
with an amazingly compact implementation. That is an unbeatable concept.RegardsRolf Tollerud Actually Picocontainer beats it in terms of compactness. Picocontainer is about 50k wheras Spring is over 900k. Then again, you get a helluvalot more with Spring. :D
As you mention, that is for Spring with all functionality, including many aspects outside of the core container. Spring does also ship packaged by individual areas. spring-core.jar, for example, is currently only 225k for the CVS version, probably a bit less for the current 1.0.2...
Regards,
Colin
|
|
|
Message #129199
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SQLJ is not dead
Juozas,
Code generation for DAOs is IMO more or less unnecessary if you use a good data access library :-) For example, the following are complete data access operations that are coded with Spring's data access helpers:
public void clearDatabase() throws DataAccessException {
getJdbcTemplate().update("DELETE FROM imagedb");
}
public void deleteImage(int imageId) throws DataAccessException {
getJdbcTemplate().update("DELETE FROM imagedb WHERE id=?", new Object[] {new Integer(imageId)});
}
public int getNrOfImages() throws DataAccessException {
getJdbcTemplate().queryForInt("SELECT COUNT(*) FROM imagedb");
}
public List getImages() throws DataAccessException {
return getJdbcTemplate().query(
"SELECT image_name, description FROM imagedb",
new RowMapperResultReader(new RowMapper() {
public Object mapRow(ResultSet rs, int rowNum) throws SQLException {
String name = rs.getString(1);
String description = rs.getString(2);
return new ImageDescriptor(name, description);
}
}));
}
}
As a detail, RowMapper implementations are thread-safe: They can thus also be kept as member objects of the DAO class, to be passed into a new RowMapperResultReader for each operation.
Note that there will be proper resource management, transaction participation, and translation of exceptions to Spring's generic DataAccessException hierarchy. The DAO implementation does not have to worry about any of those.
All you need to pass to the thread-safe JdbcTemplate instance used in this DAO is a javax.sql.DataSource to retrieve Connections from. Typically, this comes in via a setDataSource method or a constructor argument of type DataSource.
Similarly concise data access operations can be achieved for Hibernate, JDO, OJB and iBATIS SQL Maps, via Spring's corresponding template classes. For example, with Hibernate:
public Collection findOwners(String lastName) throws DataAccessException {
return getHibernateTemplate().find("from Owner owner where owner.lastName like ?", lastName + "%");
}
public Owner loadOwner(int id) throws DataAccessException {
return (Owner) getHibernateTemplate().load(Owner.class, new Integer(id));
}
public void storeOwner(Owner owner) throws DataAccessException {
getHibernateTemplate().saveOrUpdate(owner);
}
Juergen
|
|
|
Message #129201
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SQLJ is not dead
Juozai,
You can use Xdoclet hibernate tags and use hibernate named queries to get somewhat declarative data access. There's also a notion of named native SQL queries in hibernate you can define as metadata.
|
|
|
Message #129229
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tech Talk - Rod Johnson on The Spring Framework, AOP
There are actually two fairly significant transcription errors in question 5. I have highlighted them with @@@ below. In each case, when Rod said 'setter' in the audio, the transcript says 'constructor'. This obviously makes the transcript not make any sense :-)
-----
One of the differences is that Spring IoC is not ideological. For example, the PicoContainer guys now have support for @@@constructor@@@ injections and they do recognize you need support for both but they have a strong preference for constructor injection.
We take the view that the customer is always right. Personally, I do still prefer @@@constructor@@@ injection, but nevertheless, if you choose to use Spring, if you choose to use IoC, and you want to use constructor injection, I see it as our job to ensure that you can do that effectively.
-----
Regards,
Colin
|
|
|
Message #129242
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SQLJ is not dead
No, there is a very big difference. Probably it is not very clear from my posts, but idea is drop code and metadata (no generated files) and to maintain declaration only. Prototype works vey good for me (It is implemented with javadoc tags too). AOP helps to implement declerative cache, collect statistics. I have everyting I need for data access, I use the same decleration for query validation and automated tests, I have qery palans and statistics for performance tuning. Everything is related to code, I click on method declaration in UI and I see cache hit rate, query plan, SQL. This way scales very good and it is thread safe, there is no local cache and it has no problems with results of any size.
I understand, this way can not become more popular than O/R at this time, but I think it is EJB 4 :)
|
|
|
Message #129249
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SQLJ is not dead
BTW I have tried the same with JTA and RPC (not for production at this time), it must work as WS without any coding and problems too (The same declaration is reused, protocol is a configuration parameter), but do not have use cases for WS at this time.
|
|
|
Message #129291
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
to fix again and again and again and…
Backwards compatibility is important to customers. It's hard for a Microsoft zealot to understand this, they don't have such a thing in their world...
|
|
|
Message #129322
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tech Talk - Rod Johnson on The Spring Framework, AOP
Colin,
Thanks for pointing these out. The typos have been fixed.
Regards,
Nitin
|
|
|
Message #129332
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tech Talk - Rod Johnson on The Spring Framework, AOP
Colin,Thanks for pointing these out. The typos have been fixed.Regards,Nitin You may have one more..."One of the differences is that Spring IoC is not ideological. For example, the PicoContainer guys now have support for setter injections and they do recognize you need support for both but they have a strong preference for setter injection."
Don't the Pico guys like constructor injection and the Spring guys setter?
|
|
|
Message #129335
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tech Talk - Rod Johnson on The Spring Framework, AOP
In fixing the two typos, looks like I created two more. :)
Dave, you're right, the Pico guys prefer constructor injection and the Spring guys prefer setter injection.
Errata fixed.
-Nitin
|
|
|
Message #153757
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SQLJ is not dead
SQLJ does appear to be dead, as far as Oracle are concerned: JDBC and SQLJ:"Starting with Oracle Database 10g, we are desupporting the SQLJ translator... We will shortly provide (and post here) a utility to ease the migration of SQLJ applications to pure JDBC applications."From time to time I actually considered Spring support for SQLJ, and even considered using SQLJ for a current client project (on Oracle), but this finding this ruled it out.R
Rod, this is interesting. Look at that link again, it appears that there was enough industry inertia that Oracle reversed their decision! This is a strong sign that SQLJ is still very much alive in many environments!
JDBC and SQLJ
|
|
|
Message #189303
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SQLJ is Back
Rod,
JDBC and SQLJ:
The initial motivation for desupporting SQLJ was it's low adoption by the J2EE commnity however, we found out that it has been largely adopted by database developers. Following numerous complaints, and listening to his customers, Oracle has reverted the SQLJ Desupport decision; we have cancelled the Metalink Desupport Notice. Starting with Oracle Database 10g 10.1.0.4 patch set release, the SQLJ translator will be re-enabled, again. In the mean time, customers have full access to SQLJ functionalities using -sqlj option of the new Oracle Database 10g JPublisher utility.
|
|
|
Message #189315
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
CachedRowSet
Too many changes since July 2004...
Many times I was forced to design huge frameworks using PL/SQL, Microsoft Embedded SQL, etc; it is impossible to have such intermediary layer as a Java code running in separate container...
What about javax.sql.rowset.CachedRowSet, will it die?
|
|
|
Message #253176
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SQLJ is not dead
It appears in the same link you've provided, JDBC and SQLJ, that Oracle as reverted its decision to decommission support for SQLJ. So now may be an appropriate time to reconsider SQLJ support in Spring.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
