After migrating to CDI/Seam 3 I'm getting these messages in my server log:
WARN: Cannot attempt extension on null.
I saw a post in the Seam 3 forum (which is not accepting new posts at present)
with some logging from org.jboss.seam.faces.environment.SeamApplicationWrapper
which looks like it will help me diagnose the underlying cause of the messages.
Can anyone tell me how to enable this logging level on a Glassfish server? I
could see nothing in the Seam 3 FAQ to help me.
Thanks.
I'm using Glassfish 3.1, JSF 2.1.3, Weld 1.1.1 & Seam 3.
I'm no expert, but have you tried adding the line
org.jboss.seam.faces.environment.SeamApplicationWrapper.level=DEBUG
to your domain's logging.properties file? It's in the config directory of your domain (e.g. [glassfish-install-directory]/glassfish/domains/domain1/config/logging.properties).
Related
Problem statement:
Application built using Vaadin 8 deployed on Jboss EAP 7.0 has directory listing issue of all resources within /VAADIN/* e.g /VAADIN/themes/mytheme/images
Validation:
Upon validating other directories, say myapp/images or my/js this issue is not occurring which means default directory listing is off with Jboss configuration and is working perfectly. Issue only with Firefox
Approach:
I could partially fix by having the authentication filter configured for /VAADIN/* URL, but anyways post authentication the directory listing is still happening. Until that fix the listing was happening without authentication
Please suggest a fix the vulnerability
Thank you for the report, we had already noticed some related issues for Vaadin Flow but the tickets or related changes haven't got backported to Vaadin 8 yet. I'll look into it.
The directory listing shouldn't be shown, although the lack of it mainly provides security by obscurity. The files that are served to the client will be accessible through the client regardless. It's best not to include any sensitive data among them.
Edit: Backported fixes should now be available in 8.14-SNAPSHOT and 8.13.2.
I have a strange problem with my component that is a TrustAssociationInterceptor and it starts up with the Application Server, so it's not deployed.
After the upgrade to version 45 of my websphere 6.1 my log4j does not log into the file I've specified in the properties of my custom component but only into the SystemOut.log .
I can change the logging level only by the WebSphere console.
It seems websphere has the control of log4j. The log file of the custom component is created but not populated.
Has anyone any ideas on how to resolve this?
Thanks
Have you deployed 6.1.0-WS-WASSDK-WinX32-FP0000045.pak along with 6.1.0-WS-WAS-WinX32-FP0000045.pak, Is that to do something with SDK ?
How do I configure Myfaces to write to the logs through logback implementation which rest of my application uses ? Currently I'm writing logs from all parts of my application except the messages by Myfaces in log files.
I can find the messages from Myfaces even in the netbeans console.
Using Myfaces 2.1.8 with Glassfish 3.1 (Netbeans)
Myfaces may be logging to JUL. So you may be required to use jul-to-slf4j to redirect all logging to SLF4J.
Checkout this for how to fix.
I have a Seam application running on:
Linux CentOS
Tomcat 6.0.32
Java 6
JBoss Seam 2.2.1
RichFaces 3.3.3
When I run my application locally, everything works fine (Windows 7 here). But when I put the exactly same files on my server (VPS), the Tomcat starts with no errors, but the application do not load RichFaces components.
I've searching the solution for this problem for a few days, but didn't found nothing that can help me. I thought could be a permission problem (application's folder permission), so I've tried to change it too many ways, but RF components keep not loading.
Anyone can imagine what is happening?
Thanks in advance!
Fabricio Braga
I have solved the problem. The point is that in my case I have an Apache HTTP Server before Tomcat, and RichFaces add some JS files from JAR files. So, we need to map, editing apache config files to redirect also this JS files to Tomcat.
Then, I just edited this Apache mappings to point RichFaces JS files to Tomcat, for example:
"/my-domain-name/a4j/g/3_3_3.Final/org/ajax4jsf/framework.pack.js" mapped there: "/my-domain-name/a4j/*" for the Tomcat. And the same for the others files.
After that, the problem was over.
Regards,
Fabricio Braga
I have been developing a small project meant to run under weblogic 8.1.
Richfaces according to documentation states that it supports weblogic 8.1.
Weblogic 8.1 uses servlet specification 2.3 with jsp 1.2
This has been working on my locally installed version of weblogic 8.1 but when deploying to the sparc server, I start running into trouble. I have worked through some of the initial headaches, but then I got an error 500 and couldnt get the details. But after some effort I have come out with this...
javax.servlet.ServletException: javax/servlet/jsp/JspContext
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:344)
at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:346)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:152)
at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:216)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:245)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:137)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:214)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6987)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3892)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2766)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
JspContext is not part of jsp 1.2 it's newer. I am thinking this exception is originally a ClassNotFoundException or something similar considering the message. There is no 'cause' attached to the exception.
Following are the jar files contained in my web-application.
antlr-2.7.6.jar
asm-1.5.3.jar
asm-attrs-1.5.3.jar
cglib-2.1_3.jar
commons-beanutils-1.6.jar
commons-collections-3.2.jar
commons-digester-1.5.jar
commons-lang-2.4.jar
commons-logging-1.0.3.jar
dom4j-1.6.1.jar
ehcache-1.2.3.jar
hibernate-3.2.4.sp1.jar
jsf-api-1.1_02.jar
jsf-impl-1.1_02.jar
jstl-1.0.jar
jta-1.1.jar
log4j-1.2.15.jar
richfaces-api-3.1.6.SR1.jar
richfaces-impl-3.1.6.SR1.jar
richfaces-ui-3.1.6.SR1.jar
xercesImpl-2.9.1.jar
xml-apis-1.3.04.jar
I'm running out of options, I'll be trying to figure out who has the dependency on the JspContext class... but if someone could give me some insight it would be greatly appreciated. Oh, I cannot make many changes to the production web-logic server. I'd prefer not to make any at all, chances are those changes will be denied
Oh this error occurs when attempting to view the page, so deployment is successful.
Ok, I have solved my problem. Not the way I wanted to but it's working (atleast to what I know right now).
After using google (again) I found a comment with someone mentioning using richfaces 3.0.1.
Now I have seen many people say use version xxx even 3.3.x. After all I did get it working with 3.1.6 but on the windows version of weblogic (which could have possibly been tainted by some other weblogic version I have installed).
So I have modified my pom for maven to depend on:
<groupId>org.richfaces</groupId>
<artifactId>richfaces</artifactId>
<version>3.0.1</version>
This is not optimal, but I geuss it works.
Some taglibrary references needed changing, and packages changed to some extent.
I could post my project configuration for this if anyone ever needs it. Getting this all to work on weblogic 8.1 was not straight forward. But the reference documentation for 3.1.6 is to my knowledge incorrect by saying it support weblogic 8.1
jsp-api-2.1.jar contains the missing class, so you could try using it (either replace it in weblogic, or try in your /lib), but I can't predict what would happen.