JSFUnit's session key not 'put' to external context

[jjfraney]

I am using arquillian 1.0.0.CR4 and JSFUnit 2.0.0.Beta2-SNAPSHOT in jboss AS 6 on a seam 2.2 application.

This simple unit test fails.

@Test
@InitialPage("/home.seam")
public void testLogin(JSFServerSession serfver, JSFClientSession client) throws Exception {
    assertNotNull(server.getFacesContext());
}

I used debugger and found that JSFUnitFacesContext.release() is not setting the SESSION_KEY in the external context.  The comment there says: "Make the FacesContext available to JSFUnit, if and only if a new page was rendered."  Apparently, if a view would have children if a new page was rendered.

The server.log does not show any failure log messages in processing the initial page.  Log level is set to FINE.

What does it mean if a new page is not rendered?  How do I find out why it was not rendered?

Thanks,

John

[ssilvert]

John Franey wrote:

@Test

@InitialPage("/home.seam")

public void testLogin(JSFServerSession serfver, JSFClientSession client) throws Exception {

    assertNotNull(server.getFacesContext());

}

Try again.  You have a typo.

Stan

[jjfraney]

Thanks for the response.

That is a typo during keying the code into this forum app.  When I cut and paste from eclipse, I always get a horrible table.  So, I have to either type it in again, or cut and paste from a different editor.  Either way is a nuisance.  See:

	@Test
	@InitialPage("/home.seam")
	public void testLogin(JSFServerSession server, JSFClientSession client)
			throws Exception {
		assertNotNull(server.getFacesContext());

[ssilvert]

Yea, after I posted that I was wondering how it even compiled!  I should have suspected it was just a cut and paste error.

Anyway, to answer your original question, what this will do is to go through the normal JSF cleanup process in the case where you didn't render a JSF page.   For instance, you might have started with a JSF page but you navigated to a plain HTML page.

In this case, the way to test the resulting non-JSF page is to use plain HtmlUnit in the JSFUnit test.

Stan

[jjfraney]

Thanks.

Well, OK.  You seem pretty certain that my test is visiting an html page (not a jsf page).  I am green in this technology and so I will go with it, ....but....

1) I had this test case working with jsfunit-2.0.0.Beta1 and arquillian-1.0.0.Alpha5; working means the getFacesContext does not return null.

2) I had assumed that all my pages were jsf pages.  I'm using jboss seam.  I thought every seam request was a jsf request.  How do I tell the difference?

3)  I think the log indicates a jsf request.  Here are some messages from my server.log entry.  Don't they indicate a jsf request?:

2011-09-12 13:53:55,116 DEBUG [org.ajax4jsf.webapp.BaseFilter] (http-127.0.0.1-8080-3) Filter start request processing at 9/12/11 1:53 PM  for uri: /test/home.seam

2011-09-12 13:53:55,116 DEBUG [org.ajax4jsf.webapp.BaseFilter] (http-127.0.0.1-8080-3) Filter request output to XML

2011-09-12 13:53:55,116 DEBUG [org.ajax4jsf.webapp.BaseXMLFilter] (http-127.0.0.1-8080-3) XML filter service start processing request

2011-09-12 13:53:55,124 DEBUG [org.jboss.seam.contexts.FacesLifecycle] (http-127.0.0.1-8080-3) >>> Begin JSF request for /test/home.seam

2011-09-12 13:53:55,126 DEBUG [org.jboss.seam.util.Naming] (http-127.0.0.1-8080-3) JNDI InitialContext properties:{java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory, java.naming.

factory.url.pkgs=org.jboss.naming:org.jnp.interfaces}

2011-09-12 13:53:55,145 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-3) beginning transaction prior to phase: RESTORE_VIEW 1

2011-09-12 13:53:55,145 DEBUG [org.jboss.seam.transaction.UTTransaction] (http-127.0.0.1-8080-3) beginning JTA transaction

2011-09-12 13:53:55,158 DEBUG [org.ajax4jsf.event.AjaxPhaseListener] (http-127.0.0.1-8080-3) Process before phase RESTORE_VIEW 1

2011-09-12 13:53:55,159 DEBUG [org.ajax4jsf.event.InitPhaseListener] (http-127.0.0.1-8080-3) Perform additional framework initialization on first request

2011-09-12 13:53:55,159 DEBUG [org.ajax4jsf.event.InitPhaseListener] (http-127.0.0.1-8080-3) Set AjaxViewHandler on top of chain

2011-09-12 13:53:55,159 DEBUG [org.ajax4jsf.application.AjaxViewHandler] (http-127.0.0.1-8080-3) Create instance of Ajax ViewHandler

