Extreme Java

New host

2008-02-08T09:51:00.000-02:00

This blog is now hosted on my own server:

http://extremejava.tpk.com.br

Blackmagic with NetBeans and OpenOffice

2008-01-08T09:33:00.001-02:00

This one is one of the weirdest (and useful) things I ever seen in 16 years of my life as a developer (I'm 26, BTW)... OpenOffice is a very powerful Office Automation solution... NetBeans Plaform is a very powerful application platform... Can you imagine what you get when you mix both together? Yup, this is possible. With NB and OOo installed, you just need to create a NB Module with following JARs from OOo:

juh.jar
jurt.jar
officebean.jar
ridl.jar
unoil.jar

I created another module with a single TopComponent, and add this snippet:


private OOoBean oo;
@Override
public void componentOpened() {
  try {
    add(oo = new OOoBean());
    oo.loadFromURL("private:factory/swriter", null);
    oo.aquireSystemWindow();
  } catch (Exception ex) {
    Exceptions.printStackTrace(ex);
  }
}

But, this will NOT work... If you try to run it, an exception will be thrown, because OOo libs (.DLL/.SO) will not be found. They only exists in OOo install folder, and are automagically found by OOo classes - only if they aren't moved from the "classes" folder in OOo installation.

The workaround is a couple of classes in OOo SDK and The Ultimate Blackmagic(TM) - patent pending:

Grab odk / source / com / sun / star / lib / loader from OOo's CVS and add it to integration module.

Add unowinreg.dll to Windows Path (if you are on Linux, skip this step).

Alter Loader.java and add this after line 205 (after "UnoInfo" call):
```
vec.add(new File(fClassesDir, "officebean.jar").toURL());
```
This part of the magick adds "officebean" to classpath. Here lies OOoBean, and is optional if you are only using UNO interfaces. Other JARs are correctly listed by UnoInfo.

Now, the ugliest part of the evil potion: create a Facade. Using OOoBean directly will lead to some ugly ClassLoader conflicts. I've no time to fix this, but the following works:


public static Container buildOOoBean() {
  return (Container) Loader.getCustomLoader().
    loadClass("com.sun.star.comp.beans.OOoBean").
    newInstance();
}

public static void showOOoBean(Container oo) {
  Class c = oo.getClass().
    getClassLoader().
    loadClass("com.sun.star.beans.PropertyValue");
  Class ca = Array.newInstance(c, 0).getClass();
  Method m = oo.getClass().
    getMethod("loadFromURL", String.class, ca);
  m.invoke(oo, "private:factory/swriter", null);

  oo.getClass().
    getMethod("aquireSystemWindow").invoke(oo);
}

Back to the TC, I use "buildOOoBean" in ComponentOpened and "showOOoBean" AFTER the component is shown (does not work otherwise).

Yes, it is the purest evilness, but works (with some bugs):

This level of indirection is mandatory, because client module's ClassLoader is different than integration module's. If I do "OOoBean oo = new OOoBean()", the declaration and instantiation will try to use the JARs bundled. Since they don't lie on OOo install folder, the libraries will not be found. If I use "oo = (OOoBean) Loader.getCustomLoader().getClass("...").newInstance()", the "OOoBean" class from declaration will NOT be the same as the class instantiated. If you ever worked with JavaEE 4 and JSF/Struts/etc, you know that same classes from different ClassLoaders throws ClassCastException.

OOo works really well with Java, but NetBeans ClassLoader is "self-contained" (i.e. your bundled application must include EVERYTHING you use). This is a very nice architecture, but does not help if you if you need to interface with external applications.

Asynchronous Node children in NetBeans Platform

2008-01-04T14:42:00.000-02:00

5 minutes playing with the new NetBeans 6 platform and I found a very useful feature. In previous post, I download URL. Using that code, I want to create a list of POJOs (that will be represented by a list of Nodes). In old NB5 days, I had to create a Thread and a lot of syncronization code to make the download run in background. In NetBeans 6 is easy as 1, 2, 3:

Subclass ChildFactory (from Nodes API), implementing createKeys and createNodeFromKey

Create an AbstractNode passing Children.create(MyChildFactory)

Compile, run and enjoy!

HTTP POST download with Java's URL class

2008-01-04T12:31:00.000-02:00

This is easy, but I always forget the recipe. I need to download and process a file using a POST request. The code is:


URL url = new URL(FORM_URL);
URLConnection conn = url.openConnection();
conn.setDoOutput(true);

OutputStreamWriter out = new OutputStreamWriter(conn.getOutputStream());
out.write("field=value&field=value&...");
out.flush();

BufferedReader in = new BufferedReader(new InputStreamReader(conn.getInputStream()));
String line;

while ((line = in.readLine()) != null) {
    // do something
}

out.close();
in.close();

The only catch is to use URLEncoder.encode to translate keys and values to the x-form-url-encoded style.

Transactions in EJB3

2007-03-26T11:17:00.000-03:00

A little pause in the Quest for the Java Portal. I'm creating a JavaEE application, and I got a simple problem, but not well explained on the Internet. The scenario:

EJB module has:

Some CMP beans (with @ManyToOne and @OneToMany relationships);
A Session Facade (stateless local bean).

WEB module has:

A jMaki-powered menu tree;
A JSF-managed bean (that populates the jMaki tree with a call to Session Facade).

It is very simple, but I got a ServletException (caused by a LazyInitializationException) when I try to navigate the relationships on web container.

Googleing this problem, I found that the transaction of a stateless bean (using a "requires" or "requires new" attribute) is closed after the method returns, if the container opened it. Specifically, it happens when the EntityManager is destroyed. This is obvious, but not very intuitive. Solutions:

Use a stateful bean. The Entity Manager will "survive" along with the session, but I think this will make the transaction survive that long, too. Not the best solution;
Open the transaction in web container. This is strange, but logical: if I want to access the database (with lazy fetching), I must have an active transaction. EJB container is prepared to reuse the transaction by using the @TransactionAttribute annotation (defaults to "REQUIRED"). Using the brand-new resource injection, it is a matter of creating a "@Resource UserTransaction tx" attribute on my JSF managed bean. It is not nice to inject a transaction on every bean of web container, so, you only need to create a web filter that opens before chaining the operation.

As a conclusion, my contribution to JavaEE community. If you want to use Lazy Loading on web containers, you just need to create a Filter like this one:

public class TransactionFilter implements Filter {
 @Resource
 private UserTransaction tx;

 public void doFilter(ServletRequest request,
         ServletResponse response,
         FilterChain chain)
         throws IOException, ServletException {
     try {
         if (tx.getStatus() == STATUS_NO_TRANSACTION) {
             tx.begin();
         }
     } catch (NotSupportedException ex) {
         throw new ServletException(ex);
     } catch (SystemException ex) {
         throw new ServletException(ex);
     }
 
     chain.doFilter(request, response);
 }

 public void destroy() {
 }

 public void init(FilterConfig filterConfig) {
 }

}

The quest for the Java Portal - Profiling Liferay

2007-03-18T16:41:00.000-03:00

It's time to run the Profiler. I start JBoss with "run-nbprofiler.bat" (created by NetBeans) and ask NB to attach profiler. I'm using "analyze performance", filtering Java core classes. JBoss runs very slow, but this is normal, since profiler is collecting execution of every method.

My first try showed that Lucene is called a lot of times, even when server is on "idle" state. Maybe it is a background job that should have a smaller frequency.

The second try filters out Lucene classes (using NB Profiler options). I found two bootlenecks: com.liferay.portal.lucene.IndexWriterFactory.decrement (takes 58% of startup time) and JBoss classloaders. And I found that Liferay auto deploy is running too often (~5 seconds of delay). Nice for develoment, awful for production use.

I had to remove JBoss classes from profiling, and I got amazed on things I discovered. I got a OutOfMemoryError (perm gen space) - solved by adding "-XX:MaxPermSize=256m" to run script - but I could find a lot of interesting things:

getResourceAsStream was called 12068 times;
Xerces' ChildNode was instantiated 853808 times (does anybody imagine why Java is "slow"?);
Stacktrace got really deep. About 50 levels or more, not including JBoss, Lucene and JDK classes;
A chain of 7 filters was called before hitting Liferay's MainServlet. If you consider a little forward made after MainServlet, we reach 14 filters before hitting a JSP file;
JSP compilation took 19s on this environment - total execution was 180s;
LR's VelocityTaglib has 8 iconXXX() methods that took 8 seconds each - detail: each one forwards another request;
Everytime a "include" is made, the chain of 7 filter is called. And there's a LOT of includes.

Remember that this was only ONE hit and the request wasn't complete, because of the OOM error. After that, I'm going to have some fun in the "real world". I'll try to go deeper tomorrow. Maybe I can send a RFE to Liferay team after I organize the arguments.

The quest for the Java Portal - Running Liferay

2007-03-18T14:34:00.000-03:00

Now, I have a profiled environment. But, when I tried to run JBoss (without profiling), I got an error in counter-ejb module. Its classpath is not correctand, so, I added this line to my build.[user|computer].properties:

classpath.manifest=[original line in build.properties] lib/doubleclick-filter.jar

I reported this bug on Liferay JIRA [#LEP-2406]. After another 16 minutes of compilation, I forgot to initialize the database. I had two options: use a diferent connection pool or initialize it before deploying Liferay. I prefer the second, so, the easiest way was to create a MBean that depends on LiferayPool. Hypersonic is smart enough to allow multiple SQL commands in one Statement. I will upload the code later, but it is a matter of create a MBean that reads the script provided by Liferay and runs it on the poll.

This leads to an strange error about Spring transactions with EJB, Hibernate, JBoss and all. I don't remember the details, but the solution is to change the debug attribute of CachedConnectionManager. This is something I can't do in my shared JBoss server, so, I used an dirty trick:

Start JBoss with no Liferay, but with the original data source (liferay-db.xml configured);
JBoss translates your -ds file into and -service file and logs it with debug level;
Grab the translated file in log, create the -service, delete the -ds and indent the file - this will help you understand its structure;
Now, the funny part: copy CacheConnectionManager definition from jboss-jca.xml, paste into liferay-service.xml (inside the "CachedConnectionManager" optional attribute), and rename the MBean to an unique name - I put a ",name=xxx" suffix.

This will create a custom CCM to Liferay, without violating the original instance. That's what I love in Java (specially in JBoss): you can create a Lego-like software that is just a matter of do the bindings.

Liferay runs fine, but I found two bugs: a ClassNotFoundException about ical4j, and the contents of Guest community are blank. The first, I solve by adding lib/ical4j.jar to manifest classpath (as above). The second I don't care, since I will clean everything when I deploy the real application.

The quest for the Java Portal - Compiling Liferay

2007-03-16T15:09:00.000-03:00

I got some weird exceptions with JBoss Portal, so, I decided to play around with Liferay. I have it running on my shared JBoss, and I have some ideas to their structured articles feature, so I will try harder on Liferay.

I've decided to check the bootlenecks on Liferay, because it is too slow. I'll use NetBeans Profiler. Using NB's ability to create projects using existing Ant scripts, I've done some setup:

Create an Java Application project using an already existing Ant script;
Add all "src" folder to the source folders list - about 20 of them (I guess this isn't necessary unless we want to change anything);
Adjust compilation build to the "start" target and run to "deploy" (Liferay does not set "start" as dependency to "deploy");
Create a "build.[user|computer].properties" and "app.server.[user|computer].properties" to customize some build parameters. I dislike Jikes, so, I'm using "javac.compiler=modern". The rest of properties are straighforward to customize, but folders on app.server must be correctly configured - JBoss predefined values does not work on an out-of-box installation;
After building a lot of modules (about 10 minutes on an almost empty Windows box powered by an Athlon XP 3200+), more than 2000 classes - yes, two thousands - are compiled without errors. Running the "deploy" target will install Liferay on JBoss. It installs some JARs on server's lib folder - I will change this later, before uploading to the real server.

Now, you can run JBoss. But first, some one-time configuration:

Add a datasource. To use profiling, I created a memory-only HSQLDB:

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
  <jndi-name>jdbc/LiferayPool</jndi-name>
  <connection-url>jdbc:hsqldb:.</connection-url>
  <driver-class>org.hsqldb.jdbcDriver</driver-class>
  <user-name>sa</user-name>
  <password></password>
</local-tx-datasource>
</datasources>

Use NetBeans Profiler (Profile | Attach Profiler) to prepare a special run script to active profiling on JBoss - this file will be called "run-nbprofiler".

Now, we have an working environment. Next step is test and profile.

The quest for the Java Portal - Testimonial

2007-03-13T11:47:00.000-03:00

I was supposed to be an user of Java Portals, not a developer. Things like JBoss management portlet are annoying, but it is just a matter of user experience. At least JBoss Portal deploys with minimal changes. Actually, I only need to change deployment descriptors.

Portals like Gridsphere, Jetspeed and others are unusable to normal users, since they need to know Java very well. How can I replace Zope/Plone in my job if every environment admin will need to know how to use Maven/Ant/etc?

Is that hard to develop an JavaEE application that makes users' life easier?

If I need to do any developer task, I prefer to develop my own portal that conforms to JSR-168 without violating JavaEE specifications.

BTW, I'm talking as a Java Portal user (i.e. portal deployer/admin). I'm not talking as the user of the portal I will create with a Java Portal (i.e. my "costumers").

End note: I'll try JBoss Portal beta-1, since it was released this week, but I won't use it if I still needs that buggy management layout.

The quest for the Java Portal - Gridsphere Tests

2007-03-13T10:30:00.000-03:00

GridSphere compiled in an zero-error-in-deploy WAR file. But, with my well-known luck and my incredible skill of catch the weirdest bugs on Earth, I got the classic "error-page-that-throws-error" bug. A page throwed an error. This triggers the error page. But, the same error was throwed. This triggers the error page. I love when this happens. My luck was the StackOverflowError. In some EPTTE bugs the error page leads to HTTP infinite redirection.

The origin of the error? This little piece of code:

public synchronized Object deepCopy(Object oldObj) throws Exception {
   ObjectOutputStream oos = null;
   ObjectInputStream ois = null;
   try {
       ByteArrayOutputStream bos =
           new ByteArrayOutputStream(); // A
       oos = new ObjectOutputStream(bos); // B
       // serialize and pass the object
       oos.writeObject(oldObj);   // C
       oos.flush();               // D
       ByteArrayInputStream bin =
           new ByteArrayInputStream(bos.toByteArray()); // E
       ois = new ObjectInputStream(bin);                  // F
       // return the new object
       return ois.readObject(); // G
   } catch (Exception e) {
       throw e;
   } finally {
       if (oos != null) oos.close();
       if (ois != null) ois.close();
   }
}

I will not comment the weird "catch e throw e" fragment, but this was the most expensive way to follow the Prototype pattern (deep copy variant) I ever seen. You don't need to be an extreme Java programmer to notice this code will fail on the first non-serializable class found by oos.writeObject. Now, guess what was the exception I got?

java.io.NotSerializableException: org.apache.log4j.Level

After digging into the code, I discovered that GS team knows the use of transient keyword, but didn't used it on BasePortletComponent.java, line 42:

protected Log log = LogFactory.getLog(PortletPageFactory.class);

How this works on Tomcat is a mistery to me. Changing it to a final static attribute and adding some dependencies of dependencies (Jackrabbit needs Lucene and yet another logging implementation - SLF4J), made it work, but not as expected.

Result: an installation page with some really ugly URL rewrite techniques.

<link ... href="/tmp54563GridSphere-exp.war/...css" ...>
<img src="/@GRIDSPHERE_DEPLOY@/...png" ...>

The second one is a side-effect of using my own build script. The first one (along with cool design patterns) gives GridSphere an one-way ticket to my attic.

The quest for the Java Portal - Gridsphere Compilation

2007-03-13T09:41:00.000-03:00

Current version of Gridsphere, 3.0.3, supports Tomcat and Jetty only. Since I'm extreme (-lly nuthead), I've tryed to run it on JBoss. I haven't found any live demo on its site - too bad.

Like Jetspeed and eXo, there's no WAR/EAR/SAR/CAR/etcAR file to download - I must download the source and compile (there's a corrupted, hidden WAR file on server, if you edit by hand the URL of download). Good news is: it uses Ant (not Maven) - that means I does not need to dig into obscure and unstructured XML. IMHO, Maven is good for the main developer, but not for the bug hunters, like me.

As expected, it wasn't straightforward. The steps:

Set CATALINA_HOME to JBoss' server folder - "$JBOSSHOME/server/$instance". Compilation script needs a "lib" folder with JavaEE API. Tomcat 5 stores on "$C_H/common/lib", Tomcat 6 stores on "$C_H/lib". Gridsphere "detects" tomcat version by verifying if "$C_H/common/lib" exists.
This leads to a "$C_H/bin" not found. After some digging in build scripts (I love Ant), I found an strange task that adds Tomcat's bin dir to classpath:
```
110 <fileset dir="${appserver.home}/bin/">
111     <include name="*.jar">
112 </fileset>
```
Removing it and running the undocumented "ant war" task, creates the web archive.
The archive will not deploy: a ClassNotFoundException nested in a WSException. The class that was not found was the CaptchaServlet. The CNFE is strange, since the class is on "WEB-INF/lib" folder. Since I will not allow new users, I removed the reference from web.xml, but the same exception was thrown, with class GridSphereServlet.

At this point, I got tired of editing files by hand, and I created a NetBeans project to handle everything to me. This is the approach I'm doing with Liferay, and, likewise, I found a lot of dependencies, like Castor (yet another binding framework), JFreeChart, and others.

BTW, JFreeChart deserves some lines. First, I thought one of JFree JAR files were corrupt in GS distribution. I've decided to download it from JFree site and I can't see the documentation because IT IS NOT FREE. Yup. I can download the sources, but not the developer documentation.

And, like every giant project, I found useless things, like Perl5Util. I don't want to discuss if P5U is useful, but use it to replace regex like "\.xml$" with "" is a waste of resources, since String.replaceFirst can do the job.

Finally, I could compile with zero errors (and a lot of unchecked warnings). But it didn't run. I got an weird exception in Castor. After some reverse engineering, since there isn't architetural documentation, I found I need to add six XML files to their correct folders. In original GS structure, these XML lies on a "config" dir, but are copied to different folders by one of the 10 Ant scripts. Copying them made a deployable WAR file.

This is a thumbs up no NetBeans: users will always have an well organized project structure. There are no lost files on lost folders needing a lost task on a lost script to copy them to the correct place.

BTW, the problem was a static Class.getResource returning null. I had to change the code (adding some assertions) to figure it out.

Tip to Gridsphere team: use NetBeans to manage the project...

The quest for the Java Portal - inside Liferay, ep. 1

2007-03-11T02:16:00.000-03:00

Liferay is running slowly on my JBoss server, crashes lots of times, but works. I have decided to play with its source code, maybe optimizing here and there. NetBeans Profiler is perfect for this job, but Liferay was written with Eclipse. NetBeans project importer worked, but it didn't help, because the Liferay source structure is monolithic. Since I had some free time this weekend, I'm manually converting the project. I converted about 15%, but look what I found so far:

Tab size = 8. This is a HUGE tab size. Usually Java projects use 4. But this is a matter of taste.
Actually, this is what I didn't found: documentation. No JavaDocs on classes I opened. I don't know how they can work on classes without any documentation. I always forget the use of any class I don't open often... :)
Lots of third part libraries. And I'm not talking about the classic ones (like commons-logging). I found things like EasyConf (looks like Java Preferences API), OSCache (object cache that works on cluster environments) and Trone (yet another Collections framework). This explains the need for a bigger PermSize.

Liferay is a great product, but it really needs a good cleanup. Some of their optimization tricks creates overheads, like using Colt (yet another Collections framework - yes, they have TWO different YACF). Colt have some "sync collections" that works using the same synchronization principle as Hashtable and Vector. The question is: why they leave synchronization to the collection? What about using the "synchronized(xxx)" structure?

I will follow GrOG's tip (in last blog's comments): report my discoveries to the community. I preferred to report only after deciding which Portal I will use, but the decision is taking me too deep on each implementation I'm testing.

The quest for the Java Portal - JBoss Portal 2.6 live

2007-03-08T15:07:00.000-03:00

No changes in JBoss Portal 20070307 nightly build. I saw JBoss ajax4jsf and JBoss Rich Faces and could not imagine why these incredibly cool components aren't used by JBoss Portal.

The quest for the Java Portal - JBoss Portal 2.6

2007-03-08T11:19:00.000-03:00

JBoss Portal version 2.6 is still alpha, but I tryed it (since it claims to have a better user experience). I've downloaded its binary version - a JBoss' SAR archive. Out-of-box installation was a matter of copy datasource definition and the SAR file to my deploy folder.

It has the same limitations as 2.4:

Delete the management portlet and your layout is locked;
You can delete ALL users and have a nice NPE;
The layout arrangement is not inline (needs the management portlet).

But, as I expected, it is pretty light. Unlink Liferay, the startup was really quick. If it was more AJAX-aware, JBoss Portal could be my portal of choice. Well, according to Grog, beta 1 will be released soon. I'm downloading a nightly build and I'll try it again.

The quest for the Java Portal - JBoss Portal

2007-03-08T09:22:00.000-03:00

Today mission: JBoss Portal. My first impression: negative. I've tryed its live demo and, after two minutes, I render it useless. How? Follow the steps:

Login as admin/admin
Go to the admin page
Remove the administration portlet

What you got? A portal with a layout that can't be changed... That's typical from JBoss community: they create a simple kernel and everything is extension. JBoss Application Server is a microkernel that manages JMX beans. Everything else is JMX. Likewise, JBoss Portal is just a portlet container. You need that ugly and unintuitive manager (as ugly and unintuitive as AS managers) to manage everything.

BTW, that management portlet does a lot of roundtrips to the server (yep, no AJAX). If you plan to use it on your server, create a page that contains only the manager portlet.

JBoss Portal 2.4 is off my list. I will try 2.6alpha2.

Thumbs down to Java Portals

2007-03-06T20:56:00.000-03:00

One of the most frustrating things I have tryed to do was to use a Java Portal. I haven't found a JSR-168 compliant portal that could work at all. I have simple needs:

The portal must run on JBoss: I'm renting a shared JBoss server;
I need to put a "virtual-host" tag in every jboss-web.xml: this is how JBoss will map my domain to my applications;
I must have total control over JNDI/JMX naming conventions: "default" names are unacceptable, since other "clients" may want to use the same implementation;
The portal must NOT create any files on the filesystem: JBoss runs with an specific user that does not have write access to my private folders; and
Memory and CPU consumption must be light: obviously.

What I found:

JBoss Portal:

Prós: Runs on JBoss (of course) and seems to be light
Cons: UGLY. Portal layout is defined with some weird arrows on an weird admin page

Liferay

Pros: beautiful, lots of AJAX, lots of out-of-box portlets
Cons: invasive (needs to create a lot of files), eats CPU and memory like I eat chocolate and creates JMX in runtime (but does not release them on undeploy). "Professional" version (WAR) takes 30 minutes to deploy, "Enterprise" version (EAR) crashed the server (yikes) and requires a lot of customization to run on a shared server

Pros: like Liferay, it's beautiful, lots of AJAX, lots of portlets, and have an awesome "desktop" version
Cons: I have to compile EVERYTHING and do a lot of digging on its source to customize it to my needs. I simply can't understand its compilation steps. Poor documentation. I could only test tomcat version, since I could not compile an working version...

Gridsphere

Pros: dunno
Cons: runs only on Tomcat

This is amazing... With JavaEE version 5, I thought I could find a portal that could be deployed as easy as 1-2-3:

Download a WAR/EAR file;
Add some jboss-web.xml (to map JNDI and virtual host) - this is my "deployer" role on an JavaEE application lifecycle (as defined by JavaEE specs);
Deploy the file on server.

But step 1 is non-existent on portals like GridSphere. Step 2 becames steps 2.a to 2.zzzz on eXo and Liferay... Every portal wants the user to download a package bundled with tomcat/jboss or to follow this recipe:

Download source (WORA, anyone?)
Compile using Maven (yet-another-build-automation-tool)
Package using Maven (its "custom" tasks does not allow me to add a jboss-web.xml, since even web.xml is generated by it)
Deploy on tomcat (JBoss sometimes)

Why?? Is that hard to create a REAL JavaEE-compliant application that implements JSR-168??? That's a thumb down to Java Portals (and JSR-168)...

NetBeans Code Folding

2006-09-11T19:27:00.000-03:00

Tired of lose the fight against NetBeans MDR stuff, I decided to check out Code Folding. Pretty easy, indeed. I haven't done a full code fold example, but I was able to use NB 'editor-fold' pseudo-tag. Considering that you have the syntax support (see NBP Tutorials), the steps are:

On your SettingsInitializer, you need to add this line:
```
settingsMap.put(SettingsNames.CODE_FOLDING_ENABLE, Boolean.TRUE);
```
This is not obvious, but it is the most important step. Without it, you will never activate folding (this was hard to find out - like any other "non-layer.xml" stuff).

On your EditorKit, you need to implement the SyntaxUpdateTokens class and put it as a document property. Like this:

public class MyEditorKit extends NbEditorKit {
    [ ... ]        

    protected void initDocument(BaseDocument doc) {
        doc.putProperty(SyntaxUpdateTokens.class, new SUT());
    }
    
    public class SUT extends SyntaxUpdateTokens {

        private List list;
        
        public void syntaxUpdateStart() {
            list = new ArrayList();
        }

        public List syntaxUpdateEnd() {
            return list;
        }

        public void syntaxUpdateToken(TokenID tid, TokenContextPath tcp,
                int offset, int len) {
            if (tokenID == MyTokenContext.LINE_COMMENT) {
                list.add(new TokenInfo(tid, tcp, offset, len));
            }
        }
    }
}

This will tell CustomFold which tokens it must use to find the pseudo-tag.

You need to create a three-line class to add the sidebar to the editor:

public class MyFoldingSideBarFactory implements SideBarFactory {
    public JComponent createSideBar(JTextComponent jTextComponent) {
        return new CodeFoldingSideBar(jTextComponent);
    }
}

This is a weird step. I don't know why there's no ready-to-go class to do this job.

Now, glue everything in your layer.xml, under "Editor/MIME" folder:

<folder name="SideBar">
    <file name="mypkg-MyFoldingSideBarFactory.instance"/>
    <attr name="org-netbeans-editor-GlyphGutter.instance
        /mypkg-MyFoldingSideBarFactory.instance"
        boolvalue="true"/>
</folder>
<folder name="FoldManager">
    <file name="org-netbeans-editor-CustomFoldManager$Factory.instance"/>
</folder>

FoldManager can be chained, just like the SideBar. Making it easy to add a "real" code fold based on tokens.

First post - current misson brief

2006-09-09T20:16:00.000-03:00

This is the first post. I don't have any ready tip yet, but I'll post my "current mission":

I'm trying to understand how to add a new language to NetBeans. I want everything Java Editor has: Code Completion, Code Folding, etc. In theory, it's simple: I just need to add editor support and create a metamodel to feed other subsystems.

The first part is well explained on NetBeans Platform web site (actually, it's incredibly simple to add syntax highlight), but there aren't good docs about how the "Java Language Model" works on NB.

And now my problem: I've created a metadata repository using NetBeans' MDR stuff, but I simply do not know how to populate the repository using source files (and how to create source files from the repository).