Skip to Content
Version 1.1 by smmccraw on 2007/07/08 09:45
Show last authors
1 == Overview ==
2
3 By default, both Xcode and Eclipse/WOLips will configure your application to use Direct Connect. When your WebObjects application launches, it listens on a particular port (assigned by the WOPort configuration option). Under a full-blown deployment scenario, this port is used by the mod//WebObjects adaptor or the WebObjects cgi-bin adaptor to communicate between Apache and your application. However, it's also possible to run in development completely on the Direct Connect port (i.e. without a webserver). In this configuration, one noteable difference is that all resources are served by the Direct Connect server as opposed to the Apache scenario where resources are served by Apache directly and your WebObjects application only handles application requests.//
4
5 <font color="red">**Warning**</font> - wotaskd relies on direct connect being enabled so that the adaptor can communicate with it. Do not globally disable direct connect on your servers. For example, if you disable direct connect from the WebObjects.properties file in the application server's home directory, you will prevent wotaskd from responding to requests on its assigned port.
6
7 == Turning Off Direct Connect ==
8
9 * Configure your Apache to use mod//WebObjects or the cgi-bin adaptor//
10 * Ensure wotaskd is running
11 * Set WODirectConnectEnabled to false
12 * Setup your WebServerResources folder so that it is reachable by Apache
13 * Profit
14
15 === Logan Allred ===
16
17 I've heard all the comments
18 about Direct Connect being evil, and I've been bit many times by its
19 quirks, but I'd like to know from those that eschew Direct Connect what
20 their workflow is and how they benefit (especially if they use
21 Eclipse/WOLips).
22
23 {{panel}}
24
25
26
27 {{/panel}}
28
29 I still use Direct Connect, mostly because I'm used to the workflow and
30 have figured out most of the things that can go wrong by now. I like the
31 fact that all of my development resources are all in one project and it
32 seems I get some niceties in WOBuilder when using Direct Connect.
33
34 Maybe it's because most my projects focus mostly on data and not
35 presentation (I have only a few graphics and an occasional
36 stylesheet~-~-though I'm beginning to use stylesheets more), and that I go
37 back and forth between developing on Windows and Mac (so scripting can
38 become a pain). My apps have not yet suffered because of the speed of
39 loading graphics (far more the speed of database access).
40
41 It's not that I fear web servers, I'm just lazy :) and not used to a
42 workflow where I have "split development" instead of "split deployment".
43 How do you version and manage your web resources being in a completely
44 different location than your development resources (do you use resource
45 folders in Eclipse, or separate projects? or some other nice Eclipse
46 feature I haven't learned about? manual copying?). How do you handle
47 deployment across development/staging/production? How much do you have to
48 customize or modify your projects?
49
50 I can definitely see on sites with heavy presentation or dedicated graphic
51 designers where using the web server would be a real plus, but I'm usually
52 on a small team of 2-4 developers with minimal presentation.
53
54 I'm sure there's a better workflow than I'm using, I'm curious what
55 everyone else considers to be development and deployment best practices for
56 WO. What am I missing out on?
57
58 === Chuck Hill ===
59
60 First off, it is not just about images. It is about having the power of a real webserver and about avoiding problems that only appear when you move to running the app through a real web server. Think of things like:
61
62 * caching, mod//expires is NOT your friend//
63 * HTTPS
64 * SSI
65 * Rewrite rules
66 * headers only present when going through a web server
67
68 I'm sure you can think of more differences. I'd rather develop with all the services I will get in deployment and also find the problems that crop up //before// the app has been in production for half a day! I prefer my pain to be at leisure, not in panic. And, at least on OSX, it is dead easy to get Apache going.
69
70 As for work flow, what work flow? Our "projects", as seen from the source repository, are a hierarchy of folders. One is for code and that is where the WO projects go. Another is DocumentRoot and that is where, well, the document root stuff goes. Other folders are for docs, design, tests, etc. It is easy enough to check each one out where it goes. If your images are mostly static, so much less to do. If they change a lot, then the designers etc. can check in and out what they need in a way very familiar to them without needing to puzzle over arcane things like an Eclipse project. Image updates to your local doc root happen the same way that code updates to your workspace does.
71
72 For deployment, we have scripts that do command line Ant builds of all the code,tar up all the various resources (doc root included), and just generally make an install package. Another script on the target server takes that package, untars it, and copies the bits where they need to go. I don't understand how having to do split installs makes this any easier.
73
74 Category:WebObjects