To continue from the last two posts and driven by curiosity, I decided to see if a DropBoxed GlassFish application server (along with its built in JavaDB database) will be able to complement the dropboxed NetBeans IDE I already use on three Linux systems.
As a little detour I must state that these Linux systems are such that I have complete access over them. If I had to work in a more mixed environment (e.g. in Windows or in any system without administrative privileges), I would still use OS independent packages, but I would use a USB flash drive as a carrier. It doesn't seem appropriate for one to utilize the service on a machine that is publicly shared. It comes to my mind that going hardcore, could make you try to install a DropBox on the system in question (whether I doubt it is possible without administrative privileges) and as synchronized folder to use one on a flash drive. But I have the impression that, at least currently, the DropBox service is not intended for such loose usage.
So! GlassFish. OS independent ZIP archive. Extracting it somewhere under the DropBox root folder completes its installation. It takes some minutes (or maybe hour, or two) to propagate, but as usual, this has never been a concern.
Now - configuring and running seem to be more interesting. Adding the server in NetBeans under the "Servers" node is nothing special. You just point to the installation directory, where the ZIP was extracted. If you need to, specify a custom domain different from the default domain1 and that's it. NetBeans knows all the rest. If you start it from its node with the context menu, in a few seconds, you'll be able to access it in a browser. Of course it still needs certain configurations, so that not everybody has access to the administration console on port 4848, etc.
One good way to test the installation is to test it against the Quick Start Guide. If we say that the installation directory for the server is marked GF, the guide in question is the file:
GF/glassfish/docs/quickstart.html
It opens in a browser and explains with examples, what commands can be issued in the command line in order to make the administration tool do the right job for you. The tool is called asadmin and it starts the desired domain (or simply the default) and the database. In Linux the absolute and the relative paths should work the same way.
Another good testing method is to run through some tutorial, and what would be better than this one.
While taking it, it is interesting to observe what's going on in your DropBox. May be the most beautiful part is that the both entities - the syncing service and the development stack - just work. The development stack behaves like it exists in a usual file system, like it actually is. The service rapidly synchronizes the bunch of small files that are created and/or modified during the development process - changing configuration files, writing to log files, deploying the different types of Java archives to the domain sub-folders of the server, etc.
Opening your "Events" page on the DropBox web site you'll see something like this:
This of course is not the full list, but as you can see the more details are easily accessible by clicking the appropriate link:
I read some time ago a question on StackOverflow that someone had trouble running the JavaDB database after installing the GalssFish server in his DropBox folder. All I can say is that it worked in my set of environments from the command line. But just because NetBeans is good enough to manage a development environment on its own, I use it for the same purpose. Registering the application server with the IDE is the only required step - as a consequence it manages the built-in database pretty well. And after running the examples from the FirstCup tutorial on one of my machines, I could very easily review exactly the same data on every other machine registered with the syncing service:
I heard some categorizations that DropBox is a "cloud service". I don't know if this is a fair comparison, because cloud computing although becoming better and better defined every day, still has some vague boundaries. Despite that the feeling when working with my mirrored and aptly synchronized small-project-sized-single-user-development-environment is like I have one computer everywhere I go. I guess at least this is what the Coluds are trying to achieve. So if we're already there, there's nothing left but to wait and see what will be the next challenge.
Once I have more time to make some stuff with it, I'll report. Which leads me to the second point - the book:
