It's been a while since I posted and after dealing with this horrid bug in Flash I figured it would be a great topic to get me back on track.

So, apparently there's this nifty little bug in Flash/ActionScript with the URLRequest object when you attempt to do a file upload, it uses a completely different browser session than the web browser or any other requests made from within Flash (image loading, sound loading, resource loading, etc.). This isn't a problem unless you care anything about security...and unfortunately most of us do. So the project I'm currently working on uses JCIFS (http://jcifs.samba.org/) for SSO, which is actually very nice by the way, and it uses a servlet filter configured in the web.xml to authenticate the user before they ever hit the page, so by the time they reach the Servlet they've properly been authenticated and I don't have to worry about rogue users.

Okay, so that all works well and good until I try to do a file upload. I try to establish a URLRequest to my JSLServlet (of course this is jSeamless) that I use for everything else, but this time I get a nifty little login prompt using basic authentication. Now, this is of course bad, but what makes it even worse is that Flash simply prompts you and then disregards it and streams the upload into the outer darkness (where there is weeping and gnashing of teeth) so the upload from the Flash perspective worked and uploaded fully (note, before I even enter anything into the login prompt) but the server never receives the upload at all. If I enter my credentials it accepts it and then disappears, but really doesn't care anything about it.

Okay, now for the hack. Now, for you programmers that are faint of heart, don't try this at home. For the rest of us that have to do the job no matter how dirty it might get, please forgive me for what follows...if there were another way I would have done it.

Alright, so I create a new Servlet filter called UploadOverrideFilter (yes, you see where this is going) that gets put in the filter order before the NtmlHttpFilter (JCIFS filter for SSO) that detects if the reference is made to an upload (endswith("jslupload") in my case). Now, what took me a bit of work to figure out is that all mechanism for referencing directly to the Servlet that the filter can pass off to is either barred or deprecated (from ServletContext there are methods for getting a Servlet, but they always return null since deprecation) so I pull out my ugly stick and turn JSLServlet into an evil beast by maintaining a static reference to "instance" that is the initted reference to the currently context JSLServlet instance. Then I simply reference that static JSLServlet instance and explicitly call doPost(...) instead of passing off to the filter chain. See the source code for yourself:

public class UploadOverrideFilter implements Filter {
 public void init(FilterConfig config) {
 }

 public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
  if (((HttpServletRequest)request).getRequestURI().endsWith("jslupload")) {
   JSLServlet.instance.doPost((HttpServletRequest)request, (HttpServletResponse)response);
  } else {
   chain.doFilter(request, response);
  }
 }

 public void destroy() {
 }
}

Yep, it's having to write code like this that will be the death of me...a very good reason why I prefer to stick with 100% Java whenever possible is so I don't have to write hacks like this.

Well, I guess it wasn't as bad as it could have been, but it's still a hack and it's things like this that keep me up at night in the cold sweats.

So I lied, apparently my hackery wasn't enough to appease IE even though Firefox happily worked going forward. Apparently in IE it determines, "Oh, I've been authenticated on this URL before...so lets send broken authentication information instead of an upload", and then no matter what you respond back to the request with it just ignores it an on the Flash side acts like it sends the file (very quickly), but never actually comes across.

So now we must expand the previous hackery to not only ignore authentication on uploads, but we have to send to a different "url" in order to keep Flash from thinking it needs to authenticate. I originally tried doing a variation on the directory structure (ie. /authenticated and /unauthenticated), but it's a tricksy URLRequest and decided that it was the same host so it really wanted to send broken authentication information.

My solution? Make Tomcat listen on another port by adding the following line to my server.xml:

<Connector connectionTimeout="20000" maxThreads="150" port="15000" protocol="HTTP/1.1" redirectPort="8443"/>

Then I told my upload to send to the exact same URL except on a different port. I still had to have my security hackery to keep it from requesting authentication, but that did the trick. Now both IE and Firefox can upload files in a JCIFS protected container and the client is none the wiser...unless of course a firewall is blocking that port for which they are trying to upload to....but such are the hacks we must work with when dealing with Flash.

On a side note I will say that Flex 3 has functionality built-in (apparently they got enough rocks through their windows from 2.01 to make them realize they needed to fix it) to tell it to handle authentication or not via a boolean flag. None of this would have been necessary if they would have had the fore-sight to implement that in the first place, but alas, mine is not to reason why...

