Wednesday, 8 February 2012

JBoss AS 7 here?

In a previous post I promised to make a review for a book about JBoss AS 7. At that time I still didn't dig into it, and didn't know that our latest NetBeans IDE (7.1) still does not support the seventh generation of JBoss servers. You may see some informative rant going on here. And to be clear - hacking to simulate support thanks to the configurations of the 5-th or 6-th versions wouldn't help. JBoss 7 is completely redesigned to be modular. So the default support (unsurprisingly) comes from the rival - eclipse ;)
While we're waiting you may actually read the book, because it is a good one. If you need first to read the review, it is here on my other blog.

Tuesday, 17 January 2012

Be careful when using NetBeans on DropBox

My recent experimentation with the cloud service took me to a revelation that says: "Well you should've known better!" At least I should be more careful setting up my system. Especially when being aware of the nature of things, but still let myself be sloppy. 

It cost me some precious time and puzzled, achy head, but at the end the situation is already crystal clear to me.

I was trying to run NetBeans with portable JDK - both tools in the DropBox folder. It constantly refused to run saying it couldn't find a proper JDK.
At some point I decided to go with absolute paths in the netbeans.conf file. I did it very simply by defining in all my environments the variable $DROPBOX_BASE (with the actual corresponding value for every system of course). No more misty relative paths.
Still I didn't have success running the IDE. Hmm!

These days I'm experimenting with the new JBoss AS 7. Well taking the same approach there, the result that followed is obvious - the JBoss complained  that it can not find a proper JDK unless I show it its position on the system with the --jdkhome command line option. Getting the same result after using the option in question, puzzled me the most. But it didn't take long until I realized that something wrong should be happening with some executable bits. Again some time and googling passed until I remembered that on the current (Linux) system I placed the Dropbox folder on NTFS partition, which was never even designed for the idea of executable bits being set as permissions. 

So, my conclusion: when using DropBox on Linux, never set its folder on partitions designed for Windows OSes. You might still sync properly, but successfully executing binaries from it is very unlikely. 
Touché!

Tuesday, 10 January 2012

NetBeans 7.1 is here and ...

The official announcement came almost a week ago and for me it almost coincided with another event. The guys from PACKT Publishing gave me the chance to review another one of their books.

First about the IDE:
May be the release notes would be more informative than the official announcement. At least it contains all the possible links you might need along with the latest top features presented visually. Of course there is this video presentation, which is worth watching.
It seems this time the focus is on JavaFX. Its 2.0 version is covered in a way that makes its applications' configuration and deployment easy and complete - it seems you won't miss a feature here. 
From the other features presented in the video the most attractive seemed the visual debugger, the batch and selective rectangular re-factoring and the enhanced maven integration.

Once I have more time to make some stuff with it, I'll report. Which leads me to the second point - the book:

Going through this book is a nice opportunity to check the new architecture of the revamped JBoss Application Server. I guess (and hope) it will have some in-depth tweaks. Scrolling over its TOC increased my appetite seeing topics like clustering, security and cloud leveraging. I'm anxious to start it, so I'll say no more in this post.

Sunday, 4 September 2011

Developing "in the cloud"

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.

Friday, 19 August 2011

Another way to be portable - part II

