Chris I have been able to call widget and forms thru a custom widget
with no errors when the ${parameters.mainDecoratorLocation}
is replace by the actually location as defined in the web.xml
Chris Howe sent the following on 12/17/2007 10:07 AM:
> BJ's problem occurs because when he <include>s the party
> controller and the catalog controller, he wants the requests/views from
> the party controller to have mainDecoratorLocation equal one place and
> the requests/views from the catalog controller to equal another.
>
> The only way for it to solve BJ's issue is to replace current
> ${parameters.mainDecoratorLocation} with
> ${parameters.randomVariableThatSuggestsTheScreenThisIsBeingCalledFromBelongsToAWebAppDecoratorLocation}
> or to remove the variable location altogether, thus breaking the ability
> call that screen from a custom application. Not simply provide a variable to
> <decororator-screen> location's that are empty.
>
>
>
>
> ----- Original Message ----
> From: Adrian Crum <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 11:46:26 AM
> Subject: Re: Include of controllers
>
>
> 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 <[EMAIL PROTECTED]>
>> 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 <[EMAIL PROTECTED]>
>>>>>> 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 <[EMAIL PROTECTED]>
>>>>>>>> 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 <[EMAIL PROTECTED]>
>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>>
>>
>>
>
>
>
>
>
>
>
