October 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Web Services] - Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep

by darran.lofthouse＠jboss.com

At the moment we have one request for this. Parsing the web.xml is not a big job so maybe we should just go with option 3 for the moment until the refactoring takes place. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978660#3978660 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978660

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1093 - normal servlets the web.xml is modified as i

by darran.lofthouse＠jboss.com

I believe the CrossContextLoader I have available was created using the StandardClassLoader of the jbossws web application as the parent classloader so by using this we should have access to all of the classes within jbossws as well as all of the Tomcat libs. I think my priority for this should be:- - Deployment from within JBoss - Deployment from scanner thread in Tomcat - Deployment from testsuite For command line clients we can say it's the clients responsibility to include all the required jars on the classpath (we will just need to make the jars and classes in the war available). If we want to consider refactoring the wspublish to take advantage of the deployment from within Tomcat we can look at that later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978659#3978659 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978659

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - 1.0 BeanSchemaBinding failures

by scott.stark＠jboss.org

There is another pervasive xml parsing failure in the kernel tests involving the 1.0 schema binding. The issue is that the child passed into the ValueMetaDataElementInterceptor.add(Object parent, Object child, QName name) is the same object as the parent, and not a ValueMetaData instance as expected. I have not tracked down what jbossxb change would have altered the behavior. | 18749 DEBUG [ArrayXMLTestCase] url=file:/home/svn/JBossMC/jbossmc/kernel/src/resources/xml-test/org/jboss/test/kernel/config/test/testArrayNotAArray.xml | 930364 ERROR [ArrayXMLTestCase] Unexpected throwable | org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/home/svn/JBossMC/jbossmc/kernel/src/resources/xml-test/org/jboss/test/kernel/config/test/testArrayNotAArray.xml@13,18 | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:164) | at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:133) | at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:135) | at org.jboss.test.kernel.config.support.XMLUtil.<init>(XMLUtil.java:76) | at org.jboss.test.kernel.config.test.AbstractKernelConfigTest.bootstrapXML(AbstractKernelConfigTest.java:72) | at org.jboss.test.kernel.config.test.ArrayXMLTestCase.arrayNotAArray(ArrayXMLTestCase.java:85) | at org.jboss.test.kernel.config.test.ArrayTestCase.testArrayNotAArray(ArrayTestCase.java:267) | at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) | at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;J)Ljava.lang.Object;(Unknown Source) | at junit.framework.TestCase.runTest(TestCase.java:154) | at junit.framework.TestCase.runBare(TestCase.java:127) | at junit.framework.TestResult$1.protect(TestResult.java:106) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.framework.TestResult.run(TestResult.java:109) | at junit.framework.TestCase.run(TestCase.java:118) | at junit.framework.TestSuite.runTest(TestSuite.java:208) | at junit.framework.TestSuite.run(TestSuite.java:203) | at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) | at junit.extensions.TestSetup$1.protect(TestSetup.java:19) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.extensions.TestSetup.run(TestSetup.java:23) | at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) | at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) | at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) | at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) | at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) | at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) | Caused by: java.lang.ClassCastException: org.jboss.beans.metadata.plugins.AbstractPropertyMetaData | at org.jboss.kernel.plugins.deployment.xml.BeanSchemaBinding$ValueMetaDataElementInterceptor.add(BeanSchemaBinding.java:1280) | at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:1029) | at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:158) | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.endElement(SaxJBossXBParser.java:295) | at org.apache.xerces.parsers.AbstractSAXParser.endElement(Lorg.apache.xerces.xni.QName;Lorg.apache.xerces.xni.Augmentations;)V(Unknown Source) | at org.apache.xerces.xinclude.XIncludeHandler.endElement(Lorg.apache.xerces.xni.QName;Lorg.apache.xerces.xni.Augmentations;)V(Unknown Source) | at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement()I(Unknown Source) | at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Z)Z(Unknown Source) | at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Z)Z(Unknown Source) | at org.apache.xerces.parsers.XML11Configuration.parse(Z)Z(Unknown Source) | at org.apache.xerces.parsers.XML11Configuration.parse(Lorg.apache.xerces.xni.parser.XMLInputSource;)V(Unknown Source) | at org.apache.xerces.parsers.XMLParser.parse(Lorg.apache.xerces.xni.parser.XMLInputSource;)V(Unknown Source) | at org.apache.xerces.parsers.AbstractSAXParser.parse(Ljava.lang.String;)V(Unknown Source) | at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Ljava.lang.String;)V(Unknown Source) | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:160) | at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:133) | at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:135) | at org.jboss.test.kernel.config.support.XMLUtil.<init>(XMLUtil.java:76) | at org.jboss.test.kernel.config.test.AbstractKernelConfigTest.bootstrapXML(AbstractKernelConfigTest.java:72) | at org.jboss.test.kernel.config.test.ArrayXMLTestCase.arrayNotAArray(ArrayXMLTestCase.java:85) | at org.jboss.test.kernel.config.test.ArrayTestCase.testArrayNotAArray(ArrayTestCase.java:267) | at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) | at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;J)Ljava.lang.Object;(Unknown Source) | at junit.framework.TestCase.runTest(TestCase.java:154) | at junit.framework.TestCase.runBare(TestCase.java:127) | at junit.framework.TestResult$1.protect(TestResult.java:106) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.framework.TestResult.run(TestResult.java:109) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978657#3978657 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978657

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1093 - normal servlets the web.xml is modified as i

by jason.greene＠jboss.com

"darran.lofthouse(a)jboss.com" wrote : I have for the JBossWS to Tomcat deployment working now. | | Looking at the scanning thread when running within Tomcat the classloader at the time is a CrossContextLoader, if we just create a classloader similar to the CrossContextLoader that includes the jars and classes of the war being deployed we should have everything we need to be able to load the classes to test for @WebService. | | We also need to include the main tomcat libs. Not sure if this loader you refer has this in its path. The reason is that its perfectly legal to have a war with just a web.xml, and then have the classes somewher like tomcat/lib. anonymous wrote : | For the testsuite / command line clients I don't think it would be unreasonable to expect the calling client to put all the required jars on the classpath, afterall the wspublish process is not just copying the war it is actually processing the war so the caller should make sure all the required classes are available. | I think that's a reasonable expectation. anonymous wrote : | Alternatively couldn't the tool just copy the war to jbossws-deploy and let the code running within Tomcat handle it? Or even refactor the deployment into it's own servlet and then get wspublish to call the servlet directly to publish the war, again this would mean the deployment would be happening within Tomcat. | The tool was designed so that someone could deploy without the tomcat jbossws deployment service. The http deployment is an option, but its a potential security risk, so it would need to be locked down in some way. Its probably less work to just add a classpath option. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978656#3978656 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978656

19 years, 5 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Add

by genman

To answer your questions: I have used it in my projects and have used it to correct some (potential) synchronization bugs. I have found issues against other people's code. You can review the report yourself and decide on the quality of results. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978653#3978653 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978653

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1093 - normal servlets the web.xml is modified as i

by darran.lofthouse＠jboss.com

I have for the JBossWS to Tomcat deployment working now. Looking at the scanning thread when running within Tomcat the classloader at the time is a CrossContextLoader, if we just create a classloader similar to the CrossContextLoader that includes the jars and classes of the war being deployed we should have everything we need to be able to load the classes to test for @WebService. For the testsuite / command line clients I don't think it would be unreasonable to expect the calling client to put all the required jars on the classpath, afterall the wspublish process is not just copying the war it is actually processing the war so the caller should make sure all the required classes are available. Alternatively couldn't the tool just copy the war to jbossws-deploy and let the code running within Tomcat handle it? Or even refactor the deployment into it's own servlet and then get wspublish to call the servlet directly to publish the war, again this would mean the deployment would be happening within Tomcat. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978652#3978652 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978652

19 years, 5 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Add

by genman

Looks like they already ran their tool against JBoss 4.0.2: http://findbugs.sourceforge.net/demo.html Seems like mostly 3rd party stuff raises warnings. The tool integrates pretty readily with Maven: http://maven-plugins.sourceforge.net/maven-findbugs-plugin/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978651#3978651 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978651

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1079 - Incorrect WSDL to Java mapping for anonymous

by jason.greene＠jboss.com

Ok sounds good. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978650#3978650 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978650

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep

by jason.greene＠jboss.com

"scott.stark(a)jboss.org" wrote : 1 is the direction will be moving towards in head as that layer that actually deploys the web app should just be given the metadata that describes what the web app consists of. Any number of other deployers can have run earlier in the deployment phase to produce this metadata from various sources. | | A hybrid approach that moves closer to what is needed in jboss5 would be a plugin into the tomcat deployer that allowed modification of the WebMetaData. This needs to be an optional plugin binding so that we don't have to pulling in the entire webservice stack for a tomcat only config. If the plugin has modifed that data, then the tomcat deployer can write out a modified web.xml and reference it via the alt-dd. | | Perhaps we should delay this bug as part of the jboss 5 integration. Is there a reason for JBWS-1133 to get resolved sooner? How large is the demand? -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978649#3978649 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978649

19 years, 5 months

1
0
0 / 0

[Design of Security on JBoss] - Re: SecurityContext

by anil.saldhana＠jboss.com

Now that we are clear on the constituents of the Security Context (Superset of the Security Association), I would like to discuss the establishment of the SC in relation to SA. In my current prototype for the time being, I plugged in the SC in the Security Association as a map entry in the context data keyed in by security domain. I think this is not right. - What do we do with Security Association? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978646#3978646 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978646

19 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2006