|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 39
Messages: 39
Messages: 39
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Seam 1.1.5: Security, Email, PDF and more
JBoss Seam 1.1.5 has been released. Despite the strange version number, it includes exciting new functionality including:- Seam/Security - integrated JAAS-based authentication and unique EL and Drools-based authorization engine
- Facelets-based email templating - define emails using JSF tags in a Facelets template
- Facelets-based PDF templating - create iText PDF pages using JSF tags and Facelets
- WebSphere support - examples now tested and deployable on WebSphere 6.1 (along with JBoss, WebLogic and GlassFish)
- J2EE support for seam-gen - quickly generate a Seam application that deploys to a WAR on any J2EE 1.4 application server
- New JSF controls including a file upload component
- New examples and documentation enhancements
Seam 1.1.5 takes JSF where it has never been before: you can use Facelets with Seam's new JSF tag libraries to define PDF documents, and even email templates! It's now super-easy to generate reports and send emails from a Seam application. A future version of Seam will even include JSF tags for generating charts in the PDF document - soon you'll be able to use Seam for problems which you previously would have needed a specialized reporting engine for.
Until today, Security was the most requested feature in the Seam forums. Seam/Security offers an innovative authorization model based around Unified EL and JBoss Rules. The model was designed to allow elegant solution of complex cases such as row-level security and ACL-based permissioning. Right now, Seam/Security lacks some bells and whistles, but the hard work is done and we can now concentrate on executing our aggressive roadmap of new features.
Seam has now been tested on all the mainstream Java EE application servers, and JBoss is now preparing to offer Seam support on platforms other than JBoss AS (at first, the list of supported platforms will include WebLogic, WebSphere, GlassFish and possibly Tomcat).
This release was a team effort by Shane Bryzak (Seam/Security, file uploads), Norman Richards (PDF controls), Pete Muir (Email, select list control), Michael Yuan (WebSphere support) and definitely not by Gavin King (vacation, influenza, girlfriend birthday).
Full changelog:
http://jira.jboss.org/jira/secure/ReleaseNote.jspa?projectId=10071&styleName=Html&version=12311059
Download page:
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=163777&release_id=482792
Seam/Security documentation:
http://docs.jboss.com/seam/1.1.5.GA/reference/en/html/security.html
Seam PDF documentation:
http://docs.jboss.com/seam/1.1.5.GA/reference/en/html/itext.html
Seam email documentation:
http://docs.jboss.com/seam/1.1.5.GA/reference/en/html/mail.html
|
|
|
Message #226585
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spring support?
I'd love to see Spring support in Seam. Once it's in, we'll take it for a testdrive and possibly switch to it pretty soon if all the praise I've heard and read still stands.
On the other side, pushing other JBoss products is a definite drawback (at least for us) in the way of adaptation. The ability to stay vendor-independent seems to be more important than ever these days..
|
|
|
Message #226586
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Vendor independenc?
On the other side, pushing other JBoss products is a definite drawback (at least for us) in the way of adaptation. The ability to stay vendor-independent seems to be more important than ever these days..
Seam works in many different environments other than JBoss AS. Spring is also a vendor, so what's the problem with pushing yet another app-server-neutral framework? Just curious...
thanks,
bill
|
|
|
Message #226587
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring support?
...On the other side, pushing other JBoss products is a definite drawback (at least for us) in the way of adaptation. The ability to stay vendor-independent seems to be more important than ever these days.. Note that Seam has been proposed as the basis for a JSR, JSR-299, the Web Beans JSR. As such, I think it's fair to say that improvements in Seam are likely to feed into the JSR's features (or, at the very least, participants in the JSR are likely to provide equivalents) so stuff like this isn't quite as vendor-dependent as one might think.
Plus, Gavin & co. have always done a pretty good job of not tying you to a specific vendor, outside of the library itself.
|
|
|
Message #226592
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring support?
We don't try to couple Seam with any other JBoss technologies. In fact, we have the annoying habit of rejecting opportunities to couple more tightly with JBoss things when it would reduce the choices available to the users. But, we aren't afraid to flat out use a technology when it is the right thing. The business process technology is JBPM and rules are handled by Drools. (JBoss Rules) For those technologies standards don't exist (at least not in a way that is useful to us) and so have chosen them for now.
For a counter-example, look at the JPA support. The final JPA spec had a few glaring omissions that severely limit the possibilities of a pure-JPA application. We could have easily forced everyone using Seam to use Hibernate so that you would have access to those critical features. But, rather than forcing people to use "our" persistence, we also support pure JPA access for those applications that happen not to need those things. If there is any JBoss technology you'd think the Seam team wants to promote the use of, wouldn't it be Hibernate?
So, I hope you can see that we've tried very hard not to tie you down to specific technologies. We've worked hard to make sure Seam runs on non-JBoss platforms using non-JBoss technologies where possible.
|
|
|
Message #226595
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Vendor independenc?
Hmm strange you bring that up, never thought of that this way. I think the difference is that somehow they managed to avoid looking like a vendor. They *do* feel neutral, but that's getting slightly offtopic.
My original point was that I'm not that much sold on the EJB component model (for that very reason I'm less excited about the Web Beans JSR). If Seam allows me going the POJO way (I know it does), does not tie me to any proprietary framework or environment and I can easily integrate to the rest of my stack, I'm buying in.
|
|
|
Message #226600
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It is vendor independent
I'd love to see Spring support in Seam. Once it's in, we'll take it for a testdrive and possibly switch to it pretty soon if all the praise I've heard and read still stands.
I am not sure if Seam needs spring to be supported but that's another discussion of course.
On the other side, pushing other JBoss products is a definite drawback (at least for us) in the way of adaptation. The ability to stay vendor-independent seems to be more important than ever these days..
If you knew Seam a little bit closer you would know that Seam IS vendor independent. JBoss extending support for Seam for other application servers and (may be) even just servlet containers such as Tomcat.
|
|
|
Message #226601
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
yes
If Seam allows me going the POJO way (I know it does), does not tie me to any proprietary framework or environment and I can easily integrate to the rest of my stack, I'm buying in.
It does support POJO+hibernate 'mode' if that's what you ask?
|
|
|
Message #226602
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
looks good.
I'm excited about where Steam is going. I'm finally getting ready to jump ship on using Struts, and have been looking into and reading up on JSF. I think it might be worth my while to give Steam a shot at the same time.
Maybe I was misunderstood, but I thought that Gavin was talking about coming out with a new security model that (at some point) was going to be build into Steam. Did I just misunderstand this or is this still in the works? I'm interested in this as I'm not terribly fond of JAAS.
|
|
|
Message #226603
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: looks good.
The rule-based security framework is in the 1.1.5 release. It is so much better and more powerful than the standard JEE security model ... Check it out (see the doc links in the news post).
|
|
|
Message #226607
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: It is vendor independent
I am not sure if Seam needs spring to be supported but that's another discussion of course.
From purely a tech perspective I would agree. Spring has little to offer in a Seam environment. I think we've created something that is both simpler and more powerful. However, there are many applications out there that are written with Spring in mind, and there are many developers out there who understand the technology. There's a lot of value in providing a path for those developers to leverage existing code and existing knowledge.
|
|
|
Message #226608
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: It is vendor independent
I am not sure if Seam needs spring to be supported but that's another discussion of course.
From purely a tech perspective I would agree. Spring has little to offer in a Seam environment. I think we've created something that is both simpler and more powerful. However, there are many applications out there that are written with Spring in mind, and there are many developers out there who understand the technology. There's a lot of value in providing a path for those developers to leverage existing code and existing knowledge.
|
|
|
Message #226611
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
awful wikitext
The addition of s:formattedText seems like a goofy hack and kind of a boondoggle. I'm definitely not a fan of the wiki text, or in fact any kind of wikitext markup. Is there any plan to genericize the text formatting? I'd like to see it as a container tag that transforms its children, allows for addition and modification of text transformers with f:facet or similar, and including something like s:sanitizedHTML perhaps? As nice as facelets is, it's hard to compete with some of the perl toolkits where I can just "pipe a block" through an arbitrary transform.
Oh yeah and I'd like a pony :)
Perhaps it's time to split the Seam UI components like this one that are really just "extra" into a separate jar and taglib?
En passant: I hear Spring support is in fact coming. I doubt it could support all of spring, such as AOP (and certainly not Spring MVC), but it should at least be able to inject Spring Beans into the Stateless scope.
|
|
|
Message #226614
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spring support
I'd love to see Spring support in Seam.
Norman and Ales have already started work on this, and it will come in less than two months, I expect.
pushing other JBoss products is a definite drawback
Seam integrates JCP-standard technologies with several non-standards-blessed technologies interesting technologies into a consistent, unified, programming model. These include:
The standards include:
* JSF
* EJB3/JPA
* JAAS authentication
* JSP
* Unified EL
* JavaMail
* Portlet
The non-standards include:
* Facelets
* jBPM
* Hibernate
* iText
* Drools
* JCaptcha (coming soon)
* Ajax4JSF
* ICEFaces
* Trinidad (coming as soon as Trinidad actually gets released)
Of the non-standards, 3 are JBoss projects, 6 are not.
In each case, the nonstandard technology was chosen for being the best thing in its category, without regard for the vendor. jBPM, Hibernate and Drools are there because they are damn good, not because they are JBoss.
Cheers :-)
|
|
|
Message #226616
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JAAS
Maybe I was misunderstood, but I thought that Gavin was talking about coming out with a new security model that (at some point) was going to be build into Steam. Did I just misunderstand this or is this still in the works? I'm interested in this as I'm not terribly fond of JAAS.
To clarify, we use JAAS for *authentication*, where it is actually quite a reasonable model. But don't worry, you won't actually need to directly interact with JAAS APIs unless you start to need to customize stuff. What this does mean is that you can re-use existing JAAS authentication providers with Seam/Security.
In the initial release, Seam/Security is more about authorization than authentication. We don't use the JAAS authorization APIs at all.
|
|
|
Message #226617
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: It is vendor independent
I am not sure if Seam needs spring to be supported but that's another discussion of course.
From purely a tech perspective I would agree. Spring has little to offer in a Seam environment. I think we've created something that is both simpler and more powerful. However, there are many applications out there that are written with Spring in mind, and there are many developers out there who understand the technology. There's a lot of value in providing a path for those developers to leverage existing code and existing knowledge.
While I'm not personally a fan of the Spring Way, and I believe that we offer a programming model that lets you get your job done *much* faster and more elegantly than Spring, the reality is that there are millions of lines of Spring code out there in the world, and the projects that are migrating to Seam will need to re-use that code. It's not reasonable to ask them to rewrite everything from scratch.
Meanwhile, there are probably some diehards who don't share my view of Spring, and we want let them continue using the things they like about Spring, without missing out on the benefits of Seam.
|
|
|
Message #226619
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: awful wikitext
Oh yeah and I'd like a pony :)
No promises, but if you open a JIRA issue, we'll see what we can do. :)
|
|
|
Message #226621
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: awful wikitext
The addition of s:formattedText seems like a goofy hack and kind of a boondoggle. I'm definitely not a fan of the wiki text, or in fact any kind of wikitext markup.
If you don't like wikitext, don't use it ;-)
But seriously, collaboration software (forums, blogs, wikis) needs this stuff, and environments like RoR come with it basically builtin.
Yeah, wikitext is always less than elegant, but trying to type markup into a textarea is close to impossible.
Is there any plan to genericize the text formatting?
C'mon, its like one class and an ANTLR grammer! If you want something else, just use something else :-)
I doubt it could support all of spring, such as AOP (and certainly not Spring MVC), but it should at least be able to inject Spring Beans into the Stateless scope.
I don't see any problem with supporting AOP on Spring components. Why should that be a problem?
|
|
|
Message #226622
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: awful wikitext
Oh yeah and I'd like a pony :)
No promises, but if you open a JIRA issue, we'll see what we can do. :)
I am -1 on the pony. What about a donkey?
|
|
|
Message #226623
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spring support
I've been following Seam development fairly closely for the past few months, and plan to build my next significant application with Seam. I'm definitely impressed with what they've produced. Seam tackles developmental issues I've not seen other open source frameworks address, such as managing "conversational" state across business processes simply and elegantly (provided you're using JBPM). The new security functionality is the cleanest I've seen - compared to Acegi it's very straightforward, and covers entitlement.
I'd also like to see Seam be a bit more proactive on addressing Spring integration. There is significant overlap no doubt, but Spring has significant mindshare and is generally another top notch tool. Seam would only benefit from showing how and where integration would make sense.
Incidentally, they already do to some extent. Check out http://wiki.jboss.org/wiki/Wiki.jsp?page=SpringAndSeamIntegration to see how you can inject Spring beans into any Seam component. Very simple, and I think covers a significant number of integration points as is.
|
|
|
Message #226624
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JAAS
To clarify, we use JAAS for *authentication*, where it is actually quite a reasonable model. But don't worry, you won't actually need to directly interact with JAAS APIs unless you start to need to customize stuff. What this does mean is that you can re-use existing JAAS authentication providers with Seam/Security.
In the initial release, Seam/Security is more about authorization than authentication. We don't use the JAAS authorization APIs at all.
This makes sense, yes of course I would like to be able to continue to use JAAS providers, and your right my issue was more specifically with the authorization aspects JAAS. This is possibly a big +1 for me to switch.
Thanks again for all the contributions you and team have made over the last few years.
|
|
|
Message #226630
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
seam tooling support?
I for one am very excited about Seam. Does anyone know if vendors such as Oracle are planning tooling support for this? Oracle already provides excellent support for EJB3 and JSF; hopefully they will do the same for Seam.
|
|
|
Message #226633
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Vendor independenc?
Hmm strange you bring that up, never thought of that this way. I think the difference is that somehow they managed to avoid looking like a vendor. They *do* feel neutral, but that's getting slightly offtopic.
That is probably true in the early days of Spring. Havn't heard there will be another Expert One on One J2EE Development in the pipeline (what a pity!), an indication that Rod and Co no longer intends to appear a non vendor?
|
|
|
Message #226634
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: seam tooling support?
I for one am very excited about Seam. Does anyone know if vendors such as Oracle are planning tooling support for this? Oracle already provides excellent support for EJB3 and JSF; hopefully they will do the same for Seam.
The netbeans guys have been very supportive of Seam in their tools. I think you'll see much more tooling as JSR 299 matures and we see this technology making part of the standard Java EE stack.
|
|
|
Message #226658
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Seam without EJB3 question
Since the introduction of the EntityHome and the EntityQuery objects, there is no need to use session beans anymore with JSF. So my question is what are the benefits of using session beans if I am only building a web application using JSF, Seam and JBoss? (Besides the obvious fact that if I don't use session beans, I can run it on any non-j2ee container) Is there a preference of which to use (POJO vs session bean)?
|
|
|
Message #226660
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Seam 1.1.5: Security, Email, PDF and more
I think Seam has done an excellent job of filling in some of JSF's holes, and also providing a unified programming model for Java EE.
Some of Seam's features, however, are useful in standard JSF apps. Gavin, Michael, Norman, and co: it possible to use the Email and PDF components outside of Seam?
---
Kito D. Mann - Author, JavaServer Faces in Action
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
* Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 *
|
|
|
Message #226661
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Seam 1.1.5: Security, Email, PDF and more
it possible to use the Email and PDF components outside of Seam?
In theory yes, but it wouldn't work out of the box. These modules rely on Seam for managing the internal components. (Seam can automatically load the application components with no XML or other configuration hooks) You'd have to create that that and provide implementations for any core Seam components they use. It isn't something I'm inclined to work on, but if someone else has that itch, they are more than welcome to give it a go.
|
|
|
Message #226664
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Seam 1.1.5: Security, Email, PDF and more
Let me add to that by saying that I think this would be a much more feasible in a WebBeans world. If Java EE can provide that extra infrastructure, it would be much easier to write fully featured modules (application components + UI components) like these that can work independently of Seam.
|
|
|
Message #226666
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
read here
Since the introduction of the EntityHome and the EntityQuery objects, there is no need to use session beans anymore with JSF. So my question is what are the benefits of using session beans if I am only building a web application using JSF, Seam and JBoss? (Besides the obvious fact that if I don't use session beans, I can run it on any non-j2ee container) Is there a preference of which to use (POJO vs session bean)?
http://labs.jboss.com/portal/jbossseam/j2ee/part02.html
However, POJOs also have less features than EJB3 components since POJOs cannot get EJB3 container services. Examples of EJB3 services you lose in non-EJB3 Seam POJOs include the following.
* The @PersistenceContext injection no longer works in POJOs. In order to obtain an EntityManager in a Seam POJO, you have to initialize the EntityManager in Seam configuration file and then use the Seam @In annotation to inject it into the POJO.
* There is no support for declarative method-level transaction in POJOs. Instead, you can configure Seam to demarcate a database transaction from when the web request is received until the response page is rendered.
* Seam POJOs cannot be message-driven components.
* No support for @Asynchronous methods.
* No support for container managed security.
* No transaction or component level persistence contexts. All persistence contexts in Seam POJOs are "extended" and stays valid over the entire conversation.
* No integration into the container's management architecture (ie. JMX console services).
* No Java remoting (RMI) into Seam POJO methods.
* Seam POJOs cannot be @WebService components.
* No JCA integration.
So, if you do not have the need for the above services (most small to middle size web applications do not), you are can assemble your applications with pure Seam POJOs.
|
|
|
Message #226670
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring support?
I'd love to see Spring support in Seam. Once it's in, we'll take it for a testdrive and possibly switch to it pretty soon if all the praise
Your wish resembles me the following:
I'd like to see Java SE as a part of .Net Framework.
I've designed and developed several projects based on Spring + (Wicket/Pure Servlets+DWR/Prototype.js/...) architecture and I see these vivid products as a natural replacement for JSF/EJB X bloatware.
Regards,
ejboy
|
|
|
Message #226671
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring support?
I'd love to see Spring support in Seam. Once it's in, we'll take it for a testdrive and possibly switch to it pretty soon if all the praise
Your wish resembles me the following:
I'd like to see Java SE as a part of .Net Framework.
I've designed and developed several projects based on Spring + (Wicket/Pure Servlets+DWR/Prototype.js/...) architecture and I see these vivid products as a natural replacement for JSF/EJB X bloatware.
Regards,
ejboy
Just curious...
Why is EJB 3.0 bloatware when with 2 annotations (@Stateless/@PersistenceContext) you get "REQUIRED" transaction demarcation as well as automatic JPA session propagation and management. And you don't have to write any XML.
public interface MyLocal
{
public void doit();
}
@Stateless
public class MyBean implements MyLocal
@PersistenceContext EntityManager em;
public void doit()
{
do something
}
}
Compile those 2 files, jar them. Thats it. Your doit() method automatically implicitly defines a transaction boundary. EntityManager is automatically created/associated/destroyed with the transaction.
Add the Seam @In/@Out annotations and you get automatic integration with your HTTP Session. Add the webflow annotations, etc...
Bill
|
|
|
Message #226673
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring support?
Hello Bill,
Why is EJB 3.0 bloatware when with 2 annotations (@Stateless/@PersistenceContext) you get "REQUIRED" transaction demarcation as well as automatic JPA session propagation and management. And you don't have to write any XML.
...And to make it work outside JBoss (for testing or other purposes) you have to put on classpath just a 10Mb of jars ;)...
All that you've mentioned was available in Spring for years, of course without annotations, but Spring supported annotations before EJB3.
Spring is a proven and a solid technology, but I cannot find REAL applications/examples of EJB3 PROFESSIONAL usage.
And please do not tell me that
@Stateless class MyFirstBean {}
is a professional programming, it's great for demo applications and prototyping, but makes no much sense for long term projects. Anyway you can code everything in Ruby even faster, but what about maintainability. I'm sick and tired with EJB 2.0 (JBoss+Weblogic) and use EJB 3.0 only to show our customers that we have expertise in all areas.
P.S. I've understood the power of Spring only when we've finished the project similar to Google Calendar. With support for annotations Spring is as productive as EJB, but much easier to integrate with other technologies.
Regards,
ejboy
|
|
|
Message #226674
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Seam without EJB3 question
Since the introduction of the EntityHome and the EntityQuery objects, there is no need to use session beans anymore with JSF. So my question is what are the benefits of using session beans if I am only building a web application using JSF, Seam and JBoss? (Besides the obvious fact that if I don't use session beans, I can run it on any non-j2ee container) Is there a preference of which to use (POJO vs session bean)?
IMO, session beans still have some unique advantages.
First, even though I did a bunch of work to ensure that stateful JavaBean components can be efficiently clustered in Seam, my implementation is still not as efficient as the SFSB implementation in JBoss (I can't speak for other appservers) which can do stuff like attribute-level dirty checking and replication.
Second, session beans integrate nicely with the container's management/monitoring/deployment infrastructure. Especially the monitoring stuff is very useful.
Third, Seam JavaBean components don't support REQUIRES_NEW transaction propagation or transaction-scoped persistence contexts. (You don't need this stuff for basic web-apps, but people do use it for some complex cases.)
EJB gives you the timer service, which is what we build Seam async methods and async events on top of.
Finally, EJB supports remoting via @Remote or @WebService. I have zero intention of reproducing this stuff for JavaBean components. This will be a very important distinction once Seam/WS is ready ;-)
Finally, we are going to work hard in the Web Beans and EJB specs to make EJB even better in the next version of Java EE.
Really, if your environment supports EJB3, there is no really good reason to not use them. Well, one, perhaps: we screwed up in EJB3 by requiring the local interface. We should have ditched that, it's a PIA. I'm sure it will be optional in the next rev of EJB.
|
|
|
Message #226676
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: read here
However, POJOs also have less features than EJB3 components since POJOs cannot get EJB3 container services. Examples of EJB3 services you lose in non-EJB3 Seam POJOs include the following.
* The @PersistenceContext injection no longer works in POJOs. In order to obtain an EntityManager in a Seam POJO, you have to initialize the EntityManager in Seam configuration file and then use the Seam @In annotation to inject it into the POJO.
* There is no support for declarative method-level transaction in POJOs. Instead, you can configure Seam to demarcate a database transaction from when the web request is received until the response page is rendered.
* Seam POJOs cannot be message-driven components.
* No support for @Asynchronous methods.
* No support for container managed security.
* No transaction or component level persistence contexts. All persistence contexts in Seam POJOs are "extended" and stays valid over the entire conversation.
* No integration into the container's management architecture (ie. JMX console services).
* No Java remoting (RMI) into Seam POJO methods.
* Seam POJOs cannot be @WebService components.
* No JCA integration.
So, if you do not have the need for the above services (most small to middle size web applications do not), you are can assemble your applications with pure Seam POJOs.
Oh, that's an earlier list I wrote ;-)
I need to revise that list a little:
* Seam JavaBean components can now do some limited declarative transaction demarcation.
* The "no support for container-managed security" is no longer an issue now that Seam/Security is here :)
|
|
|
Message #226677
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Seam without EJB3 question
Since the introduction of the EntityHome and the EntityQuery objects, there is no need to use session beans anymore with JSF.
I think that's a little extreme. Once you start using things like IceFace's sortable columns, or just want to do something like change the sort order programmatically youself, you find EntityQuery won't do it and you need code instead. Similar goes for EntityHome, though in that case I can get a good head start by subclassing it.
Something using the Hibernate Criteria API would be more useful to me, but the Seam folks are more focused on JPA than Hibernate, so I'll be doing it myself. But it should be painless what with the @DataModel annotation and all :)
As for EJBs vs POJOs, I'd say stick with what you started with. Chances are if you were using POJOs, you didn't need any of the extra services you get with EJBs anyway (I use EJBs because I ocasionally need the global @PersistenceContext that's independent of the conversation-scoped EntityManager)
|
|
|
Message #226680
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring support?
And please do not tell me that
@Stateless class MyFirstBean {}
is a professional programming, it's great for demo applications and prototyping, but makes no much sense for long term projects.
What the...
Why doesn't it make sense for long term projects? What's wrong with it? If the default case works for your project, then it works. I know in our case, it works great. The annotations let you manage by exception. That's the whole point.
And what's "Professional Programming"? We have 3 systems done already, and are working a fourth using EJB 3. Sales reporting system, a credit card management system, and an asset tracking and software delpoyment system for the server farms.
We have a fourth we're just starting, and these apps are rolling out fast.
So far we're quite happy with EJB 3, it hasn't betrayed us yet.
|
|
|
Message #226685
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring support?
We have 3 systems done already, and are working a fourth using EJB 3.
We also had several systems done using EJB 2.0. And where is this technology now?
Spring is natural and evolutionary - EJB 3 is an artificial snapshot of current trends. The EJB authors continue to ignore other projects and reinvent the wheel, e.g. EJB Interceptors is AOP for dummies.
I do not want to offend anybody, moreover I make my money mostly because development in Java is too complex comparing to other platforms ;)
|
|
|
Message #226696
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
for dummies
The EJB authors continue to ignore other projects and reinvent the wheel, e.g. EJB Interceptors is AOP for dummies.
Spring AOP used to be "AOP for dummies" as well. Wasn't that much richer than the EJB 3.0 model. I remember the Spring guys stating that it was "good enough" for the majority of projects and "simpler to learn" than "true" AOP. Adrian Coyler comes along and joins Spring and their tune changes. Its a common tact that people use when their technology is inferior. I try not to do that myself and hope people will send a nasty email to me if I ever have/will done it.
Also, I'll say that the Spring founders ignore standardizations efforts in order to retain vendor control. It would be cool to standardize IoC under something like OSGi so IoC isn't dominated by one vendor.
Bill
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
JavaSpaces has been a bit of an unknown technology for a long time. It's one of those technologies that programmers know is out there, but haven't actually used enough to say they understand what it's for or what it can do for them. JavaSpaces is, in very simple terms, a kind of client/server map, a grid in which data lives. This article walks through the creation of a simple computation server, explaining the Spaces model along the way.
(January 29, Article)
Terracotta DSO is an open source technology created by Terracotta, meant to provide clustering to Java at the virtual machine level. It does so by weaving code around specific classes, which will communicate with a specific server process to retrieve and update data as needed. This article walks through getting one's feet wet with DSO.
(January 23, Article)
Ted Neward and other noted industry bloggers examine the heated topic of interoperability today. Watch out for what happens when worlds collide.
A companion/standalone book to Mastering EJB 2, EJB Design Patterns seeks to solidify and centralize all the cutting edge strategies and design patterns in use today.
(Book PDF Download)
Enterprise service buses are the preferred tools for integrating systems with heterogeneous data interchange interfaces and based on a wide array of technologies, from COBOL to CORBA to JEE. This article is an introduction to ESBs and enterprise integration using Mule, the open-source ESB.
(January 15, Article)
The fourth edition in the Mastering EJB series, this book provides in-depth coverage on the changes that come with EJB 3.0. More than 50% new and revised, the free download covers
the latest features of the new release and information on the Java Persistence API and the entities defined therein.
(July 17, Book Download)
This three part series is based on chapter two of Groovy in Action from Manning Publications. The chapter introduces the language in a high-level fashion. After reading this series, you will have a solid understanding of Groovy fundamentals. This is part one of the three.
(January 9, Book Excerpt)
This article by Jeff McAffer and Simon Kaegi shows how the Eclipse Equinox modular runtime works, from Eclipse' perspective, and then discusses how Equinox can be embedded in a serverside application.
(January 2, Article)
In this tech talk, Iona's Oisin Hurley and Steve Vinoski discuss Iona's view of what's important around SOA design and implementation, focusing on Iona's Celtix and Artix offerings, as well as covering some of Iona's tooling and ancillary libraries, like CXF.
(December 29, Tech Talk)
This article by Daniel Rubio clearly explains many of the advantages Java EE 5 offers for developers, showing the advantages of the new platform's changes. Annotations, EJB3 (including persistence), and changes in the web tier (including the standardization of JSF) are the main highlights.
(December 19, Article)
Java Persistence with Hibernate, by Christian Bauer and Gavin King, explains Hibernate's implementation of the Java Persistence API, covering queries, fetching strategies, caching, transactions, conversations, best practices in database design, optimizations, and coverage of JBoss Seam, JBoss' application framework for JSF, EJB 3.0, and Hibernate.
(December 14, Book Excerpt)
Google Web Toolkit (GWT) lets you build Ajax applications in Java. In this tech talk, Bruce Johnson talks about what you can expect when you build your web app with GWT. Bruce also talks about using GWT with existing JavaScript libraries.
(December 11, Tech Talk)
Learn how to build a collaborative, multi-user application with Ajax Push. This talk, recorded at the Ajax Experience in October takes a complete trip through the Ajax Push pipeline, answering questions with the lessons learned from developing the ICEfaces framework.
(December 4, TechTalk)
Using a detailed case study, application architect Paulo Caroli illustrates how to effectively apply Mock objects when performing Test Driven Development (TDD).
(December 4, Article)
In chapter three of iText in Action: Creating and Manipulating PDF, Bruno Lowagie takes a close look at the PDF, explaining why PDF was invented and how it evolved into a de facto
standard. Lowagie also lists different versions of the PDF specification to focus on features such as compression and encryption.
(November 22, Book Excerpt)
This chapter excerpt, titled "Development kick-start," walks through installing a blog server and developing a simple blog application using the MetaWebLog API, a widely supported
XML-RPC based Web services protocol that allows retrieving, posting and updating blog entries.
(November 9, Book Excerpt)
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)
|
|
