Showing posts with label Vista. Show all posts
Showing posts with label Vista. Show all posts

Wednesday, November 26, 2014

Cannot Uninstall JavaFX SceneBuilder 1.0 with JDK 8

I was recently removing some of the software development applications, tools, and files I had used from an old Vista-based laptop because the people who are primarily using that laptop now have no interest in software development. As part of that effort, I tried to remove JavaFX Scene Builder 1.0, which I had installed a couple of years ago on that laptop. I hadn't used it recently (JavaFX Scene Builder 2.0 is available) but I had not removed the version from the laptop when I stopped using that old version.

My first attempt to remove JavaFX Scene Builder 1.0 was via the Windows Vista menu option Control Panel | Programs | Uninstall a program. The next screen snapshot shows this version of JavaFX Scene Builder 1.0 that I wanted to install along with the version of Java installed on that machine (JDK 8 and Java 8 JRE). No versions of Java (JDK or JRE) before Java 8 were on this machine.

The next screen snapshot demonstrates the normal requested confirmation of the removal of JavaFX Scene Builder 1.0.

Clicking the "Yes" button on the confirmation dialog just shown led to the removal process beginning.

Unfortunately, the removal of JavaFX Scene Builder 1.0 aborted and showed the error message: "No suitable 32-bit Java Runtime Environment (JRE) has been found. You should install Java 6 Update 29 (32-bit) or above OR Java 7 Update 2 (32-bit) or above."

I was a bit surprised that JavaFX Scene Builder could not be uninstalled with a Java 8 JRE installed on the machine. I tried to uninstall it more than once to make sure, but it was resistant to removal with only JRE 8 installed. I ended up simply removing the JavaFX Scene Builder 1.0 directory with Windows Explorer as shown in the next screen snapshot.

Because I could not use the uninstaller to remove JavaFX Scene Builder 1.0, I also needed to manually remove the shortcut as shown in the next screen snapshot.

It was not a big deal to remove the directory and shortcut when the installer was unable to remove JavaFX Scene Builder 1.0 from this machine. It also would not have been too difficult to download and install a Java SE 7 JRE to use in uninstalling JavaFX Scene Builder. However, I was a bit surprised that it was written so that an appropriate version of JRE 6 or JRE 7 was required. It explicitly prevents JRE 8 or any future JRE from being used to uninstall it.

I saw this same type of situation recently with a different tool in a different environment. In that case, the version of SQLDeveloper being used would only work with a certain specified range of updates for Java SE 6 and not for any Java SE 6 updates outside of that range and not for any versions of JDK 7 or JDK 8.

Conclusion

There is a software development reminder (or lesson to be learned) from this. It is easy as humans to think only about the current timeframe and about the past, but we as software developers should put some thought into what the future holds. The prevailing version of software is not always going to be the prevailing version and when our software's documentation or the software itself advertises supporting certain versions "and above" or "and later," then we should probably not put an explicit check in our code that forces the software to have the one of the expected major revisions or that caps the supported versions.

Friday, January 1, 2010

Finding Files by Name with Groovy

I recently was trying unsuccessfully to burn some files to a DVD with my Vista-based laptop. Thanks to a Google search, I found a helpful page at TroubleFixers.com that indicated that this particular error might be caused by a dollar sign ($) in a filename extension or by the machine going into sleep mode during a mastered disc writing. Because I was having difficulty getting the Vista search to do what I wanted (probably more my fault than Vista's), I turned to a Groovy solution for finding files with $ in their name.

fileFind.groovy

#!/usr/bin/env groovy
// fileFind.groovy
//
// Find a file with recursive directory search.
//
// There are certain rules to be observed when providing the substring to be
// searched for in file names:
// Escape the $ character with a slash.
//
if (args.length < 2)
{
println "Need to specify directory to be searched and the substring of file."
println "\tUSAGE: fileFind <directoryPath> <fileNameSubString>"
System.exit(-1)
}
def directoryName = args[0]
def fileSubStr = args[1]
def filePattern = ~/${fileSubStr}/
def directory = new File(directoryName)
if (!directory.isDirectory())
{
println "The provided directory name ${directoryName} is NOT a directory."
System.exit(-2)
}
println "Searching for files including ${fileSubStr} in directory ${directoryName}..."
def findFilenameClosure =
{
if (filePattern.matcher(it.name).find())
{
println "\t${it.name} (size ${it.size()})"
}
}
println "Matching Files:"
directory.eachFileRecurse(findFilenameClosure)


The above script will print out the name of any file it finds matching the provided string. If I pass $ to it without escaping the dollar sign, all files in the directory are returned. Using backslash to escape the dollar sign accomplishes what I want (only files with $ in their name). The next two screen snapshots demonstrate this.

Finding All Files with Unescaped $



Finding Only Files with $ in Their Name




If the purpose is to delete these files that match, that is very easy to add to the above script. In a "production" quality script, I'd add some optional deletion verification. For now, I'm going to live on the edge and add capability to automatically and without verification delete the matching files. Don't try this at home!

fileFindAndDelete.groovy

#!/usr/bin/env groovy
// fileFindAndDelete.groovy
//
// Find a file with recursive directory search and delete any matching files.
//
// There are certain rules to be observed when providing the substring to be
// searched for in file names:
// Escape the $ character with a slash.
//
if (args.length < 2)
{
println "Need to specify directory to be searched and the substring of file."
println "\tUSAGE: fileFind <directoryPath> <fileNameSubString>"
System.exit(-1)
}
def directoryName = args[0]
def fileSubStr = args[1]
def filePattern = ~/${fileSubStr}/
def directory = new File(directoryName)
if (!directory.isDirectory())
{
println "The provided directory name ${directoryName} is NOT a directory."
System.exit(-2)
}
println "Searching for files including ${fileSubStr} in directory ${directoryName}..."
def findFilenameClosure =
{
if (filePattern.matcher(it.name).find())
{
println "\tDeleting ${it.name} (size ${it.size()}) ..."
it.delete()
println "\t${it.name} deleted."
}
}
println "Matching Files:"
directory.eachFileRecurse(findFilenameClosure)


I simply changed the closure to delete the files with matching names. The output of this script looks like shown in the next screen snapshot.

Find and Delete Files Matching Name via Groovy




The above scripts took advantage of Java APIs (such as java.io.File and Java regular expressions support with classes like java.util.regex.Matcher) and Groovy goodness (such as Groovy's GDK-provided File support, Groovy's regular expression support, closures, and more concise syntax).


Conclusion

Groovy is so easy to apply that it didn't take me much longer to write and use a Groovy script to delete the necessary files than it would have taken me to figure out how to do the same thing via Windows and then delete each of those found files. This was a situation where scripting works better than manual handling and Groovy makes that scripting easy.

Tuesday, June 10, 2008

A Second Look at JMX Web Services Connector: winrm

In A First Look at JMX Web Services Connector (also available as a previous blog entry), I demonstrated using JConsole to access a simple sample server using the reference implementation of the JMX Web Services Connector (JSR-262). In this blog entry, I am going to scratch the surface of using Vista's winrm (a WS-Management implementation) to access an MBean server using the JMX Web Services Connector.

Although I primarily use a Vista-based laptop for my blogging and other "outside of my day job" work, I have not used winrm previously and so much of the challenge for me in working out examples of accessing the JMX Web Services Connector without a Java client was trying to understand how winrm works. In this blog entry, I'll use examples from the thorough Java Management Extensions (JMX) Interoperation With Non Java Technologies document (written by Jean-Francois Denise and Daniel Fuchs) and add some descriptive text to describe how select commands from that document work. Before moving on, I'll reiterate that the this JMX Interoperation with Non Java Technologies PDF includes significantly more background and examples than the two I'm focusing on here.

For my example, I'm running the simple sample server that is bundled with the JSR-262 reference implementation. There is an Ant build.xml file included in the jsr262-ri\samples\simple\server directory that can be run without options to start the server portion. The next screen snapshot shows this:



As I did for running the JSR-262 reference implementation simple sample server, I'm going to use the Command Shell for running the winrm client side portions. It is vital in Vista that you start this shell as an administrator. Running Command Shell as an administrator is demonstrated in the next screen snapshot and is done by right-clicking on a shortcut for the Command Shell and selecting "Run as administrator."



For the client side, it is necessary to configure winrm by using the winrm qc (or winrm quickconfig) command. This and three other commands that should be run to configure winrm properly for the example are spelled out in the "Windows Vista WinRM Set up" section of the JMX Interoperation with Non Java Technologies document.

While in the JMX Interoperation with Non Java Technologies document, refer also to the section "Extras - WinRM Command Line Tool Examples" (toward the end). This section contains many direct winrm (no VBScript required) commands that can be run against the simple server started earlier. This is an easier way to see winrm work as a WS-Management implementation with the JMX Web Services Connector than trying to use VBScript (though the document contains VBScript code snippets as well).

One of the highlighted "extra WinRM Command Line Tool Examples" is the command to obtain MBean Server domain names. It is as follows:


winrm get http://jsr262.dev.java.net/MBeanServerResource -fragment://:Domain -r:http://127.0.0.1:9998/jmxws -a:None


This can appear a little cryptic when not used to winrm syntax. A good starting point for learning to use winrm is its usage information. You can get usage/help information by entering winrm -? (or winrm help) at the command-line. This shows, for example, that the get command used above could also have been expressed as simply “g” and is used for getting or retrieving management information. Likewise, the invoke or “i” is used to execute an operation on the managed resource.

To get more information on the get command, one can enter winrm help get and the usage displayed shows that a RESOURCE_URI should be passed to the get command.

In the example above, there is a clause –fragment://:Domain. The command winrm help switches provides more details on this. The help for –fragment:VALUE tells us that this option is used to specify a portion of the instance XML file. In this case, the value is //:Domain which corresponds to any Domain element in the XML structure (the // is XPath syntax for recursive search and : is XPath syntax for namespace separator).

The winrm help remoting command tells us what the –r option (or –remote) option does. The –r:VALUE command specifies the remote endpoint. As used in the example above it is a URL consisting of four pieces: transport, host, protocol, and prefix.

The final option in the command above is –a:None. The –a (or –authentication) option is used to specify the authentication mechanism used and is None in this example, but could have been Basic, Digest, Negotiate, or Kerberos. More information on the authentication mechanism can be found using the command winrm help auth.

Another useful winrm command that can be used against the JMX Web Services implementation allows us to retrieve the ObjectNames of all registered MBeans:


winrm enumerate http://jsr262.dev.java.net/DynamicMBeanResource -returnType:EPR -r:http://127.0.0.1:9998/jmxws -a:None


Some of this is the same as the previous command analyzed here. The –r (remote) option takes the same URL as before and the –a:None indicates that we don’t want any authentication employed for this example.

A difference in this example from the last one is the use of enumerate instead of get. Using winrm help enumerate provides information on its usage and explains that this option allows application of a filter to the returned results. In this case, one of enumerate’s options (-returnType=VALUE) is set to EPR which means that only end point references (applicable Resource URI and selectors) are displayed. The other two objects are object form (hierarchical presentation of object values) or ObjectAndEPR (a combination of the other two).

I'll show the full output of the most concise of these return types (EPR only) here:


EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=Memory

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=GarbageCollector,name=Copy

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = DefaultDomain:type=Sample

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=MemoryPool,name=Code Cache

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = com.sun.xml.ws.util:type=RuntimeVersion

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = com.sun.xml.ws.transport.http:type=HttpDump

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=Runtime

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=ClassLoading

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=MemoryPool,name=Perm Gen [shared-rw]

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=Threading

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.util.logging:type=Logging

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=MemoryPool,name=Perm Gen [shared-ro]

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=Compilation

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=MemoryPool,name=Eden Space

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = com.sun.management:type=HotSpotDiagnostic

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=GarbageCollector,name=MarkSweepCompact

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=MemoryPool,name=Survivor Space

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=MemoryPool,name=Tenured Gen

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=MemoryPool,name=Perm Gen

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=OperatingSystem

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = JMImplementation:type=MBeanServerDelegate

EndpointReference
Address = http://127.0.0.1:9998/jmxws
ReferenceParameters
ResourceURI = http://jsr262.dev.java.net/DynamicMBeanResource
SelectorSet
Selector: ObjectName = java.lang:type=MemoryManager,name=CodeCacheManager


The object version and object+EPR versions are significantly longer than this and I won't show them here.

So what's the big deal about all of this? The big deal is that this demonstrates the use of a non-Java client (in this case Windows Vista winrm) to access Java Management Extensions on the server. With the JMX Web Services Connector, you no longer need a Java-based client to monitor and manage JMX-instrumented resources (including the JVM itself)!

Saturday, March 22, 2008

Comparing Unix/Linux, PowerShell, and DOS Commands

The following lists some of my favorite Unix commands and maps the associated PowerShell and DOS commands, if any. If there is one Unix command I would love to have in PowerShell, it is the grep command with its regular expression support. I have noticed significant improvement in Vista's search capabilities compared to earlier versions of Microsoft operating systems that I have used and I would love to see that harnessed in PowerShell so that I could use it from the command line. The table appears a ways down, so scroll down to it.

UPDATE (24 March 2008): Note that I have updated this table with information on a grep equivalent and on the availability of less as an extension. Thanks to Kirk Munro for pointing both of these out (see Comments) and to Jeffrey Snover for his write-up of Select-String at http://blogs.msdn.com/powershell/archive/2008/03/23/select-string-and-grep.aspx.
Thanks also to Marco Shaw for pointing out that start-transcript (which can be closed with stop-transcript) provides functionality like Unix's script command. Thanks to Jonathan for mentioning tasklist as an alternative to ps and mentioning F7 for a graphical presentation of history commands.
























Unix/LinuxPowerShellWindows Vista DOS
lsls
dir
dir
cpcp
copy
copy
mvmv
move
move
rmrm
del
del
netstatnetstatnetstat
manman
help
help
psps
tasklist
tasklist
fingerfingerfinger
script
(stop with CTRL-D)
start-transcript
(stop with stop-transcript)
 
clearclear
cls
cls
catcat
type
type
history / hhistory / h
F7
F7
unzipunzipunzip
zipzipzip
teetee 
grepSelect-String 
moremoremore
lessless (extension) 
editeditedit
killkill
taskkill
taskkill


Type ‘man’ without any options in PowerShell command-line
to see long list of supported commands and scripting keywords.



The Windows PowerShell Quick Reference and Getting Started with Windows PowerShell are also useful resources.

Saturday, February 23, 2008

Hello Windows PowerShell

I have been frustrated for some time with DOS scripting. Fortunately, a colleague pointed me to Microsoft PowerShell (formerly known as Project Monad) for Windows XP and Windows Vista. PowerShell can be downloaded here and there are several scripts for use with PowerShell provided here. You can also download the Windows PowerShell Owner's Manual.

One of the things that is nice about PowerShell is that is supports many of the commands that we like to use in Unix/Linux. There are far too many useful things to demonstrate about PowerShell in one place, but the next two screenshots (click on them to see larger versions) demonstrate some Unix-like commands supported in Windows PowerShell.

The first screen snapshot demonstrates the very handy history command along with the ability to run a man (equivalent to help) command for a particular command.



The next screen snapshot shows the ls command along with the mv command. Having Unix equivalents makes it less frustrating to switch between Unix/Linux and Windows. Also, the ls and mkdir commands demonstrate the displaying of file modes.



Besides the Unix/Linux commands shown in the screen snapshots above, other goodies that are now available in PowerShell include pwd, ps, and cat. It is amazing how nice it is to have these little "extras" in the DOS scripting world.

Windows PowerShell requires .NET framework 2.0, so you'll need to get this if you don't already have it. There is much, much more to Windows PowerShell than what I've shown here so far. I think it is likely that I'll post future blog entries on other great features of PowerShell. It is even more likely that I'll start using PowerShell more frequently in my blog entries that show me running scripts, Java commands, the Flex compiler, etc. from the command line rather than using the old-style DOS terminal.

In related resources, Vaibhav discusses running PowerShell from Java. An interesting related article is A Return to Command-Line Control with Windows PowerShell. A free Windows PowerShell eBook is available as well. Finally, two other introductory references for using PowerShell are What is Windows PowerShell? and Top Ten Tips for Using Windows PowerShell Finally, a gentle introduction to Windows PowerShell is available in Discover PowerShell.

Monday, January 28, 2008

Making jps and jconsole Work with Java SE 6 on Windows Vista

I recently discovered that the JConsole tool stopped automatically detecting local processes in the JVM in which it was running. I knew that, at the very least, it should show itself in the connection window. The issue was resolved based on the useful information provided by Luis-Miguel Alventosa in the SDN JMX forum thread Cannot see local process list in JConsole in of JDK 6. This blog entry summarizes the recommended steps and displays how the problem was fixed. Note that another forum entry that references the forum entry linked to above is JMX - jconsole connects to local vm only if given PID.

The problem with JConsole was tied to jps as well. This was especially problematic because I could always use JConsole to connect to a particular PID, but I wanted to use jps to help me find that PID. I blogged about the usefulness of jps in this blog entry.

I followed the instructions in the JMX - Cannot see local process list in JConsole of JDK 6. My first screen shot shows the results of running jps. Note that there is no PID shown even though at least jps itself should be shown.



The next screen shot shows that JConsole cannot find any local instrumented Java applications even though it should, at the very least, find itself.



As the above screen shot (two above) demonstrates, I used the echo %TMP% command to determine what the TMP environment variable was set to. I navigated to that directory and went into the hsperfdata_Dustin folder (shown in the next screen shot).



I don't show it here, but I went into the Vista properties for the hsperfdata_Dustin directory and enabled permissions on that directory (they were ALL off). The next two screen shots demonstrate that JConsole and jps now worked for me again.





JConsole and jps weren't working simply because Vista wasn't letting me change files in that %TMP%/hsperfdata_Dustin directory. Once I opened up permissions on that directory, both jps and jconsole worked as expected.

UPDATE (25 November 2008): The blog entry JMX Examples Don't Work Under Windows discusses how the characters used in the TMP environment variable can adversely affect the ability of JConsole to "see" managed applications.