My massive hack for native drag-and-drop in jSeamless Flex implementation is functional, but only in Firefox. Apparently there is an interesting "feature" in IE that even though you may sign your Applet and the user grants that they way to trust said Applet, it still never gives you read access to the file system.

That being said, here is my outlined approach for another hack that avoids the use of an Applet in favor of Java Web Start. I know Java Web Start can do what I want to do, but to my knowledge there is no way to communicate directly between the client-side web site and the JWS instance.

1. Load the JWS application that stays hidden


2. Load the Flex content page


3. Listen via JavaScript to the mouse cursor entering the browser window - throw an event to the server upon entry


4. Server sends event back to JWS (either socket or delayed Ajax necessary for both JWS and Flex)


5. JWS application triggers the single-pixel-at-mouse-position-window that is listening for dragging


6. If JWS doesn't receive a drag enter event it goes back to sleep and hides our friendly, yet scary, window


7. If a drag enter is thrown it continues to follow the mouse until either the mouse exits the window (another event thrown by JavaScript to Flex to the Server and back to JWS) or a drop event is triggered in the window.


8. If JWS receives a window exit event it goes back to sleep.


9. If JWS receives the drop event a new event is sent down to the server with the list of files dropped.


10. Server sends an event to Flex requesting the current component the mouse is over and temporarily stores the list of files dropped via a request id.


11. Flex determines the current component the mouse is over and sends an event back to the server with that id.


12. Server triggers internal jSeamless event for file dnd with the list of files and the component id (if the component accepts the drop).


13. Upon server-side accept of a file an event is sent to JWS to stream the file


14. JWS receives file stream request and streams the file to the server.

How's that for evil? I thought the original hack was bad, but this is just downright insane. However, it would seem this is the only plausible way to get native drag and drop support.

I had made the commitment a while back that I was going to add complete and perfect drag-and-drop support to jSeamless. The Flex Implementation proclaims support for DnD so I've just pushed off the investigation up until recently. However, now that I've come to implement this great functionality I realize that there is absolutely no support for native DnD. What I refer to as "native DnD" is the ability to drag a file or any other "draggable" content from outside of the application into the application and allow it to pick up and use that content.

Okay, so I figure I'll just do the same type of JavaScript hacks I've done all along to get missing functionality into Flash. To my surprise HTML/JavaScript has no native DnD support either. At this point I'm not only surprised, but afraid my dream of a beautiful drag-and-drop solution for jSeamless is in danger of never reaching fruition.

So I spent the day brainstorming with a colleague about how this can be done. Honestly, there was never a viable solution that wasn't a massive hack, and what we ended up with was actually far better than expected. The solution consisted of using a signed Java Applet to display a single pixel JWindow linked to the cursor when the cursor enters the browser window, it is able to use this as a check to see if the cursor is dragging a droppable item. If it is not carrying something into the browser it then disables itself until the cursor leaves the browser and re-enters again. However, if it is carrying something it remains locked to the tip of the cursor and accepts the droppable wherever they drop it in the application. This JWindow intercepts the drop event, passes an event to JavaScript, JavaScript passes an event to the Flash content and is handled appropriately from there. The event is assigned an ID that can be referenced back from the Flash, to the JavaScript, to the Applet in order to initiate the download at any point in the future.

Yes, this is a massive hack, but does provide a solution that is quite seamless to the user apart from the nasty, "Would you like to grant access to this application to do whatever it wants to your hard drive?" (okay, so it's a little friendlier than that) prompt that must be displayed for the Applet to be able to know pointer location and be able to actually read the file contents from the hard drive.

Fortunately internal drag-and-drop is quite easy to write into Flex. If all goes well, this will all be finished and useful in jSeamless next week. However, for reasons of the aforementioned "evil prompt" it will be disabled by default and will have to be specified to be turned on to be used.

Today was massive hack day. ;)

Okay, so this probably doesn't par up to the JFK assassination, those crop circles, or how in the world John Locke can survive a bullet in the chest, but it's starting to really bother me.

I developed jSeamless with the intent of "seamlessly" bringing technologies together to make life easier on the developer. However, I'm starting to realize that the people that make these technologies would rather not see this happen. I never considered that anyone could understand the concepts of what I'm trying to do and actually put in some extra effort to stop me. I figured at worst people would just not care and let it pass by without another look, but that's not what seems to be happening.

First Point - Java.net

Now that jSeamless has become much more stable and has the majority of features necessary to release I thought java.net would be the place to go to get some good advertising. So I filled out a form requesting that jSeamless be featured along with an article I had written hoping to get some additional developer interest in the framework. After a couple weeks I e-mailed the editor and asked about it. The basic summation was that it would be a conflict of interest to post anything on their site about jSeamless since it directly competes with Swing because it uses Flash as the reference implementation. Now, I can understand if the purpose of jSeamless was to only do Flash development, but jSeamless is about abstraction and it just so happens the only currently completed implementation uses Flash content. I was told to send them another e-mail when there's a completed Swing implementation...we'll see how that goes.

Point Two - FlexCoders

I hang out on the FlexCoders Yahoo! Group to find answers to problems I'm having with Flex integration into jSeamless and to find out new extensions that are being written to Flex that I might be able to integrate or derive ideas from for jSeamless. I decided to post a message to the group asking for feedback from the Java developers that are also developing in Flex to get some ideas of what features they would look for in an API like jSeamless. I actually got some really good responses, I messaged back with additional information and then suddenly all the posts disappeared without a trace.

There was no e-mail letting me know I had violated some rule of the group or anything. I know the group is run primarily by people that work at Adobe, so I can only assume it had to do with marketing a framework that could take away revenue from their commercial products.

There actually several other scenarios that have had similar results, but I'm really starting to feel a lot of resistance for this system. I never imagined that I was developing something controversial or even something that would get anything worse than indifference about. This causes some problems since I was hoping to get some support from companies like Adobe or Sun in the long-run, but it would seem they don't really want such a project to succeed.

I guess this doesn't really classify as real conspiracy, but it bugs me so I figured I would share my annoyance with the world. :)

No, in a good way. :)

We've been working through a lot of stress testing at work for jSeamless to prove that it can stand up to an unreasonable load only exceeded by getting "slashdotted. We have faired quite well and we're currently working to get the document released for public "consumption". This will be a really great proof of the stability of jSeamless and put to rest a lot of the fears people have of its viability in a heavy traffic scenario.

I generally post a message in my blog after I've already done it, but this time I'm trying something a bit different and posting the idea as a mechanism to draw it out.

In my jCommon project I have Object Pooling support already, but it's explicitly limited to the pooling itself. While developing Galaxies Beyond I'm finding there are some things that would be useful to support in the pooling that would simplify usability in application. Currently you simply get() for an object from the pool and it will create the object if it doesn't exist and hasn't reached the maximum number of objects allowed for that pool or return an object that is in the pool. This works fine in most scenarios, but for more advanced pooling I need to cleanup after an item has been returned to the pool and perhaps re-init certain things when they are actually pulled from the pool.

...okay, after I got done typing all that it dawned on me that I might have already written this before. Sure enough, ObjectPool in jCommon already has support for all of this. Perhaps this should be changed to "How sad is it when you write so much code you end up re-inventing the same ideas over and over again?", but what's particularly sad is I've done this on various occasions. In fact, I wrote similar functionality for ObjectPooling in jME before I remembered that I had already created the object pooling support in jCommon. What makes it even worse is that the code I wrote was better the first time.

I'm 28 years old and if my memory is this bad now, I can't imagine what I'll be like at 80. In my defense I will state that I write thousands of lines of code a week, so there is a LOT that can be forgotten. :)

Yeah, I've done it again. I'm well known for reinventing the wheel and this is no exception.

As I've previously mentioned I decided to write a Multiplayer Sudoku game that you can compete with other players online playing. Well, I sort of got stuck for a while on the puzzle generation. I hate the idea of hard-coding puzzles and pulling from a list when it is something that could be generated. Yes, I did look around for other APIs to generate puzzles, but they either weren't in Java, were very poorly written, or were tied to a UI (like AWT or Swing). Sure, I could have made one of them work, but I decided that if I teamed up with my Wife I could create an awesome API that I could make open-source and then anyone else venturing for such a solution in the future wouldn't have the hardships I had to deal with.

