A recent quote from EDS Global Alliances Veep, Robb Rasmussen, might make you wonder if you've ever seen him and George Bush together. Talking about why the Alliance members like Sun and Microsoft don't believe Linux is right for big business (Surprise, surprise!), Robb opined,
"A large enterprise needs to be sure because it relates to securifying the environment. ... it could splinter into many different types of languages."
Well, about all I can think to say about that is HUH?
I just found out we lost one of the great pioneers of modern computing last week. While at Apple, Jef Raskin started the MacIntosh project in parallel with Steve Jobs' PARC-inspired Lisa. Raskin's Mac was character based and keyboard driven, far different from the final product produced after Jobs forced him out. His concepts were then used in the Canon Cat, a computer that didn't last long in the marketplace either because of its unique user interface or Steve Jobs' meddling.
The result of his time spent post-Apple is a UI he called The Humane Interface, about which you can learn more from The Raskin Center For Humane Interfaces. The link below is a Flash demo of the Archy UI that he thought would make computers as usable as humanly possible today. It's a remarkable vision incorporating ideas like the spacial indexing of stored information (it's easier to remember visually where you put something) that stretch back decades to his more recent ideas that you are better off directly manipulating information than you are doing indirect manipulation through proxies like icons.
Best I can tell, WAS (5.0 at least) does not have a JNDI Service Provider that can perform DNS lookups. I'm successfully using the Sun one from http://java.sun.com/products/jndi/serviceproviders.html, but I wanted to confirm that I'm not missing some other option in WAS.
I'm using this technique to do an MX Record lookup to validate an email domain. It's described http://java.sun.com/j2se/1.4.2/docs/guide/jndi/jndi-dns.html#USAGE and http://www.rgagnon.com/javadetails/java-0452.html. Alternatively, if anyone knows of other methods to do this, I'm willing to consider that too.)
Using WSAD 5.1.2 on Win2000 with CVS 1.11 on Linux server. We have
many branches that display in the CVS Perspective that aren't relevant
to our developers anymore such as old dead-end branches that have long
since been merged to the main (HEAD) branch. We would like to be able
to filter out some of these branches so they don't display to the
developer. The only way I can think of is to try to delete the branch
tag (cvs rtag -B -d
To answer my own question, we did the delete branch tag as shown below as well as deleting the "root_xxxx" version tag that wsad creates behind the scenes. It works, but the tags are still "remembered" by WSAD. To completely clear them you have to go into the CVS perspecitive, right-click each project under the Version icon and select Configure Branches and Versions. In this dialog click Remove All.
Looks great at first glance! Add a WYSIWYG HTML editor to your web app.
From: Chemi
Newsgroups: ibm.software.websphere.studio.application-site-developer
An interesting tip from: http://www.eclipsenews.com
When stepping through your code in the Eclipse debugger, it's very frustrating when you inadvertently step into utility code. Normally what happens in that situation is that the Java editor opens with an error telling you that Eclipse can't find the source. This can really mess up your debug session, so it's important to be able to keep the debugger out of utility code.
Eclipse has a preference setting called Step Filtering. You invoke it with Window => Preferences => Java => Debug => Step Filtering. The Step Filtering panel will have the following default list:
To disable stepping into a package's code, click its check box. You can click the Add Class or Add Packages button if you want to add a package or class to the list.
The last and most important part of this tech tip is that to enable step filtering, you need to toggle the Use Step Filters/Step Debug icon. That icon is at the top of the Debug view. It is a yellow arrow that goes right and then forks (visualizing a step into) down.
Thanks, Chemi!
(Answers)From: Paul Ilechko
Newsgroups: ibm.software.websphere.application-server
(Answers)From: Paul Ilechko
Newsgroups: ibm.software.websphere.application-server
(Answers)From: Mike
Newsgroups: ibm.software.websphere.studio
Hello Mike,
Yes, you are correct. My installation is a little messy, that I have installed included WSAD5.1.2, WSDD 5.5.x and others. After I have copied the following DLLs from the zipped package to the win2k system32 directory :-
libdb42.dll
libeay32.dll
ssleay32.dll
Now the subclipse plug-in works perfectly in WSAD5.1.2.
Thank you very much.
John
Hmmm, I thought the instructions on the site are ok, though you have to interpret a bit. Keep in mind I don't use subversion and this does not install subversion you need to obtain and install that separately.
Looks like you had a previous version of WSAD or something installed, the 5.1.2 directory is the one you want I think
For Windows get the .zip file from
http://subclipse.tigris.org/files/documents/906/13512/org.tigris.subversion.subclipse_0.9.3.1.zip
and unpack it, lets say, into your c:\ directory.
End WSAD
Then copy the contents of
c:\org.tigris.subversion.subclipse_0.9.3.1\eclipse\plugins
into
C:\Program Files\IBM\WebSphere Studio\Application Developer\v5.1.2\eclipse\plugins
Well, at least when I did the above I had the option of creating a new SVNExplorer perspective, though I don't have subversion installed so it won't load.
Q.E.D.
Mike
Is there a way to keep the java source code generated by the JSP compiler in a wsad/was 5.1 test environment?
When using a WebSphere Application Server, you can save the generated .java files compiled from JSP files, by adding the following statements to the ibm-web-ext.xmi file in your Web application:
<jspattributes id="/JSPAttribute_1/" name="keepgenerated" value="true" />
<jspattributes id="/JSPAttribute_2/" name="scratchdir" value="/C:\temp/" >
The generated files are stored in the location specified by the *"scratchdir"* property.