Salient Soft

Download and install TortoiseCVS from here. Note that the release notes for version 1.10.10 state that 64-bit versions of Windows are supported. My installation runs fine on Windows 7 64-bit.

Except for the main preferences screen, all of Tortoise CVS is accessed via Windows Explorer context menus. Note that this also works within the file open dialogs of applications.

Connecting to the server is done from the CVS/Checkout… menu. In the left pane of the resulting dialog, you select the protocol, protocol parameters, the server, and the repository folder. In the case of my Java repository above, this will be /Java. Note that you do not need to tell the client the server side path of the repository root.

Tortoise does not cache passwords for access to the CVS server, so you have to enter it for the first time in each session. You can however add custom switches for the connection protocol, which may allow a password to be specified. Note that this is therefore not encrypted! You will probably want a dedicated low privilege account for CVS access if you do this, and in fact this is recommended anyway  – see here for details on how to set this up.

For the pserver protocol, you can add password=mypassword to the Protocol Parameters box in the checkout dialog.
The settings in this dialog are remembered for the next time you use it. If you access multiple replositories, they are remembered and may be selected in the list box at the top.

You do not want Tortoise control on all your explorer folders, as this can slow explorer down and clutter up the context menus when you don’t want it. Use the advanced tab in the preferences dialog to include/exclude folder trees from Tortoise control. Note that if you add a folder tree to include, all others are excluded – see this post here. You can also exclude network shares etc. (done by default).

Usage Points

1. When checking out, you pick a module name in the RHS pane. You can browse for/refresh the module list first.
2. After checkout, you get a subfolder for the module tree, which contains a cvs folder which contains metadata and is managed by Tortoise.
3. If you do a ‘wild’ checkout you will end up checking out CVSROOT which you don’t need – this can be deleted.
4. You can tag a file or group of files/module etc. to indicate a version, then check this out later using the tag. Note that internally, CVS uses a an “n.n” style internal version number starting at “1.1” for a file.

No Comments »

This post details the setup of a repository server on a Windows based PC.

Download and install the CSVNT server here.
Make sure you pick the Windows Server software and not the “client trial”.
If you show all downloads you need to pick a server OS, not a client OS like Windows XP, even if installing on Windows XP Pro like I was. (You cannot install on XP home at all  – you must have simple file sharing turned off and Windows XP Home cannot do this). In my case, simple file sharing was off as I had already turned off ForceGuest, see here.
You can pick a specific account for access, or use the client account  – I presume the user/password must also match the server if you are in a workgroup rather than a domain but I did not test this. My installation was in a Workgroup with a specific account on the server PC. Note that you should run CVSNT under an account on the server with the minimum of privilege, rather than an administrator account. See here for details on how to do this.

The server runs 2 services – CVSNT Dispatch Service and CVSNT Locking Service, which both need to autostart (this is done by default). The server administration is via a control panel utility which is also available via the start menus.

Ensure that Simple File Sharing is turned off.
Make sure that you exclude cvsservice.exe and cvslock.exe in both the Windows Firewall and any Antivirus software.
In my case failure to do this caused 2 problems :-

1. cvslock.exe crashed soon after startup
2. The repository was not visible at all from the client side (in Eclipse) and would not connect – connection timeouts occurred.

You can run multiple repositories from a CVSNT server. In my case I am using a common root – “D:\CVS Repositories” and a subfolder for each respository underneath. My Java repository is named /Java and is similarly connected this way on the client. Its Root is therefore defined as D:\CVS Repositories\Java.

Connecting to the server

In all cases I use the pserver protocol – the Eclipse plugin does not support many protocols natively and pserver is the most common. I use the same protocol for Tortoise..  The server does not mandate the protocol used by the client (as far as I know) so provided the plugin is loaded for the protocol (see plugins page in the CVSNT control panel server admin tool) it should work. Pserver apparently only encrypts passwords but if you are running on a secure internal development network behind a firewall this should not be an issue, and should also improve performance as the protocol is not having to encrypt everything.

No Comments »