So, NetBeans stack (with servers) portable through DropBox - sounds quite possible. After all PortableApps can be used this way. But what's to consider first? Here's the list (it's not long at all):
  • Will the free account's box size suffice? Yes, it will, even for a full install (with the two app servers). And I guess there'll be a little bit more space for some small projects, etc.
  • What if utilize multiple platforms (Windows at work, Linux at home, and Mac on the move)? Well fortunately the IDE still has the "OS independent Zip" on the download page, but as you can see there, this option comes without the servers. The servers are completely different story, for another post.
  • And should I put the JDK also in the DropBox? If so, should it also be platform independent? Hm, friend, this is Java you know! And I think, we've already been through this :)
Maybe these are all of the preliminary considerations, so I dive in ....

Downloaded the OS independent ZIP for the latest (currently 7.0.1) version (242 MB archived, and around 470 MB extracted to a DropBox sub-folder). With my connection, it uploaded to the central server for around half an hour.
For further examinations lets name the path to the DropBox folder as DB. So if the IDE is extracted to DB/netbeans, the adventure starts from the DB/netbeans/bin folder (I believe you can easily figure out the corresponding Windows paths). In this folder there are only two files - the executables for the two major platforms. Since the IDE is configured by default to search for the java installation existing on the system, if such exists, the IDE will run. If only JRE is installed, it might run, but it surely won't compile your projects and it will complain about it. Of course, the access to a java installation can be configured, but I don't think there is a point in repeating myself. Everything said in that post still applies.
I would only add that if you use a portable JDK, you might tweak it, to make it slimmer. This means that bin, jre and lib folders will suffice. Another detail is that you might have to gather the executable files from different platforms in their corresponding sub-folders in order to be fully portable. Actually it is all a matter of taste and context. All environments that I have DropBox on are Linux, so I don't need portable JDK. In that case I only have to take care that on every environment I use compatible JDKs. For example if on Env1 I have installed JDK 1.7, the Env2 which has by default (from repositories) JDK 1.6 the projects might become in conflicted state. This might not happen for different updates of the same version of the JDK, but for a different versions of used application servers the conflict is certain. So the journey continues.

I don't know how close, but this installment looks to me similar to an IDE on the cloud. I accept every suggestion that might reduce the distance between the reality and the idea.

Sunday, 7 August 2011

Another way to be portable

Few months ago I found DropBox. I almost immediately started using it as holder of some sample NetBeans projects. Its seamless integration with the host OS and immediate synchronising of the project files amazed me. These guys have done a wonderful job. I know they are being criticised about security and privacy matters, but if you get to become paranoid about your sensitive data why use Internet at all?

At first I didn't think of it as a variant of portability - actually portable are only your projects, and not the IDE. This in fact is more similar to a very simplified one-user-version-control. And for small projects I guess I would be happy with it. I would call it cloud portability, but it still would be about the projects.

And there's the idea - what if I installed the IDE in my DropBox folder? There are few drawbacks that come into my mind:
  • It would take up most of my original 2 GB quota. This is not the greatest concern - I could invite some friends or at some point I even can go for a paid account.
  • Performance. May be this is the biggest (as usual) concern. But since the IDE is copied on every HDD I installed DropBox on, it will be ran form a hard drive and not from a flash drive. This leads me to the next concern.
  • Synchronised environments. In order for the IDE to work at all I'll have to use the same classpaths for the JVM and the libraries. And may be at some point even for any servers. I know your next question - why not install everything in the DropBox folder? It seems tempting. Something bothers me here. I'm not very sure what exactly it is, but I'll figure it soon. May be the best way to find out is to just do the thing and watch it how it moves.
One thing is certain - installing the IDE will be as slow as your bandwidth. I mean, not installing it on the local hard drive, but sending it to your other PCs. Well this is not a real worry - DropBox does the transfer, not you. And if your remote PC is online, once you get there you'll might already have the IDE on it.

I'm kind of tempted to do it, but may be after some more considerations.

Significant events


I am an occasional blogger. So here is the occasion. A big one. Actually there are three interconnected events:
  1. Oracle finally released the latest (7th) version of the standard edition variant of the prominent Java programming language's SDK. The tech related part of the web is all boiling with the fuss. Use it! Don't use it! There are severe bugs in the JVM. There's nothing scary about the bugs - they'll be fixed before the JVM is adopted in production. The new syntax enhancements are great. There's not enough new features to the language. Etc., etc., etc. It's always been and will always be a work in progress - there'll always be hideous bugs lurking in the code invisible, until the rarest never-met-before conditions bring them to the light. It's OK. Bugs, features, fallacies - its' all part of producing software. Any kind of software. Even great meta-software like Java. Since the engine is here, where's the new chassis so we can utilize it for a nice smooth software development drive? Here it comes.
  2. Oracle released the 7th version of the NetBeans IDE some time before the official release of the Java SE 7 SDK, so after the first event on the list, they had to release the NetBeans 7.0.1 with the required official support. Game on! The IDE is ready for download you very well know where from. I wish it was available in the Ubuntu repositories also, but I don't think this will be an option soon.
  3. A book. You didn't expect this, right? In fact it is a very nice book about how the IDE eases the development of Java 6 Enterprise applications. I won't tell more about it right now, because I'm in process of going through it, in order to make a full review. So, with no more distractions, I'm diving back to Mr. Heffelfinger's thoughtfully organized and narrated set of screen-shots. Here's the cover to just whet your appetite:

All the three events are pretty significant for the NetBeans users. The tool of the trade was upgraded and on the other hand there is a concise source of some background information for the developers.
A review to come. See ya ;)