Sunday July 31, 2005
Sunday July 31, 2005
Code Completion for Wicket in NetBeans IDE
One thing I've found useful about learning Wicket in NetBeans IDE is the IDE's code completion functionality. For example, here I'm creating a new Wicket component in the Source Editor, but I'm too lazy (or ignorant) to type the whole component type -- so, all I do is click Ctrl-Space and the code completion popup appears, displaying all the possible ways to complete the already-typed code, together with the related Javadoc:
To set Wicket's Javadoc up in the IDE, go to the Library Manager, select the 'wicket' library (or whatever you've called the library that contains all the Wicket JARs) and use the Javadoc tab to add the folder that contains the Javadoc:
That's it. Now you've made Wicket's Javadoc available to the IDE, and you can read the related Javadoc while using code completion inside the IDE.
Jul 31 2005, 06:48:53 AM PDT Permalink
Add a Comment
Friday July 29, 2005
Extend an Existing NetBeans IDE Project's Functionality
I found out yesterday how easy it is to create a plug-in that adds a new project-level menu item. It means making a very simple addition to the layer.xml file. I imagine that the new Delete Project menu item (available now from the Update Center) was probably added in this way. Here's what you do:
<folder name="Projects">
<folder name="Actions">
<file name="org-myorg-genericprojectaction-GenericProjectAction.instance" />
</folder>
</folder>
And then you can invoke the action from a project's contextual menu:
To put the action in a different place in the contextual menu, you'd use the <attr> element, but then you'd need to know the real name (i.e., not the name that appears on the menu item but the name that you'd find in the localization bundle). And that's always a problem to work out -- a lot of digging through the NetBeans sources to see what something else is called, in order to know where the thing you're actually interested in should go.
In addition, I can imagine some actions that are relevant to web projects, but not to J2SE projects. Or J2EE-related project actions that have no relevance for web projects. However, I don't think it's possible (yet) to make that distinction in the layer.xml file.
By the way, using the layer.xml file like this is similar to what you do in free-form projects (i.e., not the standard projects for which the IDE generates its own Ant file) with Ant targets -- you can hook Ant targets up to a free-form project's contextual menu, but then only to a specific project, not to all projects simultaneously. On top of that, of course, the functionality that a plug-in offers is, at least potentially, much more extensive than what an Ant script can provide. And -- most important of all -- you can share a plug-in much more easily than an Ant script. Just put the NBM file in an e-mail, for example, or make it available via the Update Center. The Ant script, no matter how useful it is, requires a lot of little fiddly steps before it's hooked into someone else's project.
Jul 29 2005, 12:45:44 AM PDT Permalink
Thursday July 28, 2005
Spot the Difference!
There's one difference between these two screenshots... what is it? Whoever gets the right answer first will get a postcard from Prague, signed by me as well as anyone else walking round the office at the time of my sending it! If you know the answer, or think you know, just leave your answer as a comment at the end of this blog entry.
(People who are in Prague, who know the answer, are not allowed to enter -- especially you, Roumen!) Good luck to all the others...
Jul 28 2005, 04:44:07 AM PDT Permalink
Wednesday July 27, 2005
Two Broken NetBeans Builds Later...
...I finally managed to integrate a placeholder for the upcoming NetBeans plug-in helpset into the daily NetBeans IDE Dev build (click to enlarge):
Broken builds are no fun, especially when you're the one that's been causing them, but I can only say that, as a result, I've learnt a lot today! So now, every once in a while, after installing a new NetBeans IDE Dev build, you should take a look at the NetBeans plug-in helpset and see how things are coming along...
Jul 27 2005, 08:32:37 AM PDT Permalink
Tuesday July 26, 2005
Secure That Session Bean!
Using Ethereal, a sniffer I used in NetBeans IDE, Sniffers, and the Deviant Computer User, I 'sniffed' (i.e., 'preemptively hacked') the application described in the Building Secure Enterprise Beans in NetBeans IDE tutorial. This is the data stream that Ethereal intercepted between the session bean and web application (click to enlarge):
When I decoded the garbled authorization string (as described in step 6 here), the IDE's Output window displayed the username and password that the server requires in order for the web application to access the session bean:
The point is this: HTTP Basic Authentication is useful for illustrative purposes only. To really secure an application, a far more robust security strategy should be adopted -- and that strategy is Secure Socket Layer (SSL). SSL provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. It includes support for a public key certificate, which is the digital equivalent of a passport. It is issued by a trusted organization, which is called a certificate authority (CA), and provides identification for the bearer. For details, read the Understanding Login Authentication section in the J2EE Tutorial.
Jul 26 2005, 06:54:43 AM PDT Permalink
Monday July 25, 2005
Forget XML! Use a NetBeans IDE Visual Editor instead...
From NetBeans IDE 4.1 onwards, the IDE includes visual editors for customizing various deployment descriptors. At least one of them, the web.xml Visual Editor, will be extended in the next release -- there'll be a References section where you can visually edit a web.xml file's environment entries, resource references, resource environment references, EJB references, and message destination references. This is how the new section looks in a recent development build (click the enlarge):
That's pretty cool, I think. There's something else -- slightly hidden, I guess -- if you select a header in a Visual Editor (in the screenshot of the web.xml Visual Editor above the Resource References header is selected) and you then press F1 (or the tiny round question mark in the top right of the editor), a Help topic that is specific to the header in question is displayed. So, when you press F1 while the Resource References header is selected, you'll get a fairly extensive description about resource references -- not just about how to create them in the IDE, but also what they're used for and how they relate to other elements in the web.xml file. Note, though, that the Help topics for the References section are currently a work in progress...
Jul 25 2005, 04:56:25 AM PDT Permalink
Sunday July 24, 2005
Where's the Cursor in the NetBeans IDE Source Editor?
Let's say you want to use the NetBeans IDE Source Editor to edit a file type that the IDE doesn't recognize by default. For example, Manifest files are currently not recognized by the IDE. What does this mean? This means that the IDE treats Manifest files like text files -- when you open the file, there's nothing special, like syntax highlighting or code completion. The content of a Manifest file is just displayed as a text file in the Source Editor. So, let's say you want to add syntax highlighting and code completion. What's the first thing you should do? Create a data object specifically for Manifest files. Then, and this is what this blog entry is about, make sure that the IDE is able to identify which parts of the file are different to the other parts of the file. Each part should be a distinguishable item, called a token. For example, before you can provide a specific color to identify all the Java identifiers in a Java class opened in the Source Editor, the text in the class needs to be parsed into tokens so that Java identifiers are distinguished from other parts of a Java class. (But this is already done for you, because Java classes -- unlike Manifest files -- are recognized as such and its tokens are parsed and highlighted in the Source Editor.)
Here, for example, is what a Manifest file looks like (by default) in the Source Editor:
Each of the entries in a Manifest file consists of a name-value pair. For example, the first entry above has "Manifest-Version" as the name and "1.0" as the value. Let's say our implementation of syntax highlighting would provide one color for the name, one color for the ":" sign (a colon), and another color for the value. Since each token can have a color assigned to it, you need to parse the text to recognize all names as one token, all colons as one token, and all values as one token. Therefore, before even beginning to implement syntax highlighting and code completion, you need to parse the text in the Manifest file into tokens. How would you do this?
First declare your tokens (by extending the org.netbeans.editor.TokenContext class). You could have four tokens -- one for the name, one for the colon, one for the value, and one for the end of line:
public static final TokenID NAME = new BaseTokenID("name", NAME_ID);
public static final TokenID COLON = new BaseTokenID("colon", COLON_ID);
public static final TokenID VALUE = new BaseTokenID("value", VALUE_ID);
public static final TokenID END_OF_LINE = new BaseTokenID("end-of-line", END_OF_LINE_ID);
After declaring the token, you need to find which part of the text is which token. You do this by starting in some initial state and sequentially looking at each character in the text and deciding if you stay in that state, move to another state, or announce that a token was found. For example, for names you start in the initial state and the first time you encounter a valid character for a name, you enter the ISI_NAME state. The ISI_NAME state is shown below. You stay in this state until you encounter a \r, \n or : character, which are definitely not part of a name. When you encounter such a character, you know that the characters you just walked over make up a name token.
case ISI_NAME:
switch (actChar) {
case ':':
case '\r':
case '\n':
state = ISA_AFTER_NAME;
return ManifestTokenContext.NAME;
}
break;
The code above runs within a while loop. At the end there is a break statement, which increases the offset in the text. The return statement in the code above avoids increasing the offset and ensures that the parsing of the next token will start with this character (it will likely be a colon, which is a meaningful token itself). The break statement on the other hand ensures that offset is increased. When all the characters up to the colon are tested, the IDE knows whether the cursor is inside a name or not. And when the IDE knows that, it can provide syntax highlighting and coloring (which you need to program yourself) -- because now it knows where it is and what should be provided.
Of course, this is only an outline of the technique. A detailed tutorial will be provided on this soon. Thanks to Andrei Badea for providing code and explanation for all of this.
Jul 24 2005, 10:16:05 PM PDT Permalink
Friday July 22, 2005
NetBeans IDE, Sniffers, and the Deviant Computer User
Here's a funny sentence I found in an on-line article today: "Sniffers are useful tools for deviant computer users since they can be used to pull plain text passwords off a network." Deviant computer users! Ha ha. Morally challenged? Occupationally unsettled? Try computer deviancy... (Click here to read the on-line article, which is a very good introduction to "Sniffers".) So, anyway, Petr Blaha showed me how simple it is to hack an insecure protocol like the Basic HTTP authentication that I outlined in Web Service Security: Three Steps.
It's as simple as this:
- Get a sniffer. I recommend Ethereal.
- Set up an application that uses Basic HTTP authentication. For details, see Web Service Security: Three Steps.
- Start the sniffer. (For example, in Ethereal, choose Capture > Start.)
- Deploy the web service and deploy the client. The sniffer, which you started before starting the service and client, registers the communication between them. Note that Ethereal (and probably other sniffers too) does not register anything deployed to localhost.
- Stop the sniffer. Now look in the sniffer's GUI to identify the data that pertains to the communication between the web service and client. And then use the sniffer to follow the TCP stream. In Ethereal, this means that you right-click the record that represents the data and then you choose Follow TCP Stream. You'll get a nice little overview of everything that's happened between the web service and client (click to enlarge):
Note the line above that is highlighted. This is the encoded authorization. Copy the garbled part, which in the screenshot above is as follows:
dmVyeS1oaWdoLXVwLWd1eTphYmNkZQ==
- Now create a main class in NetBeans IDE and use the following constructor:
public static void main(String[] args) throws Exception { String encoded = "dmVyeS1oaWdoLXVwLWd1eTphYmNkZQ=="; byte[] buf = Base64.decode(encoded); System.out.println("Encoded: " + encoded); System.out.print("Decoded: "); System.out.write(buf); }Note that the string that you define above is the garbled part you got from the sniffer. By the way, you need this import statement:
import com.sun.org.apache.xerces.internal.impl.dv.util.Base64;
- Run the class! This is what the NetBeans IDE Output window showed me:
Look closely at the screenshot -- this is what it includes:
Encoded: dmVyeS1oaWdoLXVwLWd1eTphYmNkZQ== Decoded: very-high-up-guy:abcde
This is the user and password defined in Web Service Security: Three Steps. If you were a "deviant computer user", you'd be pretty excited right now. Here's something from the J2EE Tutorial about HTTP Basic authorization (click here for more):
HTTP basic authentication is not particularly secure. Basic authentication sends user names and passwords over the Internet as text that is uu-encoded (Unix-to-Unix encoded) but not encrypted. This form of authentication, which uses Base64 encoding, can expose your user names and passwords unless all connections are over SSL. If someone can intercept the transmission, the user name and password information can easily be decoded.
So, considering how easy it is to hack Basic HTTP authentication, it's clear that something better -- much better -- is required. And that is... SSL authentication (actually known as client-certificate authentication)! Look how garbled the TCP stream is in Ethereal when I use SSL authentication -- I mean, compare the junk below to the stream in the dialog above (click to enlarge):
Note that the highlighted text in the screenshot above shows you that I'm using the HTTP secure port 8181, rather than the standard 8080 that I used for Basic HTTP authentication. Setting things up for SSL authentication is something I partly discussed in yesterday's blog entry, but there's much much more to it, and you can actually do everything from NetBeans IDE by integrating the JDK's Keytool via Ant scripts. But that's for another day.
(One final thought from the article that I referenced at the start of this blog entry: "Avoid using insecure protocols like Basic HTTP authentication and Telnet. As a matter of fact you should sniff your own network to see what passwords sniffer tools can pick up.")
Jul 22 2005, 06:33:08 AM PDT Permalink
Thursday July 21, 2005
Super Secure Web Services in NetBeans IDE
In Web Service Security: Three Steps, I went through some simple steps for setting up basic security for web services. An even better way of doing it is to use HTTP Security (HTTPS), which secures data by encrypting it between the server and browser. Below are the elements you added to a web service's web.xml file in Web Service Security: Three Steps -- with one additional element (emboldened), which specifies that the web service should force the client to authenticate itself via HTTPS:
<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>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-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>
Note that the <user-data-constraint> element must come after the <auth-constraint> element.
In addition, you need to enable HTTPS on the server that deploys the web service. On the Sun Java System Application Server, you do this by adding the emboldened element below to the <security-role-mapping> that you defined in Web Service Security: Three Steps:
<security-role-mapping> <role-name>doing-important-things</role-name> <principal-name>very-high-up-guy</principal-name> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </security-role-mapping>
For the Tomcat Web Server, you need to edit the server.xml file as described here (and also in Tomcat's own SSL Configuration HOW-TO). I don't know how it works for other servers, such as JBoss, but in each case you need to do something to enable the server to work with HTTPS.
Then, when a client attempts to connect to the web service (and also the first time you deploy the web service), you get this slightly forbidding looking certificate:
Using the JDK's Keytool application, you can create and manage your own certificates. So far, I'm just using the standard certificate provided by the Sun Java System Application Server. I'll be looking at creating my own soon.
Jul 21 2005, 01:49:25 AM PDT Permalink
Wednesday July 20, 2005
Download it now! JBoss Plug-in for NetBeans IDE!
Jul 20 2005, 06:24:17 AM PDT Permalink
Tuesday July 19, 2005
Overview of Wicket Components
Here's a brief overview of each of the Wicket components (the intention is to provide an overview of each, so if any are missing, they should be added), together with a reference to a sample for each. (References to samples still to be added for most components.) I will continue adding information to this list -- so it is not complete and it will keep changing -- as I learn more about Wicket. I intend to add code snippets to illustrate the usage of each component. I will also add related wicket tags to each component description. Once this overview is in a good enough state -- and assuming the Wicket team will want to host it -- it will be made available from the Wicket site. Thanks to Eelco for providing the basis of the information below.
Output components
Package: wicket.markup.html.basic
Components:
- Label. Outputs a single string. See the "HelloWorld" sample.
Java:
add(new Label("message", "Hello World!"));
HTML:<span wicket:id="message" id="message">Message goes here</span>
- MultiLineLabel. Outputs a string with converted line breaks and tabs. See the "GuestBook" sample.
Java:
public GuestBook() { // Add comment form add(new CommentForm("commentForm")); // Add commentListView of existing comments add(commentListView = new ListView("comments", commentList) { public void populateItem(final ListItem listItem) { final Comment comment = (Comment)listItem.getModelObject(); listItem.add(new Label("date", new Model(comment.getDate()))); listItem.add(new MultiLineLabel("text", comment.getText())); } }).setVersioned(false); }
HTML:<body> <span wicket:id="mainNavigation"/> <form wicket:id = "commentForm" id = "commentForm"> Add your comment here: <p> <textarea wicket:id = "text">This is a comment</textarea> <p> <input type = "submit" value = "Submit"/> </form> <p/> <span wicket:id = "comments" id="comments"> <p> <span wicket:id = "date">1/1/2004</span><br> <span wicket:id = "text">Comment text goes here.</span> </p> </span> <wicket:remove> <p> 1/2/2004<br/> More comment text here. </p> </wicket:remove> </body>
Layout and Grouping components
Packages: wicket.markup.html.panel, wicket.markup.html.border, wicket.markup.html.list, wicket.markup.html.tree
Components:
- Panel. Generic component for nesting subcomponents. See "WicketExampleHeader".
- Border. Generic component for nesting subcomponents within a border. See the "NavoMatic" sample.
- ListView. Component for repetitive elements. ListViews can contain nested ListViews.
- Loop. Same as ListView, but simpler and lighter, and therefore less advanced than ListView.
- Tree. Component for interactive server-side tree. Includes events voor expanding/collapsing and for selection. See the "Nested" sample.
- AbstractTree. Abstract tree component that can be used for implementing trees that follow an alternative rendering strategy.
Link components
Package: wicket.markup.html.link
Components:
- BookmarkablePageLink. Specialized PageLink for BookmarkablePages.
- ExternalLink. Link to non-Wicket sites, such as Google.
- ImageMap. Link defined on an image.
- Link. Generic call mechanism that can be attached to HTML anchors (such as <a href=>) or to arbitrary HTML elements, such as <TD> or <DIV>.
- PageLink. Link to a Wicket page, able to determine whether the link is active or inactive. A page is only created when the link is clicked, which saves session space.
- PopupCloseLink. Link that closes the current popup and removes it from the session.
- ResourceLink. Link to a resource, such as JAR-ed images or PDF files.
Form components
Packages: wicket.markup.html.form, wicket.markup.html.form.upload
Components:
- AbstractChoice. Basis class for all selection components.
- AbstractSingleSelectChoice. Basis class for single selection components.
- AbstractTextComponent. Basis component for custom text-based form components.
- Button. Button for triggering a Form submit.
- CheckBox. Checkbox component.
- DropDownChoice. Dropdown for selection.
- Form. Form component, equivalent of <form> in HTML.
- FormComponent. Basis for custom form component.
- ImageButton. Special button for working with images.
- ListChoice. Scroll selection instead of drop-down.
- ListMultipleChoice. Scroll and select multiple items.
- PasswordTextField. Encrypted entry field for passwords.
- RadioChoice. Radio button selection.
- RequiredTextField. Adds RequiredValidator to TextField-type component.
- TextField. Text field.
- TextArea. Multi-line text field.
- UploadForm. Special form for uploads. See "Upload" sample.
- UploadField. Field used for nesting UploadForms, so that you can create an upload per field, which allows simultaneous multiple file uploads within a single UploadForm. See "Upload" sample.
Miscellaneous components
Package: wicket.markup.html.image
Component:
- Image. Represents static and dynamic images. See "Images" sample.
Custom components
Package: wicket.markup.html
Components:
- WebComponent. For components without subcomponents. Useful for components that need to influence their body directly, such as Labels.
- WebContainer. For components that have subcomponents, such as Panels, Forms, etc.
- WebPage. Represents an HTML page.
- WebResource. Basis class for resources.
Jul 19 2005, 12:28:23 AM PDT Permalink
Monday July 18, 2005
Recognizing Wicket Applications in NetBeans IDE
I've been working on understanding how NetBeans IDE recognizes applications on disk as projects. Now, when I press Ctrl-Shift-O, I can open a Wicket application, even though it doesn't have the NetBeans project folder (nbproject), and therefore isn't a typical NetBeans IDE project. For example, this is what the Wicket examples look like once I've opened them as a single project in the IDE:
But, even though I didn't have to reorganize the Wicket folders in any way -- I just opened them as-is after downloading them from the Wicket site -- I currently can't do much with them. Of course, since most of the files are recognized in the Source Editor, I can edit them. Currently, though, I can't deploy them yet -- because I haven't implemented project-level actions yet. Still, notice how you can already use cool NetBeans IDE features such as the graphical web.xml editor.
By the way, currently the two documents that are very helpful in this area of NetBeans plug-in development are the following:
Jul 18 2005, 06:46:07 AM PDT Permalink
Sunday July 17, 2005
No More Excuses: Document Your NetBeans Plug-ins!
So you've created a brilliant NetBeans plug-in and you've made it available to the world. You're sitting back hoping for praise and glory, but... nobody 'gets' it. Maybe your target audience is using only a small subset of all the wonderful features you've provided. Or maybe they've missed the point completely. Probably you need to have another look at your user interface -- is it intuitive enough? Something else you need to do is... write some documentation! It's really not very hard -- a handful of HTML files can make a whole lot of difference. But what do you do when your HTML files are ready? Wouldn't you like to integrate them into the NetBeans help system? Did you know that you can do that? Take a look at the documentation for my own brilliant NetBeans plug-in, for example:
If you'd like to create and integrate your own set of help files, you need to take a look at a first draft of a brand new NetBeans tutorial:
NetBeans Help System Plug-in Tutorial
Feedback is welcome... and needed!
Jul 17 2005, 06:45:16 AM PDT Permalink
Friday July 15, 2005
Easy Extension of a NetBeans Data Object's Functionality
In Playing with File Types in NetBeans IDE 4.1 and elsewhere, I specified the popup menus for a data object by defining them like this in the node class:
public Action[] getActions(boolean context) {
Action[] result = new Action[] {
SystemAction.get(EditAction.class),
SystemAction.get(CutAction.class),
SystemAction.get(CopyAction.class),
SystemAction.get(RenameAction.class),
SystemAction.get(DeleteAction.class),
};
return result;
}
However, what happens if someone wants to add additional popup menus to the ones that I provided? How would they do that? They won't because they can't (not easily, anyway). Instead, if I'd known that Actions for DataLoader can be specified in a layer, I'd have specified them in the layer.xml file and simply created a reference to them in the DataLoader class:
protected String actionsContext() {
return "Loaders/text/x-tag/Actions/"; // NOI18N
}
Instead of x-tag above, I could specify x-java or x-jsp or whatever the MIME-TYPE is of the data object I want to extend.
Once the popup menus are defined in my layer.xml file, anyone else can add to them by adding them in the same place in their own module's layer.xml file. These layer.xml files can be seen as a big stack of pages in a book, that are read together as one story, providing one coherent whole -- hopefully! -- if all contributors are also good writers... However, note that this extensibility is only possible for existing loaders once they are migrated to this new style...
Jul 15 2005, 07:28:08 AM PDT Permalink
Thursday July 14, 2005
HTML and Java: Two Sides of the Same Wicket Coin
Each web page in Wicket is like a coin. It has two sides -- a Java class and an HTML file.
- Setting Up the Coin: HelloWorldApplication.java. The application object creates the application that contains the web pages. The application object is a Java class. The absolute minimum content of the application object is the definition of the home page. The home page is the first web page displayed by the application object.
Here the compiled HelloWorld.class web page is set as the home page:
getPages().setHomePage(HelloWorld.class);
The web page consists of two sides -- the Java component (the back or tails side) and its HTML rendering (the front or heads side). Importantly, since they are two sides of the same coin, the two sides have the same name and are stored in the same folder structure. Normally, this means that they are stored in the same package. So, in this case, the two sides are called HelloWorld.java and HelloWorld.html and are stored together in the same package.
- Tails: HelloWorld.java. Here a Label component is created:
add(new Label("message", "Hello World!"));There are two parameters: the component identifier ("message") and the content that the Label component should render ("Hello World!").
- Heads: HelloWorld.html. A Java component is used in an HTML file:
<span wicket:id="message">Message goes here</span>
The <span> element has one attribute, in the wicket namespace: the identifier ("id") which is defined as "message". Note that the Wicket identifier in the HTML file must match the component identifier in the Java component. The "Message goes here" text is a placeholder. You could write anything you like there -- it will be replaced by the Java component.
- Flipping the Coin. A web.xml file specifies the Wicket servlet wicket.protocol.http.WicketServlet that handles requests for the application object. A server, such as Tomcat or Jetty, is needed in order to deploy the application.
To see all of the above in practice, within the context of the two Java classes and HTML file that make up the "Hello World" application, use yesterday's blog entry to set everything up in NetBeans IDE. Alternatively, use another IDE. All Wicket applications are based on the above principles -- except that most Wicket applications have more than one coin. If you have enough coins, you can create a really rich application...
Jul 14 2005, 12:43:25 AM PDT Permalink