New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NullPointerException during deployment to a Weblogic container #495

Closed
gitblit opened this Issue Aug 12, 2015 · 17 comments

Comments

Projects
None yet
3 participants
@gitblit
Owner

gitblit commented Aug 12, 2015

Originally reported on Google Code with ID 199

What steps will reproduce the problem?
1.deploy gitblit.war to a weblogic server container
2.start the JVM
3.not the exception

What is the expected output? What do you see instead?
expected the ap to deploy, but the deployment failed.


What version of the product are you using? On what operating system?
1.2.1, HPUX, Java-6, Weblogic 10.3.4

Please provide any additional information below.

It appears that Giblit.java is trying to call 

SevletContext.getRealPath("/") - which returns a NULL when deployed as a war file -
as stated in the API for getRealPath():

"This method returns null
if the servlet container cannot translate the virtual path
to a real path for any reason (such as when the content is
being made available from a <code>.war</code> archive).
"

See also http://stackoverflow.com/questions/536228/why-does-getrealpath-return-null-when-deployed-with-a-war-file

This was not happening in v.1.1.0.

Stack trace:

<[ACTIVE] ExecuteThread: '0' f
or queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1360160594805>
<BEA-101162> <User defined liste
ner com.gitblit.GitBlit failed: java.lang.NullPointerException.
java.lang.NullPointerException
        at java.io.File.<init>(File.java:231)
        at com.gitblit.GitBlit.contextInitialized(GitBlit.java:3205)
        at com.gitblit.GitBlit.contextInitialized(GitBlit.java:3196)
        at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:481)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
....

Reported by jaymeyer on 2013-02-06 16:02:03

@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

Note: the WAR deploys to JBoss 5.1 sucessfully.  PErhaps there is a deplyment option
in Weblogic that will allow this call? I will test some options.

Reported by jaymeyer on 2013-02-06 16:06:17

@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

this looks promising

http://my-java-planet.blogspot.com/2011/11/how-to-fix-weblogic-servletcontextgetre.html

Reported by jaymeyer on 2013-02-07 04:37:52

@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

adding the attached weblogic.xml worked to fix the problem.

Now the gitblit.war deploys correctly.

Can this weblogic.xml be added to the standard build? It will be ignored by all other
containers.

Reported by jaymeyer on 2013-02-07 05:03:30


@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

Yup.  Does that go in WEB-INF?

Reported by James.Moger on 2013-02-07 12:47:14

@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

yes, WEB-INF.  
i.e. same dir as the web.xml

Reported by jaymeyer on 2013-02-07 13:17:04

@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

Reported by James.Moger on 2013-02-13 13:07:09

  • Status changed: Accepted
  • Labels added: Milestone-1.3.0
@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

Deployment as WAR file isn't working in Tomcat6, too (gitblit 1.2.1, Win2k3, Java-6,
Tomcat 6.0.33). The stacktrace is similar:

SEVERE: Exception sending context initialized event to listener instance of class com.gitblit.GitBlit
java.lang.NullPointerException
    at java.io.File.<init>(File.java:222)
    at com.gitblit.GitBlit.contextInitialized(GitBlit.java:3205)
    at com.gitblit.GitBlit.contextInitialized(GitBlit.java:3196)
    at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4206)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:4705)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779)
...

It used to work with gitblit 1.2.0, but fails in 1.2.1. You'd better get rid of the
getRealPath() there...

Reported by matthias.bauer.drs@infineon.com on 2013-02-28 12:31:25

@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

I agree, it is time to change my strategy for loading those resources.

Reported by James.Moger on 2013-02-28 13:02:17

@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

I have commited the weblogic.xml file to master.

I also reviewed WAR deployment on Tomcat 6.0.32 and it works as expected.  To be fair
I tested 1.3.0-SNAPSHOT which has slightly revised context initialization code.

Reported by James.Moger on 2013-03-29 12:48:59

  • Status changed: Queued
@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

Hm, sorry for the delay. I've been busy with other things. And setting up and verifying
my test environment took some time.

However, I've just tested with b9aa9c36981. It didn't work unfortunately:

java.lang.NullPointerException
    at java.io.File.<init>(File.java:222)
    at com.gitblit.GitBlit.contextInitialized(GitBlit.java:3282)
    at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4206)

