openwebbeans-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thusitha Thilina Dayaratne <thusithathil...@gmail.com>
Subject Re: NPE when webBeansContext.getApplicationBoundaryService() in AbstractProxyFactory openwebbeans 1.2.7
Date Wed, 20 May 2015 10:31:34 GMT
Hi Romain,Mark

Thanks a lot for your guys support.
I was able to patch the scenario and now it work fine :)
Thanks again.

Best Regards

2015-05-20 13:51 GMT+05:30 Romain Manni-Bucau <rmannibucau@gmail.com>:

>
> 2015-05-20 10:19 GMT+02:00 Thusitha Thilina Dayaratne <
> thusithathilina@gmail.com>:
>
>> Hi
>>
>> Thanks for quick response.
>> Since I'm packing openejb-core and openwebbeans-impl both contains
>> openwebbeans.properties files. Should I merge them? Or should I use one
>> particular version?
>>
>
> you need to merge (add owb missing ones)
>
>
>> >>Yes i guess resources are not osgi friendly with our current packaging
>> (why i asked if you were in osgi).
>>
>> >>Easy fix for you is to override our threadsingletonserviceimpl and
>> force it in system.properties (key is the fqn of the interface, value the
>> impl). In your impl you read the conf in >>a osgi friendly way or elsewhere.
>>
>> Yes that seems the issue. On the debug mode I try "/"
>> + DEFAULT_CONFIG_PROPERTIES_NAME instead of DEFAULT_CONFIG_PROPERTIES_
>> NAME then it is picking up the properties file correctly. I'm not quite
>> sure why it correctly picks the file when I put forward slash in-front of
>> the path.
>>
>
> guess it is due to the osgi loader. CXF checks always both places for that
> reason.
>
>
>> I will try out the patching mechanism you suggested and let you know the
>> progress.
>>
>> >>The way you described it is as it is intended.
>> >>OpenWebBeans first reads all it’s defaults from the various
>> META-INF/openwebbeans/openwebbeans.proprties files (sorted according to
>> their ordinal). After that values get overwritten with the things we get
>> from OpenEJB.
>> >>It might well be that we miss the openwebbeans.property export part in
>> our manifest. I’m not really good in OSGi…
>> >>Probably try adding this property in openejb?
>>
>>
>>
>>
>> 2015-05-20 13:31 GMT+05:30 Mark Struberg <struberg@yahoo.de>:
>>
>>> The way you described it is as it is intended.
>>>
>>> OpenWebBeans first reads all it’s defaults from the various
>>> META-INF/openwebbeans/openwebbeans.proprties files (sorted according to
>>> their ordinal). After that values get overwritten with the things we get
>>> from OpenEJB.
>>>
>>> It might well be that we miss the openwebbeans.property export part in
>>> our manifest. I’m not really good in OSGi…
>>>
>>> Probably try adding this property in openejb?
>>>
>>> LieGrue,
>>> strub
>>>
>>> > Am 20.05.2015 um 08:16 schrieb Thusitha Thilina Dayaratne <
>>> thusithathilina@gmail.com>:
>>> >
>>> > Hi,
>>> >
>>> > I did some more debugging through the openwebbeans source. Following
>>> are my findings.
>>> > In the debug mode if I set the property
>>> org.apache.webbeans.spi.ApplicationBoundaryService to
>>> org.apache.webbeans.corespi.se.DefaultApplicationBoundaryService inside the
>>> to the properties parameter in the WebBeansContext overloaded constructor
>>> everything works fine. So I back track the source to find where that
>>> properties get initialized.
>>> >
>>> > I think it is getting initialized at initialize() method in the
>>> org.apache.openejb.cdi.ThreadSingletonServiceImpl class. There it created a
>>> Properties object and put some properties and also get the application
>>> properties and put them to that as well. In my case
>>> properties.putAll(appContext.getProperties()); this doesn't add anything
>>> since appContext.getProperties() is empty.
>>> >
>>> > Then I check for the place where openwebbeans reads the
>>> openwebbeans.properties file and load from that. I think it is happen in
>>> the parseConfiguration() method inside
>>> org.apache.webbeans.config.OpenWebBeansConfiguration class. When I debug
>>> the particular line where it loads the properties from
>>> META-INF/openwebbeans/openwebbeans.properties
>>> >
>>> > Properties newConfigProperties =
>>> PropertyLoader.getProperties(DEFAULT_CONFIG_PROPERTIES_NAME);
>>> >
>>> > it return null for me.
>>> > It seems that my bundle is not correctly picking up the properties
>>> file.
>>> > Could someone figure out a possible reason for that? Is this a
>>> configuration error in my bundle?
>>> >
>>> > Thanks
>>> > Best Regards
>>> >
>>> > 2015-05-20 10:22 GMT+05:30 Thusitha Thilina Dayaratne <
>>> thusithathilina@gmail.com>:
>>> > Hi,
>>> >
>>> > >>The stuff with the -D… for all owb properties only works in trunk.
>>> > >>Could you plz try the tomee-7.0.0-SNAPSHOT? Of course this is
>>> CDI-1.1 and a few more EE7 libs, so not sure whether you need updates.
>>> > >>If it works then I can backport this to owb-1.2.x.
>>> > I've checked the tomee master branch source which is 7.0.0-SNAPSHOT.
>>> There the tomcat version is 8.0.22.
>>> > We are trying to introduce tomee support to a server based on Tomcat
>>> 7.0.59. There are quite few API changes from tomcat 7.x to 8.x. Therefore I
>>> think trying with TomEE 7.0.0-SNAPSHOT will not solve the issue.
>>> > Please correct me if I'm wrong.
>>> >
>>> > Thanks
>>> > Best Regards
>>> > /Thusitha
>>> >
>>> > 2015-05-19 22:11 GMT+05:30 Thusitha Thilina Dayaratne <
>>> thusithathilina@gmail.com>:
>>> > Hi,
>>> >
>>> > If someone like to check the bundle I put my pom in the link
>>> http://pastebin.com/jbWzKaE4
>>> > >>The stuff with the -D… for all owb properties only works in trunk.
>>> > >>Could you plz try the tomee-7.0.0-SNAPSHOT? Of course this is
>>> CDI-1.1 and a few more EE7 libs, so not sure whether you need updates.
>>> > >>If it works then I can backport this to owb-1.2.x.
>>> > Should I just change the tomee version without changing openwebbeans
>>> and etc..?
>>> >
>>> > >>Please keep us updated ;)
>>> > Sure :)
>>> >
>>> > 2015-05-19 21:56 GMT+05:30 Mark Struberg <struberg@yahoo.de>:
>>> > The stuff with the -D… for all owb properties only works in trunk.
>>> > Could you plz try the tomee-7.0.0-SNAPSHOT? Of course this is CDI-1.1
>>> and a few more EE7 libs, so not sure whether you need updates.
>>> > If it works then I can backport this to owb-1.2.x.
>>> >
>>> > Please keep us updated ;)
>>> >
>>> > LieGrue,
>>> > strub
>>> >
>>> > > Am 19.05.2015 um 18:22 schrieb Thusitha Thilina Dayaratne <
>>> thusithathilina@gmail.com>:
>>> > >
>>> > > Hi,
>>> > >
>>> > > >>does your openwebbeans.properties miss it? Are you still in
OSGi?
>>> > > I'm still in OSGi. Due to some reasons I can't use Apache karaf.
>>> > > My OSGi bundle contains the openwebbeans.properties file. But I'm
>>> getting the error.
>>> > >
>>> > >
>>> >>org.apache.webbeans.spi.ApplicationBoundaryService=org.apache.webbeans.corespi.se.DefaultApplicationBoundaryService
>>> > > I've manually set the property when the server starts as
>>> -Dorg.apache.webbeans.spi.ApplicationBoundaryService=org.apache.webbeans.corespi.se.DefaultApplicationBoundaryService
>>> > > But still no success on this.
>>> > >
>>> > >
>>> > >
>>> > > 2015-05-19 19:35 GMT+05:30 Mark Struberg <struberg@yahoo.de>:
>>> > > Hi!
>>> > >
>>> > > The property in question is:
>>> > >
>>> > >
>>> org.apache.webbeans.spi.ApplicationBoundaryService=org.apache.webbeans.corespi.se.DefaultApplicationBoundaryService
>>> > >
>>> > >
>>> > > LieGrue,
>>> > > strub
>>> > >
>>> > >
>>> > >
>>> > > > Am 19.05.2015 um 15:59 schrieb Romain Manni-Bucau <
>>> rmannibucau@gmail.com>:
>>> > > >
>>> > > > Hi
>>> > > >
>>> > > > does your openwebbeans.properties miss it? Are you still in OSGi?
>>> > > >
>>> > > >
>>> > > > Romain Manni-Bucau
>>> > > > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>> > > >
>>> > > > 2015-05-19 15:32 GMT+02:00 Thusitha Thilina Dayaratne <
>>> thusithathilina@gmail.com>:
>>> > > > Hi,
>>> > > >
>>> > > > I'm trying to upgrade tomee support in our server from tomee
>>> 1.6.0.3 to 1.7.2. Since 1.7.2 is not released yet I'm using 1.7.2-SNAPSHOT
>>> along with the openwebbeans 1.2.7.
>>> > > > After doing the changes when I deploy an simple CDI app it throws
>>> following exception (I deployed and run the same app with tomee 1.6.0.3 and
>>> openwebbeans 1.2.1 it works fine there)
>>> > > >
>>> > > > ERROR {org.apache.catalina.core.StandardWrapperValve} -  Allocate
>>> exception for servlet HelloServlet
>>> > > > java.lang.NullPointerException
>>> > > >       at
>>> org.apache.webbeans.proxy.AbstractProxyFactory.getProxyClassLoader(AbstractProxyFactory.java:81)
>>> > > >       at
>>> org.apache.webbeans.proxy.NormalScopeProxyFactory.createNormalScopeProxy(NormalScopeProxyFactory.java:122)
>>> > > >       at
>>> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:732)
>>> > > >       at
>>> org.apache.webbeans.portable.ProducerMethodProducer.produce(ProducerMethodProducer.java:105)
>>> > > >       at
>>> org.apache.webbeans.portable.AbstractProducer.produce(AbstractProducer.java:182)
>>> > > >       at
>>> org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:121)
>>> > > >       at
>>> org.apache.webbeans.component.ProducerMethodBean.create(ProducerMethodBean.java:117)
>>> > > >       at
>>> org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:68)
>>> > > >       at
>>> org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:125)
>>> > > >       at
>>> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:754)
>>> > > >       at
>>> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:628)
>>> > > >       at
>>> org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:95)
>>> > > >       at
>>> org.apache.webbeans.inject.InjectableField.doInjection(InjectableField.java:65)
>>> > > >       at
>>> org.apache.webbeans.portable.InjectionTargetImpl.injectFields(InjectionTargetImpl.java:208)
>>> > > >       at
>>> org.apache.webbeans.portable.InjectionTargetImpl.inject(InjectionTargetImpl.java:194)
>>> > > >       at
>>> org.apache.webbeans.portable.InjectionTargetImpl.inject(InjectionTargetImpl.java:184)
>>> > > >       at
>>> org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:125)
>>> > > >       at
>>> org.apache.openejb.core.WebContext.newInstance(WebContext.java:138)
>>> > > >       at
>>> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:46)
>>> > > >       at
>>> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:66)
>>> > > >       at
>>> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:61)
>>> > > >       at
>>> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1148)
>>> > > >       at
>>> org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:864)
>>> > > >       at
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:134)
>>> > > >       at
>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
>>> > > >       at
>>> org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:44)
>>> > > >       at
>>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504)
>>> > > >       at
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
>>> > > >       at
>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
>>> > > >       at
>>> org.wso2.carbon.statistics.webapp.RequestIntercepterValve.invoke(RequestIntercepterValve.java:47)
>>> > > >       at
>>> org.wso2.carbon.bam.webapp.stat.publisher.WebAppStatisticPublisherValve.invoke(WebAppStatisticPublisherValve.java:104)
>>> > > >       at
>>> org.wso2.carbon.tomcat.ext.valves.CompositeValve.continueInvocation(CompositeValve.java:99)
>>> > > >       at
>>> org.wso2.carbon.tomcat.ext.valves.CarbonTomcatValve$1.invoke(CarbonTomcatValve.java:47)
>>> > > >       at
>>> org.wso2.carbon.webapp.mgt.TenantLazyLoaderValve.invoke(TenantLazyLoaderValve.java:57)
>>> > > >       at
>>> org.wso2.carbon.tomcat.ext.valves.TomcatValveContainer.invokeValves(TomcatValveContainer.java:47)
>>> > > >       at
>>> org.wso2.carbon.tomcat.ext.valves.CompositeValve.invoke(CompositeValve.java:62)
>>> > > >       at
>>> org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetectionValve.invoke(CarbonStuckThreadDetectionValve.java:159)
>>> > > >       at
>>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
>>> > > >       at
>>> org.wso2.carbon.tomcat.ext.valves.CarbonContextCreatorValve.invoke(CarbonContextCreatorValve.java:57)
>>> > > >       at
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
>>> > > >       at
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421)
>>> > > >       at
>>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1074)
>>> > > >       at
>>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
>>> > > >       at
>>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1739)
>>> > > >       at
>>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1698)
>>> > > >       at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>> > > >       at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>> > > >       at
>>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>>> > > >       at java.lang.Thread.run(Thread.java:745)
>>> > > >
>>> > > > After some debugging the both versions I found out that NPE is
get
>>> thrown because ApplicationBoundaryService applicationBoundaryService in the
>>> WebBeansContext is null.
>>> > > >
>>> > > > The only possible place that I see where it get initialized is
in
>>> the overloaded constructor of the WebBeansContext.
>>> > > >
>>> > > > In 1.2.1 NormalScopeProxyFactory.createNormalScopeProxy() method
>>> will get the classloader from the first if clause as classLoader =
>>> bean.getBeanClass().getClassLoader()
>>> > > >
>>> > > > But in 1.2.7 it try to get classloader as classLoader =
>>> getProxyClassLoader(bean.getBeanClass())
>>> > > > From there NPE get thrown. I manually executed the 1.2.1 logic
in
>>> debug mode and then classloader get correctly.
>>> > > >
>>> > > > Did I missed setting any configurations?
>>> > > > Can someone guide me on solving this?
>>> > > >
>>> > > > Thanks
>>> > > > Best Regards
>>> > > >
>>> > > > --
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>>
>>>
>>
>>
>> --
>>
>>
>
>


--

Mime
View raw message