1. Decide on component versions to be used by building a cross compatibility matrix. Generally you will want to install the latest production builds of all components consistent with full cross compatibility. Also to be considered are the various tool bundles available, which can simplify installation and configuration by allowing multiple tools to be installed from a single kit. However, many of the bundles overlap, so this needs to be taken into account (in addition to the compatibility matrix)  so that you do not end up installing multiple versions of the same tool – for example, Java EE can come with the JDK or with Eclipse. In my case, I am using an Eclipse bundle which includes Java EE.
2. Download and install the chosen Java SE JDK.
3. Download and install Glassfish (Eclipse has a plugin for, and therefore a dependency on, Glassfish so we do the latter first).
4. Download and install Eclipse. My bundle included Java EE 5 and Eclipselink and all the web tools.
5. Install the Glassfish Plugin for Eclipse.
6. Download ICEfaces (e.g. v1.8.x). This just needs unzipping to any desired target folder (e.g. E:\ICEfaces-1.8.x). The distribution contains full documentation for getting started, running tutorials, and development.
7. Download and Install the Eclipse ICEfaces plugin.
8. Download Tomcat if required. You may just want to use Glassfish as your servlet container, but in my case some development projects will use JSF/ICEfaces/Tomcat without Java EE. I have in the past used the windows service installer version, which is a self installing .exe and installs/runs Tomcat as a service. However note that this does not work under Windows 64-bit if you are using a 32 bit JVM. See here for a manual install process from the zip kit to give you all the functionality of the windows installer version, including run as a service, configuration utility, and system tray monitor/utility.

No Comments »

This ICEfaces article details the importance of the correct separation of concerns and scoping of JSF managed bean. Of particular importance is ensuring that you do not mix up the layers of the MVC design pattern, by mashing up different MVC concerns into a single managed bean. Correct splitting up of classes and scoping can avoid this and achieve the desired loose coupling.

The approach I have taken, which differs subtly from the above article but is fundamentally the same, is as follows :-

1. I encapsulate all calls to the business/service layer in a ModelBean. This bean exposes properties which hold all the business data fetched from the service layer, and various populate and save methods to fetch/populate those properties and finally persist modified versions of them back via the service layer. As I am using JPA and have generally elected not to use the DTO pattern,  the properties  are JPA entities, objects which are the result of JPA select constructor expressions, or primitive data values from the database. For clarity, the ModelBean is stateful and session scoped and so holds the properties all the time a page is being viewed/edited, whereas all the calls to the service layer are stateless. I might have a single model bean, or I might break it down into a number of separate beans, depending on what suits the design. Whilst there could be one per JSF page, typically I find that there is scope for a lot of re-use of common methods and properties acrosss pages. Conversely, for a larger application, it may become unmodular and unwieldy to have a single model bean. A fundamental point about this bean is that it does not  perform any controller logic, i.e. does not directly interact with the components on the page (although typically of course they will refer to its properties to get data).
2. I encapsulate all the logic which interacts with the components on the page in a controller bean for the page. Where the page contains subcomponents such as custom facelets tags (in my case, a TablePair tag is an example of this), I typically find that a good design is to have a separate child controller bean for each custom component, so that the controller mirrors the structure and requirements of the view. These controller beans do not access the business/service layer directly – all such access is routed via the ModelBean above. This separates all code which is directly aware of the business layer interface from controller code which is aware of the structure and handling of the page.
3. I ensure that the view (the JSF page, facelets and tags) does not contain any business or controller logic. As this post indicates in its last paragraph, the presence of logic expressions in JSF value expressions is often a warning bell that this may have occurred, and the view has been polluted with controller or model concerns. For example, the disable attribute on a JSF component is strictly a property reference to an enable/disable property in a controller bean. The conditions under which that property is enabled or disabled are strictly a controller issue. The above post also details design guidelines for state change management and event handling and propagation for the controller bean.

A good test of the design is to ask yourself the following questions:-

1. What would need to change if the call interface to the service layer changed? Would it be necessary to change any backing beans which also contain controller logic – which handle components on the page? If so, the design has become polluted. Consider a possible requirement where the service layer interface was enhanced, and the old interface was eventually due to be deprecated. You might have a situation where you needed to support both versions. Would this result in having 2 identical copies of some controller code which interacts with components on the page? If so, you have polluted the design and mixed controller concerns in with the model. If you had to perform any bug fixes on the duplicated controller code, you would have to update both copies identically to keep them in step, and so have broken modularity.
2. Conversely, what would need to change if the user interface to the page changed, but performed the same functions in terms of the model (perhaps the interface was improved to make it more user friendly)? Would it be necessary to change any beans which contain calls to the business/service layer? If so, the design has again become polluted. Consider a possible requirement where you needed to maintain both the old and the new versions of the user interface for a period until the old one had been completely phased out. This would require 2 versions of the controller beans to be maintained. Would this result in having 2 identical copies of some model code which directly calls the business/service layer? If so, you have polluted the design and mixed model concerns in with the controller. If you had to perform any bug fixes on the duplicated model code, you would have to update both copies identically to keep them in step, and so have broken modularity.

