|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 29
Messages: 29
Messages: 29
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
ICEFaces 1.6: With Seam and JSF 1.2 compatibility
ICESoft has announced the release of the open-source ICEFaces 1.6.0, which bundles additional JSF components, tools to help integrate with JBoss Seam, compatibility with JSF 1.2 containers, compatibility with Opera, and support for the Liferay Portal.
One of ICEFaces' core capabilities is the ability to initiate a change to a client-side DOM from the server; an example of this is the auction monitor demo, which updates information live while users make bids.
They've also updated IDE support for Eclipse, Netbeans, and JDeveloper.
ICEFaces integration consists of registering a set of servlets to handle JSF requests to provide ICEFaces capabilities (such as the ability to update a model on the client from the server side, as mentioned above) and the use of XHTML as opposed to HTML.
The JSF 1.2 compatibility is not quite complete; it allows deployment into JSF 1.2 containers such as Glassfish, but requires the use of the JSF 1.1 deployment descriptor and an older web.xml descriptor, too, which serves to disable some of Java EE's core features (such as resource injection.) However, the ability to deploy into these containers is a big first step, and we should expect full 1.2 compatibility as the newer JSF specification becomes more common.
JBoss Seam is supported with a custom version of SeamGen and other examples.
ICEFaces is an excellent component set for JSF, with the ability to update data on a client as the server determines need and an excellent component set. Congratulations, guys.
|
|
|
Message #236357
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ICEFaces 1.6: With Seam and JSF 1.2 compatibility
The JSF 1.2 compatibility is not quite complete; it allows deployment into JSF 1.2 containers such as Glassfish, but requires the use of the JSF 1.1 deployment descriptor and an older web.xml descriptor, too, which serves to disable some of Java EE's core features (such as resource injection.) However, the ability to deploy into these containers is a big first step, and we should expect full 1.2 compatibility as the newer JSF specification becomes more common.
So, should I wait?
I heard that ICEFaces doesn't compatible with Ajax4jsf. Is that true (i.e. we cannot use 2 in the same application)?
|
|
|
Message #236361
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR-168 and Liferay Portal questions
Hi,
if I create a portlet for Liferay using ICEFaces,
Is the look & feel of the ICEFaces compoments the same of the Liferay portal ?
If I change the look & feel of the portal, does change the look and feel of the ICEFaces components of my portlet?
Can I use ICEFaces for creating portlets for other JSR-168 portals ?
Is it tested in WebSphere Portal ?
Thank you in advance
Javier Paniza
|
|
|
Message #236370
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ridiculous
JSF 1.2 support only now, and still half baked!??
What the heck are these guys thinking? It's much more important to support latest version of a standard in timely manner, than to add some stupid zooming DHTML gimmicks.
IMHO this also sends the signal that if we would commit to using ICEFaces we probably would not be able to upgrade to JSF 2.0 for 1-1.5 years after spec completion.
/Henri Karapuu
|
|
|
Message #236392
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ICEFaces 1.6: With Seam and JSF 1.2 compatibility
The JSF 1.2 compatibility is not quite complete; it allows deployment into JSF 1.2 containers such as Glassfish, but requires the use of the JSF 1.1 deployment descriptor and an older web.xml descriptor, too,
So, should I wait?
Probably not, but it depends which JSF 1.2 features you require (please add these requirements to the discussion). The current benefit is that you can use GlassFish and JBoss 4.2AS with the server-provided JSF implementation. Note that Facelets is still the recommended view definition technology for ICEfaces with JSF 1.2.
I heard that ICEFaces doesn't compatible with Ajax4jsf. Is that true (i.e. we cannot use 2 in the same application)?
This is not a tested configuration and incompatibilities have been observed in the past. ICEfaces and Ajax4JSF take very different approaches to page rendering and view definition so compatibility may be possible but is not likely trivial. Since one of the main benefits of ICEfaces is that update regions do not need to be specified by the designer, it is certainly important to ask why the two frameworks need to be combined.
|
|
|
Message #236393
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSR-168 and Liferay Portal questions
Hi,
if I create a portlet for Liferay using ICEFaces,
Is the look & feel of the ICEFaces compoments the same of the Liferay portal ?
If I change the look & feel of the portal, does change the look and feel of the ICEFaces components of my portlet?
We're working closely with Liferay on this, but unfortunately look & feel is somewhat outside JSR-168 and needs to be handled in a portal-specific manner. Some styles are picked up automatically through CSS mechanisms, but some are not.
Can I use ICEFaces for creating portlets for other JSR-168 portals ?
Is it tested in WebSphere Portal ?
Thank you in advance
Javier Paniza
ICEfaces is not yet tested with WebSphere Portal, but we expect to support it in the future. Any feedback you can provide on using the current ICEfaces example portlets with WebSphere would be most welcome.
|
|
|
Message #236396
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
What the heck are these guys thinking?
We were actually listening to our community, and delivering on the priorities established there.
...using ICEFaces we probably would not be able to upgrade to JSF 2.0 for 1-1.5 years after spec completion.
ICEsoft is actively involved in the JSF 2.0 expert group, so we will be well-positioned to deliver 2.0 capabilities as the specification matures, and the ICEfaces community demands.
Steve Maryka
CTO ICEsoft
|
|
|
Message #236408
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
What the heck are these guys thinking?
We were actually listening to our community, and delivering on the priorities established there.
...using ICEFaces we probably would not be able to upgrade to JSF 2.0 for 1-1.5 years after spec completion.
ICEsoft is actively involved in the JSF 2.0 expert group, so we will be well-positioned to deliver 2.0 capabilities as the specification matures, and the ICEfaces community demands.
Steve Maryka
CTO ICEsoft
As a follow up, ICEfaces has offered a very unique solution from day one from both a programming and end user experience standpoint. It's such a great example of thinking outside the box that JBoss has made commitments to enhancing integration with ICEfaces. Honestly, I'm very glad that Ted will be participating in the JSF 2.0 JSR.
|
|
|
Message #236411
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
What the heck are these guys thinking?
We were actually listening to our community, and delivering on the priorities established there.
To tell the truth i had always thought ICEfaces as the leading ajax component solution, and was looking forward for using it in my next JSF gig. Perhaps thats why the news about "coming late to the game" in regards of JSF 1.2 came as a quite a shock to me.
If indeed this was the priority your customers have set, then i apologize my hard words. Instead, i'll just say 'what the heck the ICEfaces customers were thinking' :)
/Henri Karapuu
|
|
|
Message #236413
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
As a follow up, ICEfaces has offered a very unique solution from day one from both a programming and end user experience standpoint.
Jacob, i'm not intimately familiar with ICEfaces, could you clarify what you mean by "unique solution"?
To me ICEfaces seems to be just another AJAX JSF component library -- which is something that does not qualify as 'unique' these days [1].
[1] http://www.jsfmatrix.net/
/Henri Karapuu
|
|
|
Message #236416
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
What the heck are these guys thinking?
We were actually listening to our community, and delivering on the priorities established there.
To tell the truth i had always thought ICEfaces as the leading ajax component solution, and was looking forward for using it in my next JSF gig. Perhaps thats why the news about "coming late to the game" in regards of JSF 1.2 came as a quite a shock to me.
If indeed this was the priority your customers have set, then i apologize my hard words. Instead, i'll just say 'what the heck the ICEfaces customers were thinking' :)
/Henri KarapuuIt was the customers. I remember ICESoft asking them; since 1.2 adoption is still a little behind the curve, it makes sense that the customers wanted working solutions rather than future stuff. (Plus, I've been in touch with Ted and Steve over issues like this, to the point where I think they're tired of me.)
|
|
|
Message #236417
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
To tell the truth i had always thought ICEfaces as the leading ajax component solution, and was looking forward for using it in my next JSF gig. Perhaps thats why the news about "coming late to the game" in regards of JSF 1.2 came as a quite a shock to me.
If indeed this was the priority your customers have set, then i apologize my hard words. Instead, i'll just say 'what the heck the ICEfaces customers were thinking' :)
/Henri Karapuu
Until recently, it was difficult to run JSF 1.2 outside of GlassFish (this is definitely changing now) and the requirement of JDK 1.5 is still a problem for some customers.
Your enthusiasm for JSF 1.2 is inspiring, though, so what are some of the specific features in JSF 1.2 that people must be crazy to not be using?
|
|
|
Message #236418
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
As a follow up, ICEfaces has offered a very unique solution from day one from both a programming and end user experience standpoint.
Jacob, i'm not intimately familiar with ICEfaces, could you clarify what you mean by "unique solution"?
To me ICEfaces seems to be just another AJAX JSF component library -- which is something that does not qualify as 'unique' these days [1].
[1] http://www.jsfmatrix.net/
/Henri Karapuu
Mechanically, their rendering process with their components do comet-like behavior and take the extra step to handling partial rendering automatically-- not necessarily and the component level like ADF, AJAX4JSF, and DynaFaces, but within the *whole* rendering process which simplifies rich UI development even more for developers. Their component library is an added bonus really which only facilitates ICEfaces core feature set even more.
|
|
|
Message #236422
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
Until recently, it was difficult to run JSF 1.2 outside of GlassFish
I'v been running JSF 1.2 nearly 2 years outside of GlassFish. But, generally speaking you have a valid point.
Your enthusiasm for JSF 1.2 is inspiring, though, so what are some of the specific features in JSF 1.2 that people must be crazy to not be using?
As you know the only big deal at spec level was the JSP/JSF alignment, and i assume this didn't affect majority of your customers (if you promoted facelets use etc.)
However, the really critical things were at implementation level.
For example RI 1.2 had server side state saving working reliably with non-linear navigation something like a year before MyFaces. If i would had been stuck to 1.1 spec it would had meant that:
a) My app would run up to 10x slower (because of client side state saving), or
b) My app would blow to pieces when using back button.
Also, it is possible to turn this question around. You seem to imply that JSF 1.2 was not a big deal - and indeed there were not many new features. Therefore porting apps to 1.2 spec level has been generally really easy. Would it had been big effort for ICEfaces to support 1.2 much earlier?
/Henri Karapuu
|
|
|
Message #236427
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
rich ui with JSF - memory hog
Has anyone seen any comparison matrix or just a report on what is the memory usage when using jsf components ?
I looked hard everywhere on the net but all i got was complaints about how JSF and how it is a big memory hog. But no numbers.
I did visit the icesoft website but nothing there either.
I m consulting for a healthcare provider right now and planning to go into JSF heavily for the cust. service agent facing applications and then icesoft discussion came up to add some AJAX capability. But memory issue is scary.
Any comments from anyone would be helpful !!
|
|
|
Message #236430
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
Mechanically, their rendering process with their components do comet-like behavior and take the extra step to handling partial rendering automatically-- not necessarily and the component level like ADF, AJAX4JSF, and DynaFaces, but within the *whole* rendering process which simplifies rich UI development even more for developers. Their component library is an added bonus really which only facilitates ICEfaces core feature set even more.
Interesting, thanks for the description. I was aware of server push support in ICEfaces, but didn't know about the differences in rendering.
I'm currently fitting GWT to be used as JSF components, but i'v started to have doubts if the GWT approach is ultimately a good match with JSF.
If i may ask, whats your prefered JSF AJAX solution for writing custom components?
/Henri Karapuu
|
|
|
Message #236429
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: rich ui with JSF - memory hog
Has anyone seen any comparison matrix or just a report on what is the memory usage when using jsf components ?
I looked hard everywhere on the net but all i got was complaints about how JSF and how it is a big memory hog. But no numbers.
I did visit the icesoft website but nothing there either.
I m consulting for a healthcare provider right now and planning to go into JSF heavily for the cust. service agent facing applications and then icesoft discussion came up to add some AJAX capability. But memory issue is scary.
Any comments from anyone would be helpful !!
I don't think it would ever prevent you from going with JSF, just that it requires more hardware per user than going with a stateless action solution. Seriously, if you are writing a customer service app/internal where functionality is king, it'd be dumb not to go with JSF. In my experience, trying to coordinate sorting tables, complex forms, menus, etc-- things that are expected out of support applications vs. public sites, JSF is by far the clear winner. You are dealing with a more reasonable concurrent user base and JSF takes care of all of the state management and simplify complex interactions overall, making your job and other developer's jobs much easier.
This response isn't necessarily promoting JSF as the only solution here, just that with the deployment you're describing, it's much wiser to go with a feature-heavy framework over attempting to find what scales the best out of all other options out there.
|
|
|
Message #236433
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: rich ui with JSF - memory hog
Has anyone seen any comparison matrix or just a report on what is the memory usage when using jsf components ?
I looked hard everywhere on the net but all i got was complaints about how JSF and how it is a big memory hog. But no numbers.
I did visit the icesoft website but nothing there either.
I m consulting for a healthcare provider right now and planning to go into JSF heavily for the cust. service agent facing applications and then icesoft discussion came up to add some AJAX capability. But memory issue is scary.
Any comments from anyone would be helpful !!
I don't think it would ever prevent you from going with JSF, just that it requires more hardware per user than going with a stateless action solution. Seriously, if you are writing a customer service app/internal where functionality is king, it'd be dumb not to go with JSF. In my experience, trying to coordinate sorting tables, complex forms, menus, etc-- things that are expected out of support applications vs. public sites, JSF is by far the clear winner. You are dealing with a more reasonable concurrent user base and JSF takes care of all of the state management and simplify complex interactions overall, making your job and other developer's jobs much easier.
This response isn't necessarily promoting JSF as the only solution here, just that with the deployment you're describing, it's much wiser to go with a feature-heavy framework over attempting to find what scales the best out of all other options out there.
Thanks for the feedback. As you said we made the decision to go with jsf is soley based on complexity of the UI which a web based systems cannot manage.
But the traffic is too high more than 200,000 representatives/users logged in at peak times. And even if I consider memory taken per user is 1 MB , our RAM requirements, Hardware requirements is looking ridiculous.
So for a better infrastructure planning i want to produce
correct numbers. and so was looking for some numbers to go by. It is surprising that there is hardly anything from big jsf players on jsf memory usage.
Anyway .. i will look into some home grown profiling stuff to figure that out.
|
|
|
Message #236434
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: rich ui with JSF - memory hog
But the traffic is too high more than 200,000 representatives/users logged in at peak times. And even if I consider memory taken per user is 1 MB , our RAM requirements, Hardware requirements is looking ridiculous.
So for a better infrastructure planning i want to produce
correct numbers. and so was looking for some numbers to go by. It is surprising that there is hardly anything from big jsf players on jsf memory usage.
Anyway .. i will look into some home grown profiling stuff to figure that out.
Can't you just setup a cluster for this, so you aren't necessarily capped at all in your scalability from a webtier standpoint?
|
|
|
Message #236439
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
Would it had been big effort for ICEfaces to support 1.2 much earlier?
/Henri Karapuu
Not really, but the top priorities with customers have been integration with JBoss Seam, Portlets, and component features, so other work took precedence. What is somewhat difficult is simultaneously supporting JSF 1.1 and 1.2 from a single codebase.
|
|
|
Message #236440
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: rich ui with JSF - memory hog
Can't you just setup a cluster for this, so you aren't necessarily capped at all in your scalability from a webtier standpoint?
200,000 simultaneous users would be impossible to support with Ajax Push without a cluster. Each push connection requires a socket, and there simply aren't 200,000 sockets available on a single machine. It would be necessary to run ICEfaces in "synchronous" mode (which is perfectly acceptable, many applications do not require Ajax Push).
With regard to memory, ICEfaces with Facelets uses much less memory than ICEfaces with JSP (I don't know if Facelets applications generally use less memory than equivalent JSP applications, though).
|
|
|
Message #236443
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: rich ui with JSF - memory hog
Can't you just setup a cluster for this, so you aren't necessarily capped at all in your scalability from a webtier standpoint?
200,000 simultaneous users would be impossible to support with Ajax Push without a cluster. Each push connection requires a socket, and there simply aren't 200,000 sockets available on a single machine. It would be necessary to run ICEfaces in "synchronous" mode (which is perfectly acceptable, many applications do not require Ajax Push).
With regard to memory, ICEfaces with Facelets uses much less memory than ICEfaces with JSP (I don't know if Facelets applications generally use less memory than equivalent JSP applications, though).
Good to hear from you Ted. Thanks for the feedback.
We will definately have clustering etc. we have about 40 solaris boxes 4 cpu each with 4 instances on each of them. i m just worried about RAM usage.
how much RAM can i increase of existing hardware or do i need new one is a question.
But as you said Facelets eat less memory than jsp with jsf. how do you say so? what numbers do you have to back them up? i m sure in theory you can prove it, but i cant decide how many machines just by assuming somehting in theory. a performance and memory matrix would have helped.
Have a good friday .. i m going to get a cool beer...
|
|
|
Message #236447
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
Not really, but the top priorities with customers have been integration with JBoss Seam, Portlets, and component features, so other work took precedence.
Fair enough.
And i do apologize for my too harsh wording - i'm still surprised, and can't say i personally agree with the choice, but at least i could had been polite.
Sorry,
/Henri Karapuu
|
|
|
Message #236448
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ICEFaces 1.6: With Seam and JSF 1.2 compatibility
Congrats to the ICE folks on their new release :-)
|
|
|
Message #236560
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
As you know the only big deal at spec level was the JSP/JSF alignment, and i assume this didn't affect majority of your customers (if you promoted facelets use etc.)
However, the really critical things were at implementation level.
For example RI 1.2 had server side state saving working reliably with non-linear navigation something like a year before MyFaces. If i would had been stuck to 1.1 spec it would had meant that:
a) My app would run up to 10x slower (because of client side state saving), or
b) My app would blow to pieces when using back button.
A small correction, server side state history has been a long time in myfaces it was there even before 1.2 came out. It was introduced into myfaces shortly after myfaces went out of apache incubation.
But the 1.1 RI was the first to implement it, I agree.
Anyway speaking of myfaces, the 1.2 implementation will be out soon now, with soon I mean the next few days, so finally things come to a good end there as well.
|
|
|
Message #236588
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
A small correction, server side state history has been a long time in myfaces it was there even before 1.2 came out. It was introduced into myfaces shortly after myfaces went out of apache incubation.
Werner, just for the record, and to clarify that i was not trying to badmouth MyFaces, here are my experiences:
When i was starting project A in autumn of 2005 MyFaces didn't support reliable back buttoning with server side state saving, according to test cases i run at that time.
When i started project B, in spring of 2006, Myfaces seemed to support back buttoning in single window,
but it did not work correctly with multiple windows/tabs.
/Henri Karapuu
|
|
|
Message #236589
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ridiculous
A small correction, server side state history has been a long time in myfaces it was there even before 1.2 came out. It was introduced into myfaces shortly after myfaces went out of apache incubation.
Werner, just for the record, and to clarify that i was not trying to badmouth MyFaces, here are my experiences:
When i was starting project A in autumn of 2005 MyFaces didn't support reliable back buttoning with server side state saving, according to test cases i run at that time.
When i started project B, in spring of 2006, Myfaces seemed to support back buttoning in single window,
but it did not work correctly with multiple windows/tabs.
/Henri Karapuu
Ah ok that explains a lot, no problem, point taken, for multi windowing tabs etc... you probably are right.
Cheers
Werner
|
|
|
Message #236596
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: rich ui with JSF - memory hog
But as you said Facelets eat less memory than jsp with jsf. how do you say so? what numbers do you have to back them up? i m sure in theory you can prove it, but i cant decide how many machines just by assuming somehting in theory.
We're working on obtaining some concrete numbers ... what we observe generally, however, is that when we configure ICEfaces demos with facelets (many of them can be configured either with JSP or Facelets since the syntax is equivalent for the functional parts of most pages) they can easily sustain the load on ICEfaces.org, but in JSP mode, the applications run out of heap space when the load peaks.
|
|
|
Message #236848
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSR-168 and Liferay Portal questions
Ted & Steve: Congratulations to you and everyone at ICEsoft on this release. We at Liferay have enjoyed working with your engineers, and look forward to a bright future.
Javier: In my work developing sample portlets for ICEfaces and Liferay, it has been my experience that many of the components like <ice:inputText/> pickup the Liferay theme without a problem. In the case of components like <ice:messages/>, you'll want to specify the JSR-168 CSS class names in order to make sure that your messages pickup the current Liferay theme. For example:
<ice:messages
errorClass="portlet-msg-error"
fatalClass="portlet-msg-error"
globalOnly="true"
infoClass="portlet-msg-info"
layout="table"
warnClass="portlet-msg-warn"/>
Other components like <ice:panelTab/> currently render themselves using the ICEfaces theme (XP, or Royale) rather than the current Liferay theme. Liferay is working closely with ICEsoft so that future releases of ICEfaces integrate more completely with Liferay themes.
Regards,
Neil
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
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)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
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)
|
|