On that note, I've gotten the actual solution generator written. It works quite well generating a solution in about 200 milliseconds on average. I still have to write the puzzle generator that takes into account difficulty, verification that a solution can be determined logically, and that there is only one solution. However, the majority of code I've already written can be reused for most of it.

I'll be posting a link to the project when it's completed so anyone who wants can use it. It won't be too long after that's done that I'll have it plugged in and usable in my jSeamless Sudoku game.

It's a little odd that I'm creating a Sudoku game at all really...I've never really enjoyed playing them all that much, but I do appreciate the logic of the game. My wife is much more interested in it than I am, so I'll just say I'm doing it for her. ;)

I've been trying to think of some good examples of jSeamless that wouldn't take too much time to write, but would show the power of jSeamless and some of its capabilities. To that end I've started developing a multiplayer Sudoku game. The puzzle is generated and displayed to all connected players. As each person provides a correct number they get points and that field is "solved" on all other player's board as well. If you get a number wrong you lose points. A winner is decided by how whoever had the most correct numbers in that puzzle. I'm creating a whole account management system, scoring system, database logging and statistics, and internal chat. This should be a pretty fun game when it's finished.

Here's an early screenshot:

I have to present a prototype in a couple hours that is really important to my job and the company I work for. I think I'm pretty well prepared, but have been trying to go through any last minute details and bug fixes to make sure nothing breaks horribly well I'm demonstrating it.

It's at a time like this that my brain decides to recall a poem I wrote in the third grade. Now, I'm not really sure how I got there, but now that I have I decided I'd write it down because I still like it. :)

Tomorrow is Today, if Yesterday had never been,
Today is a day that will never come again,
Now is the the time that always will be,
Time is the variable, only the mind can see.

Not bad for a third grader, huh? ;) Well, back on track I'm really excited about this demo as it is the largest application I've developed yet utilizing jSeamless and this demonstration is about getting more buy-in for the product, the framework I've written, and jSeamless from the company I work for. Next week I'll be able to start adding massive new features to jSeamless (I couldn't until this demo was completed for fear I'd screw something up).

Anyway, this will hopefully be a short day for me so I think I'm going to go home and spend the rest of the day with my wife...I love Friday. :)

Adobe Flex 2.01 is a very good framework and it is so much better than practically any other web-based UI framework in existence today, but there are so many bugs in the code and so many restrictions that are very difficult to get around I'm locked into a love and hate relationship with it.

I'm using Flex for the reference implementation of jSeamless and it is going quite well over-all, but I'm finding myself re-writing component after component because of either bugs or lack of features. The good thing about this though is that the entire Flex source code is available within the SDK, so I can see exactly what they are doing and how they are restricting me or causing bugs to occur.

My single biggest complaint about Flex is their complete lack of threading "support". That is not to say it is single-threaded. Quite the contrary. Everything is asynchronous in Flex, but thread-safety is an unknown term to the Flex team I believe. There is no way to synchronize, lock, or maintain good concurrency in the system and many a crash has been due to this. In jSeamless I have a full system I wrote to offer some concept of synchronization and though extremely limited because of ActionScript 3 support not being there, it works pretty well.

I'm about to completely re-write the way Effects are called in the Flex implementation of jSeamless because it is causing errors to occur and also offers no way of disabling effects. I'm a Java developer and writing in ActionScript 3 is really not my idea of a good time, so every line of code increases my frustration.

On the bright side, jSeamless has far exceeded the capabilities of what Flex can do because of its "flexibility" and for that I'm extremely thankful.

I know that seems like a strange question to ask, but it's one I often ask myself. In many ways I've been extremely successful throughout my life, and it occurs to me that many of those successes were good successes, and many of them were bad successes. Most of the time it's easy to tell the difference. Sometimes, however, it's very difficult to discern.

I've been feeling this way recently regarding jSeamless. I believe it's one of the greatest development endeavors of my life thus far and have no intention of abandoning it, but it is now beginning to develop a following of users, which is great, but the majority of these users simply use the API and then post when something is missing or broken. Don't get me wrong, I have no problem with this, but I'm getting extremely bogged down with providing functionality for these users instead of them helping and committing to the project themselves. I believe in the long-run it will get better and eventually I'll have some strong developers that are willing to help. For now though, it's draining to spend all day at work writing code to support them, and then coming home and writing code to support the jSeamless community.