If it works for you, there might be "specialties" in our Tomcat config involved. No
clue, what exactly. 

Standard practice with Tomcat seems to be that WAR files are deployed by dropping them
in Tomcats webapp folder. But for maintenance reasons we're doing it a bit different:
We're keeping the WAR file in a separate folder and configure everything in a context
descriptor file in conf/Catalina/localhost/. Something like this ("gitblit-test.xml"):

<?xml version='1.0' encoding='utf-8'?>
<Context path="/gitblit-test" docBase="C:/Path/To/War/gitblit/gitblit-1.3.0-SNAPSHOT.war">
  <Parameter name="baseFolder" value="D:/Path/To/Data/gitblit-test" override="false"/>
</Context>

In v1.2.0 had a whole bunch of <Parameter/> statements there to override the defaults
in web.xml (from w/i the WAR). That worked pretty well. Starting with 1.2.1 setting
the baseFolder and providing a valid gitblit.properties file there should have been
sufficient...

So with that in mind I tweaked the contextInitialized() function a bit to handle the
NPs correctly (see attached patch). This would solve the case for me. The patch isn't
perfect, though: Copying the default config to the basePath won't work this way. One
would have to use ServletContext.getResourcePaths() to get the names and ServletContext.getResourceAsStream()
to retrieve the content.

Reported by matthias.bauer.drs@infineon.com on 2013-05-06 17:58:09


@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

Thanks for the patch.  I will mostly likely adopt it.

I have moved/eliminated one contextpath retrieval.  The other ones, though, are trickier.
 This is one of those dark corners of servlet containers: direct filesystem access.

There are some containers (e.g. Jelastic) where all data must be contained within the
contextPath.  There are some containers, like yours, that return null which follows
the spec but is crappy.  :(  And then there are some containers that work just fine.

Would it be helpful to you if Gitblit supported an environment variable for specifying
the contextPath?  This would be similar/reverse of OpenShift where I can use the contextPath
as-is, but the baseFolder is set by an environment variable.

Reported by James.Moger on 2013-05-06 18:13:13

@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

Meh. I didn't expect this to be that tricky. Thanks a lot for all the effort you're
putting into that.

Regarding the environment variable thing: Configuration-wise it won't matter, if it's
environment or context (web.xml <context-param/>) parameter. Tomcat can set both from
w/i the context descriptor xml. Configuring the data path (or any other setting) is
pretty easy.

Configuring the "contextPath" (whence the physical path of the extracted WAR) doesn't
make sense. Tomcat doesn't actually expand the WAR (well maybe it does somewhere in
tmp - but that's out of reach). So there's no filesystem path to access any of the
files directly. The only way to access the webapp stuff seems to be via the ServletContext
class.

Reported by matthias.bauer.drs@infineon.com on 2013-05-07 15:05:13

@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

getResourcePaths().  Nice!  I never noticed that method.  The problem is not in the
resource reading - which getResourcePaths() would definitely help resolve - it is in
the writing/copying part.  Having a null contextFolder is a problem.  I have adopted
your tweaks and added some error logging when contextFolder is null.

I recognize that <= 1.2.0 with the web.xml config had less of an issue with this, but
that came at several maintenance (and support) costs.  It's my hope that standardizing
config on gitblit.properties and a common "data" directory structure will simplify
the user experience and the support requirements.

Thanks for your help and analysis.

Reported by James.Moger on 2013-05-10 12:21:21

@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

Your patches work perfectly for me. Thanks a lot.

Just one thing regarding Gitblit.extractResources(): I'd put is.close() and os.close()
into a "finally" block (patch attached). Just to make sure they're closed correctly
in case of an exception...

Reported by matthias.bauer.drs@infineon.com on 2013-05-15 15:23:27


@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

Oops.  :)

Reported by James.Moger on 2013-05-15 15:26:45

@gitblit

This comment has been minimized.

Owner

gitblit commented Aug 12, 2015

Fix or enhancement released in v1.3.0

Reported by James.Moger on 2013-07-14 16:52:58

  • Status changed: Fixed

@gitblit gitblit closed this Aug 12, 2015

@fzs fzs modified the milestone: 1.3.0 Dec 13, 2016

@jayasharma8

This comment has been minimized.