Comments Off on Correct Scoping/Separation of JSF Managed Beans

I’ve found that this is useful for prototyping/mockups of apps that are targetted for GlassFish. It is possible to run JPA with Eclipselink outside an EJB container, so a JSF/JPA app can be run under Tomcat, resulting in less overhead and faster turnaround of changes. For a while I’ve had to use a PC which is RAM limited, and so developing/prototyping with Eclipse and Glassfish has been slow. Turning around deployments/changes around takes time, and I’ve found the synchronisation between Eclipse and Glassfish to be a bit fussy – sometimes Eclipse misunderstands the state of Glassfish, needing a Glassfish restart which again takes valuable time.

Note the following points on doing this:-

1/ My application stack looks similar to the ‘real’ one, but my Service layer/domain objects are just POJOs which are explicitly created or injected via faces_config.xml. This Oracle Example details the various IOC features of the JSF. managed bean facility.

2/ Persistence.xml needs setting up differently to run JPA outside the container. I have found it easiest to specify the database connection explicitly, rather than using a data source. In Eclipse, you can use the persistence.xml editor to populate the connection properties directly from the one Eclipse uses for its entity validation. Whilst you can do JNDI lookups of a data source stored in Tomcat, the naming context used is different, as it makes use of the Enterprise Naming Context (ENC), i.e. “java:comp/env”. This example details how to do it if you want to go that way. A sample persistence.xml follows (with entries commented out where they have been replaced for use with Tomcat) :- 

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
 http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">

 <!--<persistence-unit name="SentryPrototype" transaction-type="JTA">-->
 <persistence-unit name="SentryPrototype" transaction-type="RESOURCE_LOCAL">

   <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>

   <!--<jta-data-source>jdbc/JPATestPool</jta-data-source>-->

   <class>uk.co.salientsoft.jpatest.domain.UserInfo</class>
   <properties>
    <property name="eclipselink.logging.level" value="INFO" />

    <!-- <property name="eclipselink.target-server" value="SunAS9" />-->
    <property name="eclipselink.target-server" value="None" />

    <property name="eclipselink.session-name" value="SentryPrototypeSession" />
    <property name="eclipselink.target-database" value="Oracle" />   
    <property name="eclipselink.ddl-generation.output-mode" value="database" />

    <property name="eclipselink.jdbc.url" value="jdbc:oracle:thin:@localhost:1521:xe"/>
    <property name="eclipselink.jdbc.user" value="sentry"/>
    <property name="eclipselink.jdbc.password" value="sentry"/>
    <property name="eclipselink.jdbc.driver" value="oracle.jdbc.OracleDriver"/>

   </properties>
  </persistence-unit>
</persistence>

3/ Ref this eclipse tutorial :-
Tomcat does not have an EJB container so you must add EJB 3.0/JPA 1.0 capability for EclipseLink JPA by placing the specification persistence.jar into the container lib directory $TOMCAT_HOME/lib.
It is recommended to put persistence_1_0.xsd there as well.  It is not recommended that the WAR include its own version of persistence.jar. Your eclipse project should reference but not include this jar and xsd.

The eclipselink.jar should be placed off of the container lib directory $TOMCAT_HOME/lib.
Since Tomcat does not include an EJB container, you may put eclipselink.jar in the web applications’s lib directory or higher up in the classloader by putting it off of Tomcats’ lib directory, where all web applications can access it.
Do not split the eclipselink.jar from the javax.persistence jar – keep them together – preferably in $TOMCAT_HOME/lib

 4/ Tomcat has its own dependencies on the Expression Language (EL) web libraries. These should be removed from WEB_INF/lib when deploying to Tomcat as pointed out here. (If you do not do this, the application will crash with duplicate class loading exceptions.) This may be done in eclipse on the Java Server Faces facet page – open the project properties for the project, and select Java Server Faces under Project Facets. Untick the entry for Standardized EL Library v1.0.

