You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by BJ Freeman <bj...@free-man.net> on 2007/12/17 19:04:17 UTC
Re: Include of controllers- patch
i probably am not
I was going to move the location data for main-decorator from the
web.xml to the actual widget files.
Adrian Crum sent the following on 12/17/2007 9:46 AM:
> If BJ supplies a patch as I described, then we'll see if it solves his
> problem. If it does, then we're talking about the same issue. ;-)
>
> -Adrian
>
> Chris Howe wrote:
>
>> You two are talking about different issues. BJ is describing a
>> pitfall that occurs when you use the <include> tag in the controller
>> for a scenario that wasn't considered when the <include> tag was
>> implemented in the controller.
>>
>> ----- Original Message ----
>> From: Adrian Crum <ad...@hlmksw.com>
>> To: dev@ofbiz.apache.org
>> Sent: Monday, December 17, 2007 11:33:43 AM
>> Subject: Re: Include of controllers
>>
>>
>> BJ,
>>
>> Go ahead and create one. I will work on it when I have time.
>>
>> To be sure we're all on the same page, the problem exists when screens
>> are nested as follows:
>>
>> <screen name="GlobalDecorator">
>> <screen name="main-decorator">
>> <screen name="sub-decorator">
>> <screen name="actual-content">
>> ...
>> </screen>
>> </screen>
>> </screen>
>> </screen>
>>
>> and the location of the sub-decorator screen is defined as
>> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
>> the actual-content screen, errors are
>> generated because <decorator-screen name="sub-decorator"
>> location="${parameters.mainDecoratorLocation}"> evaluates to the
>> custom app's main decorator xml file, and the sub-decorator screen
>> doesn't exist there.
>>
>> The solution to the problem is to avoid using
>> ${parameters.mainDecoratorLocation} as a location for sub-decorators
>> and either have no location specified or use a different
>> parameter for the sub-decorator's location - like
>> ${subDecoratorLocation}.
>>
>> A good example of this approach is in AgreementScreens.xml in the
>> Accounting component. All of the Agreement screens share a common
>> sub-decorator
>> (CommonAgreementDecorator) - and that decorator's location is
>> specified as ${parameters.agreementDecoratorLocation}. The
>> agreementDecoratorLocation parameter isn't defined anywhere, so the
>> location= expression evaluates
>> to an empty String - which causes the screen widget view handler to
>> look for
>> CommonAgreementDecorator in the existing file.
>>
>> A custom app that reuses one of the Agreement screens will only need to
>> specify the mainDecoratorLocation parameter. Since no
>> agreementDecoratorLocation
>> parameter is defined in the custom app, the sub-decorator in
>> AgreementScreens.xml is used (same as
>> above). If a custom app wanted to have a custom sub-decorator, then
>> it can specify that
>> decorator's location in the agreementDecoratorLocation parameter.
>>
>> -Adrian
>>
>> BJ Freeman wrote:
>>
>>
>>> I agree, it is not a controller or web.xml issue. However it is when
>>
>> it
>>
>>> shows up.
>>> I will change them as I come along also.
>>> thanks, that is all I wanted to know.
>>> do you want to create a jira so I can submit changes?
>>>
>>> Adrian Crum sent the following on 12/17/2007 7:57 AM:
>>>
>>>
>>>> As I mentioned before, the problem is with the coding style on some
>>>> screens, not with the controller or web.xml files. I recently changed
>>>> some of the accounting screens to correct this error.
>>>>
>>>> -Adrian
>>>>
>>>> BJ Freeman wrote:
>>>>
>>>>
>>>>
>>>>> I am not really, trying to attach the context as a whole.
>>>>> only trying to get the mainDecoratorLocation
>>>>> which is stored as a context in web.xml.
>>>>> The problem is if I put mainDecoratorLocation, in my web.xml
>>>>> then all applications I call thru my controller, or the included
>>
>> ones,
>>
>>>>> will use my mainDecoratorLocation full path.
>>>>> Maybe the solution is to put the main-decorator for all apps in the
>>>>> framework/commons
>>>>> then like in many of the application they have specific decorators
>>
>> that
>>
>>>>> include the main-decorator.
>>>>> the problems is how to fill in the actions, etcetera
>>>>>
>>>>> Chris Howe sent the following on 12/15/2007 10:40 AM:
>>>>>
>>>>>
>>>>>
>>>>>> All the <include> does is grab some xml elements from the location
>>>>>> described. Theoretically, It doesn't even need to be from the same
>>>>>> server, much less the same app (may have interesting possibilities
>>>>>> BTW). This is why I'm having such a hard time understanding why
>>
>> you
>>
>>>>>> are trying to attach context to it.
>>>>>>
>>>>>> ----- Original Message ----
>>>>>> From: BJ Freeman <bj...@free-man.net>
>>>>>> To: dev@ofbiz.apache.org
>>>>>> Sent: Saturday, December 15, 2007 12:19:27 PM
>>>>>> Subject: Re: Include of controllers
>>>>>>
>>>>>>
>>>>>> I was going thru the trunk and noticed this in all the controllers
>>>>>> <include
>>>>>> location="component://common/webcommon/WEB-INF/common-controller.xml"/>
>>>>>>
>>>>>>
>>>>>> so there is a rule that says you can include a controller not in
>>
>> the
>>
>>>>>> same app.
>>>>>>
>>>>>>
>>>>>> BJ Freeman sent the following on 11/10/2007 4:15 PM:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Almost.
>>>>>>> when the included controller view calles a screen in the partymgr
>>>>>>
>>>>>> screen
>>>>>>
>>>>>>
>>>>>>
>>>>>>> , and that screen calls for a parm that is web.xml. the parm is
>>
>> not
>>
>>>>>>> availible for the screen and so fails.
>>>>>>>
>>>>>>> At this time, the way I handle this is to put the parm in my
>>
>> Web.xml.
>>
>>>>>>> My suggestions was that if a call is made to a parm that would be
>>
>> in
>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>>
>>>>>>> applications, in this case partymgr, web.xml, that widget looks up
>>>>>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>>
>>>>>>> web.xml for that application to get it.
>>>>>>>
>>>>>>>
>>>>>>> Chris Howe sent the following on 11/10/2007 2:23 PM:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Okay, I've read through the thread. In that case, I might
>>
>> suggest
>>
>>>>>> to take a step back and look at what the two functionalities were
>>>>>> designed to accomplish.
>>>>>>
>>>>>>>> Creating the mainDecoratorLocation variable in the web.xml was
>>>>>>
>>>>>> designed for _screen reuse. the include element in the
>>
>> controller.xml
>>
>>>>>> file
>>>>>> was designed for request/response maintenance.
>>>>>>
>>>>>>>> With that in mind, you can include another controller in your
>>
>> custom
>>
>>>>>> application and then override the view with one that points to your
>>>>>> application. If you wish to then include a screen from another
>>>>>> application you can use the <include-screen> element in the screen
>>>>>> widget and
>>>>>> at the same time pass a parameters.mainDecoratorLocation to
>>
>> override the
>>
>>>>>> one gained from the web.xml context of the webapp being used.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> It appears that what BJ is suggesting would make the screen being
>>>>>>
>>>>>> called from the ofbiz application nonreusable except as decorated
>>
>> as it
>>
>>>>>> is in the ofbiz project which defeats the entire purpose of the
>>>>>> mainDecoratorLocation variable. Do I follow correctly?
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> ----- Original Message ----
>>>>>>>> From: BJ Freeman <bj...@free-man.net>
>>>>>>>> To: dev@ofbiz.apache.org
>>>>>>>> Sent: Saturday, November 10, 2007 2:12:12 PM
>>>>>>>> Subject: Re: Include of controllers
>>>>>>>>
>>>>>>>> Chris the discussion is about using the include in the
>>
>> controller.
>>
>>>>>>>> and that the current way of putting the locations of parameters
>>
>> used
>>
>>>>>> in
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> the widgets for screen decorators is causing a problem
>>>>>>>> In a lot of apps the location is called out in the web.xml
>>>>>>>> <context-param>
>>>>>>>> <param-name>mainDecoratorLocation</param-name>
>>>>>>>>
>>>>>> <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> <description>The location of the main-decorator screen to use
>>>>>>
>>>>>> for
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> this webapp; referred to as a context variable in screen def XML
>>>>>>>> files.</description>
>>>>>>>> </context-param>
>>>>>>>>
>>>>>>>> The suggeston is to take the location out to the web.xml and put
>>
>> in
>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> widget like so.
>>>>>>>>
>>>>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>>>>> location="component://party/widget/partymgr/CommonScreens.xml">
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Chris Howe sent the following on 11/9/2007 9:14 PM:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I haven't been following the thread, but instead of setting it
>>>>>>>>
>>>>>>>> explicitly in the widgets section, you may prefer to define it in
>>>>>>
>>>>>> the actions
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> section...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> <action>
>>>>>>>>> <set field="parameters.mainDecoratorLocation"
>>>>>>>>
>>>>>>>> value="component://party/widget/partymgr/CommonScreens.xml"/>
>>>>>>>>
>>>>>>>>> </action>
>>>>>>>>> <widget>
>>>>>>>>> <include-screen name="splitScreen"/>
>>>>>>>>> </widget>
>>>>>>>>> ...
>>>>>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>>>>>
>>>>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>>>>
>>>>>>>>> <screen name="splitScreen">
>>>>>>>>> ...
>>>>>>>>> <widget>
>>>>>>>>>
>>>>>>>>> </widget>
>>>>>>>>> ...
>>>>>>>>> or something similar that it remains a variable so that you can
>>>>>>
>>>>>> later
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> split the widget section out to be it's own screen so that it can
>>>>>>
>>>>>> be
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> used with the decorator in another webapp. I don't know if the
>>>>>>
>>>>>> screens
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> you're worried about here are that complex. This has been a
>>>>>>
>>>>>> better
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> pattern for me.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> ----- Original Message ----
>>>>>>>>> From: BJ Freeman <bj...@free-man.net>
>>>>>>>>> To: dev@ofbiz.apache.org
>>>>>>>>> Sent: Friday, November 9, 2007 9:57:00 PM
>>>>>>>>> Subject: Re: Include of controllers
>>>>>>>>>
>>>>>>>>> Just want to make sure we are all on the same page
>>>>>>>>> in a widget screen
>>>>>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>>>>>
>>>>>>>>> parameters.mainDecoratorLocation is in the Web.xml
>>>>>>>>>
>>>>>>>>> <context-param>
>>>>>>>>> <param-name>mainDecoratorLocation</param-name>
>>>>>>>>>
>> <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
>>
>>
>>>>>>
>>>>>>>>> <description>The location of the main-decorator screen to use
>>>>>>
>>>>>> for
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> this webapp; referred to as a context variable in screen def XML
>>>>>>>>> files.</description>
>>>>>>>>> </context-param>
>>>>>>>>>
>>>>>>>>> so to "fix"
>>>>>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>>>>>> location="component://party/widget/partymgr/CommonScreens.xml">
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> BJ Freeman sent the following on 11/9/2007 5:17 PM:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Ok so the code that allows the context to be used in the
>>
>> web.xml
>>
>>>>>> is
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>> being depreciated?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Adrian Crum sent the following on 11/9/2007 5:11 PM:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> BJ,
>>>>>>>>>>>
>>>>>>>>>>> Nothing is being reversed. You have pointed out a weakness in
>>
>> how
>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> some of the party manager screens are set up (they can't be
>>>>>>>>
>>>>>>>> reused).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> have confirmed they have a problem. So submitting a patch
>>
>> FIXES
>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>> issue - it doesn't reverse anything.
>>>>>>>>>>>
>>>>>>>>>>> -Adrian
>>>>>>>>>>>
>>>>>>>>>>> BJ Freeman wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> I will not submit a patch for what I am proposing, like a lot
>>
>> of
>>
>>>>>>>> my
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> code, it stays in the applications I am doing.
>>>>>>>>>>>> and since someone else put effort into what is in ofbiz now
>>>>>>>>>>>> I do not plan to put effort into reversing it.
>>>>>>>>>>>> :)
>>>>>>>>>>>>
>>>>>>>>>>>> Adrian Crum sent the following on 11/9/2007 4:57 PM:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> BJ,
>>>>>>>>>>>>>
>>>>>>>>>>>>> As I mentioned before, I believe it would be better/easier
>>
>> to
>>
>>>>>> fix
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> party manager screens. Including web.xml files will open up
>>
>> a
>>
>>>>>> big
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> can of
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> worms.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>
>>>>>>>>>>>>> BJ Freeman wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hans:
>>>>>>>>>>>>>> I did not put the CommonCommunicationEventDecorator
>>
>> location
>>
>>>>>> in
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> context in web.xml
>>>>>>>>>>>>>> this was done by someone else and is a standard through
>>
>> ofbiz
>>
>>>>>> as
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> far as
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> i can tell.
>>>>>>>>>>>>>> I take the path of least resistance.
>>>>>>>>>>>>>> Since it is possible to put context in the web.xml and
>>
>> someone
>>
>>>>>>>>> has
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> put a
>>>>>>>>>>>>>> lot of effort into refactoring ofbiz to this standard, I
>>
>> have
>>
>>>>>> no
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>> intention of undoing it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> so my focus for my code will be to have the web.xml
>>
>> included
>>
>>>>>> as
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> well,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> unless the powers to be say there is going to be a change
>>
>> in
>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> best
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> practices.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hans Bakker sent the following on 11/7/2007 5:47 PM:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Bj,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> request (or provide a patch) that the
>>>>>>>>>>>>>>> CommonCommunicationEventDecorator
>>>>>>>>>>>>>>> is moved to the xml file as defined in the web.xml
>>
>> parameter.
>>
>>>>>>>>> Also
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> request that the 'location' parameter is defined in the
>>>>>>
>>>>>> screen
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> you are
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> using.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Then you can use this screen in your own application using
>>>>>>
>>>>>> your
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> own
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> decorator.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, 2007-11-07 at 13:42 -0800, BJ Freeman wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have a controller.xml
>>>>>>>>>>>>>>>> it has the include for the partymgr in it.
>>>>>>>>>>>>>>>> I have a menu widget that calls the partmgr
>>>>>>>>>>>>>>>> I have the PartymgrDecoratorLocation in my web.xml
>>>>>>>>>>>>>>>> so I get to the find screen OK.
>>>>>>>>>>>>>>>> I have a few others in my web.xml as well.
>>>>>>>>>>>>>>>> so I can navigate.
>>>>>>>>>>>>>>>> however if you don't have these in your web.xml that is
>>
>> in
>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> same
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>> directory as the controller.xml you are using
>>>>>>>>>>>>>>>> https://localhost:8443/myapp/control/partymgr
>>>>>>>>>>>>>>>> then you get messages like this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> org.ofbiz.base.util.GeneralException: Error rendering
>>
>> screen
>>
>>>>>>>>
>>>>>> [component://party/widget/partymgr/CommunicationScreens.xml#EditCommunicationEvent]:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>> java.lang.IllegalArgumentException: Could not find screen
>>>>>>
>>>>>> with
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> name
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>> [CommonCommunicationEventDecorator] in the same file as
>>
>> the
>>
>>>>>>>>> screen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> name [EditCommunicationEvent] (Could not find screen with
>>>>>>
>>>>>> name
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>> [CommonCommunicationEventDecorator] in the same file as
>>
>> the
>>
>>>>>>>>> screen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> name [EditCommunicationEvent])
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> BJ,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Do you have any specific examples of what you're
>>
>> describing?
>>
>>>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> BJ Freeman sent the following on 11/5/2007 3:59 PM:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> sorry not a complete thougt
>>>>>>>>>>>>>>>>> This is not a real bug.
>>>>>>>>>>>>>>>>> when you included another contorller
>>>>>>>>>>>>>>>>> and there is a commonscreen.xml defined in the web.xml
>>
>> of
>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>> controller application it causes an error.
>>>>>>>>>>>>>>>>> so maybe puttting the application name before
>>>>>>
>>>>>> commonescreens
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> will
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>> eliminate that.
>>>>>>>>>>>>>>>>> BJ Freeman sent the following on 11/5/2007 3:55 PM:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This is not a real bug.
>>>>>>>>>>>>>>>>>> when you included another contorller
>>>>>>>>>>>>>>>>>> and it has a commonscreen.xml
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> another is that when the the other widget from the
>>>>>>
>>>>>> included
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>> controller
>>>>>>>>>>>>>>>>>> calls for a context that is in the web.xml of that
>>>>>>>>>
>>>>>>>>> application.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>>> it is not found.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>