jayasharma8 commented May 9, 2018

Hi guys,

I am getting following error when launching and trying to login to application. Login is not wokring we noticed this issue after weblogic upgrade from 10.3.5 to 10.3.6
Env details:
Liferay 4.2
weblogic 10.3.6
jdk 1.6.181

Kindly help. we are not getting any clue and stuck.

com.liferay.portal.NoSuchLayoutSetException: No LayoutSet exists with the key {companyId=liferay.com, virtualHost=test-www.xyz.com}    at com.liferay.portal.service.persistence.LayoutSetFinder.findByC_V(LayoutSetFinder.java:86)    at com.liferay.portal.service.impl.LayoutSetLocalServiceImpl.getLayoutSet(LayoutSetLocalServiceImpl.java:105)    at sun.reflect.GeneratedMethodAccessor531.invoke(Unknown Source)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)    at java.lang.reflect.Method.invoke(Method.java:597)    at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:280)    at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:187)    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:154)    at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:107)    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:210)    at com.sun.proxy.$Proxy67.getLayoutSet(Unknown Source)    at com.liferay.portal.service.ejb.LayoutSetLocalServiceEJBImpl.getLayoutSet(LayoutSetLocalServiceEJBImpl.java:65)    at com.liferay.portal.service.ejb.LayoutSetLocalServiceEJBImpl_cwukue_ELOImpl.__WL_invoke(Unknown Source)    at weblogic.ejb.container.internal.SessionLocalMethodInvoker.invoke(SessionLocalMethodInvoker.java:39)    at com.liferay.portal.service.ejb.LayoutSetLocalServiceEJBImpl_cwukue_ELOImpl.getLayoutSet(Unknown Source)    at sun.reflect.GeneratedMethodAccessor531.invoke(Unknown Source)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)    at java.lang.reflect.Method.invoke(Method.java:597)    at org.springframework.ejb.access.LocalSlsbInvokerInterceptor.invoke(LocalSlsbInvokerInterceptor.java:65)    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:210)    at com.sun.proxy.$Proxy67.getLayoutSet(Unknown Source)    at com.liferay.portal.service.LayoutSetLocalServiceUtil.getLayoutSet(LayoutSetLocalServiceUtil.java:63)    at com.liferay.portal.events.ServicePreAction.getDefaultLayout(ServicePreAction.java:689)    at com.liferay.portal.events.ServicePreAction.run(ServicePreAction.java:288)    at com.liferay.portal.events.EventsProcessor._process(EventsProcessor.java:132)    at com.liferay.portal.events.EventsProcessor.process(EventsProcessor.java:70)    at com.liferay.portal.servlet.MainServlet.service(MainServlet.java:857)    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)    at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301)    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)    at com.corelogic.bis.ite.sec.websecurity.filter.XSSValidationFilter.doFilter(XSSValidationFilter.java:148)    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)    at com.corelogic.bis.ite.sec.websecurity.filter.XSSValidationFilter.doFilter(XSSValidationFilter.java:148)    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)    at com.liferay.filters.strip.StripFilter.doFilter(StripFilter.java:94)    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)    at com.liferay.filters.secure.SecureFilter.doFilter(SecureFilter.java:143)    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)    at com.liferay.filters.compression.CompressionFilter.doFilter(CompressionFilter.java:124)    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)    at com.liferay.portal.servlet.filters.autologin.AutoLoginFilter.doFilter(AutoLoginFilter.java:117)    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)    at com.liferay.filters.sso.cas.CASFilter.doFilter(CASFilter.java:96)    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)    at com.liferay.portal.servlet.filters.virtualhost.VirtualHostFilter.doFilter(VirtualHostFilter.java:152)    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3748)    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3714)    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)    at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2283)    at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2182)    at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1499)    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:263)    at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)<May 9, 2018 1:58:41 AM CDT>    <ExecuteRequest failed java.lang.NullPointerException.java.lang.NullPointerException    at java.util.Hashtable.(Hashtable.java:195)    at weblogic.servlet.internal.session.SessionData.convertToHashtable(SessionData.java:1411)    at weblogic.servlet.internal.session.SessionData.writeExternal(SessionData.java:1170)    at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1442)    at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1411)    Truncated. see log file for complete stacktrace>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment