Monday, June 30, 2008

J2Free 0.1 Alpha Preview

A couple months back, I wrote a post titled Java Complaints and Introducing the Redemption of Java: J2Free, in which I laid out a few of my complains about Java and introduced a new project, called J2Free, that Arjun and I had begun. Well, development of J2Free had stalled for a month or so while I was out of town and working on revamping an older site. But, much to my great pleasure, we now have the first previews of J2Free to show.

Today's preview is of the entity administration portion of the project, which uses a heavy amount of reflection to analyze the structure of persistent entities and expose a CRUD interface into your persistence layer without you ever having to write a line of code. For now, the only supported persistence provider is Hibernate. After including the J2Free jar, as well as the JSPs/CSS/JavaScript files, you can begin browsing and editing the entities stored in your persistence layer through a web interface.

Here's a view of the J2Free Entity Administration section when first loaded. The entities are listed in tabs across the top.


After clicking on a tab, the available entities of that type will be loaded via an AJAX call and populate a list along the left. Entities are loaded in batches of 100 for now, with an option to load more.


Selecting an entity on the left will open that entity for editing in form that is dynamically generated based on the fields within your entity. Read-only fields are set as such, and x-to-x mappings to other entities are represented by entity 'boxes'.


Editing a single-entity field, or a collection of entities is done via a third column, the entity browser. From there, entities can be dragged and dropped between a field and the entity browser column. Click save will save any changes, and clicking delete will delete the entity.


Any entity can be clicked to display that entities properties in read-only format (to keep confusion about which entity is being edited at a given time to a minimum).


At the top of the left-side entity list is a New button that will create a new instance of any type of entity and present you with the same form used for editing entities to populate the fields. New entities are not persisted until the saved from the edit view.

There's a lot that needs to be done; including improving the visual display of entity associations, editing one-to-many associations, proper display of embedded IDs, and improvements to handle larger amounts of entity types and larger quantities of entities. Additionally, there are plans to auto-generate Lucene indexes (with Hibernate search) on String fields to allow searching of all entities. I also want to include a box for submitting custom queries (in JPQL) that will return the results in the visual entity form.

Got a long ways to go... but it's far enough along now that it has become functionally useful to me! The most exciting part is that the reflection necessary to create an entity administration CRUD interface into a persistence structure with no knowledge of the composition is the basis of a lot of what will follow, including access controlled operations that can be exposed as components within a consumer facing site and a fully-functional REST API. Imagine that, creating an API into your site as easy as setting api.enabled=true (or for more fine-grain control, setting api.enabled.classes=com.mysite.dao.*). Excited yet?

Friday, June 27, 2008

LivePipe UI

I love Prototype, have since the day I discovered it.  Today, I found something equally awesome.  LivePipe UI, where have you been my whole life?

Thursday, June 19, 2008

Adobe Flex + J2EE Security - Mismatched SessionID!

So get this.

I have a servlet called FileUploader. It takes a multipart/form-data request and proxies the file to S3. At the same time, it records some data in our database regarding the user, filename, and so forth. Simple enough.

I have a Flex 3 application that acts as a file chooser on the client side. It propogates a FileReference, which is then submitted to my FileUploader servlet via a URLRequest. Again, straight forward.

My Flex application lives in a JSP mapped to /upload. I have used declarative security to protect /upload for all HTTP methods. I have a servlet that sets a User object, containing attributes relating to the current user, to the session a after successful login, so that the User bean will be available to the FileUploader servlet.

Here's where it gets interesting...

I go to /upload and am redirected to the login page. I login and am redirected back to /upload. The JSP at /upload outputs some information from the User bean stored in the session (verifying that the bean is set correctly) as well as the JSESSIONID and the Flex application. Great so far. I use the Flex app to choose a file, which is then submitted to the FileUploader servlet. The FileUploader servlet gets the HttpSession from the request and logs the JSESSIONID. Check it the result:

JSESSIONID from the JSP: f8e64a4e62840010b6067470a346
JSESSIONID from the log: f8ec7389408a60103998c6bb75f0

WHAT!?!?! How did that happen? Is the Flex application identifying itself to my server as a different user than the browser? How can this be? The Flex documentation states that flex applications will use the underlying browser state when interacting with J2EE declarative security.

WTF Adobe? Am I surprised that it is not working according to the documentation? Not in the least.

Whenever development is going well, and especially when ahead of schedule, some Adobe product will ruin the fun. Don't believe it? Google for the Flash External Interface bug where subclass field values will "float" up to their superclass if the superclass and subclass both have a field of the same name... drove me crazy last fall...

Wednesday, June 18, 2008

Fantasy Congress Redesign

Just pushed out a redesigned Fantasy Congress today... check it out.

Netbeans 6.1 UI Freezes

Just the other day I decided to finally try out Netbeans 6 for real. I've tried out the various betas and release candidates for V6 over the past year or so, but each one has had some major flaw that severely limited by productivity. I figured that by 6.1 the IDE would be stable enough, but alas it is not.

Randomly, the UI will freeze up. It can happen 2 minutes into using the IDE or 6 hours into use. Sometimes it happens when I click on something, other times it happens without my input at all. In all cases, the IDE becomes non-responsive to input, but apparently still responsive enough to not show up as non-responsive in Activity Monitor. I've tried letting the IDE sit for up to 30 minutes to work itself out, but that did not help. I just end up force-quitting randomly throughout the day. Extremely frustrating.

I'm tempted to pull a Windows and revert to Netbeans 5.5, except that I put a great deal of time into customizing Netbeans indentation, syntax highlighting, etc when first setting up 6.1 and I don't want to lose those changes.

Sure, even Netbeans 5.5 was slow at times, but on the whole I find the UI of 6.1 to be far more sluggish and delayed. Ah!