Adam Bien's Weblog
Lightweight Publish-Subscribe--Free Article
The free JavaMagazine article "Lightweight Publish-Subscribe Communication" discusses the use of Java EE 6 (CDI / EJB 3.1) for the implementation of local communication. On the way it also deprecates some J2EE patterns. Enjoy reading and code deleting! :-)
Posted at 07:29AM Feb 07, 2012 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Comments[1] | Views/Hits: 898
*NEW* Workshop: "Real World Java EE 6/7 Bootstrap" and book: Real World Java EE Night Hacks--Dissecting the Business Tier Tweet Follow @AdamBien
Tomcat On Steroids (on Java EE 6) = TomEE--A Server Smoke Test
Apache TomEE is an opensource, Java EE 6 WebProfile certified, easy to install Java EE 6 server.
The test:
- Download size (apache-tomee-plus-1.0.0-beta-2.zip ): 43.8 MB (it is the biggest available download. It contains the Java EE 6 WebProfile with some "full profile" functionality)
- Installation = Unzip
- Disc size: 50.9 MB after installation
- Startup: same as tomcat: ./startup.sh
- Full deployment of ServerSmokeTest took < 2 secs.
- Tested were: Stereotypes (encapsulating @Named and @RequestScoped), @RequestScoped, @Named CDI-Beans, Injection of EJB 3.1 (no interface view), into CDI bean, @Singleton,@Stateless, CDI-events, POJO-injection, Interceptors
- ServerSmokeTest works without any modification on Glassfish v3, WebLogic 12c, JBoss 7.0.2, JBoss 6m5, SIwpas-1.0.0-CR4, resin-4.0.12 and even in the openshift cloud.
First impression: good. Easy to install, fast deployment, no problems. TomEE is another reason to get rid of the complicated and bloated Plain Old Web Containers :).
Posted at 08:45AM Jan 31, 2012 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Comments[2] | Views/Hits: 2429
*NEW* Workshop: "Real World Java EE 6/7 Bootstrap" and book: Real World Java EE Night Hacks--Dissecting the Business Tier Tweet Follow @AdamBien
GlassFish / Jersey Exception "java.lang.IllegalArgumentException: object is not an instance of declaring class" And Solution
The exception:
SEVERE: The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
[…]
is caused by exposing EJB 3.1 methods directly via REST without having a no-interface view declared. This happens when your EJB 3.1 REST-endpoint implements an additional interface without declaring the no-interface view:
import javax.ejb.*;
@Path("RESTafari)
@Singleton
public class RESTEndpoint implements SomeLocalInterface{}
Adding a @LocalBean annotation (and activating the no-interface view) solves the problem:
import javax.ejb.*;
@LocalBean
@Path("RESTafari)
@Singleton
public class RESTEndpoint implements SomeLocalInterface{}
Posted at 09:22AM Jan 30, 2012 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Comments[1] | Views/Hits: 1456
*NEW* Workshop: "Real World Java EE 6/7 Bootstrap" and book: Real World Java EE Night Hacks--Dissecting the Business Tier Tweet Follow @AdamBien
JavaFX 2.0 Is Available On ...Linux
JavaFX 2.0 SDK is available for Linux as Developer Preview Download. Enjoy FX-ing!
Posted at 07:00AM Jan 24, 2012 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Comments[4] | Views/Hits: 2264
*NEW* Workshop: "Real World Java EE 6/7 Bootstrap" and book: Real World Java EE Night Hacks--Dissecting the Business Tier Tweet Follow @AdamBien
Upcoming Java EE / FX Events
- In this free event at 26.01.2012 in Munich: JavaFX 2.0, Lean, Productive and Maintainable I would like to explain why Java FX rocks and what happens, if you combine Java EE with Java FX.
- Session: "Less Patterns Is More - With Java EE 6",26.01.2012, 14:30-15:30 in Munich (OOP Conference)
- Workshop: "Java EE 6/7 Best Practices", 27.01.2012, 9:00-16:00 in Munich (OOP Conference)
- Real World Java EE 6 Bootstrap Workshop, Airport Munich, at 12.03.2011 There are already sufficient registrations--it will definitely take place. One day is more than enough to become really productive with Java EE :-)
Posted at 11:30AM Jan 22, 2012 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Comments[0] | Views/Hits: 1131
*NEW* Workshop: "Real World Java EE 6/7 Bootstrap" and book: Real World Java EE Night Hacks--Dissecting the Business Tier Tweet Follow @AdamBien
How To Package @Local Interfaces In An EAR?
Got an interesting question:
Lets say you have an EAR archive which contains 3 EJB projects: one project that contains @Local interfaces that are the facades for all three EJB's. The idea is that all 3 of them can communicate with each other using that project as a dependency. Or: The second way is to have for each EJB Project one additional project that has the facade @Local interface and each EJB project to depend those who needs. Which is better?This question is impossible to answer because the reason for the modularization of the EAR is unknown. Before you are going to think about modularization I would start with answering the following questions:
- How often do you have to partially deploy contents of the EAR?
- Is it likely that you will NOT deploy the interface JAR, but only the "implementation" JARs? Why you are doing that?
- How often are you going to change the implementation without recompiling the interfaces?
Without explicit modularization requirements I would package all the clearly separated modules, components and projects into one, big, single EJB-JAR inside the WAR. In Java EE 6 I would use (see: Is Java EE 6 War The New EAR?) The Pragmatic Modularization And Packaging) WAR-packaging and put all the components into a single JAR or even into the classes folder. With Maven you could use the: jar-with-dependencies assembly configuration. If you are still developing with the ancient Java EE 5, I would create a "everything" EJB-JAR and an "everything" WAR inside the EAR. If you are going to implement an API, which is going to be implemented by several JAR-modules, I would provide a single JAR with all interface for each EJB-JAR. I would expect then to find these JARs in several EARs without any modification. Remember: Premature Extensibility (In Java EE 6) Is the Root of Some Evil :-) See also and How To Kill An OSGi Project - With 10 Questions
Posted at 12:14PM Jan 16, 2012 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Comments[0] | Views/Hits: 1290
*NEW* Workshop: "Real World Java EE 6/7 Bootstrap" and book: Real World Java EE Night Hacks--Dissecting the Business Tier Tweet Follow @AdamBien
Premature Extensibility (In Java EE 6) Is the Root of Some Evil - A Free Article
How to deal with interfaces in Java EE 6? @Qualifiers, @Stereotypes, @Alternatives with or without interfaces are discussed in this free article: http://www.oracle.com/technetwork/articles/java/intondemand-1444614.html.
Feedback is, as always, highly appreciated!Posted at 08:25AM Jan 10, 2012 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Comments[0] | Views/Hits: 1748
*NEW* Workshop: "Real World Java EE 6/7 Bootstrap" and book: Real World Java EE Night Hacks--Dissecting the Business Tier Tweet Follow @AdamBien
EJB 3.1 or CDI Managed Bean As JSF Backing Bean
Got interesting questions:
- I can use a ejb as a backing bean for Jsf(a session bean with @Named), but, is this useful I mean, have advantages against the @ManagedBean or @Named annotations directly in a class? Answer: You can directly expose EJB 3.1 to JSF or JSP by annotating the class with @Named (see: http://www.adam-bien.com/roller/abien/entry/ejb_3_1_killed_the). However: in all non-trivial projects your EJBs will contain a significant amount of presentation logic and dependencies to JSF / JAX-RS APIs. Mixing presentation and business logic makes your code more complex, harder to test and therefore harder to maintain. You can start with an EJB 3.1 exposed with @Named to JSF and on the first occurrence of any dependency to the presentation layer just refactor the presentation logic into a dedicated @RequestScoped @Named bean (I would not use @ManagedBean any more.) - A bit far, I can annotate an interface of my Ejb with @Named. These approach is cool, but again, is this better?Answer: It is hard to find a reason to use an interface for an EJB 3.1. I would start with no-interface view EJB 3.1 (a Java class annotated with @Stateless). - Why not use directly an EJB project with all my Session Beans and only access the beans there? (consider an enterprise application with and ejb module and a web module - actual stage) Answer: In Java EE 6 I always used WAR projects so far. You will have everything you need in one place. EAR-packaging works as well, but I would still separate the presentation from the business logic.
Posted at 08:31AM Jan 06, 2012 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Comments[3] | Views/Hits: 2467
*NEW* Workshop: "Real World Java EE 6/7 Bootstrap" and book: Real World Java EE Night Hacks--Dissecting the Business Tier Tweet Follow @AdamBien
An Over-Engineering Story …From 1858
That was built in such a logical way It ran a hundred years to a day, And then, ... went to pieces all at once, -- All at once, and nothing first, -- Just as bubbles do when they burst.From: http://en.wikipedia.org/wiki/Overengineering. Here the whole Deacon's Masterpiece story.
Posted at 10:11AM Jan 02, 2012 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Comments[1] | Views/Hits: 1840
*NEW* Workshop: "Real World Java EE 6/7 Bootstrap" and book: Real World Java EE Night Hacks--Dissecting the Business Tier Tweet Follow @AdamBien
Java FX 2 Data Binding Explained …With A JUnit Test
import javafx.beans.property.SimpleStringProperty;
import javafx.beans.property.StringProperty;
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;
import org.junit.Test;
public class StringDataBindingTest {
@Test
public void bindUnidirectionally(){
String expected = "DukeFX";
StringProperty from = new SimpleStringProperty();
StringProperty to = new SimpleStringProperty();
to.bind(from);
from.set(expected);
String actual = to.get();
assertThat(actual,is(expected));
}
}
Any questions? :-)
Posted at 09:16AM Dec 23, 2011 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Comments[1] | Views/Hits: 1937
*NEW* Workshop: "Real World Java EE 6/7 Bootstrap" and book: Real World Java EE Night Hacks--Dissecting the Business Tier Tweet Follow @AdamBien
