[Design of JBossXB] - Re: problem parsing sip.xml with JBossXB
by deruelle_jean
I just tried it on my servlets element :
@XmlElement(name="servlet")
@JBossXmlNsPrefix(prefix = "javaee", applyToComponentQName=false, applyToComponentContent=true, schemaTargetIfNotMapped=true)
public void setServlets(ServletsMetaData sipServlets) {
this.servlets = sipServlets;
}
But I still get this exception which is weird since the servlet element is a child of the sip-app element in the sipservlet namespace :
org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfszip:/home/deruelle/servers/jboss-5.0.0.GA/server/default/deploy/call-blocking-1.2-SNAPSHOT.war
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:337)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:297)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:269)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:230)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
at org.jboss.Main.boot(Main.java:209)
at org.jboss.Main$1.run(Main.java:547)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: {http://www.jcp.org/xml/ns/sipservlet}servlet not found as a child of {http://www.jcp.org/xml/ns/sipservlet}sip-app
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168)
at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:199)
at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
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.parseAndInit(AbstractVFSParsingDeployer.java:256)
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:188)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:323)
... 22 more
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: {http://www.jcp.org/xml/ns/sipservlet}servlet not found as a child of {http://www.jcp.org/xml/ns/sipservlet}sip-app
at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:400)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:401)
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.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:199)
... 30 more
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202334#4202334
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202334
17 years, 2 months
[Design of JBossXB] - Re: problem parsing sip.xml with JBossXB
by alex.loubyansky＠jboss.com
After all (including support for properties bound to model groups), I renamed the elements again.
/**
| * True means the element or model group the property is bound to will be bound to the namespace specified by the prefix.
| * False means the element or model group will be in the schema's target namespace.
| *
| * @return
| */
| boolean applyToComponentQName() default true;
|
| /**
| * True means the type of the property (including its child elements, their types and model groups recursively)
| * will be bound to the namespace specified by the prefix.
| * False means the type of the property (including its child elements, their types and model groups recursively)
| * will be bound to the schema's target namespace.
| *
| * @return
| */
| boolean applyToComponentContent() default true;
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202333#4202333
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202333
17 years, 2 months
[Design of JBoss Remoting, Unified Invokers] - Remoting 2: Timeout waiting on socket for InvokerLocator
by ALRubinger
Hi guys, I have a JMS/Remoting error that's environment-specific to my Hudson, cannot reproduce locally or on other CI servers. Mostly likely I just need to make the test more resilient?
java.util.concurrent.ExecutionException: org.jboss.jms.exception.MessagingNetworkFailureException
| at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:205)
| at java.util.concurrent.FutureTask.get(FutureTask.java:80)
| at org.jboss.ejb3.test.strictpool.unit.StrictPoolUnitTestCase.testMessageDriven(StrictPoolUnitTestCase.java:123)
| at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
| at junit.extensions.TestSetup.run(TestSetup.java:27)
| Caused by: org.jboss.jms.exception.MessagingNetworkFailureException
| at org.jboss.jms.client.delegate.DelegateSupport.handleThrowable(DelegateSupport.java:240)
| at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:205)
| at org.jboss.jms.client.delegate.DelegateSupport.doInvokeOneway(DelegateSupport.java:165)
| at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$send$aop(ClientSessionDelegate.java:495)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeTarget(ClientSessionDelegate$send_6145266547759487588.java)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
| at org.jboss.jms.client.container.SessionAspect.handleSend(SessionAspect.java:661)
| at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleSend_20120943.invoke(SessionAspect_z_handleSend_20120943.java)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
| at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
| at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.jms.client.delegate.ClientSessionDelegate.send(ClientSessionDelegate.java)
| at org.jboss.jms.client.container.ProducerAspect.handleSend(ProducerAspect.java:269)
| at org.jboss.aop.advice.org.jboss.jms.client.container.ProducerAspect_z_handleSend_20120943.invoke(ProducerAspect_z_handleSend_20120943.java)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
| at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.jms.client.delegate.ClientProducerDelegate.send(ClientProducerDelegate.java)
| at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:164)
| at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:207)
| at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:145)
| at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:136)
| at org.jboss.ejb3.test.strictpool.unit.MDBCallable.call(MDBCallable.java:79)
| at org.jboss.ejb3.test.strictpool.unit.MDBCallable.call(MDBCallable.java:45)
| at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
| at java.util.concurrent.FutureTask.run(FutureTask.java:123)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:4457/?JBM_clientMaxPoolSize=200&clientLeasePeriod=10000&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&connectionWait=10&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&stopLeaseOnFailure=true&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat&validatorPingPeriod=10000&validatorPingTimeout=5000]
| at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:771)
| at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:423)
| at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:160)
| at org.jboss.remoting.Client.invoke(Client.java:1708)
| at org.jboss.remoting.Client.invoke(Client.java:612)
| at org.jboss.remoting.Client.invokeOneway(Client.java:660)
| at org.jboss.remoting.Client.invokeOneway(Client.java:848)
| at org.jboss.remoting.Client.invokeOneway(Client.java:838)
| at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:180)
| ... 32 more
| Caused by: java.lang.IllegalStateException: Timeout waiting for a free socket
| at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:1048)
| at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:757)
| ... 40 more
Any recommendations for how I might increase the timeout? Client code is pretty straightforward:
QueueSession session = connection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
| try
| {
| TemporaryQueue replyQueue = session.createTemporaryQueue();
| QueueReceiver receiver = session.createReceiver(replyQueue);
|
| QueueSender sender = session.createSender(queue);
| sender.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
| TextMessage message = session.createTextMessage();
| message.setJMSReplyTo(replyQueue);
| message.setText(text);
| sender.send(message); < Exception here, MDBCallable.java:79
| sender.close(); ....
Thanks as always.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202246#4202246
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202246
17 years, 2 months
[Design of POJO Server] - Re: Sub-Profiles ProfileService changes
by emuckenhuber
So some unordered thoughts about missing things in this prototype:
** dependencies
As mentioned before the main question for me is from where should a runtime profile know that it depends
on a deployer profile in the end? Basically we can also put the deploymentPhase in here to create the
dependencies within an xml file.
** profile-spi
Maybe we should add some properties to the Profile to define some behavior?
e.g. if the profile should do a mainDeployer.checkComplete() with an uncaught exception.
This behavior could also be implied by the deploymentPhase from the xml...
** metadata
There is an initial meta data model in the profileservice.spi.metadata.* which is basically used to create
the profile dependencies and create the deployment repositories. The <sub-profile> is then getting
a simple dependency on a profileKey. The xml could look something like this:
| <profiles name="ejb3">
| <profile name="ejb3-deployers">
| <source type="immutable">${jboss.server.base.url}deployers</source>
| <source type="immutable">${jboss.server.base.url}deployers2</source>
| <sub-profile>metadata-deployers</sub-profile>
| <deployment>ejb3.deployer</deployment>
| </profile>
| <profile name="ejb3-runtime">
| <source type="mutable">${jboss.server.base.url}deploy</source>
| <source type="immutable">${jboss.server.base.url}deploy2</source>
| <deployment>ejb3-container-jboss-beans.xml</deployment>
| <deployment>ejb3-interceptors-aop.xml</deployment>
| <deployment>ejb3-timer-service.xml</deployment>
| </profile>
| </profiles>
|
I've also put a List getDependencies - for other non-profile dependencies. But not really sure if we want to have
a profile-dependency on a service?
There is also the AbstractProfileFactory - which creates the available bootstrap profiles. I don't think this is needed in
the spi, as it should just create the bootstrap profiles, which are getting registered and actived in the ProfileServiceBootstrap.
** repository spi
Based on the xml example above, it defines 2 different types for a repository. Furthermore the filtering for the deploymentName
would also need to be done by the repository itself (see FilteredDeploymentFactory).
I'm wondering if the profile should actually do more what the repository is doing now - and the repository would become more a resource discovery.
Not sure about that, but with the current RepositoryFactory spi it's hard to share the same repository for different profiles and
to combine different repository types in a profile.
Maybe a simple method like: public DeploymentRepository createDeploymentRepository(List repositorySource); would be enough.
** VFSDeployment
Due to a comment of Adrian - should we change the VFSDeployment from the profileservice-spi to a simple Deployment ?
** ProfileService
The ProfileService uses MC to resolve the dependencies between the profiles and to install them in the correct order.
Basically all known profiles are getting registered and then you can active e.g. the "default" profile,
which will first install the other profiles this profile depends on (bootstrap and deployers). At them moment profiles
are getting registered as ON_DEMAND and started based on the dependencies. At least i think that should be
the behavior of registering and activating a profile.
I mean we can start profiles also in a different way - but this was the easiest way to do that :)
One isssue though is that i'm using a Scoped MC controller - the only purpose of this was that if we want to do
e.g. mainDeployer.checkComplete() when installing the profiles it would fail, just because not all profiles are installed yet.
And it would also fail with "DEPLOYMENTS MISSING DEPENDENCIES" although it's a profile ;)
Furthermore when shutting down the server the ProfileServiceBootstrap is trying to deactivate all active profiles. This is not really nice,
as it is likely to happen that it tries to deactivate a profile which already has been deactivated due to it's dependencies.
Maybe we should just add a prepareShutdown() and shutdown() to the profileService?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202223#4202223
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202223
17 years, 2 months