Thursday June 30, 2005
Thursday June 30, 2005
Brand New Tutorial: Embedding Components in the NetBeans IDE
Embedding a component in the IDE is something I've discussed in a few blog entries a while ago. Now there's also a tutorial available. You start with the Anagram sample, which is the standard J2SE sample that is shipped with the IDE. (To have a look at it, press Ctrl-Shift-N, expand Samples, then General, and then select Anagram Sample. Click Next and then Finish.) During the tutorial, you learn about a few of the NetBeans APIs and you acquaint yourself with the new GUI support, such as wizards, for NetBeans plug-in development.
At the end of the tutorial, you've transformed the Anagram sample so that it is docked within the explorer mode (i.e., where the Projects window and Files window are also found) in the IDE (click to enlarge):
Feedback on this new tutorial (which, like the other plug-in tutorials, is in a draft phase) is, as always, more than welcome.
Here it is: NetBeans Anagram Game Plug-in Tutorial
Jun 30 2005, 08:18:14 AM PDT Permalink
3 Comments
Wednesday June 29, 2005
Interested in reviewing a NetBeans tutorial?
Recently I reported I'd completed a tutorial describing the creation, installation, and sharing of NetBeans IDE file templates. At the end of the tutorial, the New File wizard includes a new template category and template type, as shown below:
I've received several comments from various people and now have a 2nd draft of the tutorial available. Here it is: NetBeans File Template Plug-in Tutorial. If you're interested in giving this tutorial a quick review, all you've got to do is click the link and browse through it. You can give it a more thorough review by downloading NetBeans IDE Dev and building the file template as described in the tutorial. Either way, comments from the wider Sun community would be highly appreciated!
Jun 29 2005, 08:08:00 AM PDT Permalink
Tuesday June 28, 2005
Sequencing the File Templates in the NetBeans New File Wizard
I've made some progress in understanding how file templates work. The most interesting thing so far was discovering, yesterday, how to sequence categories in the New File wizard. I applied the same principle today while creating the basis for file templates for each of the test cases supported by Cactus. By default, file templates are listed alphabetically. This means that in the screenshot below, the "Java Package" template should come above the "Servlet Test Case" template.
However, by adding this line right above the declaration of the Java Package in the layer.xml file, I specified that it should appear after the "Servlet Test Case" template:
<attr name="ServletTestCase.java/Package.shadow" boolvalue="true" />
In some ways, it's a very small detail. In others, it's pretty cool to know how to do it.
Jun 28 2005, 07:55:09 AM PDT Permalink
Monday June 27, 2005
Control That NetBeans File Template Category!
In the New File wizard (Ctrl-N) there's a JUnit category containing JUnit tests. As pointed out today by John in his blog entry More Testing EJBs with NetBeans, Cactus and JUnit are closely related. Hence, if one were to create a plug-in containing Cactus tests, where better to put them than in the same category in the New File wizard as where the JUnit tests are found? But you wouldn't want that category to be called "JUnit" anymore, right? And you'd probably want the category to be right below the Java Classes category. At the end of the day you'd want the structure of the categories in the New File wizard to be something like this:
So, here are the things I needed to do in the layer.xml file:
- Hide the existing JUnit category:
<folder name="JUnit_hidden" />
- Put the new Java Test Classes category exactly where you want it to be -- after Java Classes (the localized string for "Classes") and before Java GUI Forms (the localized string for "GUIForms"):
<attr name="Classes/Java Test Classes" boolvalue="true" /> <attr name="Java Test Classes/GUIForms" boolvalue="true" />
- Create the new Java Classes category, insert the new Cactus category and copy the old JUnit category below it:
<folder name="Java Test Classes"> <folder name="Cactus"> </folder> <folder name="JUnit"> //JUnit template content from junit\src\org\netbeans\modules\junit\resources\layer.xml </folder> </folder>
That's it! And then you'll end up with a Java Test Classes category, right below the Java Classes category, containing subcategories for Cactus and JUnit.
Jun 27 2005, 06:05:48 AM PDT Permalink
Sunday June 26, 2005
Brand New Tutorial: File Template Plug-ins
There are different ways to create file templates in NetBeans IDE. One way is to right-click a file in the Projects window (or Files window) and choose Save as Template:
The Save As Template dialog box then pops up and you can select a category where the file template will be stored. Then, in the New File wizard, you'll find the template in the category where you stored it. However, what if there isn't a category that suits your template? What if you want to choose a different icon for your template? What if you want to add a description to the template (the description is visible at the bottom of the New File wizard)? And, most importantly, what if you want to share the template with your colleagues? It would be much easier if you could quickly create a plug-in that contains your template -- so that you could send it via e-mail (or place it on a shared server) to whoever needs it. The recipient would then be able to install the file templates using the Update Center. The file templates would end up in the New File wizard, just as if they were a standard part of NetBeans IDE:
Well, all of that is possible (as described in Create File Templates for NetBeans Module Development). However, there's now also a (DRAFT!) tutorial available.
Here it is: NetBeans File Template Plug-in Tutorial
Just imagine how cool it would be to learn about, for example, Cactus -- and to then create file templates that contain comments explaining how each of the methods work, which you can then share with your colleagues. Another area where this would be cool is to create Wicket templates, again with comments, which you can then send to others for re-use.
As with the other plug-in tutorials, this tutorial is at a very early draft stage -- neither the software described nor the procedure outlined reflect the final version of NetBeans Plug-in support for the next release. However, things are definitely stable enough to do some relatively simple things -- such as creating a file template plug-in. Plus, going through the tutorial will get your feet wet -- there's a lot more plug-in support on the way, so get on board at an early stage and your feedback will make a difference right from the start.
Jun 26 2005, 06:10:38 AM PDT Permalink
Saturday June 25, 2005
Brand New Tutorial: NetBeans Server Plug-ins
As mentioned in Create Your Own NetBeans Server Plug-in Module, I've been working on a tutorial that explains how to create your own server plug-in for the NetBeans IDE. No longer are you limited to the server plug-ins made by others -- you can just go ahead and make your own now. Or, if you're not completely happy with someone else's server plug-in, you can tweak and fiddle with theirs as much as you like.
Here it is: NetBeans Server-Skeleton Plug-in Tutorial
Note, though, that this tutorial is completely new and is therefore far from complete. It is a draft, a work in progress. Do not expect perfection. On the other hand, a complete code sample is provided -- you can download it, look at it, learn about it from the tutorial and the NetBeans API List, and find out how everything relates to each other. Of course, any -- and all -- comments would be highly appreciated (a feedback link is provided) -- the bottom of the tutorial provides a small table with current known issues and more will be added as comments come in.
For other tutorials on NetBeans plug-ins, see the NetBeans Developer Tutorials page.
Jun 25 2005, 08:24:33 AM PDT Permalink
Friday June 24, 2005
Help! Three web.xml Deployment Descriptors!
In Plant Cactus in NetBeans IDE 4.1, I explained how to use Cactus to test servlets deployed to Tomcat. In the second step of the procedure, I showed entries that need to be specified in the web.xml file for the Cactus servlets ServletRedirector and ServletTestRunner.
However, in which web.xml file should you put those entries? When I wrote that blog entry, my assumption was that the only web.xml file worth considering is the one that is part of your web application. I was wrong. As Petr Pisl pointed out to me in an e-mail, there are two other web.xml files, each of which could conceivably include servlet mappings. So, as a reminder to myself, and possibly as a help to others, here is a quick run-down of the web.xml files that you have available to you, followed by an explanation of the impact of the location of the web.xml file:
- ${project.dir}/web/WEB-INF/web.xml. Only used by the project in ${project.dir}.
- ${netbeans.user.dir}/jakarta-tomcat-5.5.7_base/conf/web.xml. Used by all projects that use ${netbeans.user.dir}; usually, this means all projects on the local machine.
- ${netbeans.install.dir}/enterprise1/jakarta-tomcat-5.5.7/conf/web.xml. Used by all projects that use NetBeans IDE installed in ${netbeans.install.dir}; possibly, this means everyone sharing the installation at ${netbeans.install.dir}.
As you can see, the order in which the web.xml files are listed above reflects the impact which each of them has. The web.xml file in your project affects only that project, while in ${netbeans.user.dir} it affects all projects on your machine. Only if you want to share deployment settings with other users would you change the web.xml file in the ${netbeans.install.dir}, if the machine in question is being shared with other users.
While using Cactus, though, I'll be changing a single project's web.xml file much less, because most changes I make to web.xml file for Cactus are useful for other projects too. Therefore, I'll be changing the web.xml file in my ${netbeans.user.dir}, from now onwards. (Plus, when you move your application from a development server to a production server, you'd need to remove Cactus servlets from your project's web.xml file, if they are there. This also applies to the use of the HTTP Monitor for servers that are not bundled with the IDE -- so I used the wrong web.xml file in this blog entry.) On the other hand, since my machine isn't shared with other users, I might as well use the web.xml file in my ${netbeans.install.dir} -- this way, the changes to the web.xml file are not lost when I delete my user directory...
Jun 24 2005, 03:18:53 AM PDT Permalink
Thursday June 23, 2005
Struts & JSF Support in NetBeans IDE
In a preview build of the next release of NetBeans IDE, you need only select two checkboxes in the New Project wizard... and... then... all the libraries and configuration files for Struts and JSF are included in your project:
Jun 23 2005, 11:07:14 AM PDT Permalink
Wednesday June 22, 2005
Plant Cactus in NetBeans IDE 4.1
Cactus is the current cool thing, everywhere you go you hear about it. Well, anyway, everywhere I go, which doesn't say all that much since I only leave the building to teach English. Nonetheless, according to a JavaOne presentation I've been looking through, it's "a simple test framework for unit testing server-side Java code (Servlets, EJBS, Tag Libs, Filters,...)". I've been working through the process of setting Cactus up in NetBeans, and using it over Tomcat, so that I can find out what all the buzz is about.
So, as a quick preview, here's what I ended up with at the end of the procedure:
And here's a brief run-down of the procedure for testing servlets (it assumes you've already got a web application):
- Get the Cactus software. Download it here. Then, once you've unpacked and unzipped everything, do the following to set everything up:
- Make Cactus JARs available to Tomcat. Copy the Cactus JARs into Tomcat's common/lib folder. (Don't worry about servletapi.jar though.)
- Make Cactus JARs available to your IDE project. Add the JARs you copied to Tomcat's common/lib to your application's Compile Test Classpath. (Right-click the project, choose Properties, click Libraries, and add them to the Compile Tests tab).
- Make the Cactus report formatter available to your IDE project. Go to http://jakarta.apache.org/cactus/misc/ and download cactus-reports.xsl. Put it in your application's test folder.
- Modify web.xml. Add servlet definitions and mappings in web.xml for ServletRedirector and ServletTestRunner:
<servlet> <servlet-name>ServletRedirector</servlet-name> <servlet-class> org.apache.cactus.server.ServletTestRedirector </servlet-class> <init-param> <param-name>param1</param-name> <param-value>value1 used for testing</param-value> </init-param> </servlet> <servlet> <servlet-name>ServletTestRunner</servlet-name> <servlet-class> org.apache.cactus.server.runner.ServletTestRunner </servlet-class> </servlet> <servlet-mapping> <servlet-name>ServletRedirector</servlet-name> <url-pattern>/ServletRedirector</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>ServletTestRunner</servlet-name> <url-pattern>/ServletTestRunner</url-pattern> </servlet-mapping> - Copy or create Cactus test classes. Copy classes and their related test classes from the Cactus distribution to your own application's folders. For example, get SampleServlet.java from samples\servlet\src\java\org\apache\cactus\sample\servlet and put it in a package in your Source Packages and then copy TestSampleServlet.java from samples\servlet\src\test-cactus\org\apache\cactus\sample\servlet to a package in your application's Test Packages folder.
Alternatively, assuming you know how to do it, just create your own Cactus test classes.
- Modify your Ant build file. Now you'll need to add the following to your build.xml Ant script:
<target name="-post-compile-test" depends="run"> <copy todir="${build.web.dir.real}" file="${test.src.dir}/org/me/hello/cactus-report.xsl" /> <copy todir="${build.classes.dir.real}"> <fileset dir="${build.test.classes.dir}" excludes="**/*.java"/> </copy> <input message="Which file do you want to run?" validargs="TestSampleServlet,TestSampleServletConfig" addproperty="testfile"/> <antcall target="run-cactus-test" /> </target><target name="run-cactus-test" depends="run-deploy,run-display-test"/>
<target name="run-display-test" depends="run-deploy"> <nbbrowse url="http://localhost:8084/CactusTest/ServletTestRunner?suite=org.me.hello.${testfile}&xsl=cactus-report.xsl"/> </target>
Now, when you select the project's node in the Projects window, and then choose Run > Test, you're prompted to select the class that you'd like to run. When you do this, the testfile property is set, specifying the test class that Cactus will run. And then a nice report is produced, using the cactus-report.xsl file, which gives it a friendly structure (click to enlarge):
Jun 22 2005, 04:27:04 AM PDT Permalink
Tuesday June 21, 2005
Tip for Really Really Lazy People: Search Google from NetBeans
So, let's say you're really really lazy. You're doing something in the Source Editor. For example, you're trying to work out how to write an Ant script that generates a server certificate for SSL support. You're not sure about all the arguments you need, so you'd like to Google around a bit. So what you'd do (remember, you're really really lazy) is this:
- Use your mouse to select the code you'd like to google:
- Choose File > Print to HTML from the main menu:
I only found out about the above menu item quite recently. I'm sure there are quite a few interesting uses for it.
- Select everything in the dialog box:
- When you click OK, the selected code opens in a browser. Now make another selection within the code that you previously selected and then right-click anywhere:
- Configure a security realm on the Sun Java System Application Server. (Or on whatever J2EE 1.4 application server you use for deployment. No, Tomcat is not a J2EE 1.4 application server.) For the SJS Application Server, you need to start it and then right-click its node in the IDE's Runtime window and choose View Admin Console. Under Configuration > Security > Realms > file, you can add the user ID and password:
Next, add a security role mapping to the server's server-specific deployment descriptor (at least, this is necessary for the SJS Application Server):
<security-role-mapping> <role-name>doing-important-things</role-name> <principal-name>very-high-up-guy</principal-name> </security-role-mapping>
- Add a security constraint, log-in configuration, and security role to the web service's web.xml (i.e., its deployment descriptor):
<security-constraint> <web-resource-collection> <web-resource-name>Web Service Security Resource</web-resource-name> <url-pattern>/Hello</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>doing-important-things</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> <security-role> <description>Big Bosses</description> <role-name>doing-important-things</role-name> </security-role>- security-constraint. Limits access to the resources defined in a web-resource-collection.
- login-config. Specifies the method used to authenticate the user, where BASIC (which is the default setting) uses browser authentication.
- security-role. The role name must have a corresponding entry in the server-specific file, which maps roles to principals in the security realm defined on the server.
- Add two lines to the main method of the static-stub client (as described in the J2EE Tutorial's Example: Basic Authentication with JAX-RPC section):
stub._setProperty(javax.xml.rpc.Stub.USERNAME_PROPERTY, "very-high-up-guy"); stub._setProperty(javax.xml.rpc.Stub.PASSWORD_PROPERTY, "abcde");
There are other (and better) ways of setting security from the client side, but this is the simplest scenario.
Now run the web service. The first time you do this, the server should prompt you for the user name and password. And then, once it's succesfully launched, run the client. A little password dialog box appears where you can type in the username and password:
Everything should now be well with the world -- if you type in the correct username and password and click OK... Bob's your father's brother and the static-stub client will have successfully made access to the web service.
Jun 19 2005, 03:11:02 AM PDT Permalink
Friday June 17, 2005 Quickly Close Multiple NetBeans IDE Projects
I recently -- a mere two weeks ago -- discovered that the IDE lets you perform actions on multiple projects selected in the Projects window. Just use the Shift and Ctrl key together with your mouse and you too will see what I saw:
Not bad, huh. The IDE even adds up the number of projects that I've selected, as if it's boasting: "You want me to close 7 projects? You think I can't handle that? Ha. Wait and see."
And, if you liked this tip, maybe you'll also like these earlier ones:
Quickly Unclutter the NetBeans IDE Source Editor
Quickly Navigate through the NetBeans IDE Source EditorJun 17 2005, 08:04:15 AM PDT Permalink
Thursday June 16, 2005 Brand New: NetBeans Plug-in Tutorial
A picture speaks a 1000 words. So, here are 2000 words:
Want to learn how to extend the Runtime window so that all your system's properties are displayed (as shown above)? Want to learn how to be able to edit their values? Want to learn how to set things up so that you can add system properties? Want to find out how to put everything together into a shareable plug-in?
Read the brand new NetBeans System Properties Plug-in Tutorial. Feedback is more than welcome -- although, please be aware that the tutorial is a work in progress and the code may not be 100% correct. Still, the tutorial should give you a good idea of some aspects of the Nodes API (it shows you, for example, how to create a property sheet). You can even download the sources of the plug-in and play around with it (again, please realize that the code is not necessarily 100% correct yet).
Jun 16 2005, 05:28:42 AM PDT Permalink
Wednesday June 15, 2005 Where did the name "Struts" originate?
Not necessarily a question that keeps me up at night, but something that I've wondered about once or twice is: "Where did the name 'Struts' originate?" It seems that others have wondered about the same thing. Craig McClanahan, the original author of Struts, provides the answer (here):It originally came from a strong memory from when I had a house built -- there were struts all over the place holding things up. Thus, the idea of a framework that 'holds everything up' but is itself invisible was born...
He expands on it a bit more (here):
I was originally toying with the concept of building a "framework", and the first thing contractors do when building a bridge or a house is put up the supporting infrastructure that lets you build what you really want to build, and stays out of the way other than that. In addition, "struts" are often constructed inside structures like an airplane wing -- invisible but vital.
Finally, the "s" on the end signifies that Struts is a toolkit from which you can use what you need. I didn't want to create a framework that required you to use all of it, although the parts will certainly work with more synergy together than separately.
So I am using Struts as a noun, not a verb :-)
Now if that isn't "from the horse's mouth", then I don't know what is. Still, I prefer the interpretation to which the quote above is a response -- someone called Christophe Thiebaud suggests (here) that it might relate to the famous quote from Macbeth:
Life's but a walking shadow, a poor player
That struts and frets his hour upon the stage,
And then is heard no more; it is a tale
Told by an idiot, full of sound and fury,
Signifying nothing.Not sure if Struts is a tale told by an idiot (since I don't know Craig McClanahan, but can only assume he's an intelligent person), but whether or not it is "full of sound and fury" is something I'll be able to find out soon -- because NetBeans IDE will support Struts straight out of the box! (To see how to set it up for NetBeans IDE 4.0 and 4.1, go here.)
Jun 15 2005, 01:32:25 AM PDT Permalink
Notice the "Web Search for" item in the menu? That's pretty cool. So select that and Google opens (at least, it does for me, maybe a different Search Engine is chosen depending on something or other on your own system) and the selected code ends up in the Search area.
Now all you've got to do is click Search and Google will find info on whatever the code was that you were having problems with...
Jun 21 2005, 07:16:30 AM PDT Permalink
Monday June 20, 2005
Provide Runtime Arguments for Selected Class Files in NetBeans IDE 4.1
In the Project Properties dialog box, the Arguments field specifies the runtime argument(s) for the main class. But what if you're not running a main class? How do you specify a runtime argument? The Project Properties dialog box doesn't support this scenario. But... Ant does! You can use Ant to create the application.args property which is used by the IDE when a file is run. However, you must make sure that the property is created at the right time -- before the project's properties are initialized. After the properties are initialized, you can't create the property again (you could override it in Ant, I guess, although I don't know how to do that yet). So, here's the target:
<target name="-pre-init" description="Set Runtime Arguments">
<input message="Runtime arguments:"
validargs="domsrc1.xml,domsrc2.xml,slide.xml,uddimsg.xml"
addproperty="application.args"/>
</target>
Next, you need to go to the Project Properties dialog box and delete whatever class is specified as the main class. This means that when you run the project, you're prompted to select a new main class. That's a bit inconvenient, but not too bad. So, when you run the project, you select the new 'main class' and then the -pre-init target above is called -- this asks you what runtime argument you'd like to use. (You can specify any acceptable arguments in the Ant target above, of course. If you want a blank slate rather than a pre-defined set of options, just don't define the validargs property in the target.) Then the run target is called and the application is run using the argument that you selected.
Note, however, that the above scenario only works when you run the application, not when you run a file. In other words, when you right-click a file and choose Run File, the application.args is set, but somehow (not sure why, but probably because it sets application-level arguments, not file-level arguments) not used in the target that runs the file. So, you have to right-click the project and then choose Run Project for the desired effect to occur.
Jun 20 2005, 06:02:18 AM PDT Permalink
Sunday June 19, 2005
Web Service Security: Three Steps
I've been looking at adding security to the simple web service created in the J2EE Tutorial's Creating a Simple Web Service and Client with JAX-RPC section. Once it all makes sense to me, I'll turn it all into a tutorial. Currently, my understanding (aided by Petr Blaha, a very helpful NetBeans developer and colleague) goes like this: