tag:blogger.com,1999:blog-78288004379142844672023-06-20T21:33:36.064-07:00DevBlogThis blog is intended to record some of my experiences in software development.joerg grosshttp://www.blogger.com/profile/00435504495005446117noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-7828800437914284467.post-5851605772285696192017-02-06T07:14:00.001-08:002017-02-06T07:24:53.166-08:00Typescript duck typingOne of the main surprising feature of TypeScript in my opinion is ths so called "duck typing" that works great for interfaces in Typescript. "duck typing" is a concept for dynamic typing that has been integrated in Ruby and means:<br />
<blockquote class="tr_bq">
"<i>When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.</i>" (<a href="http://wiki.ruby-portal.de/Duck_Typing" target="_blank">by James Whitcomb Rileys</a>)</blockquote>
How does it work for interface? An Example:<br />
<br />
Lets have the following object declarations:<br />
<br />
<pre class="brush: java">let myObj = {
lastname: "Petersen",
surname: "Peter"
}
let myObj2 = {
fullname: "Petersen",
titel: "Dr."
</pre>
<br />
and a simple interface declaration:<br />
<br />
<pre class="brush: java">interface Name {
lastname: string,
surname: string
}
</pre>
<br />
then the following expression is vaild in TypeScript:<br />
<br />
<pre class="brush: java">let name: Name = myObj; </pre>
<br />
but NOT this expression: <br />
<br />
<pre class="brush: java">let name2: Name = myObj2;
</pre>
<br />
Ok, this may be not be surprising at a second glance, but for a developer that has been shaped and stigmatized by Java for many years it is a surprisingly simple but effective feature. joerg grosshttp://www.blogger.com/profile/00435504495005446117noreply@blogger.com0tag:blogger.com,1999:blog-7828800437914284467.post-91879726498684194522017-02-06T01:38:00.001-08:002017-03-01T05:27:52.208-08:00Angular (2) module and ES6 modulesDiving deeper into Angular (2) during the last weeks I came to attention about the difference of the <a href="https://angular.io/docs/ts/latest/guide/ngmodule.html" target="_blank">Angular2 module (NgModule)</a> concept in comparison with the<a href="http://jsmodules.io/" target="_blank"> ES6 module</a> concept:<br />
<br />
<br />
ES6 modules export JavaScript elements per file. This is a low level module concept on basis of the programming language without any semantic meaning.<br />
<br />
Angular modules define modules in the semantics of Angular as a framework for building single page web/mobile apps. An Angular module defines which Angular specific elements <br />
<ul>
<li>belong together, </li>
<li>are exported and </li>
<li>are imported. </li>
</ul>
Further Angular specific elements are Components, Directives, Filters and Services. Such semantic could not be achieved with the use of ES6 modules. The Angular module concept is completly disjoint from ES6 modules as Angular does not make any requirements about the organization of Angular2 elements in files (although this topic is covered in the <a href="https://angular.io/docs/ts/latest/guide/style-guide.html" target="_blank">Angular2 styleguide</a> which should be take into account in any case).<br />
<br />
Some may think that the above comparsion is superfluous because the difference is quite clear, but I found some so called 'professional' articles that lack clear statements, like the <a href="https://dzone.com/articles/components-of-angular2-architecture?edition=267883&utm_source=Daily%20Digest&utm_medium=email&utm_campaign=dd%202017-02-04" target="_blank">following </a>I found describing Angular modules in short:<br />
<br />
<blockquote class="tr_bq">
"Modules are blocks of code that do a certain type of task. A module
exports some value in the main code, such as class. The first and the
most common module that you will study is the one that exports <i>Component</i> Class."</blockquote>
<br />
This explains ES6 modules that are part of the language but not the Angular module concept in any way.<br />
<br />
Update, 03/01/2017:<br />
Here are some sources about the topics:<br />
<a href="https://auth0.com/blog/javascript-module-systems-showdown/" target="_blank">Javascript and Modules</a><br />
<a href="http://blog.angular-university.io/angular2-ngmodule/" target="_blank">Angular Modules</a> joerg grosshttp://www.blogger.com/profile/00435504495005446117noreply@blogger.com0tag:blogger.com,1999:blog-7828800437914284467.post-4356129401169769962013-05-11T04:41:00.000-07:002013-05-12T10:52:08.734-07:00JavaScript Reuse by InheritanceAfter having studied some JavaScript books I discovered some useful parts of the JavaScript language that best suited to me. One of my <i>good parts</i> is concerning patterns for reuse by inheritance:<br />
<br />
Avoid class like inheritance using the <span style="font-family: "Courier New",Courier,monospace;">new<span style="font-family: Arial,Helvetica,sans-serif;"> </span></span>function. Especially for Java developers this approach might cause confusion and is error prone because inheritance using prototypes does not always behaves like some class minded developer might think (e.g. overloading of properties, prototype vs. local properties/methods). As inheritance is mainly used for the reuse of application logic, JavaScript offers other concepts for reuse that fit better with the dynamic aspect of the language:<br />
<br />
<ul>
<li>Copying of properties/methods,</li>
<li>Mix-Ins or </li>
<li>Borrowing Methods</li>
</ul>
(as mentioned in JavaScript Patterns by Stefanov).joerg grosshttp://www.blogger.com/profile/00435504495005446117noreply@blogger.com0tag:blogger.com,1999:blog-7828800437914284467.post-10913640754418544942013-05-10T11:20:00.000-07:002013-05-12T12:29:31.356-07:00A New ProjectWhile still developing rich client applications based on Eclipse RCP I started a new privat project called <i>timetraecker</i> some time ago - just a not too simple application for time recording/tracking. The purpose of the project is to explore different server and client technologies and to get an impression of handling these technologies:<br />
<br />
<ul>
<li>NOSQL - MongoDB</li>
<li>REST-Webservices</li>
<li>JSF</li>
<li>HTML5</li>
<li>GWT</li>
<li>Mobile development (Android/HTML5)</li>
<li>JavaFX </li>
</ul>
Yes, some work left! Lets see when I run out of time or the summer gets too hot...<br />
<br />
I consider following the principles of the <a href="http://roca-style.org/" target="_blank">ROCA-Style</a> for the development of the server APIs and web clients.joerg grosshttp://www.blogger.com/profile/00435504495005446117noreply@blogger.com0tag:blogger.com,1999:blog-7828800437914284467.post-4301627683328302872013-05-10T10:06:00.003-07:002013-05-12T10:52:49.021-07:00JavaScript ExperienceJavaScript has become more important with HTML5. Therefore I started to improve my JavaScript skills in the recent month. I took a deep dive in the language working through different books and examples. I also take a quick tour of node.js and was impressed about its functional richness, modular approach and its simplicity in use. After some hardcode text editor programming I decided to use WebStorm as IDE. What a relief to be back in the world of context sensitivity!<br />
<br />
I started reading the JavaScript bible of Mr. Crockford 'JavaScript: The Good Parts'. But this was hard stuff for a reentry in the JavaScript cosmos after a few years of abstinence. Although this book covers the really main and important points, you should have some practise in the language itself by working this book. Of similar quality and covering most of the typical design patterns is the book <i>JavaScript Patterns</i> written by Stoyan Stefanov. I found it easier to read and understandable than Crockford. For exploring node.js I read <i>Node.js & Co</i> by Golo Roden that covers the main aspects of node.js by following the development of a sample application. I hadn't worked it through completely but I found it well structured and easy to understand.<br />
<br />
That was a short summary of my JavaScript experience during the first months of 2013. The functional approach and its dynamic are some good parts of the language. But I do not wonder why Google invented <i>Dart </i>as an alternative language for the web. Building huge applications with JavaScript must be hard and could only be done with a bunch of very experienced, talented and disciplined developers and such are not always easy to find ;-)<br />
<table><tbody>
<tr class="lastEntryShown"><td class=""><br /></td><td class="text" lang="en"><br /></td></tr>
</tbody></table>
joerg grosshttp://www.blogger.com/profile/00435504495005446117noreply@blogger.com0tag:blogger.com,1999:blog-7828800437914284467.post-69167488350464935292012-02-12T05:34:00.000-08:002012-02-12T10:57:07.749-08:00Simple Remote Access with JEE 6 Web Profile<br />
<span style="font-size: large;">Problem</span><br />
<br />
A simple HTTP based remote access solution is not part of the JEE 6 Web Profile. Unfortunately this is one of the important parts that must be available in a rich client architecture using EclipseRCP/Spring.<br />
<br />
<br />
<span style="font-size: large;">Solution</span><br />
<br />
Therefore I started to build a solution for myself. The solution should be<br />
<ul>
<li>simple to use by an annotation,</li>
<li>based on <a href="http://hessian.caucho.com/" target="_blank">Hessian </a>and</li>
<li>plugging into the CDI container.</li>
</ul>
To use the remote access solution you have simply to
<br />
<ol>
<li>add a library to your project, </li>
<li>annotate your beans that should be remote accessible and</li>
<li>define a <a href="http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContextListener.html" target="_blank">ServletContextListener</a> in web.xml</li>
</ol>
<br />
The usage of the annotation is quite simple. You just need to define the interface to be remote exposed and the (relative) url at the bean that must implement this interface:<br />
<br />
<pre class="brush: java">@RemoteCallable(type=IPersonService.class, url="/personService")
public class PersonService implements IPersonService {
// some service methods
}
</pre>
<br />
In case of an EJB you need to define an JNDI name for your EJB. This EJB is looked up in JNDI under <span style="font-family: "Courier New",Courier,monospace;">java:app/[webapp-url]/[ejb-name]</span> (the root path is hard coded but vendor specific - this should be improved):<br />
<br />
<pre class="brush: java">@Stateless(name="ejb/PersonService")
@RemoteCallable(type=IPersonService.class, url="/personService")
public class PersonService implements IPersonService {
// some service methods
}
</pre>
<br />
You have can access <span style="font-family: "Courier New",Courier,monospace;">@RemoteCallable</span> beans from client side as follows:
<br />
<pre class="brush: java">
String url = "http://localhost:8080/eercp.server/personService";
HessianProxyFactory factory = new HessianProxyFactory();
this.remotePersonService = (IPersonService) factory.create(IPersonService.class,url);
Person person = new Person();
person = this.remotePersonService.update(person);
</pre>
<br />
<span style="font-size: large;">Implementation</span><br />
<br />
The implementation approach:<br />
<ol>
<li>During web application startup a <a href="http://blog.eisele.net/2010/01/jsr-299-cdi-portable-extensions.html" target="_blank">CDI extension</a> collects all bean types with<span style="font-family: "Courier New",Courier,monospace;"> @RemoteCallable</span> annotations and stores them in an instance variable.</li>
<li>A ServletContextListener retrieves the CDI extension bean from the CDI context and</li>
<li>uses the stored bean types to retrieve the corresponding bean/EJB implementation instances using CDI/JNDI and</li>
<li>creates a Servlet (<a href="http://www.ibm.com/developerworks/java/library/j-jtp08305/index.html" target="_blank">dynamic-proxy</a>) as remote accessible delegator for each bean/EJB (delegate). </li>
<li>Each Servlet is dynamically registered in the servlet context with the given url.</li>
</ol>
<br />
For the creation of the dynamic-proxy I used the <span style="font-family: "Courier New",Courier,monospace;">javassist</span>-library The dynamic proxy
<br />
<ul>
<li>extends the HessianServlet,</li>
<li>implements the bean service interface,</li>
<li>is associated with the bean/EJB implementation instance and</li>
<li>delegates all calls to the implementation instance.</li>
</ul>
<br />
Here are some implementation aspects in detail.<br />
<br />
Lets start with the <a href="http://blog.eisele.net/2010/01/jsr-299-cdi-portable-extensions.html" target="_blank">CDI extension</a>. Any CDI extension class must be declared in the file <span style="font-family: "Courier New",Courier,monospace;">./META-INF/services/javax.enterprise.inject.spi.Extension</span>.<br />
<br />
The extension must extend <span style="font-family: "Courier New",Courier,monospace;">javax.enterprise.inject.spi.Extension</span> and looks like this:<br />
<br />
<pre class="brush: java">public class RemoteCallableDiscoveryExtension implements Extension {
/** the list of remote callable annotated types. */
private Collection<Annotatedtype> annotatedTypes = new ArrayList<Annotatedtype>();
/** callback (is called for each annotated bean) */
<t> void processAnnotatedType(@Observes ProcessAnnotatedType<t> pat) {
AnnotatedType<t> type = pat.getAnnotatedType();
Annotation anno = type.getAnnotation(RemoteCallable.class);
if (anno != null) {
annotatedTypes.add(type);
}
}
...
}
</pre>
<br />
The life cycle of the ServletContextListener is determined by the web application. Therefore my listener could not be part of the CDI context. So I have to access the beans using the CDI SPI (Service Provider Interface). I created a helper class to achieve this:<br />
<br />
<pre class="brush: java">
public class BeanManagerAccessor {
/**
* bean manager reference.
*/
private BeanManager cdiBeanManager;
/** Retrieves and returns the bean reference from cdi context of the given type. ... */
public <T> T getReference(Class<T> beanClass) {
BeanManager cdiManager = getBeanManager();
Bean<t> bean = (Bean<T>) cdiManager.resolve(cdiManager.getBeans(beanClass));
CreationalContext<T> env = cdiManager.createCreationalContext(bean);
if (bean != null) {
return (T) cdiManager.getReference(bean, beanClass, env);
}
else {
throw new RuntimeException("No Bean for class: " + beanClass + " found!");
}
}
/** Returns the bean manager... */
public BeanManager getBeanManager() {
if (cdiBeanManager == null) {
try {
InitialContext ic = new InitialContext();
cdiBeanManager = (BeanManager) ic.lookup("java:comp/BeanManager");
} catch (Exception anEx) {
throw new RuntimeException(anEx);
}
}
return cdiBeanManager;
}
}
</pre>
At least all things are put together in my ServletContextListener implementation. Important is the <span style="font-family: "Courier New",Courier,monospace;">contextInitialized()</span> method that is called when the web application context is initialzed what also includes the
creation of the CDI application context:
<br />
<br />
<pre class="brush: java">public class BeanManagerAccessor {
public class RemoteHessianInitializer implements ServletContextListener {
...
/** Context listener callback. ... */
@Override
public void contextInitialized(ServletContextEvent sce) {
BeanManagerAccessor accessor = new BeanManagerAccessor()
// retrieve extension from CDI
RemoteCallableDiscoveryExtension extension =
accessor.getReference(RemoteCallableDiscoveryExtension.class);
Collection<Annotatedtype> annotatedTypes = extension.getRemoteCallableAnnotatedTypes();
// process all @RemoteCallable annotated beans
for (AnnotatedType annoType : annotatedTypes) {
RemoteCallable anno = annoType.getAnnotation(RemoteCallable.class);
Class iface = anno.type();
String url = anno.url();
Class implClass = annoType.getJavaClass();
// bean instance to be made remote accessible
Object instance = null;
// check if its an ejb
Stateless stateless = annoType.getAnnotation(Stateless.class);
Stateful statefull = annoType.getAnnotation(Stateful.class);
// try to retrieve ejb from jndi
if (stateless != null || statefull != null) {
try {
String ejbName = null;
if (stateless != null) {
ejbName = stateless.name();
} else if (statefull != null) {
ejbName = statefull.name();
}
if (ejbName != null) {
InitialContext ctx = new InitialContext();
String webAppName = sce.getServletContext().getContextPath();
// TODO the jndi-ejb root path (path building) should be configurable
instance = ctx.lookup("java:app" + webAppName + "/" + ejbName);
} else {
throw new RuntimeException("...");
}
} catch (Exception ex) {
...
}
} else {
try {
instance = accessor.getReference(implClass);
} catch (Exception ex) {
...
}
}
if (instance != null) {
// create hession servlet proxy
Object proxyImpl = ExtendedHessianServletProxy.createProxy(iface, instance);
// register as servlet
ServletRegistration.Dynamic dynamic =
sce.getServletContext().addServlet(iface.getName(), (HessianServlet) proxyImpl);
// register url mapping
dynamic.addMapping(url);
}
}
}
}
</pre>
<br />
The dynamic proxy class looks like this:<br />
<br />
<pre class="brush: java">public class ExtendedHessianServletProxy extends HessianServlet {
/**
* the delegate.
*/
Object delegate;
...
/** The returned proxy inherits a hession servlet that can dynamically
* used as a hession business proxy for the given interface.... */
public static Object createProxy(final Class anInterfaceToImplement, final Object anImplementor) {
ProxyFactory f = new ProxyFactory();
f.setSuperclass(ExtendedHessianServletProxy.class);
f.setInterfaces(new Class[]{anInterfaceToImplement});
f.setFilter(new MethodFilter() {
public boolean isHandled(Method aMethod) {
// only accept methods of the given interface
for (Method method : anInterfaceToImplement.getDeclaredMethods()) {
if (method.equals(aMethod)) {
return true;
}
}
return false;
}
});
Class c = f.createClass();
MethodHandler mi = new MethodHandler() {
public Object invoke(Object self, Method aMethodCalled, Method proceed,
Object[] args) throws Throwable {
ExtendedHessianServletProxy proxy = (ExtendedHessianServletProxy) self;
return aMethodCalled.invoke(proxy.getDelegate(), args); // execute the delegate method.
}
};
ExtendedHessianServletProxy proxy;
try {
proxy = (ExtendedHessianServletProxy) c.newInstance();
((ProxyObject) proxy).setHandler(mi);
} catch (Exception ex) {
.....
}
proxy.setDelegate(anImplementor);
return proxy;
}
}
</pre>
<br />
The complete source code you find at <a href="https://github.com/joerggross/eercp/tree/master/remote.hessian" target="_blank">My GitHub repository</a>.joerg grosshttp://www.blogger.com/profile/00435504495005446117noreply@blogger.com0tag:blogger.com,1999:blog-7828800437914284467.post-22682162426645757312011-12-23T07:07:00.000-08:002011-12-29T08:45:20.402-08:00An Unique Identity AspectOne of the most elegant but also dangerous techniques I have worked with in the recent years is AOP. It is elegant because you can implement crosscutting concerns so easy but it is dangerous because it makes the source code sometimes hard to understand.<br />
<br />
James Gosling <a href="http://www.eweek.com/c/a/Web-Services-Web-20-and-SOA/Suns-Gosling-New-Java-Flavors-Brewing/2/">says</a> about the concrete application of aspects some years ago:<br />
<br />
<blockquote class="tr_bq">
<i>... And because theyre narrowly focused they actually manage to be really
safe and useful. [Otherwise,] it feels like handing razor blades to
children. Youve got to have razor blades to shave your beard, but oh my
God, dont let five-year-olds do craft projects with them. And of course
most of the people out there using AOP arent 5-year-olds doing craft
projects, but theyre easily tempted. It just seems to me that that
theres just a better way.... </i></blockquote>
<br />
I won't do without aspects in the meantime, but my conclusion of what James Gosling said is that we should be careful by using them...<br />
<br />
The implemetation of an interface (a set of methods) that represent a crosscutting concern
is - in my opinion - one main use case for AOP (called inter-type
declaration). But if you won't be lost in the jungle of somewhere hidden pointcut
declarations, such an inter-type declaration should be visible at the
classes where the aspect is to be apllied. Furhermore I want to let the developer decide which class should implement such an interface/aspect. This can be achieved by an annotation that may have the same name as the interface to be implemented by the aspect. Instead of adding the interface as <code>implements</code> you simply define the annotation.<br />
<br />
I will take an unique aspect as an example.<br />
<blockquote class="tr_bq">
All persitent entitites of this project will be unique. Therefore I will
use a String based UUID. Such an UUID has one advantage over an
database generated ID (sequence): The UUID could be created and set
during instance creation and could hence even be available when an
(persistent) entity is still not persistent. In the GUI you have often
to handle such non persistent entities. Especially when these instances
are sent over the wire (by remote access) you can't rely on Java's base
implementation of object identity to check wether two (non persistent) instances are
equal.</blockquote>
<br />
The usage of an unique annotation would look like this:<br />
<br />
<pre class="brush: java">...
@ImplementsUnique
public class UniqueEntityByAnnotation {
...
}
</pre>
<br />
Thats all. By using this annotation the class will implement a <span style="font-family: "Courier New",Courier,monospace;">uniqueId </span>String field with getter and setter and suitable<span style="font-family: "Courier New",Courier,monospace;"> equals()</span> and <span style="font-family: "Courier New",Courier,monospace;">hashCode()</span>method-implementations. This functionality is provided by a <span style="font-family: "Courier New",Courier,monospace;">IUnique</span> interface:<br />
<br />
<pre class="brush: java">...
public interface IUnique {
/**
* Returns the unique id.
*/
String getUniqueId();
/**
* Sets the unique id.
*
* @param aUniqueId
* the unique id to set.
*/
void setUniqueId(String aUniqueId);
/**
* ...
*/
int hashCode();
/**
* ...
*/
boolean equals(Object obj);
}
</pre>
<br />
The implementation of uniqueness is provided by the simple Java class <span style="font-family: "Courier New",Courier,monospace;">Unique</span> that may look like this: <br />
<br />
<pre class="brush: java">/**
* Implementation of simple uniqueness.
*
* @author Jörg Groß
*
*/
public class Unique implements IUnique {
/**
* the uniqueId.
*/
protected String uniqueId;
/**
* {@inheritDoc}
*/
@Override
public final String getUniqueId() {
return this.uniqueId;
}
/**
* @{inheritDoc
*/
public void setUniqueId(String aUniqueId) {
this.uniqueId = aUniqueId;
}
// implements equals() and hashCode()
...
}
</pre>
<br />
Lets now create an aspect (using AspectJ) that will be apllied by the <span style="font-family: "Courier New",Courier,monospace;">@ImplementsUnique</span> annotation:<br />
<br />
<pre class="brush: java">import de.jgros.eercp.core.type.IUnique;
...
public privileged aspect UniqueAspect {
declare parents : @ImplementsUnique * extends Unique;
} </pre>
<br />
The aspect will not automatically be apllied if any class implements the <span style="font-family: "Courier New",Courier,monospace;">IUnique</span> interface. Instead of that all classes that define an <span style="font-family: "Courier New",Courier,monospace;">@ImplementsUnique</span> annotation will extend the <span style="font-family: "Courier New",Courier,monospace;">Unique </span>class (by adding its implementation as a mixin using AspectJ).<br />
<br />
In my opinion the main advantage of this apporach is, that the developer could still use the <span style="font-family: "Courier New",Courier,monospace;">IUnique</span>-interface and the <span style="font-family: "Courier New",Courier,monospace;">Unique </span>class by simple implementation or extension.joerg grosshttp://www.blogger.com/profile/00435504495005446117noreply@blogger.com0tag:blogger.com,1999:blog-7828800437914284467.post-56796953099402376742011-12-20T09:04:00.000-08:002011-12-21T01:27:05.787-08:00JPA Unit test setup with NetBeans<br />
For the development of server projects I will use NetBeans 7.0.1 as IDE. It seems to be very easy to set up a JEE web project with this IDE. This will be the first time for me developing with NetBeans.<br />
<br />
So I have started with a simple server project. Just one simple persistent entitiy: <span style="font-family: "Courier New",Courier,monospace;">Person</span>.<br />
<br />
The <span style="font-family: "Courier New",Courier,monospace;">Person </span>class looks like this, pretty simple:
<br />
<pre class="brush: java">
@Entity
public class Person implements Serializable {
@Id
String uniqueId;
private String firstname;
...
</pre>
<br />
Although I know that the persistence of JPA-Entities needs not to be unit tested, there are scenarios where it is useful to write unit tests to test the persistence tier, e.g. in case of complex queries (SQL, JPA query, etc). So I try to set up a test environment with an in memory Apache Derby database to execute unit tests in the IDE.<br />
<br />
It was not so easy in the unit test scenario to tell the JPA-Provider (EclipseLink) which classes are the persistent ones. By default the JPA provider scans all jar files that contain a <span style="font-family: "Courier New",Courier,monospace;">META-INF/persistence.xml</span> file and all classes with an <span style="font-family: "Courier New",Courier,monospace;">@Entity</span> annotation are considered. I will rely on this mechanism in my project. Unfortunately during test execution there is no jar file to scan and so none annotated classes are found. And there seems to be no other way to activate a different xml-file based JPA configuration during test execution. Although there is a way to overload <span style="font-family: "Courier New",Courier,monospace;">EntityManager </span>properties when creating the <span style="font-family: "Courier New",Courier,monospace;">EntityManager</span> instance in the test set up - but I found no way to add a list of persistent classes:<br />
<br />
<pre class="brush: java">
@Before
public void setUp() {
Properties props = new Properties();
props.put("javax.persistence.transactionType", "RESOURCE_LOCAL");
props.put("javax.persistence.jtaDataSource", "");
props.put("javax.persistence.nonJtaDataSource", "");
props.put("eclipselink.jdbc.driver", "org.apache.derby.jdbc.EmbeddedDriver");
props.put("eclipselink.jdbc.url", "jdbc:derby:testDB;create=true");
props.put("eclipselink.jdbc.user", "");
props.put("eclipselink.jdbc.password", "");
props.put("eclipselink.ddl-generation", "drop-and-create-tables");
props.put("eclipselink.logging.level", "INFO");
EntityManagerFactory emFactory =
Persistence.createEntityManagerFactory("eercp.server.PU", props);
em = emFactory.createEntityManager();
}
</pre>
<br />
Finally I found a way to tell EclipseLink which classes are persistent by overloading an ant target in the file <span style="font-family: "Courier New",Courier,monospace;">build.xml</span> of the NetBeans project. NetBeans executes this ant build script before test execution what gives us a chance to join in the execution process. So I placed an <span style="font-family: "Courier New",Courier,monospace;">orm.xml</span> file in the project and copy it together with the <span style="font-family: "Courier New",Courier,monospace;">persistence.xml</span>:<br />
<br />
<pre class="brush: xml">
<target if="has.persistence.xml" name="-copy-persistence-xml">
<mkdir dir="${build.web.dir}/WEB-INF/classes/META-INF"/>
<copy todir="${build.web.dir}/WEB-INF/classes/META-INF">
<fileset dir="${persistence.xml.dir}" >
<include name="persistence.xml"/>
<include name="orm.xml"/>
</fileset>
</copy>
</target>
</pre>
<br />
This does work - but it is not the way I would prefer. But it seems the only way to execute a JPA unit test with a different configuration in the NetBeans IDE.<br />
<br />
The <span style="font-family: "Courier New",Courier,monospace;">orm.xml</span>-file just contains the list of persistent classes, the JPA provider merges this information with the annotations defined at the persistent classes:<br />
<br />
<pre class="brush: xml">
<entity-mappings version="1.0"
xmlns="http://java.sun.com/xml/ns/persistence/orm"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm orm_1_0.xsd">
<entity class="de.jgros.eercp.server.domain.User"/>
</entity-mappings>
</pre>
<br />
<br />joerg grosshttp://www.blogger.com/profile/00435504495005446117noreply@blogger.comtag:blogger.com,1999:blog-7828800437914284467.post-89347372447263504362010-05-12T10:39:00.001-07:002011-12-21T12:14:21.993-08:00The blog begins ...Why this project?<br />
<br />
I've been attending the JEE Summit in Berlin to update my Java EE knowledge that was still more than 5 years old and based on J2EE (1.4) standard. A technology very hard to handle - but things have changed....<br />
<br />
Since that time - in the recent 5 years - I was lucky to support two projects that were based on Eclipse RCP and a Spring stack executed in a WAR on Tomcat. We used the Spring framwork for security, remoting, transaction, testing, and so forth... <br />
<br />
All speakers at the summit had proved that the JEE technology stack is ready for productive use. Mostly impressed I was from the potential the CDI-technology seems to offer by eliminating the need for implementation of many of the Gang Of Four patterns.<br />
<br />
This leads to a few questions that needs to be clarified: <br />
<ul>
<li>How does the 'new' JEE 'feel' in every day life of a software developer who is used to the Spring framwork?</li>
</ul>
<ul>
<li>Is it possible to use JEE Web Profile (e.g. based on Tomcat/TomEE) as backend/server of a rich client architecture (by replacing the spring stack) or do we need a full JEE container for our needs?</li>
</ul>
To answer this questions I have initiated this Project.<br />
<br />
The overall technology view (from 10.000 meters):<br />
<br />
Client<br />
<ul>
<li>Eclipse RCP </li>
</ul>
Server<br />
<ul>
<li>JEE Web Profile (EJB/CDI, Transaction, Security, JPA)</li>
</ul>
<br />
I'm sure many other frameworks/technologies/APIs/tools will be emerged and discussed when the project proceeds.joerg grosshttp://www.blogger.com/profile/00435504495005446117noreply@blogger.com