2011-09-12 13:53:55,173 FINE  [javax.faces.component] (http-127.0.0.1-8080-3) Populating PropertyDescriptor Map for class 'class org.ajax4jsf.component.AjaxViewRoot' for Thread named 'http-127.0.0

.1-8080-3'.

2011-09-12 13:53:55,175 DEBUG [org.jboss.seam.init.Initialization] (http-127.0.0.1-8080-2) Using Java hot deploy

2011-09-12 13:53:55,177 DEBUG [org.ajax4jsf.event.InitPhaseListener] (http-127.0.0.1-8080-3) Remove init phase listener from factories

2011-09-12 13:53:55,178 DEBUG [org.ajax4jsf.event.AjaxPhaseListener] (http-127.0.0.1-8080-3) Process after phase RESTORE_VIEW 1

2011-09-12 13:53:55,189 DEBUG [org.jboss.seam.core.Manager] (http-127.0.0.1-8080-3) No stored conversation

2011-09-12 13:53:55,210 DEBUG [org.ajax4jsf.webapp.BaseFilter] (http-127.0.0.1-8080-2) Filter start request processing at 9/12/11 1:53 PM  for uri: /test/ArquillianServletRunner

2011-09-12 13:53:55,210 DEBUG [org.ajax4jsf.webapp.BaseFilter] (http-127.0.0.1-8080-2) Filter request output to XML

2011-09-12 13:53:55,210 DEBUG [org.ajax4jsf.webapp.BaseXMLFilter] (http-127.0.0.1-8080-2) XML filter service start processing request

2

...

...

...

2011-09-12 13:53:55,319 DEBUG [org.ajax4jsf.event.AjaxPhaseListener] (http-127.0.0.1-8080-3) Process after phase RENDER_RESPONSE 6

2011-09-12 13:53:55,320 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-3) committing transaction after phase: RENDER_RESPONSE 6

...

...

...

2011-09-12 13:53:55,323 DEBUG [org.jboss.seam.contexts.FacesLifecycle] (http-127.0.0.1-8080-3) <<< End JSF request for /test/home.seam

2011-09-12 13:53:55,323 DEBUG [org.ajax4jsf.webapp.BaseXMLFilter] (http-127.0.0.1-8080-3) create HTML/XML parser for content type: application/xhtml+xml

...

...

...

[ssilvert]

Oh, I'm not totally sure of anything.

I'm just saying that is what that code was meant for.  It's not the request that is important here.  Rather, it's the response that matters.  A JSF request can return a non-JSF response.  And, yes, Seam can do this.

But since, your same code was working in an earlier version then you may indeed be seeing a bug or maybe your code has changed.  The final of JSFUnit 2.0 Beta 2 should be out this week.  It uses the latest Arquillian.  Maybe you can wait and try that?  If it still fails then we will need to dig deeper.

Stan

[ssilvert]

Oh, the way you can tell if you got a JSF response is to run this from your browser and look at the source.  If you see a hidden field with javax.faces.ViewState then you know you got a JSF response.

Stan

[jjfraney]

Ok, well that settles it.  I do not have a jsf response to my request.  There are no hidden fields, and no references to ViewState.   I'll will take the steps to rule out whether my code changed, and show it works back on Beta1.

I think I have the latest jsfunit now, so I'm ready to dig into this without waiting for an official release.    I am running with: df8fc6667d4543582df98d8af844b09b101d4965, Thu Sep 1 11:50:12 2011 -0400,  Is it possible the developers are neglecting to push to git hub?  The latest I can get is: 2058ad5b5d32d8f25ace029858e7bb2ffa66e3d6, Thu Sep 8 16:04:01 2011 -0700.  that is fairly fresh (3 days), and there does not seem to be significant change from the version I am using (Sep 1).

Is there a new arquillian release imminent, too?  I think Final is next.  Serendipity, baby!

I was hoping this was a quick 'A Ha'.  That I missed a config file some where.

[ssilvert]

You can actually go ahead and get the release from Nexus and give it a try.  We just don't have the docs ready yet.

https://repository.jboss.org/nexus/index.html#nexus-search;quick~jsfunit

If you are using the latest from GitHub then you probably have the right code.

Stan

[jjfraney]

Stan,

Thanks for the right questions.

I went back to my unit tests using verion jsfunit-beta1 and it worked.  It produced a response with a hidden field with ViewState.

So, I closely compared content of the two versions.  I discovered that while my application code didn't change, the unit test code changed to upgrade shrinkwrap api. I used the wrong shrinkwrap methods for web resources (wrong: addAsResource, correct: addAsWebResource).  I had also dropped my faces-config.xml and beans.xml files.  Oops.

Hopefully, my mistake did not keep the release team awake with concern about the upcoming release. 

[ssilvert]

No problem John.  I'm sure that others will run into the same issue and they can look at this discussion and get an explanation.

Regards,

Stan