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 <[email protected]>: > > 2015-05-20 10:19 GMT+02:00 Thusitha Thilina Dayaratne < > [email protected]>: > >> 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 <[email protected]>: >> >>> 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 < >>> [email protected]>: >>> > >>> > 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 < >>> [email protected]>: >>> > 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 < >>> [email protected]>: >>> > 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 <[email protected]>: >>> > 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 < >>> [email protected]>: >>> > > >>> > > 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 <[email protected]>: >>> > > 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 < >>> [email protected]>: >>> > > > >>> > > > 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 < >>> [email protected]>: >>> > > > 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 >>> > > > >>> > > > -- >>> > > > >>> > > > >>> > > >>> > > >>> > > >>> > > >>> > > -- >>> > > >>> > >>> > >>> > >>> > >>> > -- >>> > >>> > >>> > >>> > >>> > -- >>> > >>> > >>> > >>> > >>> > -- >>> > >>> >>> >> >> >> -- >> >> > > --
