Re: WebXmlParser warning about dispatcher - shale-framework-1.1.0-SNAPSHOT for Feb 23, 2007
fyi.. in my earlier message, I was *quoting* Craig's note.. everything
below here is what he said.. sorry I wasn't clear enough.. :)
Geeta
> You will want to register your view controller beans as a managed bean
> anyway, so that JSF will create them for you on demand. But, for
> Shale to provide the services it does, it must know how to translate
> the "view id" --- something like "/logon.jsp" -- into the name of the
> corresponding managed bean. That way, when you navigate to that page,
> Shale can precreate the bean and call the relevant event handlers.
>
> Thus, the managed bean name corresponding to "/logon.jsp" *must* be
> named "logon" for it to be recognized as a ViewController. In your
> scenario, you left the name copied from the Use Cases example
> ("logon$profile"), which would be suitable for a page named
> "/logon/profile.jsp".
[EMAIL PROTECTED] wrote on 02/27/2007 12:20:08 AM:
> "Rahul Akolkar" <[EMAIL PROTECTED]> wrote on 02/26/2007 11:18:56
PM:
>
> >
> > About (1), if you're not using Spring, better off taking out all
> > Spring jars and the shale-spring jar from the application. (2) sounds
> > correct, and it might change further now that Tiles is a top level
> > project at Apache. Again, seems unrelated to the 403 bit.
> >
> > -Rahul
> >
> >
>
> Hi Rahul,
>
> Thanks for the reply. After a bit of trial and error I got tiles to
behave
> properly. (I did remove all references to Spring btw). But for now I have
> also had to remove *all* config info from my chain-config.xml; else I
can't
> get rid of my 403 error. I have shelved the problem for right now so I
can
> move on.
>
> Anyway, so I at least got my app up and running. But I am having a
peculiar
> problem with just one of my jsps in that I cannot seem to hit the backing
> bean's prerender() or init() methods. I have tried changing the scope of
> the bean to no avail.
>
> So I went back to the usecases example to try to see if anything has
> changed since the last time and saw a peculiar thing. In
faces-config.xml,
> in the "Validate test" section, the backing bean name is "validate$test"
> and not "validator$test". According to a long ago post of Craig's:
> http://mail-archives.apache.org/mod_mbox/struts-user/200508.mbox/%
> [EMAIL PROTECTED]
>
> You will want to register your view controller beans as a managed bean
> anyway, so that JSF will create them for you on demand. But, for
> Shale to provide the services it does, it must know how to translate
> the "view id" --- something like "/logon.jsp" -- into the name of the
> corresponding managed bean. That way, when you navigate to that page,
> Shale can precreate the bean and call the relevant event handlers.
>
> Thus, the managed bean name corresponding to "/logon.jsp" *must* be
> named "logon" for it to be recognized as a ViewController. In your
> scenario, you left the name copied from the Use Cases example
> ("logon$profile"), which would be suitable for a page named
> "/logon/profile.jsp".
>
> Has this requirement been changed in the current Shale? More importantly
> are new requirements in place now? I looked through the docs for
> ViewController and didnt see anything.. but I may not be looking in the
> right places..
>
>
>
> My whole problem is that my breakpoints in my backing beans in init() and
> prerender() are not getting hit. My particular situation is this:
>
> 1. My faces-config.xml has this:
>
> worklist
>
> com.intellicare.webshark.action.workflow.WorkListManagerBean
>
> request
>
> nextAssignmentHome1
> #{worklist$nextAssignmentHome1}
>
>
>
> and my WorkListmanagerBean has private AssignmentBean1
nextAssignmentHome1;
> with the appropraite getters and setters. When i step through my code, in
> one of my "action" methods of WorkListmanagerBean I see that
> nextAssignmentHome1 is not null (as it should be) and I set some values
> here. At the end of my method I forward to "nextAssignmentHome1".
>
> 2. faces-config also has:
>
>
> worklist$nextAssignmentHome1
>
>
> com.intellicare.webshark.action.workflow.AssignmentBean1
>
> session
>
>
> and
> *
>
> nextAssignmentHome1
>
> /worklist/nextAssignmentHome1.jsp
>
> etc.
>
> Can you spot anything off? Because I step through the code in my worklist
> bean, I set attributes for the nextAssignmentHome1 backing bean. However,
> when I step through AssignmentBean1, everything I set in my worklist bean
> has been reset to default (null) values! (:( I even changed the above
code
> to use instead: AssignmentBean1 assignmentBean = (AssignmentBean1)
> getBean(Constants.ASSIGNMENT_BEAN1); (and removed the managed bean
property
> set in faces-config. xml but it made no differnece, my init() and
> prerender() are just *not* getting hit..(:(.. All this was working
> perfectly with my earli
Re: WebXmlParser warning about dispatcher - shale-framework-1.1.0-SNAPSHOT for Feb 23, 2007
"Rahul Akolkar" <[EMAIL PROTECTED]> wrote on 02/26/2007 11:18:56 PM:
>
> About (1), if you're not using Spring, better off taking out all
> Spring jars and the shale-spring jar from the application. (2) sounds
> correct, and it might change further now that Tiles is a top level
> project at Apache. Again, seems unrelated to the 403 bit.
>
> -Rahul
>
>
Hi Rahul,
Thanks for the reply. After a bit of trial and error I got tiles to behave
properly. (I did remove all references to Spring btw). But for now I have
also had to remove *all* config info from my chain-config.xml; else I can't
get rid of my 403 error. I have shelved the problem for right now so I can
move on.
Anyway, so I at least got my app up and running. But I am having a peculiar
problem with just one of my jsps in that I cannot seem to hit the backing
bean's prerender() or init() methods. I have tried changing the scope of
the bean to no avail.
So I went back to the usecases example to try to see if anything has
changed since the last time and saw a peculiar thing. In faces-config.xml,
in the "Validate test" section, the backing bean name is "validate$test"
and not "validator$test". According to a long ago post of Craig's:
http://mail-archives.apache.org/mod_mbox/struts-user/200508.mbox/[EMAIL
PROTECTED]
You will want to register your view controller beans as a managed bean
anyway, so that JSF will create them for you on demand. But, for
Shale to provide the services it does, it must know how to translate
the "view id" --- something like "/logon.jsp" -- into the name of the
corresponding managed bean. That way, when you navigate to that page,
Shale can precreate the bean and call the relevant event handlers.
Thus, the managed bean name corresponding to "/logon.jsp" *must* be
named "logon" for it to be recognized as a ViewController. In your
scenario, you left the name copied from the Use Cases example
("logon$profile"), which would be suitable for a page named
"/logon/profile.jsp".
Has this requirement been changed in the current Shale? More importantly
are new requirements in place now? I looked through the docs for
ViewController and didnt see anything.. but I may not be looking in the
right places..
My whole problem is that my breakpoints in my backing beans in init() and
prerender() are not getting hit. My particular situation is this:
1. My faces-config.xml has this:
worklist
com.intellicare.webshark.action.workflow.WorkListManagerBean
request
nextAssignmentHome1
#{worklist$nextAssignmentHome1}
and my WorkListmanagerBean has private AssignmentBean1 nextAssignmentHome1;
with the appropraite getters and setters. When i step through my code, in
one of my "action" methods of WorkListmanagerBean I see that
nextAssignmentHome1 is not null (as it should be) and I set some values
here. At the end of my method I forward to "nextAssignmentHome1".
2. faces-config also has:
worklist$nextAssignmentHome1
com.intellicare.webshark.action.workflow.AssignmentBean1
session
and
*
nextAssignmentHome1
/worklist/nextAssignmentHome1.jsp
etc.
Can you spot anything off? Because I step through the code in my worklist
bean, I set attributes for the nextAssignmentHome1 backing bean. However,
when I step through AssignmentBean1, everything I set in my worklist bean
has been reset to default (null) values! (:( I even changed the above code
to use instead: AssignmentBean1 assignmentBean = (AssignmentBean1)
getBean(Constants.ASSIGNMENT_BEAN1); (and removed the managed bean property
set in faces-config. xml but it made no differnece, my init() and
prerender() are just *not* getting hit..(:(.. All this was working
perfectly with my earlier version of Shale, btw...
I have been fighting with this upgrade since Friday and am ready to give
it up.. though that is such a shame since I really feel I am *this*
close..(:(
Anyway, once again thanks for your help!
Geeta
Re: WebXmlParser warning about dispatcher - shale-framework-1.1.0-SNAPSHOT for Feb 23, 2007
On 2/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi Rahul, thank you very much for your reply. After reading your statement that the dialog jars should not really effect my application, I removed them from my WEB-INF/lib directory again. Actually i had tried this before with no success, but it turned out that it was a problem with my eclispe caching stuff (even after a refresh/clean/rebuild)! So I deleted my server, created a new one, and was thrilled to see that i could go beyond what i had before..:) My happiness was short lived though.. and instead of going into the gory details, let me ask you two things: 1. Is it necessary to add this in my web.xml: org.springframework.web.context.ContextLoaderListener *even though* I don't use spring in my application? I removed it but ran into trouble and googling led me to this solution: http://www.mail-archive.com/issues@shale.apache.org/msg00050.html which made me think I ought to add in web.xml it anyways.. In any case my app would not start up without it.. Am I right..? 2. The tiles uri I used to have before (in my jsps) was http://jakarta.apache.org/tiles. However that doesn't work now and I now use http://struts.apache.org/tags-tiles. Is this correct? (I got this uri from the tld in tiles.core-2.0-r68346-SNAPSSHOT.jar). I did 1 above in order to get rid of a java.lang.IllegalStateException: No WebApplicationContext error. And I changed my uri as outlined in 2 above in order to resolve a "I don't know what you mean by this uri" kind of problem. About (1), if you're not using Spring, better off taking out all Spring jars and the shale-spring jar from the application. (2) sounds correct, and it might change further now that Tiles is a top level project at Apache. Again, seems unrelated to the 403 bit. -Rahul I am now back to the 403 (Access forbidden) page. Would I need to add anything more/different in chain-config.xml? Or am I again barking up the wrong tree? btw, I don't access my logon.jsp directly either. My 'welcome-file list" has index0.jsp. And index0.jsp forwards to index1.jsp using .. This has always worked before (before I did the upgrade to the new shale/faces/tiles..) Thank you very much again for your time; I really appreciate it! Geeta
Re: WebXmlParser warning about dispatcher - shale-framework-1.1.0-SNAPSHOT for Feb 23, 2007
Hi Rahul, thank you very much for your reply. After reading your statement
that the dialog jars should not really effect my application, I removed
them from my WEB-INF/lib directory again. Actually i had tried this before
with no success, but it turned out that it was a problem with my eclispe
caching stuff (even after a refresh/clean/rebuild)! So I deleted my server,
created a new one, and was thrilled to see that i could go beyond what i
had before..:)
My happiness was short lived though.. and instead of going into the gory
details, let me ask you two things:
1. Is it necessary to add this in my web.xml:
org.springframework.web.context.ContextLoaderListener
*even though* I don't use spring in my application? I removed it but ran
into trouble and googling led me to this solution:
http://www.mail-archive.com/issues@shale.apache.org/msg00050.html
which made me think I ought to add in web.xml it anyways.. In any case my
app would not start up without it.. Am I right..?
2. The tiles uri I used to have before (in my jsps) was
http://jakarta.apache.org/tiles. However that doesn't work now and I now
use http://struts.apache.org/tags-tiles. Is this correct? (I got this uri
from the tld in tiles.core-2.0-r68346-SNAPSSHOT.jar).
I did 1 above in order to get rid of a java.lang.IllegalStateException: No
WebApplicationContext error. And I changed my uri as outlined in 2 above in
order to resolve a "I don't know what you mean by this uri" kind of
problem.
I am now back to the 403 (Access forbidden) page. Would I need to add
anything more/different in chain-config.xml? Or am I again barking up the
wrong tree?
btw, I don't access my logon.jsp directly either. My 'welcome-file list"
has index0.jsp. And index0.jsp forwards to index1.jsp using .. This has always worked before (before I did the
upgrade to the new shale/faces/tiles..)
Thank you very much again for your time; I really appreciate it!
Geeta
"Rahul Akolkar" <[EMAIL PROTECTED]> wrote on 02/24/2007 03:35:47 PM:
> On 2/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Hi all:
> >
> > I just downloaded the shale-framework-1.1.0-SNAPSHOT (dated today) and
> > after a bit of hastle got my server to at least start up (it was a
> > challenge since I use tiles too..(:(.
> >
> > My web.xml has this filter-mapping:
> >
> > shale
> > /*
> > REQUEST
> > FORWARD
> >
> >
> > However, when tomcat starts up I get the following warnings:
> >
> > [WARN] FacesConfigurator - More than one managed bean w/ the name of
> > 'org.apache.shale.dialog.MANAGER' - only keeping the last
> > [WARN] WebXmlParser - Ignored element 'dispatcher' as child of
> > 'filter-mapping'.
> > [WARN] WebXmlParser - Ignored element 'dispatcher' as child of
> > 'filter-mapping'.
> > [WARN] SCXMLLifecycleListener - No dialog configuration information
> > present. No default configuration found at:
/WEB-INF/dialog-config.xml.
> > No embedded configuration found at: META-INF/dialog-config.xml
> > [WARN] BasicLifecycleListener - No dialog configuration information
> > present. No default configuration found at:
/WEB-INF/dialog-config.xml.
> > No embedded configuration found at: META-INF/dialog-config.xml
> >
>
>
> The three dialog related warnings are due to the fact that the app
> includes both shale-dialog-basic and shale-dialog-scxml jars. You get
> to pick one of the impls, see "API and Implementations" section:
>
> http://shale.apache.org/shale-dialog/index.html
>
> Removing one of those (of your choice) will reduce the number of
> warnings to one (assuming you still don't have a dialog-config).
> Alternatively, if you are not using dialogs, you might as well remove
> both (and the API jar, shale-dialog as well).
>
> The warnings are probably related to this:
>
> https://issues.apache.org/jira/browse/MYFACES-1415
>
> and if so, they're inconsequential.
>
>
> > Since I am (as of now) not using dialogs I ignored the dialog warnings.
> > However, I think the WebXmlParser is in fact important because when I
try
> > to access my app, I get a 403 error ("Access to the specfied resource
()
> > has been forbidden"). My initial page does a forward and that is why i
> > think getting the WebXmlParser warning is important.
> >
>
>
> Not sure what it is, a similar scenario is available in the
> shale-usecases war file (index.jsp has a to
> usecases.jsp), but accessing usecases.jsp does 403, IIRC.
>
> -Rahul
>
>
> > Btw, my chain-config.xml has this:
> >
> >
> >
> >
> >> className="org.apache.shale.application.ContextRelativePathFilter"
> >
> > includes="\S*\.xml,\S*\.faces,\S*\.css,\S*\.html,\S*\.gif,\S*\.
> png,\S*\.js,\S*\.jpg,/index0\.jsp,/index1\.jsp,/index\.jsp,/test\.
> html,/assessmentDone,/createProcess,/dbPing\.do,\S*\.resources"
> > excludes="\S*\.jsp,\S*\.jspf"/>
> >
> >
> >
> >
> > Can anybody give me a clue what's going on? .. Or at least why I get
the
> > WebXmlPars
Re: WebXmlParser warning about dispatcher - shale-framework-1.1.0-SNAPSHOT for Feb 23, 2007
On 2/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi all:
I just downloaded the shale-framework-1.1.0-SNAPSHOT (dated today) and
after a bit of hastle got my server to at least start up (it was a
challenge since I use tiles too..(:(.
My web.xml has this filter-mapping:
shale
/*
REQUEST
FORWARD
However, when tomcat starts up I get the following warnings:
[WARN] FacesConfigurator - More than one managed bean w/ the name of
'org.apache.shale.dialog.MANAGER' - only keeping the last
[WARN] WebXmlParser - Ignored element 'dispatcher' as child of
'filter-mapping'.
[WARN] WebXmlParser - Ignored element 'dispatcher' as child of
'filter-mapping'.
[WARN] SCXMLLifecycleListener - No dialog configuration information
present. No default configuration found at: /WEB-INF/dialog-config.xml.
No embedded configuration found at: META-INF/dialog-config.xml
[WARN] BasicLifecycleListener - No dialog configuration information
present. No default configuration found at: /WEB-INF/dialog-config.xml.
No embedded configuration found at: META-INF/dialog-config.xml
The three dialog related warnings are due to the fact that the app
includes both shale-dialog-basic and shale-dialog-scxml jars. You get
to pick one of the impls, see "API and Implementations" section:
http://shale.apache.org/shale-dialog/index.html
Removing one of those (of your choice) will reduce the number of
warnings to one (assuming you still don't have a dialog-config).
Alternatively, if you are not using dialogs, you might as well remove
both (and the API jar, shale-dialog as well).
The warnings are probably related to this:
https://issues.apache.org/jira/browse/MYFACES-1415
and if so, they're inconsequential.
Since I am (as of now) not using dialogs I ignored the dialog warnings.
However, I think the WebXmlParser is in fact important because when I try
to access my app, I get a 403 error ("Access to the specfied resource ()
has been forbidden"). My initial page does a forward and that is why i
think getting the WebXmlParser warning is important.
Not sure what it is, a similar scenario is available in the
shale-usecases war file (index.jsp has a to
usecases.jsp), but accessing usecases.jsp does 403, IIRC.
-Rahul
Btw, my chain-config.xml has this:
Can anybody give me a clue what's going on? .. Or at least why I get the
WebXmlParser warning? Btw, my web.xml has this header:
http://java.sun.com/xml/ns/j2ee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";>
Many thanks in advance for all help..:)
Geeta
WebXmlParser warning about dispatcher - shale-framework-1.1.0-SNAPSHOT for Feb 23, 2007
Hi all:
I just downloaded the shale-framework-1.1.0-SNAPSHOT (dated today) and
after a bit of hastle got my server to at least start up (it was a
challenge since I use tiles too..(:(.
My web.xml has this filter-mapping:
shale
/*
REQUEST
FORWARD
However, when tomcat starts up I get the following warnings:
[WARN] FacesConfigurator - More than one managed bean w/ the name of
'org.apache.shale.dialog.MANAGER' - only keeping the last
[WARN] WebXmlParser - Ignored element 'dispatcher' as child of
'filter-mapping'.
[WARN] WebXmlParser - Ignored element 'dispatcher' as child of
'filter-mapping'.
[WARN] SCXMLLifecycleListener - No dialog configuration information
present. No default configuration found at: /WEB-INF/dialog-config.xml.
No embedded configuration found at: META-INF/dialog-config.xml
[WARN] BasicLifecycleListener - No dialog configuration information
present. No default configuration found at: /WEB-INF/dialog-config.xml.
No embedded configuration found at: META-INF/dialog-config.xml
Since I am (as of now) not using dialogs I ignored the dialog warnings.
However, I think the WebXmlParser is in fact important because when I try
to access my app, I get a 403 error ("Access to the specfied resource ()
has been forbidden"). My initial page does a forward and that is why i
think getting the WebXmlParser warning is important.
Btw, my chain-config.xml has this:
Can anybody give me a clue what's going on? .. Or at least why I get the
WebXmlParser warning? Btw, my web.xml has this header:
http://java.sun.com/xml/ns/j2ee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";>
Many thanks in advance for all help..:)
Geeta
