Alright. I believe I've finally got this worked out for Windows. Here
goes...
I was determined to figure this out because, well, I'm just wired that way.
:)
I reset all the files back to default and backed all the way up to the Java
Service Wrapper which is used to start Jetty as a Windows service and picked
up on this line:
*wrapper.java.additional.1=-Djetty.home=../ *
**
That told me that "jetty.home" was being set at startup to the directory
above "Jetty-Service.exe" which, true enough, is whatever directory you
unzip the Jetty bundle into. This is similar to starting with "java -jar
start.jar" in that "jetty.home" becomes the directory where "start.jar"
lives. So far so good.
Starting up Jetty, I was back to the "java.io.FileNotFoundException" we've
been fighting with so far. Looking at the file path on that error
"./etc/openbd/bluedragon.xml"
I was drawn to the "./" again which dawned on me (not sure why it hadn't
before) that the path would be vaild on *nix machines, but not for Windows.
Ok, so where was that being set at? The service wrapper was supposed to be
setting "jetty.home" to "../" but it wasn't sticking for some reason. So I
moved over to the "webdefault.xml" which would be next in line to load and
zeroed in on:
<SystemProperty name="jetty.home" default="."/>
Now, according to the documentation on the Jetty site that property only
gets used if it's not already defined which it should be, but it looks like
it's getting overwritten. I'm not sure where the issue is, but I can't
imagine that since they don't supply OS-specific XML files this had to have
worked at one point. I believe I'm going to ping the Jetty mailing list and
see if someone over there can give some insight. Anyway, moving on...
I changed all the "jetty.home" lines in "webdefault.xml" to:
<SystemProperty name="jetty.home" default="../"/>
I then adjusted the OpenBD servlet paths in "webdefault.xml":
<servlet>
<servlet-name>cfmServlet</servlet-name>
<servlet-class>com.naryx.tagfusion.cfm.cfServlet</servlet-class>
<init-param>
<param-name>BLUEDRAGON_WORKING_DIRECTORY</param-name>
<param-value>../logs/openbd</param-value>
</init-param>
<init-param>
<param-name>BLUEDRAGON_XML</param-name>
<param-value>../etc/openbd/bluedragon.xml</param-value>
</init-param>
<load-on-startup>0</load-on-startup>
</servlet>
I fired up the service again and got a clean startup. Cool. Now you can
still unzip to any directory of your choosing and it should work fine
(instead of having to hard code a directory). However, these changes would
either need to be in a "Windows" bundle or be made manually after install.
Lastly, I had to make an adjustment to the "/etc/openbd/bluedragon.xml" file
as well since the customtags were still broke. I just updated the the
highlighted paths to start with "../(The paths which start with "$." by
default)
<cfmlcustomtags>
<mapping name="cf">
<directory>../webroot_cfmlapps/customtags</directory>
<name>cf</name>
</mapping>
</cfmlcustomtags>
<system>
<assert>false</assert>
<runtimelogging>true</runtimelogging>
<debug>true</debug>
<component-cfc>../etc/openbd/component.cfc</component-cfc>
<whitespacecomp>false</whitespacecomp>
<nativelibdir>../etc/openbd/bin</nativelibdir>
<plugin>com.bluedragon.extra.ExtraPackPlugIn</plugin>
<missingtemplatehandler></missingtemplatehandler>
<lastfile>..\etc\openbd\bluedragon.xml.bak.1</lastfile>
<errorhandler></errorhandler>
<buffersize>0</buffersize>
<password>admin</password>
<lastupdated>18/Dec/2008 14:58.39</lastupdated>
<defaultcharset>utf-8</defaultcharset>
<allowedips></allowedips>
<deniedips></deniedips>
</system>
Now, you'd think the above wouldn't work since the "bluedragon.xml" file is
actually one level deeper and those paths would only take it up one
(relative to the bluedragon.xml file), but it definitely works (see below)
so either "../" here is being interpreted correctly as "jetty.home" or the
file is being copied into the same directory as "jetty.xml" and
"webdefault.xml" during initialization. Maybe someone else knows the answer
to that one.
*Total Time* *Avg Time* *Count* *Template* 10 ms 10 ms 1 *
C:/jetty/webroot_cfmlapps/cfmlWebContext_1/dump.cfm* 0 ms 0 ms 1
C:/jetty/webroot_cfmlapps/customtags/testcustomtag.cfm 0 ms STARTUP,
PARSING, COMPILING, LOADING & SHUTDOWN 10 ms TOTAL EXECUTION TIME
Of course, the Windows folks can test this more thoroughly. All of my dev
and prod servers are on Linux.
Again, I hope this helps!
On Thu, Dec 18, 2008 at 12:09 PM, Rob <[email protected]> wrote:
>
> Thanks for your time on this Anthony.
>
> I checked the logs, and you are onto something - there is a difference
> when starting as a service vs. start.jar.
> Start.jar loads cleanly, no errors.
>
> The jetty-service log indicates a clean launch (I had already hard
> coded the paths).
>
> The bluedragon.log file has errors on service start (not on start.jar
> starts).
> Here is the pertinent part when loading from the service:
>
> 18/12/08 06:48.29: -] connection pool validation queries ENABLED
> 18/12/08 06:48.29: -] mailServer started $Revision: 1.1 $ Working in
> [D:\Explorers_Log\logs\openbd\cfmail]
> 18/12/08 06:48.29: -] CFIMAP Caching Engine Initialised.
> 18/12/08 06:48.29: -] cfApplicationManager.DefaultClientStorage=
> [cookie]
> 18/12/08 06:48.29: -] cfApplicationManager.Using J2EE Sessions? false
> 18/12/08 06:48.29: -] Generating UUID for CFTOKEN value
> 18/12/08 06:48.29: -] ERROR - failed to initialize CFREGISTRY.
> 18/12/08 06:48.29: java.io.IOException: Native library does not exist:
> $./etc/openbd/bin/cfregistry.dll
> at com.nary.io.FileUtils.resolveNativeLibPath(Unknown Source)
> at com.naryx.tagfusion.cfm.registry.cfREGISTRY.init(Unknown Source)
> at com.naryx.tagfusion.cfm.tag.tagChecker.initialiseTags(Unknown
> Source)
> at com.naryx.tagfusion.cfm.engine.cfEngine.<init>(Unknown Source)
> at com.naryx.tagfusion.cfm.engine.cfEngine.init(Unknown Source)
> at com.naryx.tagfusion.cfm.cfServlet.init(Unknown Source)
> at org.mortbay.jetty.servlet.ServletHolder.initServlet
> (ServletHolder.java:431)
> at
> org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:
> 263)
> at org.mortbay.component.AbstractLifeCycle.start
> (AbstractLifeCycle.java:42)
> at org.mortbay.jetty.servlet.ServletHandler.initialize
> (ServletHandler.java:643)
> at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
> at org.mortbay.jetty.webapp.WebAppContext.startContext
> (WebAppContext.java:1233)
> at org.mortbay.jetty.handler.ContextHandler.doStart
> (ContextHandler.java:516)
> at
> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:
> 459)
> at org.mortbay.component.AbstractLifeCycle.start
> (AbstractLifeCycle.java:42)
> at org.mortbay.jetty.handler.HandlerCollection.doStart
> (HandlerCollection.java:152)
> at org.mortbay.component.AbstractLifeCycle.start
> (AbstractLifeCycle.java:42)
> at org.mortbay.jetty.handler.HandlerWrapper.doStart
> (HandlerWrapper.java:130)
> at org.mortbay.jetty.Server.doStart(Server.java:222)
> at org.mortbay.component.AbstractLifeCycle.start
> (AbstractLifeCycle.java:42)
> at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.mortbay.start.Main.invokeMain(Main.java:194)
> at org.mortbay.start.Main.start(Main.java:523)
> at org.mortbay.start.Main.main(Main.java:119)
> at org.mortbay.jetty.win32service.JettyServiceWrapperListener.start
> (JettyServiceWrapperListener.java:47)
> at org.tanukisoftware.wrapper.WrapperManager$12.run
> (WrapperManager.java:2788)
>
> 18/12/08 06:48.29: -] cfChart: storage=[file]
> 18/12/08 06:48.29: -] cfChart: storage cache size=[0]
> 18/12/08 06:48.29: -] scheduleEngine started $Revision: 1.1 $.
> Logging in [D:\Explorers_Log\logs\openbd\cfschedule\schedule.log]
> 18/12/08 06:48.29: -] cfCacheContent: InMemoryCache=50
> 18/12/08 06:48.30: -] expressionEngine loaded: 345 functions
> 18/12/08 06:48.30: -] cfEngine: Show Debug output on error? true
> 18/12/08 06:48.30: -] cfEngine: Assertions disabled
> 18/12/08 06:48.30: -] cfEngine: Combined Form/Url Scope? false
> 18/12/08 06:48.30: -] Auto-configure of ODBC datasources is enabled
> 18/12/08 06:48.30: -] Failed to resolve ODBCNativeLib path [$./etc/
> openbd/bin/ODBCNativeLib.dll] ODBC auto-configuration disabled
> 18/12/08 06:48.30: -] Native library does not exist: $./etc/openbd/bin/
> ODBCNativeLib.dll
> 18/12/08 06:48.30: -] Open BlueDragon has initialised. Ready for
> requests.
>
> This makes some sense - cfregistry tags work when using start.jar and
> not when called when the app is started as a service. Also, the auto
> detect from ODBC was/is not working when started as a service, only
> when started manually.
>
> Perhaps these clues would help indicated where the paths are not
> compatable with windows service?
>
> Thanks,
>
> Rob
> >
>
--
Anthony Hixon, Jr.
Certified Advanced ColdFusion MX 7 Developer
Mobile: (706) 639-3617
[email protected]
--~--~---------~--~----~------------~-------~--~----~
Open BlueDragon Public Mailing List
http://groups.google.com/group/openbd?hl=en
official blog @ http://blog.openbluedragon.org/
!! save a network - trim replies before posting !!
-~----------~----~----~----~------~----~------~--~---
