[Design of OSGi Integration] - felix.framework.URLHandlersStreamHandlerProxy errors with JB
by scott.stark＠jboss.org
I'm seeing felix URL stream handlers dumping out errors when I have the JBossOSGi-1.0.0.Beta1 installed into a JBossAS-5.1.0.GA+ server with ejb jars in the deploy directory. All of the ejb jar descriptors are showing errors like the following on startup:
| 13:36:59,882 ERROR [STDERR] java.lang.reflect.InvocationTargetException
| 13:36:59,882 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor115.invoke(Unknown Source)
| 13:36:59,882 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| 13:36:59,883 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
| 13:36:59,883 ERROR [STDERR] at org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:286)
| 13:36:59,883 ERROR [STDERR] at java.net.URL.openConnection(URL.java:943)
| 13:36:59,883 ERROR [STDERR] at sun.misc.URLClassPath$Loader.findResource(URLClassPath.java:463)
| 13:36:59,883 ERROR [STDERR] at sun.misc.URLClassPath.findResource(URLClassPath.java:142)
| 13:36:59,884 ERROR [STDERR] at java.net.URLClassLoader$2.run(URLClassLoader.java:362)
| 13:36:59,884 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method)
| 13:36:59,884 ERROR [STDERR] at java.net.URLClassLoader.findResource(URLClassLoader.java:359)
| 13:36:59,884 ERROR [STDERR] at java.lang.ClassLoader.getResource(ClassLoader.java:1032)
| 13:36:59,884 ERROR [STDERR] at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1214)
| 13:36:59,884 ERROR [STDERR] at org.jboss.management.j2ee.J2EEDeployedObject.getDeploymentDescriptor(J2EEDeployedObject.java:114)
| 13:36:59,884 ERROR [STDERR] at org.jboss.management.j2ee.J2EEDeployedObject.getDeploymentDescriptor(J2EEDeployedObject.java:83)
| 13:36:59,884 ERROR [STDERR] at org.jboss.management.j2ee.EJBModule.create(EJBModule.java:134)
| 13:36:59,885 ERROR [STDERR] at org.jboss.management.j2ee.deployers.EjbModuleJSR77Deployer.deployJsr77(EjbModuleJSR77Deployer.java:52)
| 13:37:00,104 ERROR [STDERR] at org.jboss.management.j2ee.deployers.EjbModuleJSR77Deployer.deployJsr77(EjbModuleJSR77Deployer.java:41)
| 13:37:00,104 ERROR [STDERR] at org.jboss.management.j2ee.deployers.AbstractVFSJSR77Deployer.deployJsr77(AbstractVFSJSR77Deployer.java:46)
| 13:37:00,104 ERROR [STDERR] at org.jboss.management.j2ee.deployers.AbstractJSR77Deployer.deploy(AbstractJSR77Deployer.java:173)
| 13:37:00,105 ERROR [STDERR] at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
| 13:37:00,105 ERROR [STDERR] at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| 13:37:00,105 ERROR [STDERR] at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| 13:37:00,105 ERROR [STDERR] at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
| 13:37:00,105 ERROR [STDERR] at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
| 13:37:00,106 ERROR [STDERR] at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
| 13:37:00,106 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| 13:37:00,106 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
| 13:37:00,106 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| 13:37:00,106 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
| 13:37:00,107 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| 13:37:00,107 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| 13:37:00,107 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| 13:37:00,108 ERROR [STDERR] at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
| 13:37:00,108 ERROR [STDERR] at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
| 13:37:00,108 ERROR [STDERR] at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
| 13:37:00,108 ERROR [STDERR] at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
| 13:37:00,108 ERROR [STDERR] at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
| 13:37:00,109 ERROR [STDERR] at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
| 13:37:00,109 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| 13:37:00,109 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
| 13:37:00,109 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| 13:37:00,109 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
| 13:37:00,110 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| 13:37:00,110 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| 13:37:00,110 ERROR [STDERR] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| 13:37:00,110 ERROR [STDERR] at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
| 13:37:00,110 ERROR [STDERR] at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:265)
| 13:37:00,111 ERROR [STDERR] at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:100)
| 13:37:00,111 ERROR [STDERR] at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:705)
| 13:37:00,111 ERROR [STDERR] at org.jboss.bootstrap.impl.base.server.AbstractServer.start(AbstractServer.java:338)
| 13:37:00,111 ERROR [STDERR] at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.start(AbstractMCServerBase.java:238)
| 13:37:00,111 ERROR [STDERR] at org.jboss.Main.boot(Main.java:400)
| 13:37:00,112 ERROR [STDERR] at org.jboss.Main$1.run(Main.java:741)
| 13:37:00,112 ERROR [STDERR] at java.lang.Thread.run(Thread.java:613)
| 13:37:00,114 ERROR [STDERR] Caused by: java.io.IOException: Child not found profileservice-secured.jar/META-INF/jboss.xml/ for FileHandler@13541975[path= context=file:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ real=file:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/],
| ...
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234001#4234001
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234001
15 years
[Design the new POJO MicroContainer] - Re: What are the current thoughts for solving JBKERNEL-25 (I
by alesj
"scott.stark(a)jboss.org" wrote : Rather than looking at parallel deployment first, I think the consensus was to look at using on-demand as the first step in improving the boot times.
My current list, in no particular order.
* use On_Demand where it makes sense (X)
* analyze our services, add @MCAnnotations, @DisableAOP({DisableType.?}) (Y)
* federated resources lookup
** usage of AnnotationEnvironment
** fix Metadata's paradigm
*** only asking for what it needs, not checking all against some constraints
** cache other resources, as we're doing the scanning anyway
** limit what we're scanning
*** jboss-scanning.xml
*** (X) jboss-classloading.xml
* usage of (X) will limit the class sharing/lookup == speed up
* profile service loading profiles on demand
** e.g. usage @MDR enterprise bean triggers JMS profile load
* parallel deployment
* xyz ...
For (X) and (Y) I'm looking into hacking some MC based tool
to help us identify potential services that could use this, either (X) or (Y).
I need to check how I can re-use Tattletale to help me.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233985#4233985
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233985
15 years
[Design of JBoss Profiler] - Re: Memory Profiler does not work
by jorge.mota
Hi,
thank you for your response.
I tried the Class Loader Analysis (Current JVM only) link and got the following error:
org.apache.jasper.JasperException: Exception in JSP: /classLeakage/clean.jsp:6
3: <%
4: session.removeAttribute("list");
5: JVMTIInterface jvmti = new JVMTIInterface();
6: jvmti.releaseTags();
7: %>
Stacktrace:
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:506)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:377)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
root cause
javax.servlet.ServletException: releaseTags
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:843)
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:776)
org.apache.jsp.classLeakage.clean_jsp._jspService(clean_jsp.java:113)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:334)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
root cause
java.lang.UnsatisfiedLinkError: releaseTags
org.jboss.profiler.jvmti.JVMTIInterface.releaseTags(Native Method)
org.apache.jsp.classLeakage.clean_jsp._jspService(clean_jsp.java:106)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:334)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
An other question: Is the 2.0 beta version more stable for this purpose (Memory Profiling)?
Regards
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233948#4233948
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233948
15 years
[Design of JBossXB] - Marshalling an AbstractKernelDeployment
by flavia.rainone＠jboss.com
I've been trying to marshal an AbstractKernelDeployment without success:
AbstractKernelDeployment deployment = new AbstractKernelDeployment();
| AbstractBeanMetaData beanMetaData = new AbstractBeanMetaData();
| beanMetaData.setBean(Test.class.getName());
| beanMetaData.setName("test");
| List<BeanMetaDataFactory> beanFactories = new ArrayList<BeanMetaDataFactory>();
| beanFactories.add(beanMetaData);
| deployment.setBeanFactories(beanFactories);
| MarshallerImpl marshaller = new MarshallerImpl();
| SchemaBindingResolver resolver = SingletonSchemaResolverFactory.getInstance().getSchemaBindingResolver();
| marshaller.setSchemaResolver(resolver);
| StringWriter writer = new StringWriter();
|
| URL url = Test.class.getClassLoader().getResource("schema/bean-deployer_2_0.xsd");
|
| marshaller.marshal(url.toString(), null, deployment, writer);
I'm getting this exception:
Exception in thread "main" org.jboss.xb.binding.JBossXBRuntimeException: Missing value for the required attribute bean of element {urn:jboss:bean-deployer:2.0}lazy
| at org.jboss.xb.binding.sunday.marshalling.DefaultAttributeMarshaller.marshalValue(DefaultAttributeMarshaller.java:89)
| at org.jboss.xb.binding.sunday.marshalling.AbstractAttributeMarshaller.marshal(AbstractAttributeMarshaller.java:39)
| at org.jboss.xb.binding.sunday.marshalling.MarshallerImpl.marshalComplexType(MarshallerImpl.java:547)
| at org.jboss.xb.binding.sunday.marshalling.MarshallerImpl.marshalElementType(MarshallerImpl.java:430)
| at org.jboss.xb.binding.sunday.marshalling.MarshallerImpl.marshalElement(MarshallerImpl.java:329)
| at org.jboss.xb.binding.sunday.marshalling.MarshallerImpl.marshalElementOccurence(MarshallerImpl.java:309)
| at org.jboss.xb.binding.sunday.marshalling.MarshallerImpl.marshallInternal(MarshallerImpl.java:215)
| at org.jboss.xb.binding.sunday.marshalling.MarshallerImpl.marshal(MarshallerImpl.java:150)
| at org.jboss.microcontainer.tools.Test.main(Test.java:69)
Debugging the code, I see that MarshallerImpl (lines 211-216) marshals the deployment by iterating through the ElementBindings and marshalling the ocurrences of each of one those elements:
while(elements.hasNext())
| {
| ParticleBinding element = elements.next();
| ctx.particle = element;
| marshalElementOccurence((ElementBinding) element.getTerm(), root, true, true);
| }
It seems that at some point, between the marshalElementOcurrence() call and the execution of marshalComplexType(), MarshallerImpl assumes that the element at the stack is a lazy element instead of a deployment element. Given that it isn't, MarshallerImpl fails to find the value of the mandatory bean attribute of lazy and throws the exception above.
Taking a look at XsdBinder (lines 476-483), I see that it binds the schema elements with a minOcurrences of 1:
XSNamedMap elements = model.getComponents(XSConstants.ELEMENT_DECLARATION);
| if (trace)
| log.trace("Model elements: " + types.getLength());
| for(int i = 0; i < elements.getLength(); ++i)
| {
| XSElementDeclaration element = (XSElementDeclaration)elements.item(i);
| bindElement(element, 1, 0, false);
| }
I'm not sure if this has something to do with the problem or not, but it looks weird from my point of view.
So, am I doing this the wrong way? Or is this a bug?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233925#4233925
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233925
15 years