It has been almost a month since i started working with jsf and jboss. I've worked with jsf before. But i didn't use jboss, just apache with it.
I've done a bit of search and i found that JBOSS is:
WildFly, formerly known as JavaBeans Open Source Software Application Server is an application server that implements the Java Platform, Enterprise Edition. JBoss is written in Java and as such is cross-platform: usable on any operating system that supports Java.
And instead of managed beans, there are Action classes. As far as i know, the concept is the same, but some annotations are different.
Are these the only differences between jsf with and without jboss? What good does it do in a jsf application? Is jboss really required?
No, you don't need specifically JBoss AS (now Wildfly, the name has been recently changed) but you obviously need some web container (de facto web server) which run JSF applications (for instance Tomcat, Jetty, Resin or Wildfly).
Difference between plain web container (Tomcat, Jetty) and application server (Wildfly, Glassfish) is that in AS you can use Java EE technologies like EJB or JMS. For JSF the difference is that JSF libraries are usually bundled with application server so you don't have to put them into your WAR file (or have scope provided in Maven).
I am a little new to J2EE. I have a EJB3 project and I want to run a class on application start-up, how can I do that?
I know in EJB3.1 I can use #startup and #singleton unfortunately that is not a option and I have to use EJb3 and java 5. I have done some research and there were a few solutions but I have been unable to make it work.
WebSphere Application Server version 6.1 does not support EJB3 with a standard installation. You also need to have a feature pack for EJB 3.0 installed.
See this information on the IBM site.
If this is not your issue you should update your question with more detail of what goes wrong.
Your only options prior to WebSphere 8 (with EJB 3.1 support) are:
WebSphere startup beans. These are a programming model extension
Package a WAR with the application, and use a ServletContextListener to initialize state used by the EJBs.
I just migrated my web app from JSF managed beans to CDI managed beans, and I specifically wanted Tomcat or TomEE Plus to be the container of choice, because of the great things I heard about 'OpenWebBeans'. After deploying, configuring, and testing the TomEE 1.5+ / CDI-managed-beans web application, Full Page Refreshes are much much slower than Glassfish 3.1.2.2 / MyFaces 2.1.9 / JSF managed beans.
With Glassfish 3.1.2.2 / MyFaces 2.1.9 / JSF managed beans, full page refreshes only take 2 to 3 seconds.
With TomEE 1.5+ / CDI-managed-beans, full page refreshes take 5 to 10 seconds, and maybe even more than that at times. :(
Can you please tell me why is that?
Yesterday, prior to deploying the TomEE 1.5+ / CDI managed beans webapplication to the production server (Windows 2003 32-bit 4GB RAM and 1TB of diskspace), I read the following, which really did not answer my/this question at all:
glassfish v3 vs tomcat 7
I read that PPR is better on performance than FPR, but my session timeout/management implementation involved the following:
LoginFilter (servlet filter)
the following in h:head
meta http-equiv="refresh" content="#{session.maxInactiveInterval};url=pf_viewExpired.jsf"
Is CDI more (time) expensive than JSF managed beans, or is TomEE the container of choice for CDI? I know that JBoss (or Weld) is or has the reference implementation for CDI, so it may be best to consider JBoss/Weld.
Prior to completing the task of migrating from JSF-managed bean to CDI-managed bean (as well as migrating from Glassfish to TomEE), I had issues starting CDI-managed-bean web app on Glassfish/Weld.
Please answer the following questions above, and/or advise. Thanks.
As inidicated in the comments above, I am working with OpenEJB (TomEE) committers to resolve this issue. Personally, I feel the issue is possibly due to the following:
CDI managed beans defined and referenced in the app
Possible CDI cyclic references (which will possibly be resolved in CDI 1.1)
A really large CDI #SessionScoped bean, which references/injects many other CDI beans to accomplish business logic (or tasks) within the app
TomEE/OpenWebBeans (which is still under development)
So, the answer remains to be determined. I opened the following OpenEJB JIRA for this issue (URL below). Feel free to watch this JIRA, if interested.
TomEE 1.5.1 SNAPSHOT (and CDI beans) running slow on my production server
UPDATE:
Now, TomEE/CDI-managed-beans is performing just as well as Glassfish/JSF-managed-beans on the production server, because I recently did the following:
replace frequently-used dynamic SQL with #entity named queries
added query hints to JPA createQuery() and createNamedQuery()
replaced frequently-used rendered="#{EL expression}" with new facelets and ui:include src="#{EL expression}", since TomEE committers advised that rendered="#{EL expression}" gets called 6 times.
So, my TomEE/CDI-managed-beans is now running on production server and I'm monitoring performance and enduser reports/experience.
Does Tomcat 7 has the EJB implementation to allow create queues and deploy MDB listeners?
No, it doesn't. It only implements the JSP/Servlet API out the box (JSR-245 and JSR-315).
You can however use OpenEJB to enrich Tomcat with (limited) EJB support, including MDBs.
No, Tomcat is a servlet container, not a complete Java EE server, it has no EJB support on board.
There's a rich choice of open/free full Java EE servers available, check out Glassfish, JBoss, Geronimo or Jonas. And I'm probably forgetting several others.
On the Tomcat FAQ it says: "Tomcat is not an EJB server. Tomcat is not a full J2EE server."
But if I:
use Spring to supply an application context
annotate my entities with JPA
annotations (and use Hibernate as a
JPA provider)
configure C3P0 as a connection pooling data
source
annotate my service methods
with #Transactional (and use Atomikos
as JTA provider)
Use JAXB for marshalling and unmarshalling
and possibly add my own JNDI capability
then don't I effectively have a Java EE application server? And then aren't my beans EJBs? Or is there some other defining characteristic?
What is it that a Java EE compliant app server gives you that you can't easily/readily get from Tomcat with some 3rd party subsystems?
EJBs are JavaEE components that conform to the javax.ejb API.
JavaEE is a collection of APIs, you don't need to use all of them.
Tomcat is a "partial" JavaEE server, in that it only implements some of the JavaEE APIs, such as Servlets and JNDI. It doesn't implement e.g. EJB and JMS, so it's not a full JavaEE implementation.
If you added some additional bits and pieces (e.g. OpenEJB, HornetQ), you'd add the missing parts, and you'd end up with a full JavaEE server. But out of the box, Tomcat isn't that, and doesn't try to be.
But if I add (...) then don't I effectively have a Java EE application server? And then aren't my beans EJBs? Or is there some other defining characteristic?
No, you don't have a Java EE application server, a full-fledged Java EE application server is more than Tomcat + Spring + a standalone Transaction Manager. And even if you add a JMS provider and an EJB container, you still won't have a Java EE server. The glue between all parts is IMO important and is part of the added value of a Java EE container.
Regarding EJBs, the EJB specification is much more than JPA and specifices also Session Beans and Message Driven Beans (actually, I don't really consider JPA Entities as EJBs even if JPA is part of the EJB 3.0 specification in Java EE 5 for historical reasons - which is not true anymore in Java EE 6, JPA 2.0 and EJB 3.1 are separate specifications).
I should also mention that a Spring bean annotated with #Transactional is not equivalent to a Session Bean. A Java EE container can do more things with Session Beans (see below). You may not need them though but still, they are not strictly equivalent.
Last thing, Java EE containers implement a standard, the Spring container does not, it is proprietary.
What is it that a Java EE compliant app server gives you that you can't easily/readily get from Tomcat with some 3rd party subsystems?
As I said, I think that the "glue" is a part of the added value and highly contributes to the robustness of the whole. Then, ewernli's answer underlined very well what is difficult to achieve. I'd just add:
Clustering and Fail-over (to achieve fault-tolerance)
Administration facilities
Yes, a good Java EE server will do pretty neat things to improve fault tolerance (clustering of connection pools, JNDI tree, JMS destinations, automatic retry with idempotent beans, smart EJB clients, transaction recovery, migration of services, etc). For "mission critical" applications - the vast majority are not - this is important. And in such cases, libraries on top of the Servlet API are IMO not a replacement.
1) You're confusing JPA entities with EJBs. While JPA belongs to the EJB3 specification, it was always meant to be a standalone technology.
2) EJBs are: stateless beans, stateful beans and message driven beans. While each of these functionalities can easily be achieved using spring, spring just does not use this terminology. In Spring, you don't have POJO + "magic" as in EJBs, in Spring it's POJO + your own configuration (which sometimes feels like magic, too). The main difference is that spring does more and the application server does less, which is why a spring app is happy with a tomcat while an ejb3 app needs a 'real' application server.
In my opinion, 90% of applications can be deployed using spring + tomcat, ejb3 is rarely needed.
Indeed, if you put enough effort you can almost turn Tomcat/Spring into a full-fledged heavyweight application server :) You could even embed a portable EJB3 container...
What is it that a Java EE compliant app
server gives you that you can't
easily/readily get from Tomcat with
some 3rd party subsystems?
There are still a few features that are hard to get with 3rd party modules:
stateful session beans (SFSB)
extended persistence context
application client container / java web start
clustering depending on the app. server
CORBA interoperability
JCA integration ~
remoting ~
container-managed transactions ~
decent management of distributed transactions (e.g. recover heuristic tx)
Entries with ~ are also supported by Spring, but not so trivially, at least to my best knowledge.
A few more details in this answer: EJB vs Spring
Outside of the strict definition of what is and isn't an EJB, you're adding a lot of stuff to Tomcat. Even if what you have is an EJB server, it's not really plain Tomcat anymore.
The FAQ is correct: Tomcat is not an EJB server. However, it can be that or many other things if you pile on enough extra libraries and code.
An EJB implementation would be a bean written and packaged to run on any compliant EJB server. If you do what you describe, it may work, but it won't be portable to another vendor's application server.
So EJB is a standard that adheres to a specific specification and is therefore portable.
In practice many EJB's are not fully compliant or application server neutral. However, in the main they are, so the small incompatibilities would be much easier to fix if you changed application server vendors than attempting to move the architecture you described to a GlassFish, JBoss or Weblogic server.
EDIT: In response to your comment you would not have an EJB appropriately annotated and/or configured via XML in such a way that code that accessed it in EJB compliant ways would be able to use it without changes.
There are two angles to your comment. One is what functionality would you lose deploying on a JBoss or any of the others instead of Tomcat? Likely nothing, if you brought along all of the frameworks you relied on. However, if you wanted to move your code to Weblogic, for example, to use some of its features, then your code would need some likely significant changes to keep up.
I am not saying that you cannot replicate all EJB functionality (certainly the subset you care about) via other means, just that it is not the spec, and therefore not implementation independent.
then don't I effectively have a Java EE
application server? And then aren't my
beans EJB's? Or is there some other
defining characteristic?
Quick answer EJBs actually have to follow a Java EE specification. Tomcat is a Java EE container not an app server.
What is it that a Java EE compliant app
server gives you that you can't
easily/readily get from Tomcat with
some 3rd party subsystems?
Quick answer to your second question. In your case most likely nothing.
EJBs tend to be really heavy objects and people ended up using them to solve problems when they were essentially overkill. Frameworks like Spring were created to solve those problems without using EJBs. I think the first book where Spring was introduced was even called "J2EE development without EJB."