Re: Multi-Tenant Data Architecture
I read with great interest as I encountere the same situation some time ago. In practice (at least in my case), it worked to have the app run on separate EOF stacks accessing different database. So , it simplified the case to only have one instance in JavaMonitor for multi databases. However, it is not the preferred way due to the following same reason.. That is our main concern. Today we have 20 instances, but this number is likely to increase considerably in near future. If it grows to 40, are you planning on having each instance host all 40? I'd look into EOF stack size if you are thinking of having 40 in one JVM and there is a significant amount of data per tenant. That might work out to a lot of RAM per instance and so few instances per machine. It is just something to keep in mind. Shared this too and Chuck has a good point. So I opted to redisign and put all into single database. The backup / restore is a good point. Managing many EOF stacks and ensuring that one tenant does not see another tenants information might be just as complex in either scenario. I have no idea how / if EOModelGroup implements cloning. You would have to test it. I'd probably choose to do it manually so that I had control if I ever needed to make any other changes. When a session is created, you will need to ensure that all editing contexts created for that session use the correct EOObjectStoreCoordinator. You will also want to ensure that you don't use defaultAnything in your code (defaultEditingContext(), defaultModelGroup() etc.) as these are unlikey to return objects from the correct EOF stack. Caveat: this is theoretical, I don't have any experience doing this. I don't think that many people have done this, so you run the risk of finding bugs in seldom executed EOF code. My tests concurred so far. It worked as Chuck mentioned, never use defaultanything. Called OSC right at the session constructor to be safe. Thank you very much! We are not in a hurry to make this change in our application, but we are worried about future. I'll try to make some tests following your advices and see what happens. Please let us know what happens. This is seldom explored territory. I run into the similar situation and will be good to know how it goes. Cheers Cheong Hee ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
FWIW We uses an setup were access is organized by groups, sub-groups and sub-sub-groups, etc. We have sales reps which manage channel partners, which manage clients or schools. In the schools are more groups. These are all group objects. There are classes that relate to groups, students are related to one or more class. All the groups are in one table, then there is a classes table and students table. The groups are the your tenants. One of our sites has 35819 groups. A user is assigned a group and when the user logges into their group they are given a list of their sub-groups. Users are never aware of their login group, their parent groups or any other group above that. We keep track of their login group in the session. There are certain safe-guards to block exposing objects who's group relationship is not a child of the users' login group. This seems to work pretty well. Issues arise when doing searches for data in a table that's shared with multiple tenants. A tenant should not take the penalty for someone else's large data set. There is a performance hit when combining the database your searching through with the group the tenant belongs to. If you have large tenants you'll need to considere getting them their own server, or at least their own instance(s) +database. Thanks kib We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths. Walt Disney Klaus Berkling Web Application Dev. Systems Administrator DynEd International, Inc. www.dyned.com | www.eskimo.com/~kiberkli ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
Hi Guido, Guido Neitzer wrote: On Sep 22, 2009, at 4:34 PM, Chuck Hill wrote: - some increase in RAM usage due to duplicated loading of code and JVM If you don't want to do that and are committed to doing this in one instance, the next best way is to tag the root object with the tenant. But you said separate databases, so that is ruled out. You mean data categorized by tenant? Yes. I did something like this a while ago and it was actually pretty simple to come up with a model that worked for the situation we had: - all (!) entities have a client (tenant?) relationship - this is set along with audit information in awakeFromInsertion (init) automatically as every user belongs to a client - the app automatically limits fetches with restricting qualifiers (D2W app) - if an object gets fetched and it's awakeFromFetch is called and the client of this object and the client of the current user don't match, it throws a fatal exception, the users session is logged (every single action), the stack trace is logged, and the session terminated That is a good idea to avoid undesirable access to data that don't belong to the corresponding tenant. - I don't use any raw row fetching at all We do for report generation. But we could create a mechanism for sanity checking (like the one in the awakeFromFetch) as soon as all data used in reports come from the same data source. Thanks for your comments and advices. Cheers, Henrique ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
Hi Lachlan, Lachlan Deck wrote: On 23/09/2009, at 8:46 AM, Henrique Prange wrote: Chuck Hill wrote: - problems / load on one tenant do not impact others - guaranteed that one tenant will not accidently see information from another This last one is exactly the reason why we can't have a shared database at all. This is what we do .. simply requires an auto injected and'd qualifier + relevant tables related to said tenant. That is also a good idea. :) - some increase in RAM usage due to duplicated loading of code and JVM If you don't want to do that and are committed to doing this in one instance, the next best way is to tag the root object with the tenant. But you said separate databases, so that is ruled out. You mean data categorized by tenant? The application already supports this kind of architecture. We deploy one application with more than one tenant using a shared database in very exceptional cases. But that is not the rule. In most cases we can't take the risk of providing wrong information for a customer. We've never had that problem - but I understand it's theoretically possible as is providing the wrong connection dictionary ;-) Yes. One tenant per instance with separate databases is the safer way. But has the higher maintenance cost. Every solution has pros and cons. As I said, I'm not in a hurry to implement this kind of architecture. But I would like to take decisions based on good arguments and the result of some experiments. Not because of a technological problem. As, in theory, EOF can support multiple databases in one application, I think it is worth making some tests in this direction. Anyway, I'm taking all your comments into consideration before I take the final decision. :) Cheers, Henrique ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
Hi Cheong, Cheong Hee (Gmail) wrote: I read with great interest as I encountere the same situation some time ago. In practice (at least in my case), it worked to have the app run on separate EOF stacks accessing different database. So , it simplified the case to only have one instance in JavaMonitor for multi databases. Good to hear I'm no the only one trying to implement this kind of solution. When a session is created, you will need to ensure that all editing contexts created for that session use the correct EOObjectStoreCoordinator. You will also want to ensure that you don't use defaultAnything in your code (defaultEditingContext(), defaultModelGroup() etc.) as these are unlikey to return objects from the correct EOF stack. Caveat: this is theoretical, I don't have any experience doing this. I don't think that many people have done this, so you run the risk of finding bugs in seldom executed EOF code. My tests concurred so far. It worked as Chuck mentioned, never use defaultanything. Called OSC right at the session constructor to be safe. I'll try to follow this advices. Thank you. Cheers, Henrique ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
Hi Chuck, Chuck Hill wrote: Not so easy when you have more than 20 different instances (and counting) running on JavaMonitor. :p 20 does not seem like that many to manage. Yeah. I'm worried about the future. 100+ instances can become a problem to manage. Cons: - more instances to administer That is our main concern. Today we have 20 instances, but this number is likely to increase considerably in near future. If it grows to 40, are you planning on having each instance host all 40? I'd look into EOF stack size if you are thinking of having 40 in one JVM and there is a significant amount of data per tenant. That might work out to a lot of RAM per instance and so few instances per machine. It is just something to keep in mind. You are right and I don't have the exact math for this problem. I believe one solution will not fit all situations. Some tenants will require an entire instance because of the amount of data. But most tenants will not require many resources. Of course, this is based on an empirical analysis. I still have to measure in different situations to determine these magical numbers (number of tenants per instance, required amount of RAM and etc). Writing a bug free multi-tenant application with shared data is time consuming and expensive. In the case of this specific application is also too risky. Also, a shared database make the backup/restore process very difficult. You can backup everything easily, but how to revert the data for a single tenant? The backup / restore is a good point. Managing many EOF stacks and ensuring that one tenant does not see another tenants information might be just as complex in either scenario. Yeah. Whatever solution we chose, I'm convinced it is not a trivial matter. Cheers, Henrique ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
Hi Henrique, This thread may be of interest: http://lists.apple.com/archives/webobjects-dev//2007/Jul/msg00390.html We are still using the approach described by Eugene in this thread. On Sat, Sep 19, 2009 at 7:09 PM, Henrique Prange hpra...@gmail.com wrote: Hi all, Is there a way to configure EOF to access separate databases for each tenant in *one* application? I'm working in an application that has a strong non-functional requirement on multi-tenant architecture with isolated database access. I've seen some discussion related with this subject, but it was not clear to me how could I implement this kind of stuff. Any directions are really appreciated. Cheers, Henrique ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/dfrolov%40demax.ru This email sent to dfro...@demax.ru ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
Hi Chuck, Chuck Hill wrote: The easiest, and perhaps best, way to do this is to have different instances for each tenant. The configuration (in JavaMonitor or elsewhere) can then specify the database. That is our current way to deploy the application. Pros: - easy Not so easy when you have more than 20 different instances (and counting) running on JavaMonitor. :p - problems / load on one tenant do not impact others - guaranteed that one tenant will not accidently see information from another This last one is exactly the reason why we can't have a shared database at all. Cons: - more instances to administer That is our main concern. Today we have 20 instances, but this number is likely to increase considerably in near future. - some increase in RAM usage due to duplicated loading of code and JVM If you don't want to do that and are committed to doing this in one instance, the next best way is to tag the root object with the tenant. But you said separate databases, so that is ruled out. You mean data categorized by tenant? The application already supports this kind of architecture. We deploy one application with more than one tenant using a shared database in very exceptional cases. But that is not the rule. In most cases we can't take the risk of providing wrong information for a customer. Writing a bug free multi-tenant application with shared data is time consuming and expensive. In the case of this specific application is also too risky. Also, a shared database make the backup/restore process very difficult. You can backup everything easily, but how to revert the data for a single tenant? The only way that I can think of to accomplish what you want is to create an EOModelGroup for each tenant. A separate copy of each model will need to be loaded into each group and the database connection information set for that tenant. Each EOModelGroup will serve as the basis for a new EOF stack (rooted at EOObjectStoreCoordinator). Miguel gave me this same idea off-list. So, I think that is the way to go. :) Sorry for the stupid question, but would be enough to get the defaultModelGroup, clone it and change the URL for database connection on each cloned model? Or is it a better/safe idea to create one by one and load models as if it were the first time? When a session is created, you will need to ensure that all editing contexts created for that session use the correct EOObjectStoreCoordinator. You will also want to ensure that you don't use defaultAnything in your code (defaultEditingContext(), defaultModelGroup() etc.) as these are unlikey to return objects from the correct EOF stack. Caveat: this is theoretical, I don't have any experience doing this. I don't think that many people have done this, so you run the risk of finding bugs in seldom executed EOF code. Thank you very much! We are not in a hurry to make this change in our application, but we are worried about future. I'll try to make some tests following your advices and see what happens. Cheers, Henrique ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
Hi Denis, Thank you very much, Denis. I haven't found this thread while googling by the subject. The Eugene e-mail has exactly what I need... Sample code. :) Cheers, Henrique Denis Frolov wrote: Hi Henrique, This thread may be of interest: http://lists.apple.com/archives/webobjects-dev//2007/Jul/msg00390.html We are still using the approach described by Eugene in this thread. On Sat, Sep 19, 2009 at 7:09 PM, Henrique Prange hpra...@gmail.com wrote: Hi all, Is there a way to configure EOF to access separate databases for each tenant in *one* application? I'm working in an application that has a strong non-functional requirement on multi-tenant architecture with isolated database access. I've seen some discussion related with this subject, but it was not clear to me how could I implement this kind of stuff. Any directions are really appreciated. Cheers, Henrique ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/dfrolov%40demax.ru This email sent to dfro...@demax.ru ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
Hi Henrique, On Sep 22, 2009, at 3:46 PM, Henrique Prange wrote: Hi Chuck, Chuck Hill wrote: The easiest, and perhaps best, way to do this is to have different instances for each tenant. The configuration (in JavaMonitor or elsewhere) can then specify the database. That is our current way to deploy the application. Well, then you already know the pros and cons of that scenario! :-) Pros: - easy Not so easy when you have more than 20 different instances (and counting) running on JavaMonitor. :p 20 does not seem like that many to manage. - problems / load on one tenant do not impact others - guaranteed that one tenant will not accidently see information from another This last one is exactly the reason why we can't have a shared database at all. Cons: - more instances to administer That is our main concern. Today we have 20 instances, but this number is likely to increase considerably in near future. If it grows to 40, are you planning on having each instance host all 40? I'd look into EOF stack size if you are thinking of having 40 in one JVM and there is a significant amount of data per tenant. That might work out to a lot of RAM per instance and so few instances per machine. It is just something to keep in mind. - some increase in RAM usage due to duplicated loading of code and JVM If you don't want to do that and are committed to doing this in one instance, the next best way is to tag the root object with the tenant. But you said separate databases, so that is ruled out. You mean data categorized by tenant? Yes. The application already supports this kind of architecture. We deploy one application with more than one tenant using a shared database in very exceptional cases. But that is not the rule. In most cases we can't take the risk of providing wrong information for a customer. Writing a bug free multi-tenant application with shared data is time consuming and expensive. In the case of this specific application is also too risky. Also, a shared database make the backup/restore process very difficult. You can backup everything easily, but how to revert the data for a single tenant? The backup / restore is a good point. Managing many EOF stacks and ensuring that one tenant does not see another tenants information might be just as complex in either scenario. The only way that I can think of to accomplish what you want is to create an EOModelGroup for each tenant. A separate copy of each model will need to be loaded into each group and the database connection information set for that tenant. Each EOModelGroup will serve as the basis for a new EOF stack (rooted at EOObjectStoreCoordinator). Miguel gave me this same idea off-list. So, I think that is the way to go. :) Sorry for the stupid question, but would be enough to get the defaultModelGroup, clone it and change the URL for database connection on each cloned model? Or is it a better/safe idea to create one by one and load models as if it were the first time? I have no idea how / if EOModelGroup implements cloning. You would have to test it. I'd probably choose to do it manually so that I had control if I ever needed to make any other changes. When a session is created, you will need to ensure that all editing contexts created for that session use the correct EOObjectStoreCoordinator. You will also want to ensure that you don't use defaultAnything in your code (defaultEditingContext(), defaultModelGroup() etc.) as these are unlikey to return objects from the correct EOF stack. Caveat: this is theoretical, I don't have any experience doing this. I don't think that many people have done this, so you run the risk of finding bugs in seldom executed EOF code. Thank you very much! We are not in a hurry to make this change in our application, but we are worried about future. I'll try to make some tests following your advices and see what happens. Please let us know what happens. This is seldom explored territory. Chuck -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
On Sep 22, 2009, at 4:34 PM, Chuck Hill wrote: - some increase in RAM usage due to duplicated loading of code and JVM If you don't want to do that and are committed to doing this in one instance, the next best way is to tag the root object with the tenant. But you said separate databases, so that is ruled out. You mean data categorized by tenant? Yes. I did something like this a while ago and it was actually pretty simple to come up with a model that worked for the situation we had: - all (!) entities have a client (tenant?) relationship - this is set along with audit information in awakeFromInsertion (init) automatically as every user belongs to a client - the app automatically limits fetches with restricting qualifiers (D2W app) - if an object gets fetched and it's awakeFromFetch is called and the client of this object and the client of the current user don't match, it throws a fatal exception, the users session is logged (every single action), the stack trace is logged, and the session terminated - I don't use any raw row fetching at all This worked quite well, the app didn't have many clients but I never had any complaints about data being shown that shouldn't have been shown. If you are really determined you could make sure on a per call basis, that no data is accessed from a different client. Guido ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
On 23/09/2009, at 8:46 AM, Henrique Prange wrote: Chuck Hill wrote: - problems / load on one tenant do not impact others - guaranteed that one tenant will not accidently see information from another This last one is exactly the reason why we can't have a shared database at all. This is what we do .. simply requires an auto injected and'd qualifier + relevant tables related to said tenant. - some increase in RAM usage due to duplicated loading of code and JVM If you don't want to do that and are committed to doing this in one instance, the next best way is to tag the root object with the tenant. But you said separate databases, so that is ruled out. You mean data categorized by tenant? The application already supports this kind of architecture. We deploy one application with more than one tenant using a shared database in very exceptional cases. But that is not the rule. In most cases we can't take the risk of providing wrong information for a customer. We've never had that problem - but I understand it's theoretically possible as is providing the wrong connection dictionary ;-) Writing a bug free multi-tenant application with shared data is time consuming and expensive. In the case of this specific application is also too risky. Also, a shared database make the backup/restore process very difficult. You can backup everything easily, but how to revert the data for a single tenant? Very good point. But likewise shared app instances (as we use) must be updated simultaneously also. The only way that I can think of to accomplish what you want is to create an EOModelGroup for each tenant. A separate copy of each model will need to be loaded into each group and the database connection information set for that tenant. Each EOModelGroup will serve as the basis for a new EOF stack (rooted at EOObjectStoreCoordinator). Miguel gave me this same idea off-list. So, I think that is the way to go. :) Sorry for the stupid question, but would be enough to get the defaultModelGroup, clone it and change the URL for database connection on each cloned model? Or is it a better/safe idea to create one by one and load models as if it were the first time? When a session is created, you will need to ensure that all editing contexts created for that session use the correct EOObjectStoreCoordinator. You will also want to ensure that you don't use defaultAnything in your code (defaultEditingContext(), defaultModelGroup() etc.) as these are unlikey to return objects from the correct EOF stack. Caveat: this is theoretical, I don't have any experience doing this. I don't think that many people have done this, so you run the risk of finding bugs in seldom executed EOF code. Thank you very much! We are not in a hurry to make this change in our application, but we are worried about future. I'll try to make some tests following your advices and see what happens. with regards, -- Lachlan Deck ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
Hi; I've done two reasonably complex multi-tenant systems which are now seven and five years in production. Both are running out of unified models and I haven't heard of any issues around data authorisation issues. cheers. I did something like this a while ago and it was actually pretty simple to come up with a model that worked for the situation we had: ___ Andrew Lindesay www.lindesay.co.nz ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multi-Tenant Data Architecture
Hi Henrique, On Sep 19, 2009, at 8:09 AM, Henrique Prange wrote: Hi all, Is there a way to configure EOF to access separate databases for each tenant in *one* application? I'm working in an application that has a strong non-functional requirement on multi-tenant architecture with isolated database access. I've seen some discussion related with this subject, but it was not clear to me how could I implement this kind of stuff. Any directions are really appreciated. The easiest, and perhaps best, way to do this is to have different instances for each tenant. The configuration (in JavaMonitor or elsewhere) can then specify the database. Pros: - easy - problems / load on one tenant do not impact others - guaranteed that one tenant will not accidently see information from another Cons: - more instances to administer - some increase in RAM usage due to duplicated loading of code and JVM If you don't want to do that and are committed to doing this in one instance, the next best way is to tag the root object with the tenant. But you said separate databases, so that is ruled out. The only way that I can think of to accomplish what you want is to create an EOModelGroup for each tenant. A separate copy of each model will need to be loaded into each group and the database connection information set for that tenant. Each EOModelGroup will serve as the basis for a new EOF stack (rooted at EOObjectStoreCoordinator). When a session is created, you will need to ensure that all editing contexts created for that session use the correct EOObjectStoreCoordinator. You will also want to ensure that you don't use defaultAnything in your code (defaultEditingContext(), defaultModelGroup() etc.) as these are unlikey to return objects from the correct EOF stack. Caveat: this is theoretical, I don't have any experience doing this. I don't think that many people have done this, so you run the risk of finding bugs in seldom executed EOF code. Chuck -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Multi-Tenant Data Architecture
Hi all, Is there a way to configure EOF to access separate databases for each tenant in *one* application? I'm working in an application that has a strong non-functional requirement on multi-tenant architecture with isolated database access. I've seen some discussion related with this subject, but it was not clear to me how could I implement this kind of stuff. Any directions are really appreciated. Cheers, Henrique ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
