Posts Tagged With: Build

Java still vexing me in #xpages

So, as I noted in my last post about Java in XPages, things have not been smooth for me. Updates to my Java class files don’t always seem to work.

I’ve got a database that’s called Shared Resources and contains mostly XPages and configuration documents for our project. Data is stored in Main, workflow configuration and tracking goes into Workflow, and Attachments is self-explanatory. Our intention is that this will be mostly used via XPiNC, since many laptops will be in remote locations without server access.

I’m using templates, creating new ones incrementally so I don’t lose any of my intermediate changes, plus creating roll-backs in case changes snuck in somehow. I’ve got my own ID and a Development Admin ID that I use for signing. The Development Admin ID is required for the production servers, so it’s possible that signing issues have been a part of the problem. I have three database suites that I push the design to, two of those being on my development server (my Sandbox and our test copy) and the third being in production (but not yet even as a pilot, just validation testing in that environment).

I’m not currently changing any code, but trying to determine whether having custom Java code in 8.5.3 can work in either Code/Java or WebComponents/WEB-INF/src and finding that it doesn’t seem to matter. It seems to fail in either place almost at random. I know there must be a pattern, but I have had difficulty finding that pattern and need some help.

So, steps that I have followed….

  1. Clean & Build on template
  2. Refresh design of production database
  3. Marvel at failure of DebugToolbar or partial succcess (load first page, but not requisition page) or complete success on XPiNC (with complete or partial failure in IE)
  1. Clean & Build on local replica of production database
  2. Replicate with server
  3. Marvel at over-write of class files on local from server
  1. Clean & Build on server (go walk dog, practice French in Pimsleur, or contemplate fine wines)
  2. Restart Notes client since it will have cached the XPages
  3. Usually marvel at success but agonize over the idea of knocking everyone off the database while I build
Error while executing JavaScript action expression
javax.faces.FacesException: Can't instantiate class: 'eu.linqed.debugtoolbar.DebugToolbar'.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: eu.linqed.debugtoolbar.DebugToolbar
Can't instantiate class: 'eu.linqed.debugtoolbar.DebugToolbar'.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: eu.linqed.debugtoolbar.DebugToolbar
java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: eu.linqed.debugtoolbar.DebugToolbar
class java.lang.ClassNotFoundException: eu.linqed.debugtoolbar.DebugToolbar


   1: #{javascript:if (typeof dBar != "undefined") {
   2: 	dBar.init(compositeData.defaultCollapsed, compositeData.toolbarColor);
   3: }}

It does seem almost random. Since it sometimes works, I know it’s not a problem with the code that is in the files. I know from Stack Overflow links in the last post that Java residing in Code/Java does not always behave, but I seem to have problems in both locations. There are few people who do have designer rights to the database, but they’ve all been staying out of it in Designer since I started reporting problems. We all have de-selected Build Automatically, but some registration of components seems to occur if I open the production database in Designer using my personal ID. I don’t know if that is adding to the problem or not.

I’ve read some people suggest that the problem goes away in Notes 9, but since it shouldn’t have been there in 8.5.3, I don’t know if I should believe that. I also would rather not toss the additional variable of moving to Notes 9 in when we think we’re less than a month from a pilot deployment.

Right now, it works in XPiNC and IE in both of my development instances, and in XPiNC in production, but fails in browsers there. I leave for two weeks in the south of France on Thursday and they can’t really cope with something that breaks for no apparent reason while I’m gone.

Categories: IDE, Java, Xpages | Tags: , , , | 11 Comments

Closing Unrelated Projects

When I first started trying to figure out XPages, I had all the default settings and I didn’t fiddle with them. I didn’t know what any of them were for and I still spend most of my time figuring out how to design things rather than how to handle my development environment, but, I am learning.

The first change I made was recommended by the folks over at Teamwork SolutioBuildAutomaticallyns, who’ve done some marvelous work on getting our main project rolling. They let me know that leaving the default setting of Build Automatically in the Project menu was a recipe for disaster in a multi-developer environment. I think it’s a bad thing even in a single-developer environment, because it constantly rebuilds your database, slowing down the design process as you wait for your CPU to catch up. If multiple developers are working in a single database, it’s likely to do a build in the middle of someone else’s work, screwing everything up. Of course, in any environment outside of Notes, builds and change control are a far more organized and normal process than we’ve dealt with. By making your builds only occur by conscious decision, you also move in the direction of all those other development environments. (Especially useful in preparing oneself for the inevitable technology and career changes that are normal for developers.)

CleanChoicesSo, on recommendation, I started always doing a Clean and then building just my specific database. Unfortunately, over the course of a day, like any normal Notes developer, I worked on several databases. Sometimes, these were completely unrelated. Why is this unfortunate? Well, my Clean & Build list got sloppy and crowded. Sometimes, in order to make my list look cleaner, I’d close my Designer client and restart it. I knew there was a way to clean up the list without doing that, but it was easy.

Now, I would think that having all those projects open would eat up memory and that removing them would somehow free up memory. Heck, I even thought that closing the Designer client would free up memory. It doesn’t appear to do so, but that might just be the random and anecdotal nature of my “testing”.

Nonetheless, I wanted a cleaner list, so I fiddled around and, I found what I was looking for. CloseUnrelatedProjectsIf you use the Navigator view in your Designer’s Eclipse perspective, you can right-click on the one database you actually want to appear in your Clean & Build dialog, then down toward the bottom choose Close Unrelated Projects. Then, your list looks nice and neat. I wish I could say this speeds processing or limits memory use, but the only performance increase I’ve seen is the change to the dialog box. Hopefully, Notes 9 will provide better memory management in this regard, but even if it does not, my need for a neater workspace will compel me to use this process.

I’d appreciate your thoughts and comments on this, especially if you’ve any speculation or data on performance improvement using this.

Oops! I forgot to mention the biggest reason for closing projects – Search. If you use <ctrl-H> to search your design elements for a string (which I do pretty often) then it will search all open projects. If you have several open projects you’re not working on, you get a lot of extraneous results and it takes far longer to complete. Closing those unrelated projects eliminates the wasted time.

Categories: IDE | Tags: , , , | 2 Comments

Blog at

%d bloggers like this: