However this is not one post which should bring JIRA near to you. But if you know that you need it, now is best time to get it, because Atlassian started their “Get Startet” Price, which now allows you to by full functional JIRA for 10$ for ever even with one year support. All you need is a little bit of free CPU time, root access, 10$ and if you buy it outside of USA, you will need a credit card.

I installed it  for my private purposes and it works fine! I just followed Atlassian documentation (Read it carefully). Maybe, the easiest way is to install the “all in one” solution which comes with Apache Tomcat. I choosed that one. But don’t forget to switch to serious database before you start really using it. Take MySQL for example like I did.

I will not provide here step by step how to do it, because Simon has already described some of the important configurations moments as he heard about new pricing and as already mentioned the Atlassian installation guide is good and really answered all my questions.

Nevertheless feel free to ask questions here, about installation and configuration to.

Also i would like to discuss other Atlassian developer tools which also available for 10$. Is here outside someone experienced in bamboo?

Please feel free to comment here or there if you know what died changed in Ganymede in ant scripts handling since Europe release and how to fix it.

Occupational i deal with people who works with already aged version WSAD (Rational Application Developer for Web Sphere). I think they use version 5 which is based on eclipse platform in version 2.0 or 2.1 where folding was not supported.

Folding feature of eclipse based IDE’s allows you to clap uninteresting code fragments like methods constructors or imports out from your scope just in place.

So one of developers was just dropping all of his classes in just one package, doing it in apposite to the structure of whole project. He argued that doing so, hi has only one import statement in his classes for all classes from his “containing all” package. Having 15-20 import statements in a class disturbs!

God bless folding feature! Curtain!

… Database Trigger is predefined database procedure, conditionally or unconditionally succeeding or preceding other database operations automatically…[IBM Research Report, RJ1820, 1976]

That is actually what triggers are still today. But alone that definition make clear, that triggers can be also exploited for other purposes, like audit or security, but also for modelling (parts) of application logic or business rules. The main question, that appears is what should triggers do, what it can be used for, and when it becomes ugly? Generalising question thereby is, how much business logic should be done by the Database systems.

You can quick “google” for some answers like evans or from codeproject. But also academia gives similar answers. And this is good so, then there is no need to put application logic to Database tier, contrariwise logic in the database tier is contra productive.

At the moment i have to deal with some very large logistic system which logic is mostly implemented as triggers, not even stored procedures but triggers. The decision to build that system on triggers is unforgivable, even if that System was concept for years (i don’t know how old is it). I thing everybody understand why dealing with triggers is not comparable with one clean implementation of logic through e.g. 2EE based Middle-tier. At first the main logic and rules of the system are spread in a hundreds of triggers over hundreds of tables and therefore it is very difficult to maintenance. Secondly there are many side effects present, and many of them are unfortunately hard to predict, so that some kind of not determinism is always in the air. And at third there are problems on bulk updates, of course, when triggers start the avalanche, cascading each other!

Well, the richness of DB functions and options alone, should not lead to the meaning that all logic should be done in the Database-tier. Of course Database Systems which are rich on functions sells better. Yea! Maybe even better than sex . But at the End we should be carefully with every extra!

Concluding there are some tips when to use triggers:

1. Use them for Integrity control! There where invented for it!

2. Use them careful for Audit trails, consider also triggers are transaction safe, so when an operation is rolled back, all its triggered operations are also rolled back.

3. Use trigger careful for other administrative things like replication or notification.

4. Avoid to use triggers for business logic!

P.S. Next time i maybe explain why it is bad idea to programm Business applications in Visual Basic or atomate business processes witch MS Access )))

JunitEE

But Junit has some limitations, therefore, testing in each application server container becomes a tedious process. The JunitEE test framework addresses these limitations. This framework extends the standard JUnit so that tests can be executed in an application server container. JunitEE is configured in the J2EE Web module of a unit test application, and it uses a TestRunner to output HTML or XML test results. So according to Junitee.org there are following benefites :

• Your tests are packaged conveniently into a .war file which can easily be moved between servers; you can leave the .war file in the main .ear file and simply avoid enabling the test web application on the production server.
• Your test classes will be dynamically reloaded by the app server (assuming your server supports this).
• Your test cases look just like your production code, and can use the same beans (or whatever) you use as a facade for your EJBs.

How it works? Roughly it could be described like below, see resources for detailed examples:

1. Develop JUnit test cases
2. Create and configure a JUnitEE test modulePlace
   1. junit.jar and junitee.jar files in the project classpath by placing them in the WEB-INF/lib directory
   2. a jar file, like MyUnitTest.jar, containing your Test classes. Copy this file into the WEB-INF/lib directory too
   3. Include in the Servlet description like shown below in the web.xml deployment descriptor
3. Deploy and execute test cases on the Application Server.

{[.xml1 /enzymes/xml.php]}

Resources

1. New features in Junit 4
2. JunitEE Tutorial
3. Other Junit Extensions for J2EE
4. An extended example from IBM

The Java Persistence API provides a POJO persistence model for object-relational mapping. The Java Persistence API was developed by the EJB 3.0 software expert group as part of JSR 220, but its use is not limited to EJB software components. It can also be used directly by web applications and application clients, and even outside the Java EE platform, for example, in Java SE applications

So let’s look a bit deeper into the fetures of new API.

Persistense is dealing with entities. An Entitiy is a lightweight domain object, that shold be persistent. Typically an entity represents a table in a relational database, and each entity instance corresponds to a row in that table.

In the Java Persistens API the persistent state of an entity is represented either through persistent fields or persistent properties. These fields or properties use object/relational mapping annotations to map the entities and entity relationships to the relational data in the underlying data store.

So Entities are marked with the @Entity (javax.persistence.Entity) annotation and the entitiy-class shold implement Serializable interface. Further requirements for entitiy classes can be found in the Java EE 5 Tutorial.

Here ist just little examle of Persisten entitiy “User”.

{[.java1 /enzymes/s_java.php]}

If the entity name is the same as that of the table name, @Table is not required. The same with @Column Attribute. Not Persisten Fields or methods shold be marked with @Transient. Here more Information about persistent field and properties and especialy Primary Keys.
So far its quite simple.

Entities can have relations to each other. Java Persistence API knows four types of multiplicities: one-to-one, one-to-many, many-to-one, and many-to-many, which are marked with appropriate anotations. Furthermore relationships can be unidirectional or bidirectional. In a unidirectional relationship, only one entity has a relationship field or property that refers to the other. Read more about it.

This looks really intresting to me. But it gone to be better then, the Java Persistence API has an important new feature that was not covered bu SUn before: support for inheritance and polymorphism. An entity may inherit from another entity class. By default, the queries are polymorphic and are applicable against the entire entity hierarchy. Read more about inheritance posibilities.

An fionely ist better Query language

Queries and query language

The Java Persistence query language (JPQL) is an extension of the EJB QL, but overcomes EJB QL’s limitations and provides more features such as:

• Bulk update and delete operations
• Join operations
• Group-by operations
• Having operations
• Projection and subqueries
• Support for dynamic queries
• Use of named parameters (named parameters are parameters in a query that are prefixed with a colon (:))

More on JPQL in the Tutorial

Management of entities

Entities are managed by the entity manager. The entity manager is represented by javax.persistence.EntityManager instances. Each EntityManager instance is associated with a persistence context. A persistence context is a set of managed entity instances that exist in a particular data store and defines the scope under which particular entity instances are created, persisted, and removed.

As expected the are two kinds of managers an container managed and one application managed.
With a container-managed entity manager, an EntityManager instance’s persistence context is automatically propagated by the container to all application components that use the EntityManager instance within a single Java Transaction Architecture (JTA) transaction.

{[.java2 /enzymes/s_java.php]}
With application-managed entity managers, on the other hand, the persistence context is not propagated to application components, and the lifecycle of EntityManager instances is managed by the application.

{[.java3 /enzymes/s_java.php]}

Persisten context is described in persistense.xml file

Conclusion

At first look is the Java Persistence API an real break trough. (Ofcourse i should try it out in praxis befor i’m shure )
But the points are:

• standardizes the persistence API for the Java platform
• It simplificastion through a simple POJO-based persistence model
• annotations should makes entity coding and deployment easier
• And ofcourse features such as support for inheritance and polymorphism, simplistic entity relationship declaration,
• JPQL

Furthermore Java Persistence API can be used for Java SE environments too. This is possible because of the Java Persistence API’s support outside the EJB container. This is rely an advansed feature.

1. Java Persistence API on java.sun.com
2. Java Persistence API in the Java EE 5 Tototial
3. Good Article goes detailed on inheritance at JavaWorld
4. Extended fetures in Examples of using Persistence API in EJB tier
   
5. Using Persistens with JSF
6. Java WebStart Persistence