Then save the changes and redeploy the application.

For more information, the eclipse tutorial referenced in 3/ goes into greater depth on the subject. You can also find a list of the available eclipse JPA tutorials here.

5/ When running xxxxxx

Comments Off on Using Eclipse/JSF/JPA with Tomcat 6

This simple example was performed with Eclipse Galileo 3.5.1

1/ Project Creation Dialog

From the menus in eclipse, select File/New/EJB project. On the resulting dialog, name the project. You can pick other options at this stage such as EAR membership but this can be done later if desired. Note that we are not amending the configuration section (via the modify button) at this stage to add JPA faceting (more on this later).

Click Finish and your EJB project will be created.

2/Project Facets

Right click your new project, and select Project Facets on the left. Tick the box marked Java Persistence in the middle pane, and you will be presented with the following screen :-

3/ JPA Facets

Now Click the “Further configuration available” link at the bottom. This will display the JPA Facet dialog as follows. On this screen you should do the following :-

1. Select the correct platform version and library type – typically these will be Eclipselink 1.1 or later version if available.
2. Untick the box marked “Include libraries with this application”.  The  latest Eclipselink.jar  library should be deployed separately to Glassfish, and stored in the $GLASSFISH_HOME/lib directory. To clarify, Eclipselink is available as a single jar, non-OSGI deployment, or split up into multiple jars for OSGI deployment. The OSGI jars have the long names with the OSGI packaging prefixes such as “org.eclipse.persistence.core” followed by name and version number information. They are a finer grained breakdown of the classes to allow more selectivity/flexibility in use. You can copy the OSGI jars to $GLASSFISH_HOME/lib directory – this will also work but is unnecessarily complex for non-OSGI use. This post here contains a brief overview of OSGI and links to detailed information about it.
3. Select the database connection to be used. If it is not already present, click the Add connection link to create a new one. This also allows you to add a new JDBC provider for a given database type, and point to the jar file(s) for the provider. Note that you will also need to add the JDBC provider jar to GLASSFISH_HOME/lib. To clarify, this database connection is used by eclipse to validate the persistent entities and mappings in the project during development. It is not used by Glassfish at run time. The run time connection (data source) will be created in Glassfish, and persistence.xml will be configured to use the datasource that you created in Glassfish.
4. Next, you can select whether your annotated persistent classes will be discovered automatically, or whether they must be listed explicitly in persistence.xml. To ensure portatbility, you should take the manual option as  automatic discovery is not guarrranteed to be portable.
5. Finally you can select whether or not to create orm.xml. You can always create it later if you need it – if you are using annotations entirely you won’t. This post here describes how you can combine both annotations and orm.xml in order to both take advantage of features like sequences in Oracle whilst still retaining database independance.

Click OK on the JPA Facet dialog, and then OK on the project facets screen. This will complete the creation of your project.

Note that as already stated, it is possible to click the modify button in the configuration section of the dialog in stage 1, which will also display the project facet screen. However, this version of the project facet screen is different to the one displayed if you select Project Facets after creating the project. In particular it does not have the “Further configuration available” option, and so does not allow you to display the JPA Facet dialog to modfy the options there. It assumes defaults for these options instead.

It is possible to  reconfigure the project JPA Facet settings subsequently, by selecting the “Java Persistence” option which appears in the list on the left of the project properties dialog (this only appears for projects with the JPA facet selected). This displays the “Java Persistence” dialog which has the same options as the “JPA Facets” dialog. Instead, you can also untick Java Persistence on the Project Facets screen, applying the changes, and retick the option. This will reveal the “Further Configuration Available” option to allow access to the JPA Facet dialog as well. In the example above, we added the Java persistence facet after saving the project which gave us immediate access to the JPA Facets dialog.

No Comments »

This article on CodeIdol is a good detailed FAQ on the Enterprise Naming Context or ENC, also known as the Java EE Application Component Environment, accessed via the JNDI name “java:comp/env”.  The article details the use of the java ee annotations in @javax.annotation.EJB and the equivalent XML, including injection of bean references via XML using <injection-target> rather than annotations. 

Another article on redhat.com gives a good overview of this with some other helpful links.

No Comments »

Update

I have posted some further notes on this here. The notes are in raw form from an earlier investigative email – much of it is covered here, but some points and links are not, and I do not have the time or inclination at present to rework everything into a single post!

The following examples show typical scenarios which have been tested as working :-

1/ Local EJB Interface injected into JSF managed bean via @EJB

Note that when implementing a dual interface as here, you can extend a single underlying interface. In this case, SimpleBeanLocal and SimpleBeanRemote both extend SimpleBean. However, when you do this, the implementation code must explicitly implemement both SimpleBeanLocal and SimpleBeanRemote as in this example. Implementing the superinterface SimpleBean on its own will not work. This is also explained in this post.

JSF managed bean code

@EJB()
private SimpleBean simpleBean;

EJB Implementation Code

@Stateless()
public class SimpleBeanImpl implements SimpleBeanLocal, SimpleBeanRemote {

...class code here...

}

2/ Local EJB Interface looked up in JSF managed bean directly via JNDI 

JSF managed bean code

try {
  InitialContext ctx = new InitialContext();

  /* Note that the JNDI name consists of the Java EE Environment Naming Context (ENC) -
    "java:comp/env", followed by "/", followed by the <ejb-ref-name> used in web.xml.
    The extra /Local is just to make the name different to the remote example.
    Any name can be used providing web.xml matches, and multiple slashes can be present.
  */

  simpleBean = (SimpleBean) ctx.lookup("java:comp/env/ejb/JPAGlassFishIce/Local/SimpleBean");     
  userList = simpleBean.fetchUsers();
} catch (NamingException e1) {
  e1.printStackTrace();
}

web.xml

<!-- We define a reference for the bean here.
     If we were using @EJB this would do it for us,
     but in this case we are using an explicit JNDI lookup.
-->
<ejb-local-ref>
    <ejb-ref-name>ejb/JPAGlassFishIce/Local/SimpleBean</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <local-home></local-home>
    <local>uk.co.salientsoft.jpaglassfishice.domain.SimpleBeanLocal</local>
</ejb-local-ref>

EJB Implementation Code

@Stateless()
public class SimpleBeanImpl implements SimpleBeanLocal, SimpleBeanRemote {

...class code here...

}

3/ Remote EJB Interface injected into JSF managed bean via @EJB

JSF managed bean code

@EJB(name="ejb/JPAGlassFishIce/SimpleBean", beanInterface=SimpleBeanRemote.class)
private SimpleBean simpleBean;

EJB Implementation Code

@Stateless(mappedName="ejb/JPAGlassFishIceEJB/SimpleBean")
public class SimpleBeanImpl implements SimpleBeanLocal, SimpleBeanRemote {

...class code here...

}

4/ Remote EJB Interface looked up in JSF managed bean directly via JNDI 

JSF managed bean code

try {
  InitialContext ctx = new InitialContext();

  /* Note that the JNDI name here matches the mappedName given in the
     @Stateless annotation in the EJB implementation code.
     mappedName is only relevant for remote interfaces.
     It is not used for a local interface.
  */

  simpleBean = (SimpleBean) ctx.lookup=("ejb/JPAGlassFishIceEJB/SimpleBean");     
  userList = simpleBean.fetchUsers();
} catch (NamingException e1) {
  e1.printStackTrace();
}

EJB Implementation Code

@Stateless(mappedName="ejb/JPAGlassFishIceEJB/SimpleBean")
public class SimpleBeanImpl implements SimpleBeanLocal, SimpleBeanRemote {

...class code here...

}

No Comments »

Update 08/09/2022

Another interesting and helpful post on primary key generation may be found on Baeldung here.

Original Post

There are a number listed on eclipse.org, oracle.com, and Sun.com. The eclipse ones are often not all complete but still useful.

1. A general list of Eclipse tutorials is here
2. Eclipse/JPA/Tomcat web tutorial
3. Eclipselink/JPA/JSF web tutorial (looks incomplete and is missing the source code).
4. Eclipselink/JPA/Glassfish V2 Web Tutorial – also a work in progress.
5. Oracle – Build a Web Application (JSF) Using JPA
6. Oracle – Example: Web Application (JSF) Using JPA (another article using the same code example as the previous one)
7. The Sun Java ee 5 tutorial contains a JPA example.

No Comments »

This one is from Web Age Solutions and is a good basic tutorial building on their earlier “simple session bean” one:-
http://www.webagesolutions.com/knowledgebase/javakb/jkb006/index.html

No Comments »