Darn, I didn't even pick up that part of this problem was the wrapper. I had responded to a post last week with that same fix.
Sorry about that... I could have saved you some time: http://groups.google.com/group/openbd/browse_thread/thread/96d0977520a31665/00b49cfaa8657491?lnk=gst&q=josh#00b49cfaa8657491 -Josh On Dec 18, 1:10 pm, "Anthony Hixon, Jr." <[email protected]> wrote: > 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 !! -~----------~----~----~----~------~----~------~--~---
