June 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: AOP and CL warning at undeploy

by kabir.khan＠jboss.com

Should the AnnotationRepositoryToMetaData.classLoader field not be a WeakReference? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157102#4157102 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157102

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: AOP and CL warning at undeploy

by kabir.khan＠jboss.com

>From a quick glance the problem seems to stem from that the ExtendedManagedObjectAdvisor wrapping the containers are not cleaned up. When the container is stopped, the ExtendedManagedObjectAdvisor has a Set of AdviceBindings. Each AdviceBinding entry has a reference back to the affected advisors. The ExtendedManagedObjectAdvisor needs to remove itself from its bindings. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157101#4157101 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157101

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bounding the number of threads created by the MDB contai

by ovidiu.feodorov＠jboss.com

How do I run a full testsuite? I would like to take a snapshot before applying any change, so I can figure out whether I broke something or not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157095#4157095 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157095

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Register dynamic class loading with a domain

by sguilhen＠redhat.com

The more we discuss about this the more convinced I become that we should just include the stubs in the war deployments. First because if you want your component to be a client of an IIOP application you should provide the stubs that will allow your component to make the IIOP calls. I don't see why you would rely on the app server runtime to provide those for you. Second because of the possibility of abuse that you have just described. I don't think we should include a hack to allow the generation of stubs when someone forgets to add those stubs to the deployments. When we act as a client, stubs should either be pre-compiled and inserted in the deployment war file or downloaded from a location specified in the IOR (when the server makes such mechanism available). As the RI doesn't make stubs available for download, the only other way left for us is to include the pre-compiled stubs in the vehicles war files. At least this is what I think. If this makes sense, we should review the way stubs are generated in the ejb container. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157084#4157084 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157084

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Register dynamic class loading with a domain

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | 2) The way the IIOP WebCL processing is done now is incorrect in my opinion. | ... | 3) The way the classloaders currently work is that they first check | for the class resource existing. | The simplest way to do this (similar to how it works now) is pretty ugly. i.e. Something like: | public Class<?> loadClass(...) | { | Class<?> result = current classloading code | if (result == null) | result = runClassNotFoundHandlers(this, ...); | if (result == null) | throw ClassNotFoundException(...); | return result; | } | It's ugly in that you've got to allow the ClassNotFoundHandler to say, I'm defining this class against a different classloader so don't invoke defineClass() yourself. The protocol/api that lets it do that, would potentially be a major security hole, it would certainly be open to abuse. :-) The alternative is a lot more complicated since the ClassNotFoundHandler would probably have to take part in the class search and caching algorithms (general solution). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157080#4157080 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157080

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Register dynamic class loading with a domain

by adrian＠jboss.org

"sguilhen(a)redhat.com" wrote : | As Adrian said, we can always include the stub classes in the vehicles war deployments to have the tests passing, but it would be good to have a more general solution in place. Another solution would be to write a new stub deployer that either * Takes a list of interfaces to generate stubs for (could be the interfaces defined on the ejb-refs in the ejb-jar/web.xml) * Scans the deployment for Remote classes and generates them automatically. The generated bytecode could then be placed in the in memory vfs that is available for each classloader used by aop. http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/jboss-deploye... This doesn't require any change to the classloader, such as the complicated multiple pass, and the resource does exist in the in-memory vfs context. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157074#4157074 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157074

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Register dynamic class loading with a domain

by adrian＠jboss.org

There's some issues with this proposal. 1) The domain wouldn't be a very easy place (administratively) to register this behavour. ClassLoading Domains are created dynamically as required. A better place to register a "ClassNotFoundHandler" would be on the ClassLoading System. This is where AOP registers its Transformer when running in its old legacy mode. 2) The way the IIOP WebCL processing is done now is incorrect in my opinion. If you are going to generate a stub then it should be defined against the same classloader as the interface. Otherwise you'll get memory leaks. This will effectively require a double lookup, once to determine there is no stub class and a second one to find the interface. e.g. with the current ejb stub generation, each ejb jar gets its own WebCL and each will generate its own copy of the stub (not visible to other applications and potentially leaking the interface reference if things don't get redeployed properly). 3) The way the classloaders currently work is that they first check for the class resource existing. i.e. It effectively does a ClassLoader.getResource("com/acme/Whatever_Stub.class") before going onto the other classloading processing (which requires a lot of complicated dancing around because of the Sun classloader problems). If the resource doesn't exist, the classloader is not considered/used. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157071#4157071 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157071

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: trunk Ejb3Deployment is incompatible with jbossas trunk

by alesj

How come Scott's last proposal doesn't handle that? Since I've also added that to metadata-beans.xml. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157069#4157069 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157069

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: trunk Ejb3Deployment is incompatible with jbossas trunk

by ALRubinger

We're not out of the woods yet. :) This is from the EJB3 TestSuite "composite" test. Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Element persistence is not bound as a global element. | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:193) | at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:153) | at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:191) | at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:165) | at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132) | at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118) | at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:128) | at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:329) | ... 67 more | Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Element persistence is not bound as a global element. | at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:662) | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:407) | at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) | at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source) | at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) | at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) | at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source) | at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) | at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) | at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) | at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) | at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) | at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) | at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:189) | ... 74 more S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157065#4157065 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157065

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Is META-INF in the classpath?

by alesj

I 'missing' better stream handling in both JBossXBHelper parse methods. Since we're going 'around the corner' to get what we already have at that point - a file and its stream. Since if we pass in URL, it's probably some code deeper in unmarshaller that opens connection/stream on top of that vfs's url, meaning it goes all the way to recreating whole vfs structure ... Jaxb and jaxp deployers already have this done via (Input|Dom)Source. Should I open JBossXB issue? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157063#4157063 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157063

16 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2008