[Design of EJB 3.0] - Re: Setting load-balance-policy
by adrian＠jboss.org
"bstansberry(a)jboss.com" wrote :
| First obvious step was to add property loadBalancePolicy to ClusterConfigMetaData. Doesn't help.
|
| Tricky thing here is for EJB2 the relevant cluster-config subelements are "home-load-balance-policy" and "bean-load-balance-policy". For EJB3 its just "load-balance-policy". This difference is reflected in different specifications for cluster-config in jboss_5_0.dtd vs jboss_5_0.xsd.
|
| When I stop the deploy in a debugger I see that JBossXB is expecting the EJB2 properties, even though ejb-jar specifies ejb-jar_3_0.xsd. The jboss.xml is properly specifying the xmlns and xsi:schemaLocation as well.
|
| The parsing is being handling by the JBossEjbParsing deployer when this happens.
|
| Any ideas?
JBossXB doesn't look at the schema or dtd. It looks at the class
to generate the SchemaBinding.
Try enabling TRACE logging for org.jboss.xb
and see what it says when it analyzes the ClusterConfigMetaData class.
The SAXParser will give you a validation error if it doesn't match the schema or dtd.
You want to write a test in the metadata project (e.g. the everything tests).
It's easier to debug as well. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104327#4104327
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104327
18 years, 4 months
[Design of EJB 3.0] - Setting load-balance-policy
by bstansberry＠jboss.com
Been trying to sort out the setting of a clustered bean's load balance policy with the unified metadata. Simple test is to deploy the clusteredsession-test.jar from the ejb3 testsuite and see what happens. Always get this failure:
| Caused by: org.jboss.xb.binding.JBossXBRuntimeException: {http://www.jboss.com/x
| ml/ns/javaee}load-balance-policy not found as a child of {http://www.jboss.com/x
| ml/ns/javaee}cluster-config
| at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startE
| lement(SundayContentHandler.java:396)
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHan
| dler.startElement(SaxJBossXBParser.java:407)
| at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Sour
| ce)
| at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Sourc
| e)
| at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unkn
| own Source)
| at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
| Dispatcher.dispatch(Unknown Source)
| at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
| known 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 Sour ce)
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBPars er.java:189)
| ... 27 more
|
First obvious step was to add property loadBalancePolicy to ClusterConfigMetaData. Doesn't help.
Tricky thing here is for EJB2 the relevant cluster-config subelements are "home-load-balance-policy" and "bean-load-balance-policy". For EJB3 its just "load-balance-policy". This difference is reflected in different specifications for cluster-config in jboss_5_0.dtd vs jboss_5_0.xsd.
When I stop the deploy in a debugger I see that JBossXB is expecting the EJB2 properties, even though ejb-jar specifies ejb-jar_3_0.xsd. The jboss.xml is properly specifying the xmlns and xsi:schemaLocation as well.
The parsing is being handling by the JBossEjbParsing deployer when this happens.
Any ideas?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104323#4104323
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104323
18 years, 4 months
[Design of EJB 3.0] - Great error message!
by adrian＠jboss.org
I got this error message:
| Caused by: java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
| at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:653)
| at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:460)
| at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286)
| at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222)
| at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69)
| at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52)
| at java.lang.Class.initAnnotationsIfNecessary(Class.java:3031)
| at java.lang.Class.getAnnotation(Class.java:2989)
| at org.jboss.aop.annotation.AnnotationElement$AnnotationElementAction$1.getVisibleAnnotation(AnnotationElement.java:264)
| at org.jboss.aop.annotation.AnnotationElement.getVisibleAnnotation(AnnotationElement.java:114)
| at org.jboss.aop.Advisor.resolveAnnotation(Advisor.java:356)
| at org.jboss.ejb3.Ejb3AnnotationHandler.validateMDBTransactionAttribute(Ejb3AnnotationHandler.java:179)
| at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:155)
| at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:499)
| at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:459)
| at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:441)
| at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:407)
| at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:349)
| at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:133)
| ... 62 more
| 22:43:23,548 WARN [MainDeployer] Failed to deploy: file:/home/ejort/jboss-head/ejb3/output/test-lib/quartzmdb.jar
|
It was actually trying to tell me that my interceptor class wasn't deployed. :-)
It's referenced in an annotation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104321#4104321
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104321
18 years, 4 months
[Design of EJB 3.0] - JNDI Binding and ejbcontext test
by adrian＠jboss.org
The ejbcontext test is failing because it binds the remote proxy at /Stateless
but then wants to bind the home in a subcontext /Stateless/home
The /Stateless jndi binding can't be both a binding and a naming context. ;-)
The same is true for the Stateful bean in this test.
But this brought up an issue, where the already succesful bindings are not removed
from jndi, even though the deployment has failed.
|
| public void start() throws Exception
| {
| init();
|
| super.start();
| Class[] interfaces = {ProxyFactory.class};
| String targetId = getTargetId();
| String clientBindUrl = ProxyFactoryHelper.getClientBindUrl(binding);
| Object factoryProxy = createPojiProxy(targetId, interfaces, clientBindUrl);
| log.debug("Binding proxy factory for " + container.getEjbName() + " in JNDI at " + jndiName + PROXY_FACTORY_NAME + " with client bind url " + clientBindUrl);
| try
| {
|
| // OK
|
| Util.rebind(container.getInitialContext(), jndiName + PROXY_FACTORY_NAME, factoryProxy);
| }
| catch (NamingException e)
| {
| NamingException namingException = new NamingException("Could not bind stateful remote proxy with ejb name " + container.getEjbName() + " into JNDI under jndiName: " + container.getInitialContext().getNameInNamespace() + "/" + jndiName + PROXY_FACTORY_NAME);
| namingException.setRootCause(e);
| throw namingException;
| }
| assert !Dispatcher.singleton.isRegistered(targetId) : targetId + " is already registered";
| Dispatcher.singleton.registerTarget(targetId, this);
|
| StatefulContainer statefulContainer = (StatefulContainer) container;
| RemoteHome remoteHome = (RemoteHome) statefulContainer.resolveAnnotation(RemoteHome.class);
| if (remoteHome != null && !bindHomeAndBusinessTogether(statefulContainer))
| {
| Object homeProxy = createHomeProxy(remoteHome.value());
| String homeJndiName = ProxyFactoryHelper.getHomeJndiName(container);
| log.debug("Binding home proxy at " + homeJndiName);
|
| // OOPS an error doesn't unbind the remote proxy!
|
| Util.rebind(container.getInitialContext(), homeJndiName, homeProxy);
| }
| }
|
|
THIS IS A MEMORY LEAK!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104290#4104290
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104290
18 years, 4 months
[Design of JBoss Profiler] - Problem starting profiler in linux
by pmclsousa
Hi to all.
I am having a strange (or not) problem running the profiler, in a Linux.
Starting the JBoss without the -server VM option works fine, at least without any visible problem. The command line is this one:
java -Xms128m -Xmx1024m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/usr/local/jboss/lib/endorsed -XrunjbossInspector:/home/dev/JBossProfiler/tmp,include=com.mindergy,ignore=* -classpath /usr/local/jboss/bin/run.jar org.jboss.Main -c default -b 111.111.111.111
Startig JBoss with the -server VM option results on this error:
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGSEGV (0xb) at pc=0x00674a82, pid=15415, tid=3086297792
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_12-b04 mixed mode, sharing)
# Problematic frame:
#
[error occurred during error reporting, step 60, id 0xb]
# An error report file with more information is saved as hs_err_pid15415.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
The Lib was compiled with success in the system.
Naturaly, it's better to run with the -server option, so can someone please help me on this? Did i missing something?
The distribution of Linux is the CentOS, with this version:
Linux version 2.6.18-8.1.8.el5 (mockbuild(a)builder4.centos.org) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Tue Jul 10 06:50:22 EDT 2007
Thanks in advance for yout help
Regards
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104286#4104286
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104286
18 years, 4 months
[Design of POJO Server] - Misleading error message when structural deployer throws an
by adrian＠jboss.org
I came across a problem where the structural deployers protocol
leads to a misleading error message when a structural deployer throws an error.
Really under the current protocol, it's a bug in the EARStructure Deployer.
You get something like:
| 19:18:05,290 WARN [EARStructure] Error during determineStructure: dd-web.ear
| java.lang.RuntimeException: Error determining structure: dd-web.ear
| at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:252)
| at org.jboss.deployers.vfs.plugins.structure.StructureDeployerWrapper.determineStructure(StructureDeployerWrapper.java:66)
| at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.doDetermineStructure(VFSStructuralDeployersImpl.java:192)
| at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.determineStructure(VFSStructuralDeployersImpl.java:216)
| at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:80)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.determineStructure(MainDeployerImpl.java:528)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:257)
| Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: description not found as a child of web
| 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.deployment.EARStructure.determineStructure(EARStructure.java:151)
| ... 58 more
| Caused by: org.jboss.xb.binding.JBossXBRuntimeException: description not found as a child of web
| at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:396)
| 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.xinclude.XIncludeHandler.startElement(Unknown Source)
| at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source)
| at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(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)
| ... 60 more
| 19:18:05,292 WARN [JARStructure] Error determining structure: dd-web.ear
| java.lang.IllegalStateException: Context already exists with path '' contexts=[ContextInfoImpl{path= metaData=META-INF classPath=null}]
| at org.jboss.deployers.plugins.structure.StructureMetaDataImpl.addContext(StructureMetaDataImpl.java:59)
| at org.jboss.deployers.vfs.spi.structure.helpers.AbstractStructureDeployer.createContext(AbstractStructureDeployer.java:271)
| at org.jboss.deployers.vfs.plugins.structure.jar.JARStructure.determineStructure(JARStructure.java:122)
| at org.jboss.deployers.vfs.plugins.structure.StructureDeployerWrapper.determineStructure(StructureDeployerWrapper.java:66)
| at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.doDetermineStructure(VFSStructuralDeployersImpl.java:192)
| at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.determineStructure(VFSStructuralDeployersImpl.java:216)
| at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:80)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.determineStructure(MainDeployerImpl.java:528)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:257)
|
The second error is obviously bogus.
What has happened is that the EARStructure Deployer has recognised
the deployment, but then thrown a RuntimeException because it can't parse the xml.
It's obviously thrown the RuntimeException because it can't throw a
DeploymentException since that's not part of the api.
But the EARStructure hasn't tidied up the context it added
when it recognised the deployment.
This leads the StructureDeployerWrapper to say the EARStructure
didn't recognise the deployment
|
| public boolean determineStructure(VirtualFile root, VirtualFile parent, VirtualFile file, StructureMetaData metaData, VFSStructuralDeployers deployers)
| {
| if (file == null)
| throw new IllegalArgumentException("Null file");
|
| try
| {
| boolean result = deployer.determineStructure(root, parent, file, metaData, deployers);
| if (log.isTraceEnabled())
| {
| if (result == false)
| log.trace("Not recognised: " + file.getName());
| else
| log.trace("Recognised: " + file.getName());
| }
| return result;
| }
| catch (Throwable t)
| {
|
| // ===========> HERE!
|
| log.warn("Error during determineStructure: " + file.getName(), t);
| return false;
| }
| }
|
and so it goes onto the JARStructure.
This recognises it as a jar but it fails to create the top level context
because it is still there from the EARStructure. This is the bogus error message.
There are two possible fixes.
1) Fix the EARStructure to tidyup after itself. Like the JARStructure
deployer
| catch (Exception e)
| {
| log.warn("Error determining structure: " + file.getName(), e);
|
| // =====> HERE!
|
| // Remove the invalid context
| if( context != null )
| metaData.removeContext(context);
| return false;
| }
|
or
2) We allow structure deployers to say it recognised the deployment
but can't process it because of some error.
i.e. we allow determineStructure() to throw a DeploymentException
(or unchecked exception) and terminate the determineStructure()
althogether when an error occurs, leaving the deployment in an ERROR state.
My thoughts:
Solution (1) was the original design because a broken deployer can't completely
break the server, e.g.
| public class DenialOfService implements StructureDeployer
| {
| public DenialOfService()
| {
| // I'm first!
| setRelativeOrder(Integer.MIN_VALUE);
| }
|
| public boolean determineStructure(...)
| {
| throw new RuntimeException("Nobody can deploy anything!");
| }
| }
|
but deploying an ear as a jar because the application.xml is malformed
doesn't sound correct either.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104281#4104281
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104281
18 years, 4 months