I am working with a java developer who is writing a jar that needs to use multi-threading. We discovered today that Domino is managing the way that it uses threads using the NotesThread class. He is in the process of changing his code to do it the "domino" way. The traditional java 1.6 way is not going to work.
He is asking me for the jar that contain the following classes so he can build his solution. Can someone point me to what jar contains these classes.
com.ibm.domino.xsp.module.nsf.NSFComponentModule;
com.ibm.domino.xsp.module.nsf.NotesContext;
com.ibm.domino.xsp.module.nsf.SessionCloner;
Note: I have sent him most every XPages and ExtLib jars that I had on my machine and he is still getting a computation error.
Also, I am not 100% sure he is using NotesThread, I recently found this: http://www.wissel.net/blog/d6plinks/SHWL-99U64Q and sent it to him. Perhaps all he needs is to manage the NotesContext and Session. First I need to get him the jar he needs, hence this question. The developer does not have Notes Designer installed. He uses Rational Application Developer to write his jar.
I see Frantisek has pointed you in the right direction for the jar you are looking for.
However, if you need to find one yourself here is how:
In Domino Designer, go to the Editor for Java Design Element (either open an existing .java file or create a new one, you just need to be in the Java Editor. (or alternatively switch to the 'Java' perspective)
Then press 'Ctrl + Shift + T' which is the shortcut for the 'Open Type' dialog.
The Open Type dialog lets you search for a Java Class and will open the Source if it can do so. In this case we won't be able to open the source, but it will tell us where it is getting the .class file from.
The Open Type search will show you matching classes for your search, and if you click one of the classes, it will show you the location of the class/source in the field at the bottom of the dialog.
Related
Using the Domino/Notes API, when importing DXL design elements (for example a LotusScript agent), you have the option to either compile LotusScript code at the time of import, with DXLImporter.setCompileLotusScript(boolean flag), or leave the code uncompiled. If you leave the code uncompiled, then Domino will compile the code before first use. This is all fine with LotusScript.
Reading the API, I see no option for Java code. How can you compile Java code for use after importing from DXL programmatically?
(The question is not how you do it manually (like open every Java design element and save it to force compilation) but how it can be done programmatically)
You're going to need to do something along the lines of what the ODP to NSF compiler does https://frostillic.us/blog/thread.xsp?thread=NSF+ODP+Tooling. For obvious reasons (OSGi dependencies, Java library accessibility, builder processes etc) it's not a trivial task.
In Lotuscript you can manipulate design elements - create them, change them, rename them, etc.
Are you able to do the same thing for Xpages and custom controls design elements?
====================================================================
My question should have been clearer. What I want to accomplish is to copy an existing cc and give it a new name, programatically. The app will then close and reopen (or refresh or get rebuilt) so that the app can "see" the new cc. If I copy the cc it will only have one field on it. I will add custom code later. I could just create a new cc with no code in it, that would work too.
I am not familiar with the DXL exporter but I can research it. Using that can I just export the design of the cc to an XML file in a temp directory, use the transform to change the name, and then import the control?
I think the XPage or Custom Control design elements are probably under MISC_CODE or MISC_FORMAT design elements in a NoteCollection.
However, accessing that design element is the easy part. Doing a create / rename / change etc is a much bigger task.
Remember that the XPage or Custom Control XML file is only a starting point:
XPages and Custom Controls also have a .xsp.metadata file, as you'll see with source control.
Custom Controls will also have (and need) a .xsp-config file.
There are corresponding .java files for every XPage and Custom Control in the Local source folder. They're created by a builder based on parsing the XML. I don't think you'll be able to create those programmatically. I'm not sure of the impact of renaming them.
For Custom Controls, even if you can rename the .java file, it's referenced in the .java files of relevant XPages. Updating those is goiong to be a significant task.
The XPages runtime doesn't even use those .java files. Instead it uses the .class files in WebContent\WEB-INF (you need to use Project Explorer view and modify the filter to see those files). This is compiled byte code, so you won't be able to update the .class files for XPages containing renamed Custom Controls, as far as I know.
Even if you can rename the .class files, the XPages runtime almost certainly won't use them until either a Clean (which will overwrite anything you've done) or an HTTP restart. As far as I can tell they're cached.
Depending on your use cases, it's possible not all these points will be an issue, e.g. if you're modifying the XML files and building with headless designer.
I suspect this is why nothing was added to the NoteCollection object or a specific NotesXPage / NotesCustomControl API class added.
In Lotuscript you can manipulate design elements - create them, change them, rename them, etc.
This is only partially true. There is a LS API to create/alter views and outlines. Good luck with other design elements - although they're standard "notes", so you can access their items, in most cases you won't compile them and there will be some problems with signatures (real experience with TeamStudio CIAO).
Your question has two points of view - do you want to alter design elements in design process or alter running application?
To help a designer you can go the way of Eclipse extensions and enrich tools in IBM Designer to help developer. Something like TeamStudio Designer. In this case you need to look for source design elements, mentioned by Paul.
To enrich application you don't need to alter source design elements. IBM Designer transforms XML in source code to a Java code (JSF framework) - so you can generate your Java code from anything you wish. Take a look inside Local\xsp folder of NSF in Package explorer. You will find Java sources made from your XPages and Custom Controls. So if you don't need to work with design elements, go for Java components - they can be built on the fly.
And of course, there is always the option of DXL framework - so you can clone/alter design of the application through XML transformations. Good starting point: http://www-10.lotus.com/ldd/ddwiki.nsf/dx/ls-design-programming.htm
I have noticed that lately our xpages application build/compilation time has gone drastically up. It can even take almost whole minute to clean application.
It is quite complex app with some controls (custom controls and java controls) and a lot of legacy code (js, ls, java), but similar app build in pure ecplise with the same amout of java code (which is the only part of this app that changes) cleans in less than 3 seconds ...
I have done a bit of research with rcp debug console and noticed that while cleaning there is some insane traffic that sums to 15000 transactions (and this database has only like 300 design elements that contains code at all!)
The log looks like this repeated over and over again:
...
[1240:0007-03E0] (13586-124 [14561]) OPEN_NOTE(REPC12579BB:0033C2FE-NT00003052,00400000): 0 ms. [48+17446=17494]
[1240:0007-03E0] (13587-124 [14562]) OPEN_NOTE(REPC12579BB:0033C2FE-NT00006C12,00400000): 1 ms. [48+32118=32166]
So my question is:
Does this mean that xpages builder is really badly written or maybe I do not know something?
Are you doing Project - Build or Project - Build All. If the latter and you have multiple NSFs open, then the build will run for all apps. You can close the apps in Package Explorer.
When you say there are 300 design elements, is that the number you see in the Applications Navigator? Bear in mind that's just a drop in the ocean of the actual files being built. Package Explorer will show there are additional Java and xsp-config files for each XPage and Custom Control. These are the Java classes compiled down from the XML markup you see in the XPages and Custom Control design elements. But this is not all that gets built. The server or local database cannot run .java files. It needs to run .class files compiled for the relevant platform. In addition, there are other .class files that need incorporating into the application at compile time, which can be seen by selecting Project - Properties in the Package Explorer view. If you have localization, there are still more files for each language for each XPage / Custom Control. And of course there are files like xsp.properties, an activator .java file and .class file.
The XPage builder may seem badly written because these files need creating. But it is actually very clever, because we don't need to write Java and we don't need to define all the relevant Java files the application is dependent on. We don't need to create a new XSPInput or whatever the Java classes are for the various controls. We can just drag and drop, set the properties from pretty panels which give us drop-downs or Boolean selectors etc. Without those the build time for the app after each save would be quicker, but the development time would be slower.
Its appears after all that there is a solution to build time problem - its the new Domino Designer 9. After upgrading to public beta version the build times dropped drastically (to just few seconds)!
I made a discovery some time back. Just follow these steps:
Create a .doc/.xls/.ppt file in office 2003. Keep some test data in there and close the file. Now rename the file to change it's file extension to a random string, taking care that it is unassociated, like test.asdfghjkl etc.
Double click the file and it opens seamlessly in the parent application.
Now AFAIK, windows checks the file extension of the file and uses it to do an action, viz open an application and pass the file to it to open. Then how does the office suite manage to do this?
EDIT: How about the case when the extension is changed to one that is associated with another application. Is there a priority algorithm in place for handling that ?
Do you have the "View extensions for known types" option on?
EDIT: #Comments....
Yes, its a stupid/insulting question, but when troubleshooting a problem I have learned to assume nothing, and trust the users 0%.
BUT, I tried it, and you're right. Its stupid that MS has this kind of behavior, and it can only lead to security vulnerabilities, which led me on a search for your answer.
From the posts at http://seclists.org/fulldisclosure/2007/Jan/0444.html
"You have stumbled on an age-old
quirky behavior of Windows. Office
document formats are based on a
standard Windows container format, OLE
structured storage files, also known
as "docfiles". A docfile's name and
extension are irrelevant - the file
is, conceptually, a serialization of
an OLE object, and like all
serialization formats it contains the
identifier of the application that
produced it, in the form of an OLE
class id (in GUID format) in this
case. You can easily verify that it
doesn't work with the newer Office XML
formats"
Indeed it doesnt work for the 2007 *X file types, but 2K3 is still a problem. To solve this problem... Upgrade! =)
And here at security focus under TOC point 2.
So, there you go.
I can't seem to make this happen now, but I know I saw Windows reading XML processing instructions a few years back. Maybe that is what's going on?
I am using a UI component from J2ME Polish. I found a simple bug in the code, and want to quickly fix it but cannot find any build scripts in the download package, although source-code is included.
The problem cannot be solved by extending the class as it involves members with private access.
How should I go about fixing it? Should I simply compile the class in question with Javac or should try to locate build script in their repository?
There is no binary code for J2MEPolish UI library, because these classes are also preprocessed during your application compilation. This is why there is also no build script for J2MEPolish UI part - the resulting binary, if it compiles, would not make any sense :)
If you are using this UI class directly (there is no Polish magic involved) I would suggest to copy it into your own project, make the changes there and you should be just fine.
But there is a small issue. I'm not 100% sure, but Polish build process should be as follows: first your classes are preprocessed and then Polish classes will be preprocessed. If the UI component, that you copied into your project, will stay in the same java package, it could happen that your changes will be overwritten by buggy Polish implementation. You can check it by running the application or looking at the final java code in build directory.
If the overwriting problem happens, then you have two options - move UI class in your project into different package (I'm 99% sure this should be fine if you use it directly) or you need to modify Polish build process, so that it would preprocess Polish classes first and you could overwrite changes done by it.
/JaanusSiim
I know this question has been answered and accepted but an easier method would be to used their built in property (for any one coming here via the magic search engines)
polish.client.source=/projecthome/j2me-polish-source
which is simply a copy of their sources packaged with the installer. You can copy this into your own source tree and thus have version history of your changes.
While JaanusSiim's method might work I would not recommend it as it becomes confusing having de.enough.** packages in your own source tree I normally create a src for my personal source and a src-j2mepolish for their source files this was it is VERY explicit what I have added to the standard versions.