Brick Riccardi

Martijn Verburg wrote: (e.g. You can't get memory leaks, you don't need to tidy up after yourself etc).

Does the book cover some of these things? It sounds like the book is more of a primer on "java devs should be familiar with these x,y,z and technologies." I did look over the book description here http://www.java7developer.com/ and it does look like you cover the new Java 7 features which will be useful.

I'm a bit unclear where 'most' of the focus of the book is (I know it's not an Effective Java replacement.) Personally I'll probably skip the chapters on Groovy (which I use), Clojure and Scala. I know they're important but there is no way an intro to them in a few chapters of a book will do them justice, and if I just need to know 'what they're about on a surface level' their respective home pages give this information. What could be useful are tips on when and why to shift from core java to a language to something like scala or clojure.

Vyas Sanzgiri wrote:
Can you expand a little more on "optimize imports"?

For example, you have imports that are no longer needed in your files. You want to get rid of them. In Flex Builder (and I think in FlashBuilder) I was only able to do this on a per file basis. In IDEA I'm able to select the entire project and fix all the imports in the project. Same thing with formatting. It can format the whole project instead of a file at a time.

What bothered me most about Flex Builder's refactoring though was when I even selected refactor->move file and I'd pick a new package... well it moved it but never fixed the imports in all the files that referred to the class! That's just wrong. (Maybe a later release has fixed this, I don't know.) Never mind all the other little extras you get with IDEA when using it.. little things that I just like.. some small yea.. like seeing the color in the gutter of css color, autocomplete in css, color popup in css. Automcomlet when typing path names to assests like to an image you need. In files, it quickly highlights things wrong that eclipse wouldn't catch. Smart completion (eg when in a function it will suggest vars that match what your trying to add as args, listing the most recent ones close to the function which are typically what you want.) Analyze code, etc. It's suggestions to fix things are typically nice also. Once you start using it you just realize it's helping with a lot of small things that make my job easier without even me thinking about it. I should keep list some time as I'm working. To each his own though. I'm no longer religious about my IDE choice... although I still think IDEA is the best for how I like to work (In the Java world hands down IDEA rocks also.. especially if you do anything with Groovy... although the Eclipse groovy plugin is now really getting good.. hats off to those guys for their progress.)

I prefer IDEA over Eclipse for Flex development. The refactoring is just way better and little things like optimize imports across the whole project, or format across all the files etc. It doesn't have a wysiwyg editor but I never use it anyway.

Slobodan Erakovic wrote:
It is kind of three new areas, in order to successfully use (merge) my knowledge of Java (specifically in backend), with frontend, if I choose Flex, or I am wrong about my consideration about Flex?
Any advice, architectural direction?

Well the backend server side I'd create TOTALLY without regard for the front end (well other than the fact that for every server side class, I also have a matching method that returns XML.) But other than that UI front end doesn't matter.

I'm a java guy myself but haven't messed with JavaFX. I just don't want to bother with it, because I doubt it's going to be a major player (I could be wrong though, but I just don't see it.) If you are going to learn a new front end UI technology I'd still stick with Flex/AS or even Silverlight over JavaFX, but that's just me. By the way if you know Java, then ActionScript is a breeze - the learning curve for me was just learning how to deal properly with Events and asynch operations properly. (RobotLegs made my job a lot easier there. For a good UI example.. I HIGHLY recommend Joel's AddressBook example app http://github.com/joelhooks/robotlegs-examples-AddressBook - It's awesome. Thanks Joel

I'll probably create a tutorial soon myself (actually in June when done with this project) that demonstrates an Employee CRUD app written with Flex (RobotLegs) on the front-end hooked into Stripes/Groovy/iBATIS on the java side. (I've written some other ones for other technologies here so it will be similar .)

Just throwing in my +1 for RobotLegs. Simply a beautiful framework that is so simple to use, clean, and versatile.

Slobodan Erakovic wrote: However, I was wondering does Flex can communicate with Java backend (example: I have some Java based web app. in backed, Servlets, EJB3, Web Services, or whatever) ? Does Flex send a request, which can be handled as a HttpServletRequest, from the Servlet?

Yes very easily. You can use BlazeDS or I still prefer just using the HttpService object to send and HttpRequest and return XML from my servlet (technically I'm returning it from Stripes ActionBeans on the midtier, but it's ultimately just a servlet under the hood.)

I'm new to Flex/AS and currently working on a Flex3 project. I'm coming over from the Java world of things (server side stuff for this app is in Java/Groovy/Stripes.)
One of the minor annoyances I seem to be running into is in relation to populating a VO from a form. Most of the examples seem to show either creating an identical bindable object definition in mxml or examples like this http://www.johncblandii.com/index.php/2008/06/flex-3-two-way-form-databinding.html that still have you declaring a bunch of bindable properties.

In the web world I can have a simple model declaration on the server side "dog of type Dog" and behind the scenes any modern framework will take of binding the request params correctly to the model object without much effort. It seems like in Flex, a similar type of approach should be available. Maybe something where you could just do...

[Bindable] var seedEmployee:Employee; var resultEmployee:Employee; <mx:Form [b]bindTo="resultEmployee"[/b]> <mx:FormItem label="Name" required="true"> <mx:TextInput id="name width="200" text="{seedEmployee.name}"/> </mx:FormItem>

Even the brief Flex4 examples on two-way binding seem to show examples of setting up two way binding on the fields directly not the whole form to a value object? for example they often show:

<fx:Binding source="fieldA.text" destination="fieldB.text" twoWay="true"/>

Isn't there an easy way to bind the entire form to a value object? I'm sure there is, and I'm just missing it, and most of the examples online don't seem to demonstrate it either. Although, I have seen some examples for Flex4 that do NOT show the above Binding definition and instead just use something like <mx:TextInput id="name" text="@{employee.name}"/> which I'm assuming would handle the two way binding. I could seed the form with one 'employee' and when I'm done and click submit just pass that reference to employee to the service layer.

Is it not common to use JMX and MBean to help manage aspects of a war(s) deployed to Tomcat? I have a case where I want to be able to change the logging level of a webapp and clear a cache at runtime. I figured JMX/MBeans would be perfect for this - yet finding information how to set this all up on Tomcat leaves a LOT to be desired.

The only link that is somewhat helpful is this one http://oss.wxnet.org/mbeans.html. I'd like to find a little more information and some other sites with some examples but there is seriously nothing out there.

The lack of info out there makes me wonder if I'm even taking the correct approach trying to use JMX to manage parts of my app at runtime? What do others do? Is it maybe better to just build some sort of admin tool within the application to help manage its internals?

Thanks for any advice.

Originally posted by Aurelio Calegari:


You don't need DAOs if you're using App Service + JPA, because JPA is itself a domain store. You may want to use DAOs when you're encapsulating access to legacy systems either through using raw JDBC directly or emulating a screen scraper. You may want to combine App Service + JPA for trivial stuff and App Service + DAO to run stored procedures, for example.

I'm confused what you mean by this. Why wouldn't one also want a service class and a dao to abstract away all the jpa query stuff?

For example, if returning an employee doesn't it make sense to have:

EmployeeService { public Employee getEmployee(int id) { return employeeDAO.getEmployee(): } } EmployeeDAO { @PersistenceContext protected EntityManager em; public Employee getEmployee(int id) { Query query = em.createNamedQuery("Employee.findByEmployeeID"); query.setParameter("id", id); return (Employee)query.getSingleResult(); } }

(above shortened and not real code, but you get the idea)

This way you can do other stuff in your Employee service class, like maybe you want to do some transformation of the Employee to XML. Why would you want to tie up all the JPA specific logic inside of a service class? If the dao that gets an Employee is separate you can use it in other places as well. Although maybe my use of the DAO is the same idea as your use of a Service class? (where my Service class would be a different type of service class in your scenario?)

I have a compound Primary Key and I created an object to represent that Primary Key. What I'm curious about is how I can join on a member property of that primary key object if I so desire.

For example this named query is not working:

select ap from AssociatePreference ap, Associate ass where ass.associateID = ap.pk.associateID and ass.dmzID = :dmzID

The error:

findByDmzId(com.foobar.ondp.persistence.model.AssociatePreferenceTest) Time elapsed: 0.01 sec <<< FAILURE! java.lang.IllegalArgumentException: node to traverse cannot be null! at org.hibernate.hql.ast.util.NodeTraverser.traverseDepthFirst(NodeTraverser.java:31) at org.hibernate.hql.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:254) at ...

I'm not sure why I can't query on that kind of join, there should be a way since it's so darn simple in sql. I understand I can actually get the AssociatePreference List by going after the Associate record - that'll work fine - however there 'should' be a way I can just get AssociatePreferene objects trying a join in some way without caring about the entire Associate.

I've posted relevant portions of code below:

@Entity @Table(name = "NPPAssociatePreference") @NamedQueries({ @NamedQuery(name="AssociatePreference.byDmzID", query="select ap from AssociatePreference ap, Associate ass where ass.associateID = ap.pk.associateID and ass.dmzID = :dmzID") }) public class AssociatePreference extends BaseEntity { private AssociatePreferencePK pk; private String value; public String getValue() { return value; } public void setValue(String value) { this.value = value; } @EmbeddedId public AssociatePreferencePK getPk() { return pk; } public void setPk(AssociatePreferencePK pk) { this.pk = pk; } } @Embeddable public class AssociatePreferencePK extends BasePK { private int associateID; private int preferenceID; public AssociatePreferencePK() { super(); } public AssociatePreferencePK(int associateID, int preferenceID ) { this.associateID = associateID; this.preferenceID = preferenceID; } @Column(nullable=false) public int getAssociateID() { return associateID; } public void setAssociateID(Integer associateID) { this.associateID = associateID; } @Column(nullable=false) public int getPreferenceID() { return preferenceID; } public void setPreferenceID(Integer preferenceID) { this.preferenceID = preferenceID; } } @Entity @Table(name = "NPPAssociate") public class Associate extends BaseEntity { private int associateID; private Set<AssociatePreference> associatePreferences; //many more properties @Id @Column(nullable=false, unique=true) public Integer getAssociateID() { return this.associateID; } @OneToMany(fetch=FetchType.LAZY, cascade=CascadeType.REMOVE) @JoinColumn(name="associateID") public Set<AssociatePreference> getAssociatePreferences() { return this.associatePreferences; } .... }

edited bc forgot to disable smilies
[ October 27, 2008: Message edited by: Brick Riccardi ]

(I also posted this on a jboss jpa forum and haven't received a response yet, so trying here as well...)

I'm new to JPA (and Hibernate for that matter. Come from iBATIS background.)

Take a case where you have a Company object which contains a List of Employees, and each Employee object has List of Address objects and List of Preferences (Address and Preference would be another domain models.)

I obviously don't want to to return some of the nested items all of the time, so lazy seems to be fine for the nested collections, and typically I suppose I should use 'join fetch' to pull back some of the nested items. However, in the Employee object there are two Collections and I've read it's not a good idea (if even possible?) to join fetch two different collections within the same object.

My question is how can I force the lazy loading of some objects so that they are all populated without traversing the entire nested structure and having to call the getter on the lazy fields just to get them populated?

It looks like in Hibernate you can call Hibernate.initialize(yourObject.getYourCollection) and it will initialize the lazy load of the objects, which is bit cleaner than yourObject.getYourCollection.size(). But not sure how to accomplish the same thing with just standard JPA syntax?

Also how does this work if you are nested more than one level and I need my nested lazy collections also populated? (For example maybe I need the whole object tree populated before sending it to the web tier or off to some other business process outside of the scope of my EntityManager.)

Maybe I can manually set the fetch type to Eager for those domain models before performing my specific query? I haven't seen an example of that done though.

Thanks for any help.

I've been googling and could use some advice on how others deal with this. For sake of discourse imagine this Entity (only showing relevant for this example):

@Entity @Table(name = "Person") @NamedQueries( { @NamedQuery(name = "Person.Alll", query="?"), @NamedQuery(name = "Person.AllWithCompany", query = "from Person p left join fetch p.company), @NamedQuery(name = "Person.AllWithChildren", query = "from Person p left join fetch p.children) }) class Person { String name; @OneToMany(fetchType=???) @JoinColumn(name="personId") List<Person> children; @ManyToOne(fetch=FetchType.LAZY) @JoinColumn(name="companyId") Company company; }

Basically sometimes I want everything (including children and company info), sometimes I do not need everything. My question is how to write the queries and set up the fetchTypes to accommodate the different scenarios? I'm not opposed to some n+1 since I understand it's not reasonable to expect it to be able to do multiple fetch joins, but the problem is I don't want to declare any of my fetchTypes EAGER since I don't always want the collection fetched, but if I leave it LAZY, then I'll end up with LazyInitialized exceptions if I'm detached and end up needing everything.

Is the approach to take when needing everything (using this as an example)..
1) get the Person back using the fetch join on Company
2) make another query to the Person entity to get children
3) call the setChildren setter on the parent person (from step1 ) with the children we just got

Thanks for any help in figuring the best practice for this kind of situation, which I would think would come up quite often. Sorry for such a basic question, but the books that I have don't seem to cover this.

As a side note, I've been looking at using Embedded JBoss for my testing, and I have to admit - it's extremely frustrating. The wiki doesn't provide any clear examples. The downloadable application does show some unit testing using it, but it's confusing about what practice to follow and the wiki mentions things not shown in the example code. Also if look online how people are using it, it varies widely (the link to the example you gave Reza for Rob's stuff is cool, but I think it might be sort of outdated?) I'm hearing if you are using JBoss5 things might work differently in regard to what you need to use. Overall, it's just a painful endeavor as is a lot of JEE lately.


Actually as more of a sidenote/rant this is why I'm growing and more and more weary of Java/JEE. There are just TOO many of ways doing things. I suppose this is a blessing and a curse, but I see it more as a curse when developers today "just want to get stuff done." I think this is why you see the allure of things like Rails and even Grails for that matter. It shouldn't take one pouring over wiki entries to figure out the best way to test things.

I'm also thinking of using OpenEJB/Tomcat instead of JBoss5. I'm curious if others have had experience with this combo and their thoughts? (Easy to get setup and running?)

Originally posted by Reza Rahman:
I really think you should give EasyGloss a spin too. You'll cut down on *all* the custom code you wrote...

I've been looking over the usage examples/docs for EasyGloss that you see here https://easygloss.dev.java.net/#usage and I really don't see how this cuts down on custom code at all. It actually looks like I might not more lines of code, but I might be missing something?

The only thing I see it saving is that using easyGloss I wouldn't have to create any setters in my ejbs. (But adding a setter is so simple, that I think that part is negligible.)

In EasyGloss you still need to write all the code to add the ejbs to gloss (ie gloss.addEJB(someEJB). This doesn't seem to save the much over just calling the setter of the ejbs you care about for a particular unit test.

In regard to setting up the EntityManager you still need to do:

JavaEEGloss gloss = new JavaEEGloss();
EntityManagerFactory emf = Persistence.createEntityManagerFactory("fred");
EntityManager em = emf.createEntityManager();
gloss.addGenericEM(em);

which I'd be doing only once in my Base class as well. The difference here is, using EasyGloss I wouldn't need to have to inject the EntityManager manually with "myEjb.setEntityManager(em)" however I'd still have to add my ejb to gloss with gloss.addEJB(myEJB)so it's still one line I'd have to write either way.

I'll look at it some more though.

Originally posted by Reza Rahman:
I really think you should give EasyGloss a spin too. You'll cut down on *all* the custom code you wrote...

Wow *all*, I definitely will be checking EasyGloss out then. I thought I was up on things and yet this is the first time I've heard of it. Thanks.