<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Hi Johan,</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Thanks as always for the explanation, and some of the history on this. I'll go the jmods route to avoid this. Agreed a warning on this <i>somewhere</i> would be good, as it's not something developers typically need to consider.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Kind Regards,</div><div class="gmail_default" style="font-family:verdana,sans-serif">Cormac</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 9 Feb 2025 at 10:56, Johan Vos <<a href="mailto:johan.vos@gluonhq.com" target="_blank">johan.vos@gluonhq.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Cormac,<div><br></div><div>I understand the problem, and I agree it can be really annoying. It either needs better communication, or a fix. The maven artifacts are something we added with Gluon (hence not Oracle). As you said, windows signing certificates come with a price (and building hassle).</div><div>The reason we started uploading those artifacts is mainly because developers are very used to the maven artifact approach during development. I believe this lowered the bar for JavaFX development after the JDK didn't ship with the JavaFX code anymore. A developer who just wants to explore using JavaFX is less likely to download an additional SDK or jmods. Simply adding a few lines in a pom.xml is something most developers are familiar with.</div><div>For shipping applications, I strongly discourage this, and highly recommend the SDK/jmods approach. I can see now though that offering the "maven artifacts for developers" created higher expectations than intended.</div><div><br></div><div>The problem you described is more or less documented in <a href="https://bugs.openjdk.org/browse/JDK-8316276" target="_blank">https://bugs.openjdk.org/browse/JDK-8316276</a> . There have been discussions (e.g. on the jigsaw list) in the past about this, as other projects (e.g. dl4j) have similar issues with jars containing native code. There is no standard approach in Java to deal with this, which is why the NativeLibLoader contains a bunch of logic that allows to invoke the code in the native libs from the classes in the same jar. That logic has been modified over the years, to account for specific issues (e.g. [1] and [2]), but it's not perfect. </div><div><br></div><div>I'm not against signing those libraries (it is a net loss of money and time though), but as you noticed yourself, this won't fix all problems. We should probably make it more clear that the maven artifacts should not be used in production systems, and are for development only -- for developers by developers.</div><div><br></div><div>- Johan</div><div><br></div><div>[1] <a href="https://bugs.openjdk.org/browse/JDK-8317308" target="_blank">https://bugs.openjdk.org/browse/JDK-8317308</a></div><div>[2] <a href="https://bugs.openjdk.org/browse/JDK-8307536" target="_blank">https://bugs.openjdk.org/browse/JDK-8307536</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 8, 2025 at 10:01 PM Cormac Redmond <<a href="mailto:credmond@certak.com" target="_blank">credmond@certak.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:verdana,sans-serif">Hi Steve,</div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">Thanks. I can also workaround it (with very limited changes) in another way by overriding <span style="color:rgb(0,0,0)">javafx.runtime.version with something specific to my app, and its version (which will ultimately dictate the cache directory name) -- as the chances of having a clash then, are astronomically low.</span></div><div style="font-family:verdana,sans-serif"><span style="color:rgb(0,0,0)"><br></span></div><div style="font-family:verdana,sans-serif"><span style="color:rgb(0,0,0)">However, none of these things are solutions, but workarounds -- my stance is that it should not be up to the developer to firstly know this problem even exists (most won't), and then to workaround it by avoiding using certain JARs. It's not like we're building apps in un-documented or unusual ways, quite the opposite.</span></div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">Kind Regards,</div><div style="font-family:verdana,sans-serif">Cormac</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 8 Feb 2025 at 18:16, Steve Hannah <<a href="mailto:steve@weblite.ca" target="_blank">steve@weblite.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">This also doesn't seem to affect apps running with the zulufx distributions (the JRE with JavaFX bundled).<br><br>E.g. this build of JavaFX ensemble <a href="https://www.jdeploy.com/~jdeploy-demo-javafx-ensemble" target="_blank">https://www.jdeploy.com/~jdeploy-demo-javafx-ensemble</a><br>It uses Java 19, and OpenJFX 20, and it doesn't seem to create an .openjfx directory anywhere that I can find.<br><br>Therefore, you can deploy your app using jDeploy and it won't have this issue. (Disclosure, I'm the creator of jDeploy). Similarly, if you bundle your app with a ZuluFX distribution, and strip out your maven jars (which is what jDeploy does), you won't have this issue.<br><br>Steve</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 8, 2025 at 9:35 AM Cormac Redmond <<a href="mailto:credmond@certak.com" target="_blank">credmond@certak.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">Hi,</div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">Thanks for the reply. Yes -- my project uses JFX JARs rather than jmods (as many do). And the clashing application in question, must be the same. But this is a real problem that occurred with a real user, and I only have a handful of users.</div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">Oracle signing the JFX DLLs, while an improvement, would still leave the following problems wide open:</div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><ul><li>There's no way to stop a developer (or some build tool) from re-signing or removing signature from signed DLLs, in which case this problem can still re-occur</li><li>In the event of a genuine difference of a DLLs (under the same cache folder version), if the DLL cannot be deleted (to be replaced), because a running application application is using it -- a completely feasibly scenario -- then we have one application breaking another.</li></ul><div>Also, the developers shipping apps are in full control of the JFX JARs, their DLLs, and the *reported" javafx.version and javafx.runtime.version. E.g., I could have JFX 21.0.5 in a JFX 23.0.2 cache folder if I wanted simply by changing javafx.runtime.version (or javafx.cachedir).</div><div><br></div><div>It's far too brittle.</div><div><br></div></div><br clear="all"></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><font color="#000000" face="verdana, sans-serif"><br></font></div><div><font color="#000000" face="verdana, sans-serif">Regards,</font></div><div><font color="#000000" face="verdana, sans-serif"><b><br></b></font></div><font color="#000000" face="verdana, sans-serif"><b>Cormac Redmond</b></font><div><font color="#000000" face="verdana, sans-serif">Software Engineer, Certak Ltd.</font></div><div><font color="#000000"><b><br></b></font></div><div><font face="verdana, sans-serif" size="2">e: <a href="mailto:credmond@certak.com" target="_blank">credmond@certak.com</a> | m: +353 (0) 86 268 2152 | w: <a href="http://www.certak.com" target="_blank">www.certak.com</a></font></div><div><br></div><div><br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 8 Feb 2025 at 12:49, Christopher Schnick <<a href="mailto:crschnick@xpipe.io" target="_blank">crschnick@xpipe.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>I think that went a bit under the radar as this only occurs when
using the maven dependencies. The SDK and jmod downloads do not
have that issue as they don't copy DLLs into any temp directory.
Only the maven jars have to do this.<br>
<br>
About signing any JavaFX DLLs, that would indeed be a good
addition considering all other JDK DLLs are signed.<br>
<br>
Best<br>
Christopher Schnick<br>
</p>
<div>On 08/02/2025 13:31, Cormac Redmond
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">Hi,</div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br>
</div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">I
am surprised nobody else sees this bug as a
higher-priority conversation point. </div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">
<div><br>
</div>
<div>It's troubling to see how
running one self-contained application can break another
self-contained application (because of a cache that most
JFX devs wouldn't even know exist).</div>
<div><br>
</div>
</div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">If
one well-behaved JFX application cannot delete/replace a
file JFX cache on start-up, because another well-behaved
JFX application is using that cached file (it will be if
built on the same JFX version) -- then the application
will not run, at all. </div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br>
</div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">And
as I explained earlier, this is a likely occurring
scenario in the wild -- the only reason this bug isn't
more prevalent /reported / noticeable, is that it's not
too likely for a user to have two JFX applications using
the same JavaFX version, on their machine. But that's down
to pure coincidence / chance. I wouldn't say the same for
Electron or Flutter, etc. If they had this bug, it would
be noticed and it would be news.</div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br>
</div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">Also,
the creators of these applications would have no idea that
their application is not starting, nor would the users
know why.</div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br>
</div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">By
the way, the problem is not just about *signed* DLLs +
checksums, obviously. It would occur if the DLLs are
different for any other reason too, obviously, and the
authors of NativeLibLoader thought this possibility is
high enough to do the checksum + delete + replace check.
The application shouldn't silently fail because of a cache
management bug.</div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br>
</div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br>
</div>
<br clear="all">
</div>
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div><font color="#000000" face="verdana, sans-serif"><br>
</font></div>
<div><font color="#000000" face="verdana, sans-serif">Regards,</font></div>
<div><font color="#000000" face="verdana, sans-serif"><b><br>
</b></font></div>
<font color="#000000" face="verdana, sans-serif"><b>Cormac
Redmond</b></font>
<div><font color="#000000" face="verdana, sans-serif">Software
Engineer, Certak Ltd.</font></div>
<div><font color="#000000"><b><br>
</b></font></div>
<div><font face="verdana, sans-serif" size="2">e: <a href="mailto:credmond@certak.com" target="_blank">credmond@certak.com</a>
| m: +353 (0) 86 268 2152 | w: <a href="http://www.certak.com" target="_blank">www.certak.com</a></font></div>
<div><br>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, 6 Feb 2025 at 19:56,
Cormac Redmond <<a href="mailto:credmond@certak.com" target="_blank">credmond@certak.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>
<div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="color:rgb(34,34,34)">Hi,</span></div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">I have found
a "serious" bug, where two completely independent JFX
applications, both with their own embedded runtime
(built with jlink & jpackage) & using the same
JavaFX version, are unable to run simultaneously,
because of the JFX cache -- at least on Windows.</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div><span style="font-family:verdana,sans-serif">When
trying to run any application, <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"></span>NativeLibLoader
does a checksum on DLLs in the cache</span><font face="verdana, sans-serif"> (e.g.: C:\Users\xyz\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll);
and tries to delete any files that exist where the
checksums do not match (in order to replace them):</font></div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> if
(!Arrays.equals(isHash, fileHash)) {<br>
Files.delete(f.toPath());<br>
}<span class="gmail_default" style="font-family:verdana,sans-serif"></span></blockquote>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">But a second
application <u>fails</u> to start, as it is unable to
delete these files because they're in use by the first
application (see stacktrace below).</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">But why are
the checksums different, shouldn't they be the same?
They are different because the DLLs are signed by the
builder of the applications -- different authors and
different timestamps. So the DLL checksums will be
different despite the DLLs being the same, in terms of
the JFX version.</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">Why are
these JFX DLLs signed by the authors? Because for some
reason, they come <u>unsigned</u>, and all DLLs when
packaged <b><u>should</u></b> be signed, including any
embedded in JARs, to avoid alarming Windows Defender
warnings and mistrust, etc. There's no point spending
a small fortune on Windows code-signing certs and
shipping with any unsigned third-party DLLs (including
any embedded in JARs). You might sign your own
binaries and any unsigned third-party binaries.
Similarly for MacOS, everything, including embedded
native libs in JARs, etc., needs to be signed for
gatekeeper & notarization to allow it.</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">So it would
be better if JFX DLLs came signed, to avoid forcing
developers to do it (which would also avoid this
checksum mishap). Or, if developers need to sign
Oracle's DLLs, then this checksum approach isn't
suitable. Also, there should really be a proper
fallback in place -- a cache bug should not have
such a catastrophic outcome.</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">FYI: JLink
also removes signatures from a bunch of JDK DLLs when
assembling the runtime, but leaves a bunch of Windows
DLLs untouched. Personally, I'd prefer all DLLs to
come signed, and let the developers re-sign if they
want. Removing the signatures is adding
unnecessary hurdles for folks, for no benefit I can
see.</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">Anyway,
example stacktrace:</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Loading
D3D native library ...<br>
WARNING: java.lang.UnsatisfiedLinkError: Can't load
library: C:\Program Files\KafkIO\bin\prism_d3d.dll<br>
Loading library prism_d3d from resource failed:
java.nio.file.AccessDeniedException: <span class="gmail_default" style="font-family:verdana,sans-serif"></span>C:\Users\<span class="gmail_default" style="font-family:verdana,sans-serif"></span>x<span class="gmail_default" style="font-family:verdana,sans-serif">yz</span>\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll<br>
java.nio.file.AccessDeniedException: C:\Users\<span class="gmail_default" style="font-family:verdana,sans-serif"></span>x<span class="gmail_default" style="font-family:verdana,sans-serif">yz</span>\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll<br>
at
java.base/sun.nio.fs.WindowsException.translateToIOException(Unknown
Source)<br>
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown
Source)<br>
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown
Source)<br>
at
java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown
Source)<br>
at
java.base/sun.nio.fs.AbstractFileSystemProvider.delete(Unknown
Source)<br>
at
java.base/java.nio.file.Files.delete(Unknown Source)<br>
at
com.sun.glass.utils.NativeLibLoader.cacheLibrary(NativeLibLoader.java:300)<br>
at
com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:218)<br>
at
com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:200)<br>
at
com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:142)<br>
at
com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58)<br>
at
com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54)<br>
at
java.base/java.security.AccessController.doPrivileged(Unknown
Source)<br>
at
com.sun.prism.d3d.D3DPipeline.<clinit>(D3DPipeline.java:50)<br>
at java.base/java.lang.Class.forName0(Native
Method)<br>
at java.base/java.lang.Class.forName(Unknown
Source)<br>
at java.base/java.lang.Class.forName(Unknown
Source)<br>
at
com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218)<br>
at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92)<br>
at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)<br>
at java.base/java.lang.Thread.run(Unknown
Source)<br>
GraphicsPipeline.createPipeline failed for
com.sun.prism.d3d.D3DPipeline<br>
java.lang.UnsatisfiedLinkError: no prism_d3d in
java.library.path: C:\Program
Files\KafkIO;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program
Files\Oculus\Support\oculus-runtime;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;c:\dev\apps\apache-maven-3.9.9\bin;C:\dev\apps\cygwin64\bin;C:\Program<span class="gmail_default" style="font-family:verdana,sans-serif"></span> Files
(x86)\Windows Kits\10\Windows Performance
Toolkit\;C:\Program Files\dotnet\;C:\Program
Files\Git\cmd;C:\Program Files\7-Zip;C:\Program
Files\SafeNet\Authentication\SAC\x64;C:\Program
Files\SafeNet\Authentication\SAC\x32;C:\Program
Files\Docker\Docker\resources\bin;%JAVA_HOME%\bin;;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Users\<span class="gmail_default" style="font-family:verdana,sans-serif"></span>x<span class="gmail_default" style="font-family:verdana,sans-serif">yz</span>\scoop\apps\zulu-jdk\current\bin;C:\Users\<span class="gmail_default" style="font-family:verdana,sans-serif"></span><span class="gmail_default" style="font-family:verdana,sans-serif"></span>x<span class="gmail_default" style="font-family:verdana,sans-serif">yz</span>\scoop\apps\zulu22-jdk\current\bin;C:\Users\<span class="gmail_default" style="font-family:verdana,sans-serif"></span>x<span class="gmail_default" style="font-family:verdana,sans-serif">yz</span>\scoop\apps\zulu21-jdk\current\bin;C:\Users\<span class="gmail_default" style="font-family:verdana,sans-serif"></span>x<span class="gmail_default" style="font-family:verdana,sans-serif">yz</span>
\scoop\shims;C:\Users\<span class="gmail_default" style="font-family:verdana,sans-serif"></span>x<span class="gmail_default" style="font-family:verdana,sans-serif">yz</span>
\AppData\Local\Microsoft\WindowsApps;C:\dev\scripts;C:\Program
Files\JetBrains\IntelliJ IDEA 2024.2\bin;C:\Program
Files\KafkIO\app;.<br>
at
java.base/java.lang.ClassLoader.loadLibrary(Unknown
Source)<br>
at
java.base/java.lang.Runtime.loadLibrary0(Unknown
Source)<br>
at
java.base/java.lang.System.loadLibrary(Unknown Source)<br>
at
com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:170)<br>
at
com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58)<br>
at
com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54)<br>
at
java.base/java.security.AccessController.doPrivileged(Unknown
Source)<br>
at
com.sun.prism.d3d.D3DPipeline.<clinit>(D3DPipeline.java:50)<br>
at java.base/java.lang.Class.forName0(Native
Method)<br>
at java.base/java.lang.Class.forName(Unknown
Source)<br>
at java.base/java.lang.Class.forName(Unknown
Source)<br>
at
com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218)<br>
at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92)<br>
at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)<br>
at java.base/java.lang.Thread.run(Unknown
Source)</blockquote>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">Kind
Regards,</div>
<div style="font-family:verdana,sans-serif"><span>Cormac</span></div>
</div>
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Steve Hannah<div>Web Lite Solutions Corp.</div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</div>