I guess a project has to catch on at its own pace, I just wish there were more people interested in helping. jSeamless is becoming a large project and I'm just one person. I often brag about how much this one person can do, but I realize as well as anyone that my limitations are definitely there.

It saddens me these days to see so few programmers that question the way things are done and simply accept as the best way to do things what is considered to be the standard. I fear innovation is being lost in this generation of developers since instead of questioning and trying to make new and better ways to accomplish tasks they simply take what is "standard" and conform to it.

Someone told me the other day, "I come from the school of thought, there's nothing special about me", and I think that's becoming more and more the norm. If everyone approached technology this way we could never move forward. Innovation is necessary for advance and the programming community is one of the most necessary places for this to occur. We become too comfortable with the coding practices of today and since we aren't forced to push beyond, we settle to what we know.

To be honest, this is not something I've considered to be a problem until I started working on the implementation in jSeamless of it. Servlet Sessions are just fine for the majority of web applications but I began to realize that they are inherently flawed conceptually. The first problem is that multiple tabs in a browser (even multiple windows in Firefox) rely on the same session. If you are trying to replicate functionality like a regular desktop application this is problematic.

Have you ever opened up two instances of Notepad? Did you ever dream that the second instance would be using the same session as the first? Why should this be the case in web applications?

I've said this before, but companies push their developers to write web applications that mimic functionality of a desktop application. Why do they do this instead of just deploying applications to their users? Well, there are still a few good reasons for this, but internal applications there's no other reason than it makes management happy that they can add "web" to everything. Yes, I'm probably shooting myself in the foot proclaiming such things as the majority of jSeamless' success is because it is so powerful for web applications. This is actually the primary reason I created it. I'd personally much rather be doing application development and with jSeamless now I can.

Back on topic, I realized that determining "session" based on what window was open was practically impossible to do as there is no good way of determining any sort of window or tab id that differentiates it from another. However, by forcing immediate redirects to a generated id in the URL it does allow me to do so. Yes, it's sort of jumping back in time to pre-cookie days, but it's really the only way to go. This does have some nice advantages though in jSeamless. First, it allows bookmarking of a "session" and reconnecting to it later and picking up where you left off. Second, it does allow good differentiation from one session to the next. So if you open a new window or tab you can reliably create a new "session" for the web application you're connecting to. This is implemented now in jSeamless and will be coming out in Beta 4, so we'll see how well received it is. :)

There has long been a problem with getting information from the server to the client real-time in web applications. There are several hacks out there for making this happen, but most of them revolve around some idea of polling or server push.

These have significant flaws and a while back I sat down to come up with a better solution. I believe I've done so, and I've called it "Delayed Ajax". Now, the name might lead you to believe that it's going to be quite the opposite of real-time, but hopefully I can explain this well and you'll see why I chose the name and why it is the best option for server to client communication available without going to a pure socket connection.

This is actually an extremely simple idea and perhaps others have been doing it for years, but after a lot of searching I have yet to find anyone (correct me if my google skills are lacking) that has been pushing this idea. The idea is founded on Ajax polling, but with a slight twist. The draw-back with polling is that you either poll very fast and create a lot of wasted bandwidth, or you poll slowly and messages from the server to the client are very slow to arrive.

Okay, so here's the twist. Instead of the client polling, the server immediately responding with message(s) or nothing, the client processing and then waiting a few seconds and doing it again, I put the wait-state on the server instead. The client essentially sends an Ajax requests and forgets about it. The server accepts the request and if there is anything waiting in the queue to go to the client it immediately returns. However, if there is nothing in the queue there is a timeout period (typically around ten seconds) that it holds onto the connection without returning anything waiting on data to come through. As soon as anything hits the queue it immediately fires it out to the client and returns. This gives perfect real-time Ajax communication from server to client The client has no waiting, it fires and forgets but when the callback gets hit it will process the data from the server and then immediately fire again.

In my case I'm handling the server-side aspect with a Servlet, but this can be handled in practically any server-side language that supports multithreaded requests (since multiple requests have to sit idle in a thread waiting for data into the queue).

I've long procrastinated setting up a blog, but since I'm being bombarded by ideas in my head and my forum posts are becoming more and more off-topic I've decided to set up a blog for my random ideas and rants to at least get them out of my head.