Skip to Content
Last modified by Aaron Rosenzweig on 2012/07/20 01:35
From version 3.1
edited by Quinton Dolan
on 2007/07/12 20:16
Change comment: There is no comment for this version
To version 2.1
edited by smmccraw
on 2007/07/08 09:45
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.qdolan
1 +XWiki.smmccraw
Content
... ... @@ -2,12 +2,8 @@
2 2  
3 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 4  
5 -{{color value="red"}}
6 -*Warning*
7 -{{/color}}
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.
8 8  
9 - - 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.
10 -
11 11  == Turning Off Direct Connect ==
12 12  
13 13  * Configure your Apache to use mod//WebObjects or the cgi-bin adaptor//
... ... @@ -18,18 +18,47 @@
18 18  
19 19  === Logan Allred ===
20 20  
21 -I've heard all the comments about Direct Connect being evil, and I've been bit many times by its quirks, but I'd like to know from those that eschew Direct Connect what their workflow is and how they benefit (especially if they use Eclipse/WOLips).
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 22  
23 -I still use Direct Connect, mostly because I'm used to the workflow and have figured out most of the things that can go wrong by now. I like the fact that all of my development resources are all in one project and it seems I get some niceties in WOBuilder when using Direct Connect.
23 +{{panel}}
24 24  
25 -Maybe it's because most my projects focus mostly on data and not presentation (I have only a few graphics and an occasional stylesheet~-~-though I'm beginning to use stylesheets more), and that I go back and forth between developing on Windows and Mac (so scripting can become a pain). My apps have not yet suffered because of the speed of loading graphics (far more the speed of database access).
25 +
26 26  
27 -It's not that I fear web servers, I'm just lazy :) and not used to a workflow where I have "split development" instead of "split deployment". How do you version and manage your web resources being in a completely different location than your development resources (do you use resource folders in Eclipse, or separate projects? or some other nice Eclipse feature I haven't learned about? manual copying?). How do you handle deployment across development/staging/production? How much do you have to customize or modify your projects?
27 +{{/panel}}
28 28  
29 -I can definitely see on sites with heavy presentation or dedicated graphic designers where using the web server would be a real plus, but I'm usually on a small team of 2-4 developers with minimal presentation.
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.
30 30  
31 -I'm sure there's a better workflow than I'm using, I'm curious what everyone else considers to be development and deployment best practices for WO. What am I missing out on?
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).
32 32  
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 +
33 33  === Chuck Hill ===
34 34  
35 35  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: