[Design of JBoss Web Services] - Re: swaref.xsd: connection time out during deployment
by lall2
Hi,
I am getting a similar error with JBoss 4.2.2 and JBossws-native-3.0.1
Is this the same problem like in
http://jira.jboss.org/jira/browse/JBWS-2252 or is it already fixed in another release?
| [wsconsume] java.net.ConnectException: Connection timed out: connect
| [wsconsume] at org.jboss.com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildModel(WSDLModeler.java:213)
| [wsconsume] at org.jboss.com.sun.tools.ws.processor.config.ModelInfo.buildModel(ModelInfo.java:88)
| [wsconsume] at org.jboss.com.sun.tools.ws.processor.Processor.runModeler(Processor.java:82)
| [wsconsume] at org.jboss.com.sun.tools.ws.wscompile.CompileTool.run(CompileTool.java:543)
| [wsconsume] at org.jboss.com.sun.tools.ws.util.ToolBase.run(ToolBase.java:57)
| [wsconsume] at org.jboss.ws.tools.jaxws.impl.WSContractConsumerImpl$1.run(WSContractConsumerImpl.java:163)
| [wsconsume] at org.jboss.ws.tools.jaxws.impl.WSContractConsumerImpl.consume(WSContractConsumerImpl.java:166)
| [wsconsume] at org.jboss.ws.tools.jaxws.api.WSContractConsumer.consume(WSContractConsumer.java:176)
| [wsconsume] at org.jboss.ws.tools.jaxws.ant.wsconsume.executeNonForked(wsconsume.java:196)
| [wsconsume] at org.jboss.ws.tools.jaxws.ant.wsconsume.execute(wsconsume.java:217)
| [wsconsume] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
| [wsconsume] at org.apache.tools.ant.Task.perform(Task.java:364)
| [wsconsume] at org.apache.tools.ant.Target.execute(Target.java:341)
| [wsconsume] at org.apache.tools.ant.Target.performTasks(Target.java:369)
| [wsconsume] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
| [wsconsume] at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
| [wsconsume] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
| [wsconsume] at org.eclipse.ant.internal.ui.antsupport.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32)
| [wsconsume] at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
| [wsconsume] at org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunner.java:423)
| [wsconsume] at org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRunner.java:137)
| [wsconsume] Caused by: java.net.ConnectException: Connection timed out: connect
| [wsconsume] at org.jboss.com.sun.tools.ws.processor.modeler.wsdl.JAXBModelBuilder.bind(JAXBModelBuilder.java:128)
| [wsconsume] at org.jboss.com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildJAXBModel(WSDLModeler.java:2207)
| [wsconsume] at org.jboss.com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.internalBuildModel(WSDLModeler.java:224)
| [wsconsume] at org.jboss.com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildModel(WSDLModeler.java:181)
| [wsconsume] ... 20 more
| [wsconsume] Caused by: java.net.ConnectException: Connection timed out: connect
| [wsconsume] at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:90)
| [wsconsume] at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:402)
| [wsconsume] at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:301)
| [wsconsume] at com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl.startElement(AbstractReferenceFinderImpl.java:95)
| [wsconsume] at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
| [wsconsume] at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:240)
| [wsconsume] at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:277)
| [wsconsume] at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:246)
| [wsconsume] at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:123)
| [wsconsume] at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.parseSchema(SchemaCompilerImpl.java:135)
| [wsconsume] at org.jboss.com.sun.tools.ws.processor.modeler.wsdl.JAXBModelBuilder.internalBuildJAXBModel(JAXBModelBuilder.java:91)
| [wsconsume] at org.jboss.com.sun.tools.ws.processor.modeler.wsdl.JAXBModelBuilder.<init>(JAXBModelBuilder.java:70)
| [wsconsume] at org.jboss.com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildJAXBModel(WSDLModeler.java:2190)
| [wsconsume] ... 22 more
| [wsconsume] Caused by: java.net.ConnectException: Connection timed out: connect
| [wsconsume] at java.net.PlainSocketImpl.socketConnect(Native Method)
| [wsconsume] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
| [wsconsume] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
| [wsconsume] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
| [wsconsume] at java.net.Socket.connect(Socket.java:519)
| [wsconsume] at java.net.Socket.connect(Socket.java:469)
| [wsconsume] at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
| [wsconsume] at sun.net.www.http.HttpClient.openServer(HttpClient.java:382)
| [wsconsume] at sun.net.www.http.HttpClient.openServer(HttpClient.java:509)
| [wsconsume] at sun.net.www.http.HttpClient.<init>(HttpClient.java:231)
| [wsconsume] at sun.net.www.http.HttpClient.New(HttpClient.java:304)
| [wsconsume] at sun.net.www.http.HttpClient.New(HttpClient.java:316)
| [wsconsume] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:817)
| [wsconsume] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:769)
| [wsconsume] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:694)
| [wsconsume] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:938)
| [wsconsume] at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
| [wsconsume] at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
| [wsconsume] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
| [wsconsume] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
| [wsconsume] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
| [wsconsume] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
| [wsconsume] at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
| [wsconsume] at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:394)
| [wsconsume] ... 33 more
| [wsconsume] error: java.net.ConnectException: Connection timed out: connect
|
wsdl:
| <?xml version="1.0" encoding="UTF-8"?>
| <definitions name='SwAService' targetNamespace='http://std.spg.com/ws/swa' xmlns='http://schemas.xmlsoap.org/wsdl/' xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/' xmlns:tns='http://std.spg.com/ws/swa' xmlns:xsd='http://www.w3.org/2001/XMLSchema'>
| <types>
| <xs:schema targetNamespace='http://std.spg.com/ws/swa' version='1.0' xmlns:swaRef='http://ws-i.org/profiles/basic/1.1/xsd' xmlns:tns='http://std.spg.com/ws/swa' xmlns:xs='http://www.w3.org/2001/XMLSchema'>
| <xs:import namespace='http://ws-i.org/profiles/basic/1.1/xsd' schemaLocation='http://ws-i.org/profiles/basic/1.1/swaref.xsd'/>
| <xs:element name='documentDT' type='tns:documentDT'/>
| <xs:element name='findDocument' type='tns:findDocument'/>
| <xs:element name='findDocumentResponse' type='tns:findDocumentResponse'/>
| <xs:element name='sendDocument' type='tns:sendDocument'/>
| <xs:complexType name='sendDocument'>
| <xs:sequence>
| <xs:element form='qualified' minOccurs='0' name='document' type='tns:documentDT'/>
| </xs:sequence>
| </xs:complexType>
| <xs:complexType name='documentDT'>
| <xs:sequence>
| <xs:element minOccurs='0' name='correlationid' type='xs:string'/>
| <xs:element minOccurs='0' name='creationdate' type='xs:dateTime'/>
| <xs:element minOccurs='0' name='documentdescription' type='xs:string'/>
| <xs:element minOccurs='0' name='filename' type='xs:string'/>
| <xs:element minOccurs='0' name='document' type='swaRef:swaRef'/>
| </xs:sequence>
| </xs:complexType>
| <xs:complexType name='findDocument'>
| <xs:sequence>
| <xs:element form='qualified' minOccurs='0' name='filename' type='xs:string'/>
| <xs:element form='qualified' minOccurs='0' name='correlationid' type='xs:string'/>
| </xs:sequence>
| </xs:complexType>
| <xs:complexType name='findDocumentResponse'>
| <xs:sequence>
| <xs:element form='qualified' minOccurs='0' name='document' type='tns:documentDT'/>
| </xs:sequence>
| </xs:complexType>
| </xs:schema>
| </types>
| <message name='SwAWS_findDocument'>
| <part element='tns:findDocument' name='findDocument'/>
| </message>
| <message name='SwAWS_findDocumentResponse'>
| <part element='tns:findDocumentResponse' name='findDocumentResponse'/>
| </message>
| <message name='SwAWS_sendDocument'>
| <part element='tns:sendDocument' name='sendDocument'/>
| </message>
| <portType name='SwAWS'>
| <operation name='findDocument' parameterOrder='findDocument'>
| <input message='tns:SwAWS_findDocument'/>
| <output message='tns:SwAWS_findDocumentResponse'/>
| </operation>
| <operation name='sendDocument'>
| <input message='tns:SwAWS_sendDocument'/>
| </operation>
| </portType>
| <binding name='SwAWSBinding' type='tns:SwAWS'>
| <soap:binding style='document' transport='http://schemas.xmlsoap.org/soap/http'/>
| <operation name='findDocument'>
| <soap:operation soapAction='http://std.spg.com/ws/swa/findDocument'/>
| <input>
| <soap:body use='literal'/>
| </input>
| <output>
| <soap:body use='literal'/>
| </output>
| </operation>
| <operation name='sendDocument'>
| <soap:operation soapAction='http://std.spg.com/ws/swa/sendDocument'/>
| <input>
| <soap:body use='literal'/>
| </input>
| </operation>
| </binding>
| <service name='SwAService'>
| <port binding='tns:SwAWSBinding' name='SwAWSPort'>
| <soap:address location='REPLACE_WITH_ACTUAL_URL'/>
| </port>
| </service>
| </definitions>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164234#4164234
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164234
17 years, 8 months
[Design of POJO Server] - AltDD processing missing from MultipleVFSParsingDeployer
by adrian＠jboss.org
Since the RARParsingDeployer moved to the new MultipleVFSParsingDeployer
the AltDD test is failing:
http://hudson.jboss.org/hudson/job/JBoss-AS-5.0.x-TestSuite-sun15/lastBui...
This is because it is not using the alternate deployment descriptor specified in the
ear deployment descriptor.
| Caused by: org.xml.sax.SAXException: Content is not allowed in prolog. @ vfszip:/home/ejort/jboss-head/testsuite/output/lib/testdeployers-ear-altdd-connector.ear/testdeployers-invalidmcf.rar/META-INF/ra.xml[1,1]
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$MetaDataErrorHandler.fatalError(SaxJBossXBParser.java:432)
| at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
| at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
| at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
| at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
| at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)
| at org.apache.xerces.impl.XMLDocumentScannerImpl$PrologDispatcher.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)
| ... 69 more
| 14:13:30,058 WARN [MainDeployer] Failed to deploy: file:/home/ejort/jboss-head/testsuite/output/lib/testdeployers-ear-altdd-connector.ear
|
The processing that is missing is to look for the .altDD attachment.
See AbstractVFSParsingDeployer.
In fact, The MultipleVFSParsingDeployer overrides the wrong method.
1) It is wrong for it to check for the altDD on the "merged" metadata class name
in the method inherited from AbstractVFSParsingDeployer.
It should be checking for the "expectedType".getName() + ".altDD"
attachment.
2) If there's an altDD, the original metadata file may not even exist
(currently the deployment would be ignored altogether in this case).
so it should be matching against the name of the file not assuming the file exists.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164223#4164223
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164223
17 years, 8 months
[Design the new POJO MicroContainer] - Re: Bug in Microcontainer - Errors from DependencyInfo/Item
by adrian＠jboss.org
"alesj" wrote :
| 3) Currently not testing this:
|
| | for (Method method : methods)
| | {
| | // Should we suppress this?
| | if ("getLifecycleCallbacks".equals(method.getName()))
| | continue;
| |
| If handleInstallLifecycleCallbacks throws exception ((in initial incrementState)) on DependencyInfo::getLifecycleCallbacks(), it gets caught, but re-thrown:
|
| | boolean ok = incrementState(context, trace);
| | if (ok)
| | {
| | try
| | {
| | registerControllerContext(context);
| | }
| | catch (Throwable t)
| | {
| | // This is probably unreachable? But let's be paranoid
| | ok = false;
| | throw t;
| | }
| | }
| | if (ok)
| | {
| | resolveContexts(trace);
| | }
| | else
| | {
| | errorContexts.remove(context);
| | throw context.getError();
| | }
| |
| Should we add context-2-error-handling code to this method?
You need to write that test, but it looks to me that currently the case
is already handled since the handleInstallLifecycleCallbacks is in a try/catch block
that moves the context to the error state and then the code you show
removes it altogether and rethrows the error.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164195#4164195
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164195
17 years, 8 months
[Design of POJO Server] - Re: Scoping of war/jar file embedded in sar service archives
by adrian＠jboss.org
"scott.stark(a)jboss.org" wrote : "adinn" wrote :
| | I just want to understand what the difference is. It sounds like the war manifest classpath behavior has changed, but if anything I would expect that in jbossas5 the war manifest was ignored while what you describe appears to be the opposite; that 4.X/5.0.BetaX were not using the war manifest classpath. I think we have gone around on whether the war manifest classpath should be picked up or not.
| |
|
| The issue is probably that the war manifest classpath should only be processed
| when it is a top level deployment (well nearly see below :-).
|
| If it is not a top level deployment, then the jars will already be included
| in the top level deployment classloader (and should be shared
| between the wars).
|
| This logic would go in the WARStructure deployer
|
|
| | // Add the war manifest classpath entries (if its top level)
| | if (isTopLevel(parent))
| | addClassPath(root, file, false, true, context);
| |
|
| However it should really also check (for non-top level deployments)
| whether the manifest entry is included as a context within the parent.
|
| e.g. an ear might not delcare the jar in application.xml,
| instead it is only referenced from the war manifest.
|
|
| | // Add the war manifest classpath entries (if its top level)
| | if (isTopLevel(parent) || doesntAlreadyHaveContext(metadata, file))
| | addClassPath(root, file, false, true, context);
| |
|
| If you agree with my analysis, then create a JIRA issue for it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164192#4164192
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164192
17 years, 8 months
[Design of JBoss Portal] - Portlet rendered twice on JBP 2.6.5SP1
by michaelchan
I was debugging my portlets on JBP today and found that my portlets sometimes get rendered twice.
The following is the only way to sort of overcome the problem.
When I am logged in as admin, the portlets definitely get rendered twice, and the strange thing is, the session ID is difference between the two rendering process. And it is consistent everytime when I refresh the portal page.
I have a debug line in my portlet, which outputs the session ID, everytime when I refresh the page, the debug line is outputed twice, with a different sessionID. The two sessionIDs are consistent within the session, meaning that if I get ID=1234 and ID=2222 from the debug lines, I will always get those unless session destoryed or timed out.
The worst thing is, sometimes even I have logged out, the portlet still rendered twice, but this time, the two session ID get outputed are identical.
How do I get rid of the rendering issue??
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164185#4164185
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164185
17 years, 8 months
[Design of JBoss Portal] - Portlet rendered twice on JBP 2.6.5SP1
by michaelchan
I was debugging my portlets on JBP today and found that my portlets sometimes get rendered twice.
The following is the only way to sort of overcome the problem.
When I am logged in as admin, the portlets definitely get rendered twice, and the strange thing is, the session ID is difference between the two rendering process. And it is consistent everytime when I refresh the portal page.
I have a debug line in my portlet, which outputs the session ID, everytime when I refresh the page, the debug line is outputed twice, with a different sessionID. The two sessionIDs are consistent within the session, meaning that if I get ID=1234 and ID=2222 from the debug lines, I will always get those unless session destoryed or timed out.
The worst thing is, sometimes even I have logged out, the portlet still rendered twice, but this time, the two session ID get outputed are identical.
How do I get rid of the rendering issue??
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164172#4164172
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164172
17 years, 8 months
[Design of JBoss Build System] - Re: [jboss-as-control-plugin] Deploy/Undeploy Mojos
by ALRubinger
Reviewed patches by Antony attached to
http://jira.jboss.com/jira/browse/JBASMP-2
(was: http://jira.jboss.com/jira/browse/JBBUILD-478 )
First off, new issues for JBoss AS Maven Plugins will go here:
http://jira.jboss.com/jira/browse/JBASMP
Similarly, the Server Manager has its own Project tracking:
http://jira.jboss.com/jira/browse/JBASM
General Comments
There are a lot of suggestions both in the JIRA Comments and on this forum. Once these mature into valid tasks, assign a new JIRA Issue for them, otherwise they'll fall through the cracks due to the noise overload. An example is: http://jira.jboss.com/jira/browse/JBASMP-4, which I pulled from comments in JBASMP-2.
Also, JIRA Comments are not the place for discussion. That's why we've got forums. :)
So the flow is:
Propose/discuss (Forum) > Create JIRA Issue > Assign
Each issue should have its own Forum Thread to keep things organized. If need be, we'll open up a JBoss AS Maven Plugins Forum, but let's see if that'll be necessary first.
Replies to JIRA Comments
"astubbs" wrote : Another proposal regarding is IMO JbossAsControlCreateConfigurationMojo should copy the configuration from resources/jbossasconf (or something of that nature) vs resources/conf as conf as ambiguous.
This is configurable by way of the "overlayLocation" property that may be passed to the Mojo. "src/main/resources" seemed an intelligent default, no?
/**
| * Location of the overlay files
| *
| * @parameter alias='jboss.overlayLocation' default-value='${basedir}/src/main/resources'
| */
| private String overlayLocation;
Gradle
OK, OK, cool. I get it. But priority 1 of the Roadmap (which doesn't yet exist in any written form aside from my blog, that's a big TODO) is to release the Maven Plugins with a full working set. Then enhance. :)
Groovy Mojos
See above, Gradle. I'll keep these configurations posted as patched, but each patch should try to address one issue alone; this makes reverts and tracking much easier. Already we're biting off too much in terms of scope - release early, release often. :)
jboss-server-manager-2.patch
I've committed the change provided to fix spaces in Win32 classpaths:
http://jira.jboss.com/jira/browse/JBASM-2
Regarding the WarDeployer, this isn't the mechanism I'd had in mind.
* This class is a simple File copy utility/wrapper for Commons FileUtils. What makes this specific to WAR Deployment?
* I'd been incorrect in mentioning "existing logic in jboss-server-manager". What I'd been thinking of is within the jboss-test project, JBossTestServices.deploy(), which invokes upon the JMX Bus to Deploy a URL. @see http://anonsvn.jboss.org/repos/jbossas/projects/test/trunk/src/main/java/....
So what I'd prefer to see is the Deploy Mojo to delegate to this kind of code. Because the Maven Plugins should not rely on jboss-test, we'd either have to rewrite this logic elsewhere or port it to server-manager, where both the Plugins and jboss-test could call upon it.
maven-jboss-as-control-example alternate pom.patch
Good use of Profiles here to make a more user-friendly POM that's adaptable to different start/stop/deploy scenarios. However, the idea behind this project is simply to be self-documenting (and a free test mechanism to make sure the plugins work). Let's discuss this one more, I'd like to be convinced further why you believe we should change the "mvn clean install does everything" approach already in place. True users are going to be adapting our Plugins into their own POMs, remember, so I want this to be KISS and low barrier to entry for new users (who may also be new to Maven).
Perhaps instead of replacing the existing POM, we add a profile-based one as well. Users then have some boilerplate better suited to real-world usage in addition to the simple startup provided by the original POM.
maven-jboss-plugins-aggregator-2.patch
To be continued...
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164146#4164146
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164146
17 years, 8 months