Great job! Works like a charm. Thank you very much for your time and effort.
I just ran into another issue concerning calling a module from within another module, and also had a question concerning unit testing of filters. Would it be best to start a new thread for these topics? On Oct 1, 4:51 pm, "Peter J. Farrell" <[email protected]> wrote: > I believe I worked it out completely. There are more than a few ways > that environments can be setup: > > 1. Modules inheriting the environment name from the base > 2. Modules resolving the server name itself but have a base environment > defined > 3. Module that resolve the server name itself but *do not* have a base > environment defined > 4. Then multiple modules in a combination of 1 and 2 > > I have committed a fix to the repo and I have it working in my test > case. Please update from repo and check for me. Thanks for working > with me to figure out this issue -- as I outlined above -- there are > many different ways that environments can be setup and it gets > complicated to support all of those scenarios automagically without > complicated configuration. > > Best, > .Peter > > Po said the following on 10/01/2009 12:40 PM: > > > > > Here is my module EnvironmentProperty xml: > > > <?xml version="1.0" encoding="UTF-8"?> > > <!DOCTYPE mach-ii PUBLIC > > "-//Mach-II//DTD Mach-II Configuration 1.8.0//EN" > > "http://www.mach-ii.com/dtds/mach-ii_1_8_0.dtd";> > > > <mach-ii version="1.8"> > > <properties> > > <property name="environment" > > type="MachII.properties.EnvironmentProperty"> > > <parameters> > > <!-- Optional: Name of default environment to use if no > > server matches --> > > <parameter name="defaultEnvironmentName" value="dev" /> > > > <!-- Optional: Name of property to place in name of the > > resolved server --> > > <!-- <parameter name="serverPropertyName" > > value="serverName" /> --> > > > <!-- Name of environment (can be any name) --> > > <parameter name="dev"> > > <struct> > > <!-- Name of generic environment group to assign > > this environment to (production,qa,staging,development,local) --> > > <key name="environmentGroup" value="development" /> > > > <!-- Array of developer servers --> > > <key name="servers"> > > <array> > > <element value="dev.xyz.com" /> > > </array> > > </key> > > > <!-- Structure of development properties to set --> > > <key name="properties"> > > <struct> > > <key name="devMode" value="true" /> > > </struct> > > </key> > > </struct> > > </parameter> > > </parameters> > > </property> > > </properties> > > </mach-ii> > > > In this example there is no base EnvironmentProperty defined. If I do > > not define the defaultEnvironmentName, then I get the exception. In > > my real app I actually do use a base EnvironmentProperty, but I was > > just wondering why when only a module EnvironmentProperty is defined, > > the defaultEnvironmentName needs to be defined even if there is a > > match between the servers parameter and the cgi.server_name. > > > I saw that you added useResolvedEnvironmentNameFromParent parameter, > > but I am using the latest 1.8 and I still get the same error. Should > > that have fixed it or is this a different issue? > > > On Sep 30, 6:58 pm, "Peter J. Farrell" <[email protected]> wrote: > > >> Can you share your XML configuration for the EnvironmentProperty? I > >> think that will help. Feel free to strip off properties values or > >> replace with dummy information. > > >> Do you have a server namedwww.xyz.cominthe list or array of servers > >> for an environment your configuration? Having xyz.com does not > >> matchwww.xyz.com. The property uses the value from cgi.server_name to do > >> the > >> resolution sowww.xyz.comisthe value that is found. You may need to > >> definewww.xyz.comorxyz.com (without the www) in order to get a match. > > >> Also, remember that the "servers" list in the module does not inherit > >> from the parent base application however, the EnvironmentProperty when > >> defined in the modules uses the environment name that the parent base > >> application sets. This lets you define all the servers in the parent > >> base app to the environment name and then just leave the "servers" > >> parameter for each environment in the module definition. I.e. base > >> application resolves to "dev" environment then the module environment > >> property will try to load the "dev" environment. Your environment names > >> between the base and the parent base application need to match. We > >> maybe need to add a flag parameter so people can load different > >> environments entirely for the module and improve the exception messages. > > >> Best, > >> .Peter > > >> Po said the following on 09/30/2009 05:14 PM: > > >>> Then I think there is still something wrong. I do (and did) have the > >>> list of server names defined in the module environment xml and I know > >>> they match the actual server names, but yet if I do not include the > >>> defaultEnvironmentName, it still gives me that exception: > > >>> ----- > >>> No environment can be resolved for 'www.xyz.com'andno default > >>> environment has been defined. > >>> Please define a default environment or add this server to a defined > >>> environment. > >>> ----- > > >>> This seems to only happen when I include the module environment but > >>> not a base one. > > >>> On Sep 30, 5:50 pm, "Peter J. Farrell" <[email protected]> wrote: > > >>>> It is optional if you do not want a default environment to load. > >>>> Otherwise, you have to list all the server names or server name pattern > >>>> combinations in which your application will be deployed because the > >>>> environment property matches environments by server names. If one does > >>>> not match, it uses the default environment name or throw an exception > >>>> (like you saw) if it doesn't match any of the server names / patterns > >>>> and no default environment name is defined. > > >>>> There are situations where you don't want to define a default > >>>> environment. > > >>>> .Peter > > >>>> Po said the following on 09/30/2009 02:57 PM: > > >>>>> That did it! I had that line of code commented out. > > >>>>> Just a heads up, the documentation still specifies the > >>>>> defaultEnvironmentName as optional: > > >>>>> ----- > >>>>> <!-- Optional: Name of default environment to use if no server matches > >>>>> --> > >>>>> <parameter name="defaultEnvironmentName" value="production" /> > >>>>> ----- > > >>>>> Thanks for all your help! > > >>>>> On Sep 30, 3:43 pm, "Peter J. Farrell" <[email protected]> wrote: > > >>>>>> Would be willing to share your xml configuration? It's not a bug, just > >>>>>> something is up with your configuration. > > >>>>>> Looks like the documentation has some inconsistencies in it. The > >>>>>> default environment name parameter should be "defaultEnvironmentName" > >>>>>> not "defaultEnvironment". The sample code is correct, but the prose > >>>>>> below it referred to "defaultEnvironment" which is incorrect. I have > >>>>>> updated the wiki to correct issue. > > >>>>>> You should define a parameter in the EnvironmentProperty parameters > >>>>>> like > >>>>>> this: > > >>>>>> <parameter name="defaultEnvironmentName" > >>>>>> value="Name-Of-Default-Environment-Name-Here" /> > > >>>>>> I have a feeling this is the issue for you. > > >>>>>> .pjf > > >>>>>> Po said the following on 09/30/2009 02:02 PM: > > >>>>>>> Thank you for the prompt reply Peter. > > >>>>>>> As it seems to always be the case, I apparently did not the read the > >>>>>>> docs properly. As soon as I posted my question, I decided to take > >>>>>>> another look at the EnvironmentProperty docs and saw this little gem: > > >>>>>>> "The EnvironmentProperty uses (via inheritance) the environment name > >>>>>>> and group from the base application if used in a module for > >>>>>>> environment resolution. This means your environment names in your > >>>>>>> module must match the environment names in your base application." > > >>>>>>> But I do agree that there should not necessarily be a base > >>>>>>> environment. I went ahead and updated to head and now I get this > >>>>>>> exception: > > >>>>>>> ----- > >>>>>>> No environment can be resolved for 'www.xyz.com'andnodefault > >>>>>>> environment has been defined. > >>>>>>> Please define a default environment or add this server to a defined > >>>>>>> environment. > >>>>>>> ----- > > >>>>>>> Is it not picking up the AppManager's default environmentName? > > >>>>>>> On Sep 30, 2:23 pm, "Peter J. Farrell" <[email protected]> wrote: > > >>>>>>>> I bet you don't have an EnvironmentProperty setup in the base > >>>>>>>> application yet. If you add one, I bet the exception will go away. > >>>>>>>> However, I think there was the assumption that if you have > >>>>>>>> environments > >>>>>>>> setup in a module that an environments have been setup for the base > >>>>>>>> application. So I see a logic error in the code because I don't > >>>>>>>> think > >>>>>>>> this is a good assumption on our part. Here is the ticket: > > >>>>>>>>http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ticket/401 > > >>>>>>>> I've committed a fix already that will allow you to set up an > >>>>>>>> environment in a module without the parent being set up. If you could > >>>>>>>> update to head from the repo and let me know if this fix works, I'd > >>>>>>>> really appreciate it as I will then close out the ticket. > > >>>>>>>> Best, > >>>>>>>> .pjf > >>>>>>>> Team Mach-II > > >>>>>>>> Po said the following on 09/30/2009 11:57 AM: > > >>>>>>>>> SETUP: mach-ii 1.8 (latest from trunk) > > >>>>>>>>> I would like to setup some environment properties > > ... > > read more »- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to Mach-II for CFML list. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/ Wiki / Documentation / Tickets: http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ -~----------~----~----~----~------~----~------~--~---
