[JBoss-dev] RE: 4.0.4.GA WS release + EJB3 RC6
Hi Bill, JBossWS will not contain the JAXWS api in the forseeable future. We plan to have a JAXWS implemenation by the end of Q3. I suggest you resolve the dependency on JAXWS in the EJB3 project without relying on functionality provided by JBossWS. Cheers xxx Thomas Diesler Web Service Lead JBoss Inc. xxx From: Bill Decoste Sent: 18 May 2006 03:33 To: Thomas Diesler Subject: 4.0.4.GA WS release + EJB3 RC6 Hi Thomas, I’m responding to a forum posting … we can’t build EJB3s annotated with WS annotations using JBoss-4.0.4.GA and EJB3 RC6. However, the latest WS build in head resolves this issue. When do you plan on releasing the version in head? http://www.jboss.org/index.html?module=bb&op=viewtopic&t=83046 Thanks Bill DeCoste JBoss [EMAIL PROTECTED]
[JBoss-dev] RE: Where is javaee_web_services_client_1_2.xsd
This is not a J2EE-1.4 schema http://java.sun.com/xml/ns/j2ee/#resources I'd say the test deployment is incorrect xxx Thomas Diesler Web Service Lead JBoss Inc. xxx >-Original Message- >From: Scott M Stark >Sent: Friday, May 12, 2006 15:59 >To: jboss-development@lists.sourceforge.net >Cc: Dev - JBossWS >Subject: Where is javaee_web_services_client_1_2.xsd > >I'm seeing the following warning while running one of the ejb3 tests: > >06:57:08,069 WARN [JBossEntityResolver] Cannot load systemId >from resource: jav aee_web_services_client_1_2.xsd >06:57:08,069 WARN [JBossEntityResolver] Trying to resolve >systemId as a non-fil e URL: >http://java.sun.com/xml/ns/javaee/javaee_web_services_client_1_2.xsd >06:57:08,506 WARN [JBossEntityResolver] Cannot load systemId >from resource: jav aee_web_services_client_1_2.xsd >06:57:08,506 WARN [JBossEntityResolver] Trying to resolve >systemId as a non-fil e URL: >http://java.sun.com/xml/ns/javaee/javaee_web_services_client_1_2.xsd > >where is this schema supposed to be picked up from? > > >Scott Stark >VP Architecture & Technology >JBoss Inc. > > > --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Access to kernel instance in jboss head
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3942912#3942912 xxx Thomas Diesler Web Service Lead JBoss Inc. xxx >-Original Message- >From: Bill Burke >Sent: Thursday, May 11, 2006 16:08 >To: Thomas Diesler >Subject: Re: Access to kernel instance in jboss head > >you can inject it. it has a bean name. > >Thomas Diesler wrote: >> Folks, >> >> I can deploy beans on the jboss-head integrated kernel. How can I >> access the Kernel instance, or more specifically get at the >KernelRegistry? >> >> >http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3942877#39428 >> 77 >> ><http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3942877#3942 >> 877> >> >> cheers >> -thomas >> > >-- >Bill Burke >Chief Architect >JBoss Inc. > --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] FW: Access to kernel instance in jboss head
Folks, I can deploy beans on the jboss-head integrated kernel. How can I access the Kernel instance, or more specifically get at the KernelRegistry? http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3942877#3942877 cheers -thomas
[JBoss-dev] Using the latest jbossws
Hi Julien/Chris If you need to check whether I bugfix works for you in jboss-4.0.x, please follow the process documented here: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBWSFAQBuildAndInstall cheers -thomas
[JBoss-dev] Insuffient obfucated jboss-backport-concurrent
Please comment on http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3938538#3938538 cheers -thomas
[JBoss-dev] hot swap classes with eclipse
# Use the eclipse compiler to allow for hot code swapping # http://www.jboss.org/index.html?module=bb&op=viewtopic&t=65783 # # Make sure you have these jars in tools/lib # # org.eclipse.jdt.core_3.1.0.jar # jdtCompilerAdapter.jar (is contained in org.eclipse.jdt.core_3.1.0.jar) # #build.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
[JBoss-dev] RE: building from local repository
> Why do you point to a local cvs copy? For speed purposes? It’s not for speed purposes. Before I update the public repository, I need to check the build locally. Cherrs -thomas From: Ruel Loehr Sent: 18 April 2006 15:58 To: Thomas Diesler Cc: 'jboss-development' Subject: RE: building from local repository Thomas, I’m assuming you set the JBOSS_REPOSITORY env variable to a local folder. Your correct that the md5’s only exist on the public replo. If you point the JBOSS_REPOSITORY var to the http://repository.jboss.com, that will clear up the problem you are seeing. Why do you point to a local cvs copy? For speed purposes? Ruel Loehr JBoss QA - 512-342-7840 ext 2011 Yahoo: ruelloehr Skype: ruelloehr AOL: dokoruel From: Thomas Diesler Sent: Tuesday, April 18, 2006 5:03 AM To: Ruel Loehr Cc: 'jboss-development' Subject: building from local repository Hi Ruel, The build from a local repository fails because [getwithsum] cannot find the md5 files in my local version of the repository. Adding reference: jbossas-thirdparty [getwithsum] Executing task GetWithSum [getwithsum] The source md5 is file:/d:/cvs/repository.jboss.com//antlr/2.7.6rc1/component-info.xml.md5 [getwithsum] The dest md5 is D:\cvs\jboss-branch\jboss-4.0.x\thirdparty\antlr\component-info.xml.md5 [getwithsum] Retrieving file: c:\DOCUME~1\Thomas\LOCALS~1\Temp\temp127.tmp [getwithsum] from URL: file:///d:/cvs/repository.jboss.com//antlr/2.7.6rc1/component-info.xml.md5/d:/cvs/repository.jboss.com//antlr/2.7.6rc1/component-info.xml.md5 [getwithsum] Error getting file:/d:/cvs/repository.jboss.com//antlr/2.7.6rc1/component-info.xml to D:\cvs\jboss-branch\jboss-4.0.x\thirdparty\antlr\component-info.xml The md5 files are available from http://repository.jboss.com but not in cvs. How is this supposed to work? cheers -thomas xxxxxxx Thomas Diesler Web Service Lead JBoss Inc. xxx
[JBoss-dev] RE: JBWS 808
Chris, This should be covered by your integration tests. You would need to tell me how to run those. xxx Thomas Diesler Web Service Lead JBoss Inc. xxx >-Original Message- >From: Chris Laprun >Sent: Saturday, April 15, 2006 01:17 >To: Thomas Diesler >Subject: JBWS 808 > >Hi Thomas, > >I see that you have resolved http://jira.jboss.com/jira/browse/ >JBWS-808. I was wondering when we could get an updated version >in the Branch_4_0. > >I currently cannot test WSRP with JBWS because of this issue >and I would like to make sure that everything works fine >before you guys go 1.0. > >Thanks in advance. > >Best, >Chris > >== >JBoss Portal Developer / WSRP Architect > > > > --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] building from local repository
Hi Ruel, The build from a local repository fails because [getwithsum] cannot find the md5 files in my local version of the repository. Adding reference: jbossas-thirdparty[getwithsum] Executing task GetWithSum[getwithsum] The source md5 is file:/d:/cvs/repository.jboss.com//antlr/2.7.6rc1/component-info.xml.md5[getwithsum] The dest md5 is D:\cvs\jboss-branch\jboss-4.0.x\thirdparty\antlr\component-info.xml.md5[getwithsum] Retrieving file: c:\DOCUME~1\Thomas\LOCALS~1\Temp\temp127.tmp[getwithsum] from URL: file:///d:/cvs/repository.jboss.com//antlr/2.7.6rc1/component-info.xml.md5/d:/cvs/repository.jboss.com//antlr/2.7.6rc1/component-info.xml.md5[getwithsum] Error getting file:/d:/cvs/repository.jboss.com//antlr/2.7.6rc1/component-info.xml to D:\cvs\jboss-branch\jboss-4.0.x\thirdparty\antlr\component-info.xml The md5 files are available from http://repository.jboss.com but not in cvs. How is this supposed to work? cheers -thomas xxxThomas DieslerWeb Service LeadJBoss Inc.xxx
[JBoss-dev] RE: Toward JBoss v4.0.4.GA - Part 2 - Build/thirdparty Issues
We plan to do a final relase during the course of this week. xxx Thomas Diesler Web Service Lead JBoss Inc. xxx >-Original Message- >From: Scott M Stark >Sent: Wednesday, April 05, 2006 20:58 >To: Dimitris Andreadis; 'jboss-development' >Cc: The Core >Subject: RE: Toward JBoss v4.0.4.GA - Part 2 - Build/thirdparty Issues > >jbossws1.0 should be a final release. I think the only thing >holding back jbossretro from a final release is feedback on >the efficacy based on the current jbossws14 in 4.0.4CR2. > >> -Original Message- >> From: Dimitris Andreadis >> Sent: Wednesday, April 05, 2006 3:33 AM >> To: jboss-development >> Cc: The Core >> Subject: Toward JBoss v4.0.4.GA - Part 2 - Build/thirdparty Issues >> Importance: High >> >> >> Various Issues >> -- >> >> - Breakage of jboss commons. Is this the right time, or >should do for >> 4.0.5. Aren't we already overloaded? Who & How? >> >> - Which thirdparty libs can be removed? So far I've noticed >> apache-wss4j & apache-jaxme. >> >> - JBoss.Net is not even included in the docs/examples now. >> Should it be removed from the 4.0.x module checkout? >> >> - The following jboss lists are *NOT* final (GA). What will >be updated >> for 4.0.4.GA? Project leads speak! >> >> >> >> >> >> >> >> >> >> >> >> >> >> > --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] catalog does not work for remote clients
Hi Jason/Scott, the new catalog support in jboss-head does not work for remote clients. I need to look into it on monday. Have a good weekend -thomas
[JBoss-dev] RE: wsrp integration
> [...]/jbpm/bpel and [...]/portal/wsrp seem fine to me Yes, that's fine. > neither Portal nor jBPM is an integral component of the Appserver. Whether these components are shipped with the AS binary distribution is one aspect, whether they have automated integration tests is another. The latter is a MUST. Our testsuite has the ability to create specialized jboss configurations, start/stop these configurations and run tests in those configurations. Every component that is expected to work in the AS should have automated integration tests. An integration test is a test that checks whether stuff that you depend on works in the way you expect. How you setup fuctional tests for your component is up to you. Cheers -thomas > -Original Message- > From: Alejandro Guizar > Sent: 24 March 2006 19:56 > To: Thomas Diesler; Chris Laprun > Cc: Julien Viet; Dev - JBossWS > Subject: RE: wsrp integration > > Thomas, > > I saw a WSRP folder under testsuite/src/main/org/jboss/test/webservice and > testsuite/src/resources/webservice and thought the place for BPEL > integration tests should also be there. > > Does your comment imply that both the WSRP and BPEL tests should be placed > elsewhere? If so, what is your suggestion? [...]/jbpm/bpel and > [...]/portal/wsrp seem fine to me, except that neither Portal nor jBPM is > an integral component of the Appserver. > > -Alejandro > > > -Original Message- > > From: Thomas Diesler > > Sent: Friday, March 24, 2006 3:54 AM > > To: Chris Laprun > > Cc: Julien Viet; Anil Saldhana; Dev - JBossWS > > Subject: RE: wsrp integration > > > > > > The WSRP integration testsuite would probably also have integration > tests > > other than for jbossws. > > > > -thomas > > > > > > >-Original Message- > > >From: Thomas Diesler > > >Sent: Friday, March 24, 2006 10:52 > > >To: Chris Laprun > > >Cc: Julien Viet; Anil Saldhana; Dev - JBossWS > > >Subject: RE: wsrp integration > > > > > > > > >>But these tests would still be located in the webservice testsuite > > >>though, right? > > > > > >No, WSRP is just another jbossws client and should have its > > >own integration testsuite. > > > > > >xxx > > >Thomas Diesler > > >Web Service Lead > > >JBoss Inc. > > >xxx > > > > > > > > >>-Original Message- > > >>From: Chris Laprun > > >>Sent: Friday, March 24, 2006 10:48 > > >>To: Thomas Diesler > > >>Cc: Julien Viet; Anil Saldhana; Dev - JBossWS > > >>Subject: Re: wsrp integration > > >> > > >> > > >>On Mar 24, 2006, at 4:17 AM, Thomas Diesler wrote: > > >> > > >>> IMHO, you need to identify the integration requirements and > > >>create for > > >>> these aspects in the main test suite. WSRP functional > > >aspects do not > > >>> need to be tested in the main testsuite. > > >> > > >>I agree. > > >> > > >>> A practical approach would be to create tests when issues actually > > >>> occur. i.e. you run your wsrp testsuite with jbossws, for > > >>every issue > > >>> you see you create a test in the wsrp integration testsuite. > > >> > > >>Makes sense in the shorter term. However, complete coverage would be > > >>ideal in the long run both for WS and WSRP. > > >> > > >>> There should be a tests-wsrp target in the testsuite that runs the > > >>> collection of integration tests. wsrp integration tests do > > >>not belong > > >>> in the webservice testsuite. i.e. should not run as part of > > >>> tests-webservice > > >> > > >>But these tests would still be located in the webservice testsuite > > >>though, right? > > >> > > >>Best, > > >>Chris > > >> > > >>== > > >>JBoss Portal Developer / WSRP Architect > > >> > > >> > > >> > > >> --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: JBossRetro, JBossWS and JDK1.4
Ryan, When you are ready with jbossretro, pls create a jira task for me to produce a snapshot that uses jbossretro. The jira task should conatin instructions on howto run the build using jbossretro. Cheers -thomas xxx Thomas Diesler Web Service Lead JBoss Inc. xxx >-Original Message- >From: Ryan Campbell >Sent: Saturday, March 18, 2006 18:46 >To: Jason T. Greene; Thomas Diesler >Cc: QA; 'jboss-development@lists.sourceforge.net' >Subject: RE: [JBoss-dev] RE: JBossRetro, JBossWS and JDK1.4 > >I didn't realize they were versioned together, but this makes sense. > >So the question is, is webservices ready for a 1.0.0.CR4? > >I have tested webservices snapshot code with >jboss-4.0/testsuite (weaved with jbossretro and >retrotranslator) and got the following error: > >Suite: org.jboss.test.webservice.samples.ServerSideJMSTestCase >Test:testSOAPMessageToEndpointQueue >Type:error >Exception: javax.naming.NameNotFoundException >Message: MessageDrivenEndpointQueue not bound > >-Original Message- >From: Jason T. Greene >Sent: Saturday, March 18, 2006 12:07 AM >To: jboss-development@lists.sourceforge.net; Thomas Diesler >Cc: QA; Adrian Brock >Subject: RE: [JBoss-dev] RE: JBossRetro, JBossWS and JDK1.4 > >Codewise, they are identical. The intention is to maintain one >codebase across both versions of the JDK. So there is no need >for another tag. > >-Jason > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:jboss- >> [EMAIL PROTECTED] On Behalf Of Ryan Campbell >> Sent: Friday, March 17, 2006 11:19 AM >> To: Thomas Diesler >> Cc: QA; Adrian Brock; jboss-development >> Subject: [JBoss-dev] RE: JBossRetro, JBossWS and JDK1.4 >> >> Thomas, >> >> I noticed that you have tags for JBOSSWS_1_0_* but not specifically >> for JBossWS14. So do the versions for jbossws14 in the repository >> correspond to the JBOSSWS_1_0_* tags? >> >> http://repository.jboss.com/jboss/jbossws14/ >> >> I was planning on creating a JBossWS14_1_0_0_CR3, but I see >you have a >> JBOSSWS_1_0_RC3. >> >> What is the relationship between jbossws releases to >jbossws14 releases? >> > > --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: repository.jboss.com checkout problem
FYI, svn is much better about this. It does not distinguish between txt and binary (i.e. it does not rewrite CR/LF) and uses a binary diff algorithm http://svnbook.red-bean.com/nightly/en/svn.forcvs.binary-and-trans.html xxx Thomas Diesler Web Service Lead JBoss Inc. xxx >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On >Behalf Of Jason T. Greene >Sent: Saturday, March 18, 2006 20:04 >To: Dimitris Andreadis; >jboss-development@lists.sourceforge.net; Anil Saldhana >Cc: QA >Subject: RE: [JBoss-dev] Re: repository.jboss.com checkout problem > >It uses one gigantic RCS file with markers to distinguish the versions. >So if you have 10 updates to a 100 meg file, you get a gig >file. So don't ever store iso files in CVS :) > >-Jason > >> -Original Message- >> From: Dimitris Andreadis >> Sent: Saturday, March 18, 2006 2:59 AM >> To: Jason T. Greene; 'jboss-development@lists.sourceforge.net'; Anil >> Saldhana >> Cc: QA >> Subject: RE: [JBoss-dev] Re: repository.jboss.com checkout problem >> >> >> Jason, for every binary file, does it make a new physical file, or is >it >> one big file with some sort of marking to distinguish the >entries? CVS >is >> really bad with binaries, more so big ones... >> >> > -Original Message- >> > From: Jason T. Greene >> > Sent: 18 March, 2006 08:16 >> > To: jboss-development@lists.sourceforge.net; Anil Saldhana >> > Cc: QA >> > Subject: RE: [JBoss-dev] Re: repository.jboss.com checkout problem >> > >> > Cvs doesn't actually have a diff algorithm for binary >files, what it >> > does is store an entire copy for every single change and branch >> > point in the same file. >> > >> > When we move to subversion this problem goes away because >it uses a >> > binary diff algorithm, reducing storage and network overhead. >> > >> > -Jason >> > >> > > -Original Message- >> > > From: [EMAIL PROTECTED] >[mailto:jboss- >> > > [EMAIL PROTECTED] On Behalf Of >Adrian Brock >> > > Sent: Friday, March 17, 2006 12:42 PM >> > > To: Anil Saldhana >> > > Cc: jboss-development; QA >> > > Subject: [JBoss-dev] Re: repository.jboss.com checkout problem >> > > >> > > On Fri, 2006-03-17 at 11:51 -0600, Anil Saldhana wrote: >> > > > Adrian Brock wrote: >> > > > >> > > > >Anybody else having problems checking out from cvs? >> > > > > >> > > > >It is getting stuck here: >> > > > >cvs update: Updating eclipse/sdk/3.1.1 U >> > > > >eclipse/sdk/3.1.1/eclipse-SDK-3.1.1-linux-gtk.tar.gz >> > > > > >> > > > >I tried cancelling it and restarting, but it still gets stuck? >> > > > > >> > > > > >> > > > Doesn't CVS do diffs on the server and need to have >> > atleast 10 times >> > > > RAM the size of the file? >> > > >> > > It looks like this is correct, it has got past eclipse now. >> > > It definitely stalled at one point though, unless 2 hours >> > is typical >> > > to download eclipse? :-) >> > > -- >> > > >> > > Adrian Brock >> > > Chief Scientist >> > > JBoss Inc. >> > > >> > > >> > > >> > > >> > > --- >> > > This SF.Net email is sponsored by xPML, a groundbreaking >scripting >> > > language that extends applications into web and mobile >> > media. Attend >> > > the live webcast and join the prime developer group >> > breaking into this >> > > new coding territory! >> > > >> > >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=1216 >> > > 42 ___ >> > > JBoss-Development mailing list >> > > JBoss-Development@lists.sourceforge.net >> > > https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > >--- >This SF.Net email is sponsored by xPML, a groundbreaking >scripting language that extends applications into web and >mobile media. Attend the live webcast and join the prime >developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 >___ >JBoss-Development mailing list >JBoss-Development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Synching up on webservice/retro tasks for
This should be fixed. xxx Thomas Diesler Web Service Lead JBoss Inc. xxx >-Original Message- >From: Ryan Campbell >Sent: Thursday, March 16, 2006 00:55 >To: Jason T. Greene; 'Thomas Diesler' >Cc: 'jboss-development@lists.sourceforge.net' >Subject: RE: Synching up on webservice/retro tasks for > >I see that Thomas actually fixed these a few hours ago. I've >forced a cruisecontrol run to see where we actually are. > >-Original Message- >From: Ryan Campbell >Sent: Wednesday, March 15, 2006 5:27 PM >To: Jason T. Greene; 'Thomas Diesler' >Cc: 'jboss-development@lists.sourceforge.net' >Subject: RE: Synching up on webservice/retro tasks for > > >The webservices tests in the head testsuite are failing. >Testing a retrotranslated jbossws14.sar in jboss-4.0/testsuite >produces the same errors. Can someone from the WS team look at this? > > --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: WebServices in the 3.2.8 compatibility testsuite
> I would say if you QA to test WebService between different versions at any > time, you will need to provide a compatible testsuite. Lets talk about this in vegas - if you are there. > -Original Message- > From: Clebert Suconic > Sent: 06 February 2006 21:48 > To: Thomas Diesler > Cc: Scott M Stark; '[EMAIL PROTECTED]' > Subject: RE: WebServices in the 3.2.8 compatibility testsuite > > Okay... > > At this point my understanding is it's not needed to perform compatibility > tests with WebServices. > > I would say if you QA to test WebService between different versions at any > time, you will need to provide a compatible testsuite. > > > Clebert > > -Original Message- > From: Thomas Diesler > Sent: Monday, February 06, 2006 2:41 PM > To: Clebert Suconic > Cc: Scott M Stark; [EMAIL PROTECTED] > Subject: RE: WebServices in the 3.2.8 compatibility testsuite > > Hi Clebert, > > see attached my earlier response. With web service, the endpoint and the > client are fundamentally detached (i.e. the server side endpoint does not > care what technology put the message on the wire) > > All of our WS tests currently deploy the endpoint and the client to the > same box - this is not very sensible. Similar to a J2EE-1.4 application > client, the client should be deployed to a separate box (that may run a > different jboss version) > > If you look at testsuite/output/lib you see jars like ws4ee-sometest.jar + > ws4ee-sometest-client.jar > > Form JBossTest, both jars should be deployable to different jboss > versions. This is currently not possible. > > Please create a JIRA issue for this requirement that equally applies to > all tests where the client does a jndi lookup - it should not use the jndi > tree from the server if you want to test compatibility. > > Cheers > -thomas > > > -Original Message- > > From: Clebert Suconic > > Sent: 06 February 2006 16:29 > > To: Thomas Diesler > > Subject: FW: WebServices in the 3.2.8 compatibility testsuite > > > > Hey Thomas... > > > > I don't know if you saw that e-mail. > > > > We still need to know if there are client libraries that need to be > > validated. > > > > Or if we don't need to validate client libraries, if it's required to > > validate any sort of protocol in between versions. (3.2.x vs previous, > > 4.0.x vs previous). > > > > It seems that you said that 3.2.x it's not needed even within previous > > version of 3.2.x, but what about 4.0.x withing previous prevsions. > > > > Please, copy QA in your answer. > > > > Thanks > > > > > > Clebert > > > > -Original Message- > > From: Clebert Suconic > > Sent: Friday, February 03, 2006 11:20 AM > > To: Thomas Diesler > > Cc: QA; Dimitris Andreadis; Scott M Stark; Ryan Campbell > > Subject: RE: WebServices in the 3.2.8 compatibility testsuite > > > > >For QA: Generally web service client deployments should be disconnected > > from web service endpoint deployments. Currently an application client > is > > deployed on the same host as the webservice endpoint - this is strictly > > speaking incorrect. > > > > We know what a webservice is (that is a disconnected service endpoint), > > but we need to know if there are client libraries that might need to be > > required on WebService clients. > > > > You already answered our question about if we need interoperability > > between 3.2.x and 4.0.x, but you didn't answer what tests we need (or > even > > if we have to) to execute to guarantee interoperability between 4.0.x > and > > previous versions of 4. > > > > > > -Original Message- > > From: Thomas Diesler > > Sent: Friday, February 03, 2006 7:20 AM > > To: Dimitris Andreadis; Scott M Stark; Ryan Campbell; Clebert Suconic > > Cc: QA > > Subject: RE: WebServices in the 3.2.8 compatibility testsuite > > > > Hi Dimitris, > > > > There is no need to test interoperability between 3.2.x and 4.0.x web > > services . With jboss 4.0.x we have J2EE-1.4 compliant web services that > > did not exist prior to jboss-4.0.0. The Jboss.Net implementation is > > shipped with jboss-4.0.x as an optional module in docs/examples. If > > customers really choose to install Jboss.NET on jboss-4.0.x (what we > > discourage them from doing so) and they really run into interop issues > > with jboss-3.2.x, we will be dealing with those on a case by case basis. > > > > For QA: Generally web service clien
[JBoss-dev] RE: Restore DeploymentRolesLoginModule
> Why the
DeploymentRolesLoginModule has to be in this login-config.xml section is the
question.
Ok, I 'll find out for my sections.
From: Scott M Stark Sent: Monday,
January 30, 2006 14:26To: Thomas DieslerCc:
'jboss-development@lists.sourceforge.net'Subject: RE: Restore
DeploymentRolesLoginModule
As we talked about
when going through the cts originally, I view the deployment descriptor roles
as useful only for run-as behavior. Every other security deployment needs to
use the security domain configuration mechanism. We do not need to be
dynamically generating this info on a deployment basis from the proprietary
sun descriptor. The user to role mappings are defined up front in the cts
guide. I would guess this should just work using the existing
UserRolesLoginModule and the cts security-domain with its associated
cts-users.properties/cts-roles.properties. Why the DeploymentRolesLoginModule
has to be in this login-config.xml section is the
question.
From: Thomas
Diesler Sent: Monday,
January 30, 2006 5:17 AMTo:
Scott M StarkCc:
'jboss-development@lists.sourceforge.net'Subject: RE: Restore
DeploymentRolesLoginModule
For this to be tested the
DeploymentRolesLoginModule needs to be removed from login-config.xml in the
cts configuration. I had ~70 tests failing in module jaxrpc/webservice
because of ClassNotFoundException.
How do you suggest
to handle the role/principal mapping in sun-ejb-jar.xml if not through
in jboss.xml?
Is there a way to
pickup that mapping from jboss.xml other than through
the DeploymentRolesLoginModule?
I assume you want to
keep that functionality in jboss_4_0.dtd.
-thomas
From: Scott
M Stark Sent: Monday,
January 30, 2006 14:03To:
Thomas DieslerCc:
'jboss-development@lists.sourceforge.net'Subject: RE: Restore
DeploymentRolesLoginModule
This does not mean
this is where we need to be picking up these roles from. Create a jira issue
with the failing tests as I really thought I had eliminated the need for the
DeploymentRolesLoginModule when I last when through the security portion of
the cts.
From:
Thomas Diesler Sent:
Monday, January 30, 2006 4:52 AMTo: Scott M StarkCc: 'jboss-development@lists.sourceforge.net'Subject: RE: Restore
DeploymentRolesLoginModule
There are
various tests that define a role mapping in sun-ejb-jar.xml. These roles are
mapped to jboss.xml like this
A search
found 98 sun-ejb-jar.xml files with that mapping.
xxxThomas
DieslerWeb Service LeadJBoss
Inc.xxx
From:
Scott M Stark Sent:
Monday, January 30, 2006 13:43To: Thomas DieslerCc: 'jboss-development@lists.sourceforge.net'Subject: RE: Restore
DeploymentRolesLoginModule
What tests depend
on this login module? As I remember only the run-as capability needed to
augment the roles and this does not require a login module to do
this.
From:
Thomas Diesler Sent:
Monday, January 30, 2006 4:16 AMTo: Scott M StarkCc: 'jboss-development@lists.sourceforge.net'Subject: RE: Restore
DeploymentRolesLoginModule
I did not
realize the server module now depends on security. I rolled back the
module dependency and try to refactor such that DeploymentRolesLoginModule does
not depend on server meta data
From:
Thomas Diesler Sent:
Monday, January 30, 2006 11:18To: Scott M StarkCc: 'jboss-development@lists.sourceforge.net'Subject: Restore
DeploymentRolesLoginModule
Scott,
I
restored the DeploymentRolesLoginModule and its associated dependency to
the server module because various CTS tests depend on this login
module.
The
comment now reads:
/**
*
The DeploymentRolesLoginModule adds the roles to the subject that were
declared in the
*
assembly-descriptor element in jboss.xml.
*
*
*
*
*
*
*
*
*
This allows dynamic role assignment to a given principal per EJB jar
[JBoss-dev] RE: Restore DeploymentRolesLoginModule
For this to be tested the DeploymentRolesLoginModule needs to
be removed from login-config.xml in the cts configuration. I had ~70 tests
failing in module jaxrpc/webservice because of ClassNotFoundException.
How do you suggest to handle the role/principal mapping
in sun-ejb-jar.xml if not through
in jboss.xml?
Is there a way to pickup that mapping from jboss.xml other than
through the DeploymentRolesLoginModule?
I assume you want to keep that functionality in
jboss_4_0.dtd.
-thomas
From: Scott M Stark Sent: Monday,
January 30, 2006 14:03To: Thomas DieslerCc:
'jboss-development@lists.sourceforge.net'Subject: RE: Restore
DeploymentRolesLoginModule
This does not mean
this is where we need to be picking up these roles from. Create a jira issue
with the failing tests as I really thought I had eliminated the need for the
DeploymentRolesLoginModule when I last when through the security portion of
the cts.
From: Thomas
Diesler Sent: Monday,
January 30, 2006 4:52 AMTo:
Scott M StarkCc:
'jboss-development@lists.sourceforge.net'Subject: RE: Restore
DeploymentRolesLoginModule
There are
various tests that define a role mapping in sun-ejb-jar.xml. These roles are
mapped to jboss.xml like this
A search
found 98 sun-ejb-jar.xml files with that mapping.
xxxThomas
DieslerWeb Service LeadJBoss
Inc.xxx
From: Scott
M Stark Sent: Monday,
January 30, 2006 13:43To:
Thomas DieslerCc:
'jboss-development@lists.sourceforge.net'Subject: RE: Restore
DeploymentRolesLoginModule
What tests depend
on this login module? As I remember only the run-as capability needed to
augment the roles and this does not require a login module to do
this.
From:
Thomas Diesler Sent:
Monday, January 30, 2006 4:16 AMTo: Scott M StarkCc: 'jboss-development@lists.sourceforge.net'Subject: RE: Restore
DeploymentRolesLoginModule
I did not
realize the server module now depends on security. I rolled back the module
dependency and try to refactor such that DeploymentRolesLoginModule does
not depend on server meta data
From:
Thomas Diesler Sent:
Monday, January 30, 2006 11:18To: Scott M StarkCc: 'jboss-development@lists.sourceforge.net'Subject: Restore
DeploymentRolesLoginModule
Scott,
I
restored the DeploymentRolesLoginModule and its associated dependency to
the server module because various CTS tests depend on this login
module.
The
comment now reads:
/**
*
The DeploymentRolesLoginModule adds the roles to the subject that were
declared in the
*
assembly-descriptor element in jboss.xml.
*
*
*
*
*
*
*
*
*
This allows dynamic role assignment to a given principal per EJB jar
deployment.
*
Used by EJB jar deployments in the CTS.
Cheers
-thomas
Revision : 1.1.6.2
Date : 2006/1/14
6:38:48
Author : 'starksm'
State : 'dead'
Lines : +2 -2
Description
:
Remove
the unsupported/documented
DeploymentRolesLoginModule
Revision : 1.51.2.10
Date : 2006/1/14
6:50:56
Author : 'starksm'
State : 'Exp'
Lines : +1 -5
Description
:
JBAS-2359,
refactor security classes out of the server module to security
module
[JBoss-dev] RE: Restore DeploymentRolesLoginModule
There are various tests that define a role mapping in
sun-ejb-jar.xml. These roles are mapped to jboss.xml like
this
A search found 98 sun-ejb-jar.xml files with that mapping.
xxxThomas DieslerWeb Service LeadJBoss
Inc.xxx
From: Scott M Stark Sent: Monday,
January 30, 2006 13:43To: Thomas DieslerCc:
'jboss-development@lists.sourceforge.net'Subject: RE: Restore
DeploymentRolesLoginModule
What tests depend on
this login module? As I remember only the run-as capability needed to augment
the roles and this does not require a login module to do
this.
From: Thomas
Diesler Sent: Monday,
January 30, 2006 4:16 AMTo:
Scott M StarkCc:
'jboss-development@lists.sourceforge.net'Subject: RE: Restore
DeploymentRolesLoginModule
I did not
realize the server module now depends on security. I rolled back the module
dependency and try to refactor such that DeploymentRolesLoginModule does
not depend on server meta data
From:
Thomas Diesler Sent:
Monday, January 30, 2006 11:18To: Scott M StarkCc: 'jboss-development@lists.sourceforge.net'Subject: Restore
DeploymentRolesLoginModule
Scott,
I restored
the DeploymentRolesLoginModule and its associated dependency to the server
module because various CTS tests depend on this login
module.
The comment
now reads:
/**
* The
DeploymentRolesLoginModule adds the roles to the subject that were declared
in the
*
assembly-descriptor element in jboss.xml.
*
*
*
*
*
*
*
*
*
This allows dynamic role assignment to a given principal per EJB jar
deployment.
*
Used by EJB jar deployments in the CTS.
Cheers
-thomas
Revision : 1.1.6.2
Date : 2006/1/14
6:38:48
Author : 'starksm'
State : 'dead'
Lines : +2 -2
Description
:
Remove the
unsupported/documented
DeploymentRolesLoginModule
Revision : 1.51.2.10
Date : 2006/1/14
6:50:56
Author : 'starksm'
State : 'Exp'
Lines : +1 -5
Description
:
JBAS-2359,
refactor security classes out of the server module to security
module
[JBoss-dev] RE: Restore DeploymentRolesLoginModule
I did not realize the server module now depends on security. I rolled back the module dependency and try to refactor such that DeploymentRolesLoginModule does not depend on server meta data From: Thomas Diesler Sent: Monday, January 30, 2006 11:18To: Scott M StarkCc: 'jboss-development@lists.sourceforge.net'Subject: Restore DeploymentRolesLoginModule Scott, I restored the DeploymentRolesLoginModule and its associated dependency to the server module because various CTS tests depend on this login module. The comment now reads: /** * The DeploymentRolesLoginModule adds the roles to the subject that were declared in the * assembly-descriptor element in jboss.xml. * * * * * * * * * This allows dynamic role assignment to a given principal per EJB jar deployment. * Used by EJB jar deployments in the CTS. Cheers -thomas Revision : 1.1.6.2 Date : 2006/1/14 6:38:48 Author : 'starksm' State : 'dead' Lines : +2 -2 Description : Remove the unsupported/documented DeploymentRolesLoginModule Revision : 1.51.2.10 Date : 2006/1/14 6:50:56 Author : 'starksm' State : 'Exp' Lines : +1 -5 Description : JBAS-2359, refactor security classes out of the server module to security module
[JBoss-dev] Restore DeploymentRolesLoginModule
Scott, I restored the DeploymentRolesLoginModule and its associated dependency to the server module because various CTS tests depend on this login module. The comment now reads: /** * The DeploymentRolesLoginModule adds the roles to the subject that were declared in the * assembly-descriptor element in jboss.xml. * * * * * * * * * This allows dynamic role assignment to a given principal per EJB jar deployment. * Used by EJB jar deployments in the CTS. Cheers -thomas Revision : 1.1.6.2 Date : 2006/1/14 6:38:48 Author : 'starksm' State : 'dead' Lines : +2 -2 Description : Remove the unsupported/documented DeploymentRolesLoginModule Revision : 1.51.2.10 Date : 2006/1/14 6:50:56 Author : 'starksm' State : 'Exp' Lines : +1 -5 Description : JBAS-2359, refactor security classes out of the server module to security module
[JBoss-dev] J2EE-1.4 signature tests
There are still some J2EE-1.4 signature test failures. javax.ejb is due to some added methods from the EJB3 API. Javax.mail I did not investigate. javax.xml.namespace is due to equals(), hashCode() being added to QName, which is IMO a test challenge rather than a bug in our public API Generally the signature tests only give sufficient feedback for the first couple of classes. Further down I could not find a way to find out what the test is complaining about other than recompiling the test with a modified package list Also have a look at jboss-4.0.x/j2ee/j2ee-check.sh Cheers -thomas Some signatures failed. Failed packages listed below: javax.ejb javax.mail javax.xml.namespace Passed packages listed below: javax.ejb.spi javax.jms javax.mail.event javax.mail.internet javax.mail.search javax.activation javax.xml.rpc javax.xml.rpc.encoding javax.xml.rpc.handler javax.xml.rpc.handler.soap javax.xml.rpc.holders javax.xml.rpc.server javax.xml.rpc.soap javax.xml.soap javax.xml.registry javax.xml.registry.infomodel javax.management.j2ee javax.management.j2ee.statistics javax.management javax.management.loading javax.management.modelmbean javax.management.monitor javax.management.openmbean javax.management.relation javax.management.timer javax.security.jacc
RE: [JBoss-dev] RE: Sync xml tests with HEAD for use with jboss-xml-binding.jar
Alex, Is there a benefit of duplicating jbossxb tests in 4.0.x when we use the binary drop? If they are not testing integration issues the most appropriate fix might simply be removing the test from the 4.0.x testsuite. Cheers -thomas >-Original Message- >From: Scott M Stark >Sent: Wednesday, January 11, 2006 03:46 >To: jboss-development@lists.sourceforge.net; Thomas Diesler; >Alexey Loubyansky >Subject: RE: [JBoss-dev] RE: Sync xml tests with HEAD for use >with jboss-xml-binding.jar > > >One incompatibility is the change of the SchemaBindingResolver >method from: > >SchemaBinding resolve(String nsUri, String localName, String >baseURI, String schemaLocation) > >to: > >SchemaBinding resolve(String nsUri, String baseURI, String >schemaLocation) > >I suppose this is a minor issue as this is only showing up in >a anonymous testcase specific implementation. > > classname="org.jboss.test.xml.MBeanServerUnitTestCase" >name="testMbeanService" time="1.641"> >type="org.jboss.xb.binding.JBossXBException">org.jboss.xb.bindi >ng.JBossXBException: Failed to parse source > at >org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBoss >XBParser.java:138) > at >org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImp >l.java:129) > at >org.jboss.test.xml.MBeanServerUnitTestCase.testMbeanService(MBe >anServerUnitTestCase.java:135) >Caused by: java.lang.UnsupportedOperationException: >resolve(String,String,String) was not required in 4.0.3 > at >org.jboss.test.xml.MBeanServerUnitTestCase$1.resolve(MBeanServe >rUnitTestCase.java:124) > at >org.jboss.xb.binding.sunday.unmarshalling.WildcardBinding.getEl >ement(WildcardBinding.java:84) > > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: JBossWS-1.0RC1 release works in 4.0.x
This can also been found in the repository under jboss/jbossws-1.0RC1 We have: jbossws14.sar jbossws14-client.jar for jdk-1.4 jbossws.sar jbossws-client.sar for jdk-1.5 respectivly cheers -thomas From: Scott M Stark Sent: 10 January 2006 20:49 To: Thomas Diesler; Dev - JBossWS; Alexey Loubyansky; Jason T. Greene; Sacha Labourey; Ivelin Ivanov Cc: 'jboss-development@lists.sourceforge.net' Subject: RE: JBossWS-1.0RC1 release works in 4.0.x We also need a jdk5 compiled version under a different version for inclusion in profiles like ejb3 that require jdk5, and for users that run with jdk5. http://jira.jboss.com/jira/browse/JBAS-2645 From: Thomas Diesler Sent: Tuesday, January 10, 2006 5:57 AM To: Dev - JBossWS; Alexey Loubyansky; Scott M Stark; Jason T. Greene; Sacha Labourey; Ivelin Ivanov Cc: jboss-development@lists.sourceforge.net Subject: JBossWS-1.0RC1 release works in 4.0.x Hi folks, I completed the work arround using retrotranslator. The good news first --- The new web service stack can be used in 4.0.x without known limitations. This will give cutomers ws-security, ws-addressing, ws-eventing, jsr-181 annotations, ejb3 endpoints, etc. Here is what I did and what the current situation is: - The repository now contains retrotranslator-0.9.6jboss, which contains an obfuscated version of asm-3.0_beta in retrotranslator-runtime.jar - Minor modification to JBossWS code base that showed up at runtime - new IllegalStateException(String,Throwable) not supported by retrotranslator - JBossXB moved out of jboss-common.jar into jboss-xml-binding.jar, which is available in the repository (jboss/jbossxb/1.0.RC1) - Disabled usage of xml binding sources in 4.0.x - use the binary from the repository instead - Minor modifications to the 4.0.x codebase (common/security module) to use jboss-xml-binding.jar from the repository - Sync xml testsuite from HEAD to Branch_4_0 The retrotranslated version of jbossws can be build like this: cd /jboss-head/webservice ant -Dretro=true In 4.0.x it can be deployed like this: cd /jboss-4.0.x/webservice ant deploy-jbossws14 The ws4ee testsuite runs without failure. Verification work needs to be done that jboss-xml-binding.jar from the repository can be used by all modules in 4.0.x The CTS tests need to be run agains retrotranslated jbossws. A small number of issues still need to be resolved for jbossws-1.0 final. cheers -thomas
[JBoss-dev] RE: Sync xml tests with HEAD for use with jboss-xml-binding.jar
The snapshot version is a placeholder for itermediary versions. 1.0RC1 is the now verified version that passes all webservice tests in 4.0.x. I'm happy with whatever solution you can provide that allows jbossws-1.0 to be used with the upcomming 4.0.4 release. This is necessary to provide our customers with the WS functionality that we prommised to deliver by the end of last year. What I provided is a possible solution for projects that depend on xml binding to be backportable to 4.0.x I don't expect this solution to be final. Please drive the discussion arround jbossxb binary usage further from here. Cheer -thomas >-Original Message- >From: Alexey Loubyansky >Sent: Tuesday, January 10, 2006 14:53 >To: Thomas Diesler >Cc: Scott M Stark; jboss-development@lists.sourceforge.net >Subject: Re: Sync xml tests with HEAD for use with >jboss-xml-binding.jar > >So, after Scott said we can't have 'snapshot' you renamed >snapshot to RC1? I don't think this is what the problem was... >Thomas, I think, you are going to fast w/o decisions made on >forums or dev list. This way you may create more problems than solve. > >You did start the discussion >http://www.jboss.com/index.html?module=bb&op=viewtopic&p=391243 >8#3912438 > >but there was no decision on how it should be done. If you >want it be like remoting then, I thought, at least a separate >project/module should have been created for jbossxb first. > >Thomas Diesler wrote: >> I would prefer you to maintain a single jbossxb version in HEAD with >> known binary drops in the repository that are then beeing >used in 4.0.x. >> Otherwise I have little confidence that we will get retrotranslated >> versions of projects that depend on jbossxb (like JBossWS) >working in >> 4.0.x >> >> Currently, the build of module common in 4.0.x does not use the >> sources xml binding. >> >> IMHO, it'd be better to allocate the already scarce >resources towards >> a binary solution drop like we have with remoting. >> The impact for customers should be minimal. >> >> xxx >> Thomas Diesler >> Web Service Lead >> JBoss Inc. >> xxx >> >> >> >>>-Original Message- >>>From: Alexey Loubyansky >>>Sent: Monday, January 09, 2006 11:27 >>>To: Thomas Diesler >>>Cc: jboss-development@lists.sourceforge.net >>>Subject: Sync xml tests with HEAD for use with jboss-xml-binding.jar >>> >>>Thomas, >>> >>>as I understood Scott we don't want to update jbossxb users in >>>jboss-4.x to use jbossxb from HEAD. The tests are supposed >to reflect >>>the api and functionality used. So, I don't think the tests >from HEAD >>>should be backported to branch 4. >>> >>>alex >>> >> >> > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBossWS-1.0RC1 release works in 4.0.x
Hi folks, I completed the work arround using retrotranslator. The good news first --- The new web service stack can be used in 4.0.x without known limitations. This will give cutomers ws-security, ws-addressing, ws-eventing, jsr-181 annotations, ejb3 endpoints, etc. Here is what I did and what the current situation is: - The repository now contains retrotranslator-0.9.6jboss, which contains an obfuscated version of asm-3.0_beta in retrotranslator-runtime.jar - Minor modification to JBossWS code base that showed up at runtime - new IllegalStateException(String,Throwable) not supported by retrotranslator - JBossXB moved out of jboss-common.jar into jboss-xml-binding.jar, which is available in the repository (jboss/jbossxb/1.0.RC1) - Disabled usage of xml binding sources in 4.0.x - use the binary from the repository instead - Minor modifications to the 4.0.x codebase (common/security module) to use jboss-xml-binding.jar from the repository - Sync xml testsuite from HEAD to Branch_4_0 The retrotranslated version of jbossws can be build like this: cd /jboss-head/webservice ant -Dretro=true In 4.0.x it can be deployed like this: cd /jboss-4.0.x/webservice ant deploy-jbossws14 The ws4ee testsuite runs without failure. Verification work needs to be done that jboss-xml-binding.jar from the repository can be used by all modules in 4.0.x The CTS tests need to be run agains retrotranslated jbossws. A small number of issues still need to be resolved for jbossws-1.0 final. cheers -thomas
[JBoss-dev] RE: Sync xml tests with HEAD for use with jboss-xml-binding.jar
I would prefer you to maintain a single jbossxb version in HEAD with known binary drops in the repository that are then beeing used in 4.0.x. Otherwise I have little confidence that we will get retrotranslated versions of projects that depend on jbossxb (like JBossWS) working in 4.0.x Currently, the build of module common in 4.0.x does not use the sources xml binding. IMHO, it'd be better to allocate the already scarce resources towards a binary solution drop like we have with remoting. The impact for customers should be minimal. xxx Thomas Diesler Web Service Lead JBoss Inc. xxx >-Original Message- >From: Alexey Loubyansky >Sent: Monday, January 09, 2006 11:27 >To: Thomas Diesler >Cc: jboss-development@lists.sourceforge.net >Subject: Sync xml tests with HEAD for use with jboss-xml-binding.jar > >Thomas, > >as I understood Scott we don't want to update jbossxb users in >jboss-4.x to use jbossxb from HEAD. The tests are supposed to >reflect the api and functionality used. So, I don't think the >tests from HEAD should be backported to branch 4. > >alex > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Webservice/test failures (Cglib ASM incompatibility)
This is fixed. The cglib code that you introduced in jbossws has a dependency on asm-1.5.3, wchich is not compatible with asm-3.0_beta used by the retrotranslator. Other modules have similar dependency. I now bundle an obfuscated version of asm-3.0_beta with the retrotranslator-0.9.6jboss.jar BTW, the retrotranslated jbossws14.sar now runs in 4.0.x with jdk-1.4 without failure. xxx Thomas Diesler Web Service Lead JBoss Inc. xxx >-Original Message- >From: Jason T. Greene >Sent: Monday, January 09, 2006 06:38 >To: Dev - JBossWS >Subject: Webservice/test failures (Cglib ASM incompatibility) > >FYI, There was an update to ASM 3.0-beta in jboss-head that >breaks cglib. So, currently the jsr181 tests, and some tools >tests are failing. I will take a look at it tomorrow morning. > >-Jason > > >Jason T. Greene >Developer - Web Services >JBoss Inc. > > > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [jboss-cvs] repository.jboss.com/hibernate/3.1 ...
Ok, I restored compatiblity to asm-1.5.3. If hibernate is incompatible with asm-3.0_beta things will become compilicated. xxx Thomas Diesler Web Service Lead JBoss Inc. xxx >-Original Message- >From: Scott M Stark >Sent: Friday, January 06, 2006 20:09 >To: Thomas Diesler; jboss-development@lists.sourceforge.net >Subject: RE: [jboss-cvs] repository.jboss.com/hibernate/3.1 ... > >A component should be compatible with multiple versions, not >just the latest as this will break other uses of hibernate >that cannot use asm-3.0_beta. For example, from the tomcat >5.5.9 component-info.xml: > > > > > > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Thomas Diesler >> Sent: Friday, January 06, 2006 7:59 AM >> To: [EMAIL PROTECTED] >> Subject: [jboss-cvs] repository.jboss.com/hibernate/3.1 ... >> >> User: tdiesler >> Date: 06/01/06 10:58:54 >> >> Modified:hibernate/3.1 component-info.xml >> Log: >> Update to asm-3.0_beta >> >> Revision ChangesPath >> 1.2 +1 -1 >> repository.jboss.com/hibernate/3.1/component-info.xml >> >> (In the diff below, changes in quantity of whitespace are not >> shown.) >> >> Index: component-info.xml >> === >> RCS file: >> >/cvsroot/jboss/repository.jboss.com/hibernate/3.1/component-info.xml,v >> retrieving revision 1.1 >> retrieving revision 1.2 >> diff -u -b -r1.1 -r1.2 >> --- component-info.xml 16 Dec 2005 02:16:38 - 1.1 >> +++ component-info.xml 6 Jan 2006 15:58:54 - 1.2 >> @@ -8,7 +8,7 @@ >> >> >> >> - >> + >> >> >> > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] HyperJAXB
Hi Alex, Gavin Jason pointed this out to me? You where talking about persisting XML at JBossWorld https://hyperjaxb.dev.java.net/? Cheers -thomas PS: Alex, maybe you want to be on the JAXB-2.0 EG
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1675) Integrate Critical CTS bug fixes
[ http://jira.jboss.com/jira/browse/JBAS-1675?page=history ] Thomas Diesler updated JBAS-1675: - Description: This issue links to the outstanding JBCTS project issues that need to be included into JBAS 4.0.2. (was: This issue links to the outstanding JBWS project issues that need to be included into JBAS 4.0.2.) > Integrate Critical CTS bug fixes > > > Key: JBAS-1675 > URL: http://jira.jboss.com/jira/browse/JBAS-1675 > Project: JBoss Application Server > Type: Bug > Components: Web Services service > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Priority: Critical > Fix For: JBossAS-4.0.2 Final > > > This issue links to the outstanding JBCTS project issues that need to be > included into JBAS 4.0.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1675) Integrate Critical CTS bug fixes
Integrate Critical CTS bug fixes Key: JBAS-1675 URL: http://jira.jboss.com/jira/browse/JBAS-1675 Project: JBoss Application Server Type: Bug Components: Web Services service Reporter: Thomas Diesler Assigned to: Thomas Diesler Priority: Critical Fix For: JBossAS-4.0.2 Final This issue links to the outstanding JBWS project issues that need to be included into JBAS 4.0.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1674) web-console depends on UseJBossWebLoader=true
[ http://jira.jboss.com/jira/browse/JBAS-1674?page=history ] Thomas Diesler updated JBAS-1674: - Summary: web-console depends on UseJBossWebLoader=true (was: web-console depends on UseJBossWebLoader) > web-console depends on UseJBossWebLoader=true > - > > Key: JBAS-1674 > URL: http://jira.jboss.com/jira/browse/JBAS-1674 > Project: JBoss Application Server > Type: Bug > Components: Management Service > Versions: JBossAS-4.0.2RC1 > Reporter: Thomas Diesler > > > with the CTS configuration, I get: > 10:27:46,515 ERROR [[/web-console]] Servlet /web-console threw load() > exception > java.lang.ClassNotFoundException: > org.jboss.console.plugins.monitor.CreateSnapshotServlet > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1332) > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181) > web-console.war/WEB-INF/web.xml contains > > Create Snapshot > > org.jboss.console.plugins.monitor.CreateSnapshotServlet > 1 > > The class lives in jboss-console.jar, which is not deployed anywhere. > With true as it is configured > in > the default configuration all works fine, but jboss-console.jar is not > deployed either -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1674) web-console depends on UseJBossWebLoader
web-console depends on UseJBossWebLoader Key: JBAS-1674 URL: http://jira.jboss.com/jira/browse/JBAS-1674 Project: JBoss Application Server Type: Bug Components: Management Service Versions: JBossAS-4.0.2RC1 Reporter: Thomas Diesler with the CTS configuration, I get: 10:27:46,515 ERROR [[/web-console]] Servlet /web-console threw load() exception java.lang.ClassNotFoundException: org.jboss.console.plugins.monitor.CreateSnapshotServlet at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1332) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181) web-console.war/WEB-INF/web.xml contains Create Snapshot org.jboss.console.plugins.monitor.CreateSnapshotServlet 1 The class lives in jboss-console.jar, which is not deployed anywhere. With true as it is configured in the default configuration all works fine, but jboss-console.jar is not deployed either -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Reopened: (JBAS-1639) Integrate Critical JBWS bug fixes
[ http://jira.jboss.com/jira/browse/JBAS-1639?page=history ] Thomas Diesler reopened JBAS-1639: -- Final CTS testrun is missing > Integrate Critical JBWS bug fixes > - > > Key: JBAS-1639 > URL: http://jira.jboss.com/jira/browse/JBAS-1639 > Project: JBoss Application Server > Type: Bug > Components: Web Services service > Reporter: Scott M Stark > Assignee: Thomas Diesler > Priority: Critical > Fix For: JBossAS-4.0.2 Final > > > This issue links to the outstanding JBWS project issues that need to be > included into JBAS 4.0.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1478) Move axis-ws4ee to package org.jboss.org.apache.axis
[ http://jira.jboss.com/jira/browse/JBAS-1478?page=history ] Thomas Diesler resolved JBAS-1478: -- Resolution: Done Moved to org.jboss.axis > Move axis-ws4ee to package org.jboss.org.apache.axis > > > Key: JBAS-1478 > URL: http://jira.jboss.com/jira/browse/JBAS-1478 > Project: JBoss Application Server > Type: Task > Components: Web Services service > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-35) Servlet Invoker - counterpart to HTTP Invoker (runs within web container)
[ http://jira.jboss.com/jira/browse/JBREM-35?page=history ] Thomas Diesler updated JBREM-35: Priority: Optional (was: Minor) Fix Version: 1.2.0 beta (was: 1.0.1 final) It needs to be discussed who this would work with the WS4EE deployment model for JSE. As a reminder, it uses the element to the declare the endpoint implemenation bean. What would be the benefit of running server side JBossWS with a dependency on Remoting rather than Tomcat? > Servlet Invoker - counterpart to HTTP Invoker (runs within web container) > - > > Key: JBREM-35 > URL: http://jira.jboss.com/jira/browse/JBREM-35 > Project: JBoss Remoting > Type: Feature Request > Components: transport > Versions: 1.0.1 beta > Reporter: Tom Elrod > Assignee: Tom Elrod > Priority: Optional > Fix For: 1.2.0 beta > > > Need a servlet invoker that will be the same as the HTTP Invoker (which is > its own web server), but will run inside a web container (such as Tomcat) as > a servlet. Will then process request same as HTTP Invoker after > doPost()/doGet() called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-27) Support for HTTP/HTTPS proxy
[ http://jira.jboss.com/jira/browse/JBREM-27?page=history ] Thomas Diesler updated JBREM-27: Priority: Optional (was: Major) Fix Version: 1.2.0 beta (was: 1.0.1 final) > Support for HTTP/HTTPS proxy > > > Key: JBREM-27 > URL: http://jira.jboss.com/jira/browse/JBREM-27 > Project: JBoss Remoting > Type: Feature Request > Components: transport > Reporter: Thomas Diesler > Assignee: Tom Elrod > Priority: Optional > Fix For: 1.2.0 beta > > > This request showed up on the web services forum. Proxies are currently > suported in axis-ws4ee.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-33) Add GET support within HTTP server invoker
[ http://jira.jboss.com/jira/browse/JBREM-33?page=comments#action_12315647 ] Thomas Diesler commented on JBREM-33: - As far as I can see, we don't need support for GET for JBossWS. > Add GET support within HTTP server invoker > -- > > Key: JBREM-33 > URL: http://jira.jboss.com/jira/browse/JBREM-33 > Project: JBoss Remoting > Type: Task > Components: transport > Versions: 1.0.1 beta > Reporter: Tom Elrod > Assignee: Tom Elrod > Fix For: 1.0.1 final > > > Add support for GET request using HTTP invoker (only supports POST at this > point) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1478) Move axis-ws4ee to package org.jboss.org.apache.axis
[ http://jira.jboss.com/jira/browse/JBAS-1478?page=history ] Thomas Diesler reassigned JBAS-1478: Assign To: Thomas Diesler > Move axis-ws4ee to package org.jboss.org.apache.axis > > > Key: JBAS-1478 > URL: http://jira.jboss.com/jira/browse/JBAS-1478 > Project: JBoss Application Server > Type: Task > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1478) Move axis-ws4ee to package org.jboss.org.apache.axis
Move axis-ws4ee to package org.jboss.org.apache.axis Key: JBAS-1478 URL: http://jira.jboss.com/jira/browse/JBAS-1478 Project: JBoss Application Server Type: Task Reporter: Thomas Diesler Fix For: JBossAS-4.0.2 Final -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-20) Multiple ports wsdl service element
[ http://jira.jboss.com/jira/browse/JBAS-20?page=history ] Thomas Diesler closed JBAS-20: -- Resolution: Won't Fix Invalid, because jboss is not in control of the wsdl that is requested from a WS client. > Multiple ports wsdl service element > --- > > Key: JBAS-20 > URL: http://jira.jboss.com/jira/browse/JBAS-20 > Project: JBoss Application Server > Type: Bug > Components: Web Services service > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > A wsdl can potentially have more than one associated with a wsdl > element. This is ok for a server deployment, which can give give > the port name in webservices.xml. > A client requesting the wsdl from the server, does not have this option in > . We should adjust the returned wsdl such that it only > contatains the port the client was asking for in the ?WSDL request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1235) TimedObject id persistence fails on restart
[ http://jira.jboss.com/jira/browse/JBAS-1235?page=history ] Thomas Diesler resolved JBAS-1235: -- Resolution: Cannot Reproduce Bug I run the PersistenceTestCase ant -Dtest=org.jboss.test.txtimer.test.PersistenceTestCase one-test with a timer duration of 30s. Killed the jboss server process, and restarted jboss-4.0.2beta After restart the timer event is fired. 11:34:33,432 INFO [Server] JBoss (MX MicroKernel) [4.0.2beta (build: CVSTag=Branch_4_0 date=200502041757)] Started in 24s:109ms 11:34:33,557 INFO [TimerEntityBean] ejbTimeout [pk=1,count=1,[EMAIL PROTECTED] timer=[id=1target=[target=jboss.j2ee:jndiName=test/txtimer/TimerEntity,service=EJB,pk=1],remaining=-5484,periode=0,in_time out] > TimedObject id persistence fails on restart > --- > > Key: JBAS-1235 > URL: http://jira.jboss.com/jira/browse/JBAS-1235 > Project: JBoss Application Server > Type: Bug > Components: CMP service > Versions: JBossAS-4.0.0 Final > Reporter: SourceForge User > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > SourceForge Submitter: cstach . > Upon restarting JBoss, persisted timers throw this SQL > exception because it seems that the entity bean that > implements the TimedObject had its primary key (Long) > converted into a byte array. > java.sql.SQLException: Cannot convert class [B to SQL > type requested due to java.lang.ClassCastException - > null > at > com.mysql.jdbc.PreparedStatement.setObject > (PreparedStatement.java:922) > at > com.mysql.jdbc.PreparedStatement.setObject > (PreparedStatement.java:944) > at > org.jboss.resource.adapter.jdbc.WrappedPreparedStatem > ent.setObject(WrappedPreparedStatement.java:615) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCParameterSetter$5.se > tNotNull(JDBCParameterSetter.java:130) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCParameterSetter$JDB > CAbstractParameterSetter.set > (JDBCParameterSetter.java:56) > at > org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFi > eldBridge.setArgumentParameters > (JDBCAbstractCMPFieldBridge.java:354) > at > org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFi > eldBridge.setPrimaryKeyParameters > (JDBCAbstractCMPFieldBridge.java:343) > at > org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge.se > tPrimaryKeyParameters(JDBCEntityBridge.java:770) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.e > xecute(JDBCLoadEntityCommand.java:157) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.e > xecute(JDBCLoadEntityCommand.java:72) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEnt > ity(JDBCStoreManager.java:631) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEnt > ity(JDBCStoreManager.java:613) > at > org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity > (CMPPersistenceManager.java:391) > at > org.jboss.resource.connectionmanager.CachedConnection > Interceptor.loadEntity > (CachedConnectionInterceptor.java:351) > at > org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv > oke(EntitySynchronizationInterceptor.java:232) > at > org.jboss.resource.connectionmanager.CachedConnection > Interceptor.invoke > (CachedConnectionInterceptor.java:185) > at > org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke > (EntityReentranceInterceptor.java:111) > at > org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke > (EntityInstanceInterceptor.java:211) > at > org.jboss.ejb.plugins.EntityLockInterceptor.invoke > (EntityLockInterceptor.java:89) > at > org.jboss.ejb.plugins.EntityCreationInterceptor.invoke > (EntityCreationInterceptor.java:53) > at > org.jboss.ejb.plugins.CallValidationInterceptor.invoke > (CallValidationInterceptor.java:48) > at > org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext > (AbstractTxInterceptor.java:105) > at > org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti > ons(TxInterceptorCMT.java:283) > at > org.jboss.ejb.plugins.TxInterceptorCMT.invoke > (TxInterceptorCMT.java:149) > at > org.jboss.ejb.plugins.SecurityInterceptor.invoke > (SecurityInterceptor.java:128) > at org.jboss.ejb.plugins.LogInterceptor.invoke > (LogInterceptor.java:191) > at > org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invok > e(ProxyFactoryFinderInterceptor.java:122) > at org.jboss.ejb.EntityContainer.internalInvoke > (EntityContainer.java:514) > at org.jboss.ejb.Container.invoke > (Container.java
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1065) No redeployment possible after unsuccessful first deployment
[ http://jira.jboss.com/jira/browse/JBAS-1065?page=history ] Thomas Diesler resolved JBAS-1065: -- Resolution: Done Fixed in Branch_4_0 > No redeployment possible after unsuccessful first deployment > > > Key: JBAS-1065 > URL: http://jira.jboss.com/jira/browse/JBAS-1065 > Project: JBoss Application Server > Type: Bug > Versions: JBossAS-4.0.0 Final > Reporter: SourceForge User > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > SourceForge Submitter: simongunz . > If deployment of ear fails (e.g. because of invalid > deployment descriptors) any further deployment of the > same (valid, since error corrected) archive fails with > the following exception: > org.jboss.deployment.DeploymentException: Error in > accessing application metadata: ; - nested throwable: > (javax.management.InstanceAlreadyExistsException: > jboss.j2ee:service=EARDeployment,url='jpi-jboss-iv.ear' > already registered.) > New deployment only succeeds after restarting JBoss. > Since this is very inconvenient this behaviour should > be changed so that deployment fails completely if there > is a mistake in the deployment descriptor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1099) Missing EJB verifier message
[ http://jira.jboss.com/jira/browse/JBAS-1099?page=history ] Thomas Diesler resolved JBAS-1099: -- Resolution: Duplicate Issue > Missing EJB verifier message > > > Key: JBAS-1099 > URL: http://jira.jboss.com/jira/browse/JBAS-1099 > Project: JBoss Application Server > Type: Bug > Versions: JBossAS-4.0.0 Final > Reporter: SourceForge User > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > SourceForge Submitter: igorfie . > I had element specified in my > ejb-jar.xml file, but forgot to package service > endpoint interface. Here is the error message that I > got from JBoss: > > 08:27:49,290 WARN [verifier] EJB spec violation: > Bean : test/wiki/ejb/Explorer > Method : public abstract EJBHome getEJBHome() throws > RemoteException > Section: 7.11.9 > Warning: No warning message found, please file a Bug > report. > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1392) Implement EJBVerifier21.isJAXRPCType
[ http://jira.jboss.com/jira/browse/JBAS-1392?page=history ]
Thomas Diesler reassigned JBAS-1392:
Assign To: Thomas Diesler
> Implement EJBVerifier21.isJAXRPCType
>
>
> Key: JBAS-1392
> URL: http://jira.jboss.com/jira/browse/JBAS-1392
> Project: JBoss Application Server
> Type: Task
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Priority: Optional
> Fix For: JBossAS-4.0.2 Final
>
>
> Current implemention is
>protected boolean isJAXRPCType(Class class1)
>{
> // TODO this should be implemented along the jaxrpc spec
> return isRMIIDLValueType(class1);
>}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1183) Verifier warning message not found
[ http://jira.jboss.com/jira/browse/JBAS-1183?page=history ] Thomas Diesler resolved JBAS-1183: -- Resolution: Duplicate Issue > Verifier warning message not found > -- > > Key: JBAS-1183 > URL: http://jira.jboss.com/jira/browse/JBAS-1183 > Project: JBoss Application Server > Type: Bug > Versions: JBossAS-4.0.0 Final > Reporter: SourceForge User > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > SourceForge Submitter: murphyp1 . > 13:05:47,004 WARN [verifier] EJB spec violation: > Bean : /d6501/SentinelMonitor > Section: 7.11.1 > Warning: No warning message found, please file a Bug > report. > 13:05:47,035 ERROR [MainDeployer] could not create > deployment: > file:/C:/home2/jboss/server/aistech/deploy/d6501ws- > ejb.jar > org.jboss.deployment.DeploymentException: Verification > of Enterprise Beans failed, see above for error messages. > at org.jboss.ejb.EJBDeployer.create > (EJBDeployer.java:553) > at org.jboss.deployment.MainDeployer.create > (MainDeployer.java:898) > at org.jboss.deployment.MainDeployer.deploy > (MainDeployer.java:754) > at org.jboss.deployment.MainDeployer.deploy > (MainDeployer.java:718) > at sun.reflect.GeneratedMethodAccessor37.invoke > (Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke > (Method.java:324) > at > org.jboss.mx.interceptor.ReflectedDispatcher.invoke > (ReflectedDispatcher.java:144) > at org.jboss.mx.server.Invocation.dispatch > (Invocation.java:80) > at > org.jboss.mx.interceptor.AbstractInterceptor.invoke > (AbstractInterceptor.java:122) > at org.jboss.mx.server.Invocation.invoke > (Invocation.java:74) > at > org.jboss.mx.interceptor.ModelMBeanOperationIntercepto > r.invoke(ModelMBeanOperationInterceptor.java:131) > at org.jboss.mx.server.Invocation.invoke > (Invocation.java:74) > at > org.jboss.mx.server.AbstractMBeanInvoker.invoke > (AbstractMBeanInvoker.java:249) > at org.jboss.mx.server.MBeanServerImpl.invoke > (MBeanServerImpl.java:642) > at org.jboss.mx.util.MBeanProxyExt.invoke > (MBeanProxyExt.java:175) > at $Proxy8.deploy(Unknown Source) > at > org.jboss.deployment.scanner.URLDeploymentScanner.de > ploy(URLDeploymentScanner.java:305) > at > org.jboss.deployment.scanner.URLDeploymentScanner.sc > an(URLDeploymentScanner.java:463) > at > org.jboss.deployment.scanner.AbstractDeploymentScann > er$ScannerThread.doScan > (AbstractDeploymentScanner.java:204) > at > org.jboss.deployment.scanner.AbstractDeploymentScann > er$ScannerThread.loop > (AbstractDeploymentScanner.java:215) > at > org.jboss.deployment.scanner.AbstractDeploymentScann > er$ScannerThread.run > (AbstractDeploymentScanner.java:194) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1070) Warning message not found when deploying WS4EE Web Service
[ http://jira.jboss.com/jira/browse/JBAS-1070?page=history ] Thomas Diesler resolved JBAS-1070: -- Resolution: Done Refactor EJB verification to incude message properties for EJB21. > Warning message not found when deploying WS4EE Web Service > -- > > Key: JBAS-1070 > URL: http://jira.jboss.com/jira/browse/JBAS-1070 > Project: JBoss Application Server > Type: Bug > Versions: JBossAS-4.0.0 Final > Reporter: SourceForge User > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > SourceForge Submitter: davidsalter . > When deploying a WS4EE webservice, a message > stating "no warning message is found" is displayed on > the console when a method in the endpoint interface > does not implement java.rmi.RemoteException. > In this situation, the JBoss console instructs the > developer to file a bug report. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1392) Implement EJBVerifier21.isJAXRPCType
[ http://jira.jboss.com/jira/browse/JBAS-1392?page=history ]
Thomas Diesler updated JBAS-1392:
-
Assign To: (was: Scott M Stark)
> Implement EJBVerifier21.isJAXRPCType
>
>
> Key: JBAS-1392
> URL: http://jira.jboss.com/jira/browse/JBAS-1392
> Project: JBoss Application Server
> Type: Task
> Reporter: Thomas Diesler
> Priority: Optional
> Fix For: JBossAS-4.0.2 Final
>
>
> Current implemention is
>protected boolean isJAXRPCType(Class class1)
>{
> // TODO this should be implemented along the jaxrpc spec
> return isRMIIDLValueType(class1);
>}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1392) Implement EJBVerifier21.isJAXRPCType
Implement EJBVerifier21.isJAXRPCType
Key: JBAS-1392
URL: http://jira.jboss.com/jira/browse/JBAS-1392
Project: JBoss Application Server
Type: Task
Reporter: Thomas Diesler
Assigned to: Scott M Stark
Priority: Optional
Fix For: JBossAS-4.0.2 Final
Current implemention is
protected boolean isJAXRPCType(Class class1)
{
// TODO this should be implemented along the jaxrpc spec
return isRMIIDLValueType(class1);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-21) Cannot find wsdl in client deployment
[ http://jira.jboss.com/jira/browse/JBAS-21?page=history ] Thomas Diesler resolved JBAS-21: Resolution: Won't Fix I think the exception message is clear enough. > Cannot find wsdl in client deployment > - > > Key: JBAS-21 > URL: http://jira.jboss.com/jira/browse/JBAS-21 > Project: JBoss Application Server > Type: Bug > Components: Web Services service > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Priority: Trivial > Fix For: JBossAS-4.0.2 Final > > > The was not null in this case but pointed to WEB-INF which did > not exist > Caused by: java.lang.IllegalArgumentException: WSDL file argument cannot be > null > at > org.jboss.webservice.WSDLDefinitionFactory$WSDLLocatorImpl.(WSDLDefinitionFactory.java:95) > at > org.jboss.webservice.WSDLDefinitionFactory.parse(WSDLDefinitionFactory.java:58) > at > org.jboss.metadata.ServiceRefMetaData.getWsdlDefinition(ServiceRefMetaData.java:170) > at > org.jboss.webservice.ServiceClientDeployer.setupServiceRefEnvironment(ServiceClientDeployer.java:63) > ... 30 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1115) bad path to included xsd gets built in WSDLFilePublisher
[ http://jira.jboss.com/jira/browse/JBAS-1115?page=history ]
Thomas Diesler resolved JBAS-1115:
--
Resolution: Done
Fixed in Branch_4_0
> bad path to included xsd gets built in WSDLFilePublisher
>
>
> Key: JBAS-1115
> URL: http://jira.jboss.com/jira/browse/JBAS-1115
> Project: JBoss Application Server
> Type: Bug
> Components: Web Services service
> Versions: JBossAS-4.0.0 Final
> Reporter: SourceForge User
> Assignee: Thomas Diesler
> Fix For: JBossAS-4.0.2 Final
>
>
> SourceForge Submitter: mazzgolf .
> Problem when deploying a web service whose WSDL
> imports/includes other WSDL/schemas.
> See attached for a simple hello.war that illustrates this
> problem. To replicate, simply place the war file in the
> JBoss deploy directory and start.
> I don't think this has anything to do with platforms, but
> just in case - this is on JBoss 4.0, JDK 1.4.2, Windows
> XP SP1.
> Description:
> My web service WSDL imports another WSDL which in
> turn includes a schema (these are WSRF specification
> files).
> It looks like WSDLFilePublisher is not building the path
> correctly to that included schema. It's missing a "/" in
> one spot and has a double slash "//" in another spot.
> While debugging in WSDLFilePublisher, line 206 results in
> this as value for resourcePath:
> WEB-INF/wsdl//services/../spec/wsrfWS-
> ResourceProperties-1_1.xsd
> Note that there is a "/" missing between the last
> directory "wsrf" and the schema filename "WS-
> ResourceProperties-1_1.xsd". There is also a double
> slash "//" in there as well. The double-slash is probably
> OK and most file systems will parse it fine, however,
> obviously the missing slash is going to cause problems
> (which it does on my box).
> The value of this.expLocation was "WEB-INF/wsdl/" and
> the value of schemaLocation was "WS-
> ResourceProperties-1_1.xsd". baseURI had a value
> of "file:/C:/mazz/jboss/jboss-
> 4.0.0/server/default/data/wsdl/jboss-
> wsdm.war/services/../spec/wsrf/WS-ResourceProperties-
> 1_1.wsdl". this.di.shortName is "jboss-wsdm.war". index
> is 57. All of those values are correct.
> The WSDL includes the .xsd like this:
>
>
> ...
> The resulting exception is (which is actually thrown in
> line 210):
> 16:13:24,774 ERROR [ServiceDeployer] Cannot startup
> webservice for: jboss-wsdm.war
> org.jboss.deployment.DeploymentException: Cannot
> publish wsdl to: C:\mazz\jboss\jboss-4.0.0
> \server\default\data\wsdl\jboss-
> wsdm.war\services\sensor.wsdl; - nested throwable:
> (java.lang.IllegalArgumentException: Cannot find schema
> import in
> deployment: WEB-INF/wsdl//services/../spec/wsrfWS-
> ResourceProperties-1_1.xsd)
> at
> org.jboss.webservice.WSDLFilePublisher.publishWsdlFile
> (WSDLFilePublisher.java:106)
> If, in my debugger, I fix the resourcePath evaluated on
> line 205 such that the path has the proper slashes, my
> web service deploys fine.
> In this example, its as if I made this fix on line 205 of
> WSDLFilePublisher.java
> from:
>resourcePath = resourcePath.substring(0,
> resourcePath.lastIndexOf("/"));
> to:
>resourcePath = resourcePath.substring(1,
> resourcePath.lastIndexOf("/") + 1);
> Obviously, it would be best if no assumptions were made
> about the location of "/" (that is to say, don't assume
> resourcePath has a leading "/" - I do above and hence
> the "1" in the first argument to substring). Probably
> would be better if we do something like this for the first
> parameter to that substring:
> resourcePath.charAt(0) == "/" ? 1 : 0
> Same holds true with that second argument. We should
> not do the "+1" if we know the schemaLocation is an
> absolute path. Otherwise, we'd introduce another
> double slash. So, perhaps, line 205 should be the
> following:
>resourcePath = resourcePath.substring
> (resourcePath.chatAt(0) == "/" ? 1 : 0,
> resourcePath.lastIndexOf("/") + (schemaLocation.charAt
> (0) == "/" ? 0 : 1));
> I'll leave it up to the commiter to decide the best course
> of action.
> John Mazz
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1115) bad path to included xsd gets built in WSDLFilePublisher
[
http://jira.jboss.com/jira/browse/JBAS-1115?page=comments#action_12315208 ]
Thomas Diesler commented on JBAS-1115:
--
Thanks for the good feedback
> bad path to included xsd gets built in WSDLFilePublisher
>
>
> Key: JBAS-1115
> URL: http://jira.jboss.com/jira/browse/JBAS-1115
> Project: JBoss Application Server
> Type: Bug
> Components: Web Services service
> Versions: JBossAS-4.0.0 Final
> Reporter: SourceForge User
> Assignee: Thomas Diesler
> Fix For: JBossAS-4.0.2 Final
>
>
> SourceForge Submitter: mazzgolf .
> Problem when deploying a web service whose WSDL
> imports/includes other WSDL/schemas.
> See attached for a simple hello.war that illustrates this
> problem. To replicate, simply place the war file in the
> JBoss deploy directory and start.
> I don't think this has anything to do with platforms, but
> just in case - this is on JBoss 4.0, JDK 1.4.2, Windows
> XP SP1.
> Description:
> My web service WSDL imports another WSDL which in
> turn includes a schema (these are WSRF specification
> files).
> It looks like WSDLFilePublisher is not building the path
> correctly to that included schema. It's missing a "/" in
> one spot and has a double slash "//" in another spot.
> While debugging in WSDLFilePublisher, line 206 results in
> this as value for resourcePath:
> WEB-INF/wsdl//services/../spec/wsrfWS-
> ResourceProperties-1_1.xsd
> Note that there is a "/" missing between the last
> directory "wsrf" and the schema filename "WS-
> ResourceProperties-1_1.xsd". There is also a double
> slash "//" in there as well. The double-slash is probably
> OK and most file systems will parse it fine, however,
> obviously the missing slash is going to cause problems
> (which it does on my box).
> The value of this.expLocation was "WEB-INF/wsdl/" and
> the value of schemaLocation was "WS-
> ResourceProperties-1_1.xsd". baseURI had a value
> of "file:/C:/mazz/jboss/jboss-
> 4.0.0/server/default/data/wsdl/jboss-
> wsdm.war/services/../spec/wsrf/WS-ResourceProperties-
> 1_1.wsdl". this.di.shortName is "jboss-wsdm.war". index
> is 57. All of those values are correct.
> The WSDL includes the .xsd like this:
>
>
> ...
> The resulting exception is (which is actually thrown in
> line 210):
> 16:13:24,774 ERROR [ServiceDeployer] Cannot startup
> webservice for: jboss-wsdm.war
> org.jboss.deployment.DeploymentException: Cannot
> publish wsdl to: C:\mazz\jboss\jboss-4.0.0
> \server\default\data\wsdl\jboss-
> wsdm.war\services\sensor.wsdl; - nested throwable:
> (java.lang.IllegalArgumentException: Cannot find schema
> import in
> deployment: WEB-INF/wsdl//services/../spec/wsrfWS-
> ResourceProperties-1_1.xsd)
> at
> org.jboss.webservice.WSDLFilePublisher.publishWsdlFile
> (WSDLFilePublisher.java:106)
> If, in my debugger, I fix the resourcePath evaluated on
> line 205 such that the path has the proper slashes, my
> web service deploys fine.
> In this example, its as if I made this fix on line 205 of
> WSDLFilePublisher.java
> from:
>resourcePath = resourcePath.substring(0,
> resourcePath.lastIndexOf("/"));
> to:
>resourcePath = resourcePath.substring(1,
> resourcePath.lastIndexOf("/") + 1);
> Obviously, it would be best if no assumptions were made
> about the location of "/" (that is to say, don't assume
> resourcePath has a leading "/" - I do above and hence
> the "1" in the first argument to substring). Probably
> would be better if we do something like this for the first
> parameter to that substring:
> resourcePath.charAt(0) == "/" ? 1 : 0
> Same holds true with that second argument. We should
> not do the "+1" if we know the schemaLocation is an
> absolute path. Otherwise, we'd introduce another
> double slash. So, perhaps, line 205 should be the
> following:
>resourcePath = resourcePath.substring
> (resourcePath.chatAt(0) == "/" ? 1 : 0,
> resourcePath.lastIndexOf("/") + (schemaLocation.charAt
> (0) == "/" ? 0 : 1));
> I'll leave it up to the commiter to decide the best course
> of action.
> John Mazz
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.co
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-897) invalid ejb-link
[ http://jira.jboss.com/jira/browse/JBAS-897?page=history ] Thomas Diesler closed JBAS-897: --- Resolution: Done The ServiceDeployer now takes the entire deployment down again when the WS endpoint cannot be started. We have good exceptions for invalid ejb-link, servlet-link entries > invalid ejb-link > > > Key: JBAS-897 > URL: http://jira.jboss.com/jira/browse/JBAS-897 > Project: JBoss Application Server > Type: Bug > Components: Web Services service > Reporter: SourceForge User > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > SourceForge Submitter: tdiesler . > Bill reported: > I made a typo in my ejb-jar.xml file so it didn't match the > within my webservices.xml file. No complaint > from JBoss on deployment on this. > Bill -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMAIL-30) Merge the Nokia branch
Merge the Nokia branch -- Key: JBMAIL-30 URL: http://jira.jboss.com/jira/browse/JBMAIL-30 Project: JBoss Mail Type: Task Reporter: Thomas Diesler Assigned to: Andrew Oliver Fix For: 1.0-M2 The nokia brach contains significant performance inprovements when constructing the Mail object. Please ping me when the testsuite passes, so I can do the merge. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1377) bad path to included xsd gets built in WSDLFilePublisher
[ http://jira.jboss.com/jira/browse/JBAS-1377?page=history ]
Thomas Diesler closed JBAS-1377:
Resolution: Duplicate Issue
> bad path to included xsd gets built in WSDLFilePublisher
>
>
> Key: JBAS-1377
> URL: http://jira.jboss.com/jira/browse/JBAS-1377
> Project: JBoss Application Server
> Type: Bug
> Components: Web (Tomcat) service
> Versions: JBossAS-4.0.0 Final
> Reporter: Thomas Diesler
> Assignee: Anil Saldhana
> Fix For: JBossAS-4.0.2 Final
>
>
> SourceForge Submitter: mazzgolf .
> Problem when deploying a web service whose WSDL
> imports/includes other WSDL/schemas.
> See attached for a simple hello.war that illustrates this
> problem. To replicate, simply place the war file in the
> JBoss deploy directory and start.
> I don't think this has anything to do with platforms, but
> just in case - this is on JBoss 4.0, JDK 1.4.2, Windows
> XP SP1.
> Description:
> My web service WSDL imports another WSDL which in
> turn includes a schema (these are WSRF specification
> files).
> It looks like WSDLFilePublisher is not building the path
> correctly to that included schema. It's missing a "/" in
> one spot and has a double slash "//" in another spot.
> While debugging in WSDLFilePublisher, line 206 results in
> this as value for resourcePath:
> WEB-INF/wsdl//services/../spec/wsrfWS-
> ResourceProperties-1_1.xsd
> Note that there is a "/" missing between the last
> directory "wsrf" and the schema filename "WS-
> ResourceProperties-1_1.xsd". There is also a double
> slash "//" in there as well. The double-slash is probably
> OK and most file systems will parse it fine, however,
> obviously the missing slash is going to cause problems
> (which it does on my box).
> The value of this.expLocation was "WEB-INF/wsdl/" and
> the value of schemaLocation was "WS-
> ResourceProperties-1_1.xsd". baseURI had a value
> of "file:/C:/mazz/jboss/jboss-
> 4.0.0/server/default/data/wsdl/jboss-
> wsdm.war/services/../spec/wsrf/WS-ResourceProperties-
> 1_1.wsdl". this.di.shortName is "jboss-wsdm.war". index
> is 57. All of those values are correct.
> The WSDL includes the .xsd like this:
>
>
> ...
> The resulting exception is (which is actually thrown in
> line 210):
> 16:13:24,774 ERROR [ServiceDeployer] Cannot startup
> webservice for: jboss-wsdm.war
> org.jboss.deployment.DeploymentException: Cannot
> publish wsdl to: C:\mazz\jboss\jboss-4.0.0
> \server\default\data\wsdl\jboss-
> wsdm.war\services\sensor.wsdl; - nested throwable:
> (java.lang.IllegalArgumentException: Cannot find schema
> import in
> deployment: WEB-INF/wsdl//services/../spec/wsrfWS-
> ResourceProperties-1_1.xsd)
> at
> org.jboss.webservice.WSDLFilePublisher.publishWsdlFile
> (WSDLFilePublisher.java:106)
> If, in my debugger, I fix the resourcePath evaluated on
> line 205 such that the path has the proper slashes, my
> web service deploys fine.
> In this example, its as if I made this fix on line 205 of
> WSDLFilePublisher.java
> from:
>resourcePath = resourcePath.substring(0,
> resourcePath.lastIndexOf("/"));
> to:
>resourcePath = resourcePath.substring(1,
> resourcePath.lastIndexOf("/") + 1);
> Obviously, it would be best if no assumptions were made
> about the location of "/" (that is to say, don't assume
> resourcePath has a leading "/" - I do above and hence
> the "1" in the first argument to substring). Probably
> would be better if we do something like this for the first
> parameter to that substring:
> resourcePath.charAt(0) == "/" ? 1 : 0
> Same holds true with that second argument. We should
> not do the "+1" if we know the schemaLocation is an
> absolute path. Otherwise, we'd introduce another
> double slash. So, perhaps, line 205 should be the
> following:
>resourcePath = resourcePath.substring
> (resourcePath.chatAt(0) == "/" ? 1 : 0,
> resourcePath.lastIndexOf("/") + (schemaLocation.charAt
> (0) == "/" ? 0 : 1));
> I'll leave it up to the commiter to decide the best course
> of action.
> John Mazz
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1377) bad path to included xsd gets built in WSDLFilePublisher
[ http://jira.jboss.com/jira/browse/JBAS-1377?page=history ]
Thomas Diesler updated JBAS-1377:
-
Fix Version: JBossAS-4.0.2 Final
(was: JBossAS-4.0.1 Final)
> bad path to included xsd gets built in WSDLFilePublisher
>
>
> Key: JBAS-1377
> URL: http://jira.jboss.com/jira/browse/JBAS-1377
> Project: JBoss Application Server
> Type: Bug
> Components: Web (Tomcat) service
> Versions: JBossAS-4.0.0 Final
> Reporter: Thomas Diesler
> Assignee: Anil Saldhana
> Fix For: JBossAS-4.0.2 Final
>
>
> SourceForge Submitter: mazzgolf .
> Problem when deploying a web service whose WSDL
> imports/includes other WSDL/schemas.
> See attached for a simple hello.war that illustrates this
> problem. To replicate, simply place the war file in the
> JBoss deploy directory and start.
> I don't think this has anything to do with platforms, but
> just in case - this is on JBoss 4.0, JDK 1.4.2, Windows
> XP SP1.
> Description:
> My web service WSDL imports another WSDL which in
> turn includes a schema (these are WSRF specification
> files).
> It looks like WSDLFilePublisher is not building the path
> correctly to that included schema. It's missing a "/" in
> one spot and has a double slash "//" in another spot.
> While debugging in WSDLFilePublisher, line 206 results in
> this as value for resourcePath:
> WEB-INF/wsdl//services/../spec/wsrfWS-
> ResourceProperties-1_1.xsd
> Note that there is a "/" missing between the last
> directory "wsrf" and the schema filename "WS-
> ResourceProperties-1_1.xsd". There is also a double
> slash "//" in there as well. The double-slash is probably
> OK and most file systems will parse it fine, however,
> obviously the missing slash is going to cause problems
> (which it does on my box).
> The value of this.expLocation was "WEB-INF/wsdl/" and
> the value of schemaLocation was "WS-
> ResourceProperties-1_1.xsd". baseURI had a value
> of "file:/C:/mazz/jboss/jboss-
> 4.0.0/server/default/data/wsdl/jboss-
> wsdm.war/services/../spec/wsrf/WS-ResourceProperties-
> 1_1.wsdl". this.di.shortName is "jboss-wsdm.war". index
> is 57. All of those values are correct.
> The WSDL includes the .xsd like this:
>
>
> ...
> The resulting exception is (which is actually thrown in
> line 210):
> 16:13:24,774 ERROR [ServiceDeployer] Cannot startup
> webservice for: jboss-wsdm.war
> org.jboss.deployment.DeploymentException: Cannot
> publish wsdl to: C:\mazz\jboss\jboss-4.0.0
> \server\default\data\wsdl\jboss-
> wsdm.war\services\sensor.wsdl; - nested throwable:
> (java.lang.IllegalArgumentException: Cannot find schema
> import in
> deployment: WEB-INF/wsdl//services/../spec/wsrfWS-
> ResourceProperties-1_1.xsd)
> at
> org.jboss.webservice.WSDLFilePublisher.publishWsdlFile
> (WSDLFilePublisher.java:106)
> If, in my debugger, I fix the resourcePath evaluated on
> line 205 such that the path has the proper slashes, my
> web service deploys fine.
> In this example, its as if I made this fix on line 205 of
> WSDLFilePublisher.java
> from:
>resourcePath = resourcePath.substring(0,
> resourcePath.lastIndexOf("/"));
> to:
>resourcePath = resourcePath.substring(1,
> resourcePath.lastIndexOf("/") + 1);
> Obviously, it would be best if no assumptions were made
> about the location of "/" (that is to say, don't assume
> resourcePath has a leading "/" - I do above and hence
> the "1" in the first argument to substring). Probably
> would be better if we do something like this for the first
> parameter to that substring:
> resourcePath.charAt(0) == "/" ? 1 : 0
> Same holds true with that second argument. We should
> not do the "+1" if we know the schemaLocation is an
> absolute path. Otherwise, we'd introduce another
> double slash. So, perhaps, line 205 should be the
> following:
>resourcePath = resourcePath.substring
> (resourcePath.chatAt(0) == "/" ? 1 : 0,
> resourcePath.lastIndexOf("/") + (schemaLocation.charAt
> (0) == "/" ? 0 : 1));
> I'll leave it up to the commiter to decide the best course
> of action.
> John Mazz
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://w
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1115) bad path to included xsd gets built in WSDLFilePublisher
[ http://jira.jboss.com/jira/browse/JBAS-1115?page=history ]
Thomas Diesler updated JBAS-1115:
-
Fix Version: JBossAS-4.0.2 Final
(was: JBossAS-4.0.1 Final)
> bad path to included xsd gets built in WSDLFilePublisher
>
>
> Key: JBAS-1115
> URL: http://jira.jboss.com/jira/browse/JBAS-1115
> Project: JBoss Application Server
> Type: Bug
> Components: Web Services service
> Versions: JBossAS-4.0.0 Final
> Reporter: SourceForge User
> Assignee: Thomas Diesler
> Fix For: JBossAS-4.0.2 Final
>
>
> SourceForge Submitter: mazzgolf .
> Problem when deploying a web service whose WSDL
> imports/includes other WSDL/schemas.
> See attached for a simple hello.war that illustrates this
> problem. To replicate, simply place the war file in the
> JBoss deploy directory and start.
> I don't think this has anything to do with platforms, but
> just in case - this is on JBoss 4.0, JDK 1.4.2, Windows
> XP SP1.
> Description:
> My web service WSDL imports another WSDL which in
> turn includes a schema (these are WSRF specification
> files).
> It looks like WSDLFilePublisher is not building the path
> correctly to that included schema. It's missing a "/" in
> one spot and has a double slash "//" in another spot.
> While debugging in WSDLFilePublisher, line 206 results in
> this as value for resourcePath:
> WEB-INF/wsdl//services/../spec/wsrfWS-
> ResourceProperties-1_1.xsd
> Note that there is a "/" missing between the last
> directory "wsrf" and the schema filename "WS-
> ResourceProperties-1_1.xsd". There is also a double
> slash "//" in there as well. The double-slash is probably
> OK and most file systems will parse it fine, however,
> obviously the missing slash is going to cause problems
> (which it does on my box).
> The value of this.expLocation was "WEB-INF/wsdl/" and
> the value of schemaLocation was "WS-
> ResourceProperties-1_1.xsd". baseURI had a value
> of "file:/C:/mazz/jboss/jboss-
> 4.0.0/server/default/data/wsdl/jboss-
> wsdm.war/services/../spec/wsrf/WS-ResourceProperties-
> 1_1.wsdl". this.di.shortName is "jboss-wsdm.war". index
> is 57. All of those values are correct.
> The WSDL includes the .xsd like this:
>
>
> ...
> The resulting exception is (which is actually thrown in
> line 210):
> 16:13:24,774 ERROR [ServiceDeployer] Cannot startup
> webservice for: jboss-wsdm.war
> org.jboss.deployment.DeploymentException: Cannot
> publish wsdl to: C:\mazz\jboss\jboss-4.0.0
> \server\default\data\wsdl\jboss-
> wsdm.war\services\sensor.wsdl; - nested throwable:
> (java.lang.IllegalArgumentException: Cannot find schema
> import in
> deployment: WEB-INF/wsdl//services/../spec/wsrfWS-
> ResourceProperties-1_1.xsd)
> at
> org.jboss.webservice.WSDLFilePublisher.publishWsdlFile
> (WSDLFilePublisher.java:106)
> If, in my debugger, I fix the resourcePath evaluated on
> line 205 such that the path has the proper slashes, my
> web service deploys fine.
> In this example, its as if I made this fix on line 205 of
> WSDLFilePublisher.java
> from:
>resourcePath = resourcePath.substring(0,
> resourcePath.lastIndexOf("/"));
> to:
>resourcePath = resourcePath.substring(1,
> resourcePath.lastIndexOf("/") + 1);
> Obviously, it would be best if no assumptions were made
> about the location of "/" (that is to say, don't assume
> resourcePath has a leading "/" - I do above and hence
> the "1" in the first argument to substring). Probably
> would be better if we do something like this for the first
> parameter to that substring:
> resourcePath.charAt(0) == "/" ? 1 : 0
> Same holds true with that second argument. We should
> not do the "+1" if we know the schemaLocation is an
> absolute path. Otherwise, we'd introduce another
> double slash. So, perhaps, line 205 should be the
> following:
>resourcePath = resourcePath.substring
> (resourcePath.chatAt(0) == "/" ? 1 : 0,
> resourcePath.lastIndexOf("/") + (schemaLocation.charAt
> (0) == "/" ? 0 : 1));
> I'll leave it up to the commiter to decide the best course
> of action.
> John Mazz
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://w
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1070) Warning message not found when deploying WS4EE Web Service
[ http://jira.jboss.com/jira/browse/JBAS-1070?page=history ] Thomas Diesler updated JBAS-1070: - Fix Version: JBossAS-4.0.2 Final > Warning message not found when deploying WS4EE Web Service > -- > > Key: JBAS-1070 > URL: http://jira.jboss.com/jira/browse/JBAS-1070 > Project: JBoss Application Server > Type: Bug > Versions: JBossAS-4.0.0 Final > Reporter: SourceForge User > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > SourceForge Submitter: davidsalter . > When deploying a WS4EE webservice, a message > stating "no warning message is found" is displayed on > the console when a method in the endpoint interface > does not implement java.rmi.RemoteException. > In this situation, the JBoss console instructs the > developer to file a bug report. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1065) No redeployment possible after unsuccessful first deployment
[ http://jira.jboss.com/jira/browse/JBAS-1065?page=history ] Thomas Diesler updated JBAS-1065: - Fix Version: JBossAS-4.0.2 Final > No redeployment possible after unsuccessful first deployment > > > Key: JBAS-1065 > URL: http://jira.jboss.com/jira/browse/JBAS-1065 > Project: JBoss Application Server > Type: Bug > Versions: JBossAS-4.0.0 Final > Reporter: SourceForge User > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > SourceForge Submitter: simongunz . > If deployment of ear fails (e.g. because of invalid > deployment descriptors) any further deployment of the > same (valid, since error corrected) archive fails with > the following exception: > org.jboss.deployment.DeploymentException: Error in > accessing application metadata: ; - nested throwable: > (javax.management.InstanceAlreadyExistsException: > jboss.j2ee:service=EARDeployment,url='jpi-jboss-iv.ear' > already registered.) > New deployment only succeeds after restarting JBoss. > Since this is very inconvenient this behaviour should > be changed so that deployment fails completely if there > is a mistake in the deployment descriptor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1235) TimedObject id persistence fails on restart
[ http://jira.jboss.com/jira/browse/JBAS-1235?page=history ] Thomas Diesler updated JBAS-1235: - Fix Version: JBossAS-4.0.2 Final > TimedObject id persistence fails on restart > --- > > Key: JBAS-1235 > URL: http://jira.jboss.com/jira/browse/JBAS-1235 > Project: JBoss Application Server > Type: Bug > Components: CMP service > Versions: JBossAS-4.0.0 Final > Reporter: SourceForge User > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > SourceForge Submitter: cstach . > Upon restarting JBoss, persisted timers throw this SQL > exception because it seems that the entity bean that > implements the TimedObject had its primary key (Long) > converted into a byte array. > java.sql.SQLException: Cannot convert class [B to SQL > type requested due to java.lang.ClassCastException - > null > at > com.mysql.jdbc.PreparedStatement.setObject > (PreparedStatement.java:922) > at > com.mysql.jdbc.PreparedStatement.setObject > (PreparedStatement.java:944) > at > org.jboss.resource.adapter.jdbc.WrappedPreparedStatem > ent.setObject(WrappedPreparedStatement.java:615) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCParameterSetter$5.se > tNotNull(JDBCParameterSetter.java:130) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCParameterSetter$JDB > CAbstractParameterSetter.set > (JDBCParameterSetter.java:56) > at > org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFi > eldBridge.setArgumentParameters > (JDBCAbstractCMPFieldBridge.java:354) > at > org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFi > eldBridge.setPrimaryKeyParameters > (JDBCAbstractCMPFieldBridge.java:343) > at > org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge.se > tPrimaryKeyParameters(JDBCEntityBridge.java:770) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.e > xecute(JDBCLoadEntityCommand.java:157) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.e > xecute(JDBCLoadEntityCommand.java:72) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEnt > ity(JDBCStoreManager.java:631) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEnt > ity(JDBCStoreManager.java:613) > at > org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity > (CMPPersistenceManager.java:391) > at > org.jboss.resource.connectionmanager.CachedConnection > Interceptor.loadEntity > (CachedConnectionInterceptor.java:351) > at > org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv > oke(EntitySynchronizationInterceptor.java:232) > at > org.jboss.resource.connectionmanager.CachedConnection > Interceptor.invoke > (CachedConnectionInterceptor.java:185) > at > org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke > (EntityReentranceInterceptor.java:111) > at > org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke > (EntityInstanceInterceptor.java:211) > at > org.jboss.ejb.plugins.EntityLockInterceptor.invoke > (EntityLockInterceptor.java:89) > at > org.jboss.ejb.plugins.EntityCreationInterceptor.invoke > (EntityCreationInterceptor.java:53) > at > org.jboss.ejb.plugins.CallValidationInterceptor.invoke > (CallValidationInterceptor.java:48) > at > org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext > (AbstractTxInterceptor.java:105) > at > org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti > ons(TxInterceptorCMT.java:283) > at > org.jboss.ejb.plugins.TxInterceptorCMT.invoke > (TxInterceptorCMT.java:149) > at > org.jboss.ejb.plugins.SecurityInterceptor.invoke > (SecurityInterceptor.java:128) > at org.jboss.ejb.plugins.LogInterceptor.invoke > (LogInterceptor.java:191) > at > org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invok > e(ProxyFactoryFinderInterceptor.java:122) > at org.jboss.ejb.EntityContainer.internalInvoke > (EntityContainer.java:514) > at org.jboss.ejb.Container.invoke > (Container.java:854) > at > org.jboss.ejb.txtimer.TimedObjectInvokerImpl.callTimeout > (TimedObjectInvokerImpl.java:63) > at > org.jboss.ejb.txtimer.TimerImpl$TimerTaskImpl.run > (TimerImpl.java:472) > at java.util.TimerThread.mainLoop > (Timer.java:432) > at java.util.TimerThread.run(Timer.java:382) > 11:44:21,750 ERROR [TimerImpl] Error invoking > ejbTimeout: javax.ejb.EJBException: Internal error > setting parameters for field id; CausedByException is: > Cannot convert class [B to SQL type requested > due to java.l
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1099) Missing EJB verifier message
[ http://jira.jboss.com/jira/browse/JBAS-1099?page=history ] Thomas Diesler updated JBAS-1099: - Fix Version: JBossAS-4.0.2 Final > Missing EJB verifier message > > > Key: JBAS-1099 > URL: http://jira.jboss.com/jira/browse/JBAS-1099 > Project: JBoss Application Server > Type: Bug > Versions: JBossAS-4.0.0 Final > Reporter: SourceForge User > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > SourceForge Submitter: igorfie . > I had element specified in my > ejb-jar.xml file, but forgot to package service > endpoint interface. Here is the error message that I > got from JBoss: > > 08:27:49,290 WARN [verifier] EJB spec violation: > Bean : test/wiki/ejb/Explorer > Method : public abstract EJBHome getEJBHome() throws > RemoteException > Section: 7.11.9 > Warning: No warning message found, please file a Bug > report. > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-897) invalid ejb-link
[ http://jira.jboss.com/jira/browse/JBAS-897?page=history ] Thomas Diesler updated JBAS-897: Fix Version: JBossAS-4.0.2 Final > invalid ejb-link > > > Key: JBAS-897 > URL: http://jira.jboss.com/jira/browse/JBAS-897 > Project: JBoss Application Server > Type: Bug > Components: Web Services service > Reporter: SourceForge User > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > SourceForge Submitter: tdiesler . > Bill reported: > I made a typo in my ejb-jar.xml file so it didn't match the > within my webservices.xml file. No complaint > from JBoss on deployment on this. > Bill -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-21) Cannot find wsdl in client deployment
[ http://jira.jboss.com/jira/browse/JBAS-21?page=history ] Thomas Diesler updated JBAS-21: --- Fix Version: JBossAS-4.0.2 Final > Cannot find wsdl in client deployment > - > > Key: JBAS-21 > URL: http://jira.jboss.com/jira/browse/JBAS-21 > Project: JBoss Application Server > Type: Bug > Components: Web Services service > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Priority: Trivial > Fix For: JBossAS-4.0.2 Final > > > The was not null in this case but pointed to WEB-INF which did > not exist > Caused by: java.lang.IllegalArgumentException: WSDL file argument cannot be > null > at > org.jboss.webservice.WSDLDefinitionFactory$WSDLLocatorImpl.(WSDLDefinitionFactory.java:95) > at > org.jboss.webservice.WSDLDefinitionFactory.parse(WSDLDefinitionFactory.java:58) > at > org.jboss.metadata.ServiceRefMetaData.getWsdlDefinition(ServiceRefMetaData.java:170) > at > org.jboss.webservice.ServiceClientDeployer.setupServiceRefEnvironment(ServiceClientDeployer.java:63) > ... 30 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1183) Verifier warning message not found
[ http://jira.jboss.com/jira/browse/JBAS-1183?page=history ] Thomas Diesler updated JBAS-1183: - Fix Version: JBossAS-4.0.2 Final > Verifier warning message not found > -- > > Key: JBAS-1183 > URL: http://jira.jboss.com/jira/browse/JBAS-1183 > Project: JBoss Application Server > Type: Bug > Versions: JBossAS-4.0.0 Final > Reporter: SourceForge User > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > SourceForge Submitter: murphyp1 . > 13:05:47,004 WARN [verifier] EJB spec violation: > Bean : /d6501/SentinelMonitor > Section: 7.11.1 > Warning: No warning message found, please file a Bug > report. > 13:05:47,035 ERROR [MainDeployer] could not create > deployment: > file:/C:/home2/jboss/server/aistech/deploy/d6501ws- > ejb.jar > org.jboss.deployment.DeploymentException: Verification > of Enterprise Beans failed, see above for error messages. > at org.jboss.ejb.EJBDeployer.create > (EJBDeployer.java:553) > at org.jboss.deployment.MainDeployer.create > (MainDeployer.java:898) > at org.jboss.deployment.MainDeployer.deploy > (MainDeployer.java:754) > at org.jboss.deployment.MainDeployer.deploy > (MainDeployer.java:718) > at sun.reflect.GeneratedMethodAccessor37.invoke > (Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke > (Method.java:324) > at > org.jboss.mx.interceptor.ReflectedDispatcher.invoke > (ReflectedDispatcher.java:144) > at org.jboss.mx.server.Invocation.dispatch > (Invocation.java:80) > at > org.jboss.mx.interceptor.AbstractInterceptor.invoke > (AbstractInterceptor.java:122) > at org.jboss.mx.server.Invocation.invoke > (Invocation.java:74) > at > org.jboss.mx.interceptor.ModelMBeanOperationIntercepto > r.invoke(ModelMBeanOperationInterceptor.java:131) > at org.jboss.mx.server.Invocation.invoke > (Invocation.java:74) > at > org.jboss.mx.server.AbstractMBeanInvoker.invoke > (AbstractMBeanInvoker.java:249) > at org.jboss.mx.server.MBeanServerImpl.invoke > (MBeanServerImpl.java:642) > at org.jboss.mx.util.MBeanProxyExt.invoke > (MBeanProxyExt.java:175) > at $Proxy8.deploy(Unknown Source) > at > org.jboss.deployment.scanner.URLDeploymentScanner.de > ploy(URLDeploymentScanner.java:305) > at > org.jboss.deployment.scanner.URLDeploymentScanner.sc > an(URLDeploymentScanner.java:463) > at > org.jboss.deployment.scanner.AbstractDeploymentScann > er$ScannerThread.doScan > (AbstractDeploymentScanner.java:204) > at > org.jboss.deployment.scanner.AbstractDeploymentScann > er$ScannerThread.loop > (AbstractDeploymentScanner.java:215) > at > org.jboss.deployment.scanner.AbstractDeploymentScann > er$ScannerThread.run > (AbstractDeploymentScanner.java:194) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-20) Multiple ports wsdl service element
[ http://jira.jboss.com/jira/browse/JBAS-20?page=history ] Thomas Diesler updated JBAS-20: --- Fix Version: JBossAS-4.0.2 Final > Multiple ports wsdl service element > --- > > Key: JBAS-20 > URL: http://jira.jboss.com/jira/browse/JBAS-20 > Project: JBoss Application Server > Type: Bug > Components: Web Services service > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: JBossAS-4.0.2 Final > > > A wsdl can potentially have more than one associated with a wsdl > element. This is ok for a server deployment, which can give give > the port name in webservices.xml. > A client requesting the wsdl from the server, does not have this option in > . We should adjust the returned wsdl such that it only > contatains the port the client was asking for in the ?WSDL request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1185) NPE when do not match
[ http://jira.jboss.com/jira/browse/JBAS-1185?page=history ] Thomas Diesler closed JBAS-1185: Resolution: Done > NPE when do not match > --- > > Key: JBAS-1185 > URL: http://jira.jboss.com/jira/browse/JBAS-1185 > Project: JBoss Application Server > Type: Bug > Reporter: SourceForge User > Assignee: Thomas Diesler > > > SourceForge Submitter: tdiesler . > See > http://www.jboss.org/index.html? > module=bb&op=viewtopic&p=3853822#3853822 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1115) bad path to included xsd gets built in WSDLFilePublisher
[ http://jira.jboss.com/jira/browse/JBAS-1115?page=history ]
Thomas Diesler updated JBAS-1115:
-
Description:
SourceForge Submitter: mazzgolf .
Problem when deploying a web service whose WSDL
imports/includes other WSDL/schemas.
See attached for a simple hello.war that illustrates this
problem. To replicate, simply place the war file in the
JBoss deploy directory and start.
I don't think this has anything to do with platforms, but
just in case - this is on JBoss 4.0, JDK 1.4.2, Windows
XP SP1.
Description:
My web service WSDL imports another WSDL which in
turn includes a schema (these are WSRF specification
files).
It looks like WSDLFilePublisher is not building the path
correctly to that included schema. It's missing a "/" in
one spot and has a double slash "//" in another spot.
While debugging in WSDLFilePublisher, line 206 results in
this as value for resourcePath:
WEB-INF/wsdl//services/../spec/wsrfWS-
ResourceProperties-1_1.xsd
Note that there is a "/" missing between the last
directory "wsrf" and the schema filename "WS-
ResourceProperties-1_1.xsd". There is also a double
slash "//" in there as well. The double-slash is probably
OK and most file systems will parse it fine, however,
obviously the missing slash is going to cause problems
(which it does on my box).
The value of this.expLocation was "WEB-INF/wsdl/" and
the value of schemaLocation was "WS-
ResourceProperties-1_1.xsd". baseURI had a value
of "file:/C:/mazz/jboss/jboss-
4.0.0/server/default/data/wsdl/jboss-
wsdm.war/services/../spec/wsrf/WS-ResourceProperties-
1_1.wsdl". this.di.shortName is "jboss-wsdm.war". index
is 57. All of those values are correct.
The WSDL includes the .xsd like this:
...
The resulting exception is (which is actually thrown in
line 210):
16:13:24,774 ERROR [ServiceDeployer] Cannot startup
webservice for: jboss-wsdm.war
org.jboss.deployment.DeploymentException: Cannot
publish wsdl to: C:\mazz\jboss\jboss-4.0.0
\server\default\data\wsdl\jboss-
wsdm.war\services\sensor.wsdl; - nested throwable:
(java.lang.IllegalArgumentException: Cannot find schema
import in
deployment: WEB-INF/wsdl//services/../spec/wsrfWS-
ResourceProperties-1_1.xsd)
at
org.jboss.webservice.WSDLFilePublisher.publishWsdlFile
(WSDLFilePublisher.java:106)
If, in my debugger, I fix the resourcePath evaluated on
line 205 such that the path has the proper slashes, my
web service deploys fine.
In this example, its as if I made this fix on line 205 of
WSDLFilePublisher.java
from:
resourcePath = resourcePath.substring(0,
resourcePath.lastIndexOf("/"));
to:
resourcePath = resourcePath.substring(1,
resourcePath.lastIndexOf("/") + 1);
Obviously, it would be best if no assumptions were made
about the location of "/" (that is to say, don't assume
resourcePath has a leading "/" - I do above and hence
the "1" in the first argument to substring). Probably
would be better if we do something like this for the first
parameter to that substring:
resourcePath.charAt(0) == "/" ? 1 : 0
Same holds true with that second argument. We should
not do the "+1" if we know the schemaLocation is an
absolute path. Otherwise, we'd introduce another
double slash. So, perhaps, line 205 should be the
following:
resourcePath = resourcePath.substring
(resourcePath.chatAt(0) == "/" ? 1 : 0,
resourcePath.lastIndexOf("/") + (schemaLocation.charAt
(0) == "/" ? 0 : 1));
I'll leave it up to the commiter to decide the best course
of action.
John Mazz
was:
SourceForge Submitter: mazzgolf .
Problem when deploying a web service whose WSDL
imports/includes other WSDL/schemas.
See attached for a simple hello.war that illustrates this
problem. To replicate, simply place the war file in the
JBoss deploy directory and start.
I don't think this has anything to do with platforms, but
just in case - this is on JBoss 4.0, JDK 1.4.2, Windows
XP SP1.
Description:
My web service WSDL imports another WSDL which in
turn includes a schema (these are WSRF specification
files).
It looks like WSDLFilePublisher is not building the path
correctly to that included schema. It's missing a "/" in
one spot and has a double slash "//" in another spot.
While debugging in WSDLFilePublisher, line 206 results in
this as value for resourcePath:
WEB-INF/wsdl//services/../spec/wsrfWS-
ResourceProperties-1_1.xsd
Note that there is a "/" missing between the last
directory "wsrf" and the schema filename "WS-
ResourceProperties-1_1.xsd". There is also a double
slash "//" in there as well. The double-slash is probably
OK and most file systems will parse it fine, however,
obviousl
[JBoss-dev] [JBoss JIRA] Reopened: (JBAS-1115) bad path to included xsd gets built in WSDLFilePublisher
[ http://jira.jboss.com/jira/browse/JBAS-1115?page=history ]
Thomas Diesler reopened JBAS-1115:
--
Assign To: Thomas Diesler (was: Anil Saldhana)
The fix is invalid as it breaks simple imports of the form
schemaLocation="SomeSchema.xsd"
Did, you realy run the testsuite?
> bad path to included xsd gets built in WSDLFilePublisher
>
>
> Key: JBAS-1115
> URL: http://jira.jboss.com/jira/browse/JBAS-1115
> Project: JBoss Application Server
> Type: Bug
> Components: Web (Tomcat) service
> Versions: JBossAS-4.0.0 Final
> Reporter: SourceForge User
> Assignee: Thomas Diesler
> Fix For: JBossAS-4.0.1 Final
>
>
> SourceForge Submitter: mazzgolf .
> Problem when deploying a web service whose WSDL
> imports/includes other WSDL/schemas.
> See attached for a simple hello.war that illustrates this
> problem. To replicate, simply place the war file in the
> JBoss deploy directory and start.
> I don't think this has anything to do with platforms, but
> just in case - this is on JBoss 4.0, JDK 1.4.2, Windows
> XP SP1.
> Description:
> My web service WSDL imports another WSDL which in
> turn includes a schema (these are WSRF specification
> files).
> It looks like WSDLFilePublisher is not building the path
> correctly to that included schema. It's missing a "/" in
> one spot and has a double slash "//" in another spot.
> While debugging in WSDLFilePublisher, line 206 results in
> this as value for resourcePath:
> WEB-INF/wsdl//services/../spec/wsrfWS-
> ResourceProperties-1_1.xsd
> Note that there is a "/" missing between the last
> directory "wsrf" and the schema filename "WS-
> ResourceProperties-1_1.xsd". There is also a double
> slash "//" in there as well. The double-slash is probably
> OK and most file systems will parse it fine, however,
> obviously the missing slash is going to cause problems
> (which it does on my box).
> The value of this.expLocation was "WEB-INF/wsdl/" and
> the value of schemaLocation was "WS-
> ResourceProperties-1_1.xsd". baseURI had a value
> of "file:/C:/mazz/jboss/jboss-
> 4.0.0/server/default/data/wsdl/jboss-
> wsdm.war/services/../spec/wsrf/WS-ResourceProperties-
> 1_1.wsdl". this.di.shortName is "jboss-wsdm.war". index
> is 57. All of those values are correct.
> The WSDL includes the .xsd like this:
>
>
> ...
> The resulting exception is (which is actually thrown in
> line 210):
> 16:13:24,774 ERROR [ServiceDeployer] Cannot startup
> webservice for: jboss-wsdm.war
> org.jboss.deployment.DeploymentException: Cannot
> publish wsdl to: C:\mazz\jboss\jboss-4.0.0
> \server\default\data\wsdl\jboss-
> wsdm.war\services\sensor.wsdl; - nested throwable:
> (java.lang.IllegalArgumentException: Cannot find schema
> import in
> deployment: WEB-INF/wsdl//services/../spec/wsrfWS-
> ResourceProperties-1_1.xsd)
> at
> org.jboss.webservice.WSDLFilePublisher.publishWsdlFile
> (WSDLFilePublisher.java:106)
> If, in my debugger, I fix the resourcePath evaluated on
> line 205 such that the path has the proper slashes, my
> web service deploys fine.
> In this example, its as if I made this fix on line 205 of
> WSDLFilePublisher.java
> from:
>resourcePath = resourcePath.substring(0,
> resourcePath.lastIndexOf("/"));
> to:
>resourcePath = resourcePath.substring(1,
> resourcePath.lastIndexOf("/") + 1);
> Obviously, it would be best if no assumptions were made
> about the location of "/" (that is to say, don't assume
> resourcePath has a leading "/" - I do above and hence
> the "1" in the first argument to substring). Probably
> would be better if we do something like this for the first
> parameter to that substring:
> resourcePath.charAt(0) == "/" ? 1 : 0
> Same holds true with that second argument. We should
> not do the "+1" if we know the schemaLocation is an
> absolute path. Otherwise, we'd introduce another
> double slash. So, perhaps, line 205 should be the
> following:
>resourcePath = resourcePath.substring
> (resourcePath.chatAt(0) == "/" ? 1 : 0,
> resourcePath.lastIndexOf("/") + (schemaLocation.charAt
> (0) == "/" ? 0 : 1));
> I'll leave it up to the commiter to decide the best course
> of action.
> John Mazz
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1377) bad path to included xsd gets built in WSDLFilePublisher
bad path to included xsd gets built in WSDLFilePublisher
Key: JBAS-1377
URL: http://jira.jboss.com/jira/browse/JBAS-1377
Project: JBoss Application Server
Type: Bug
Components: Web (Tomcat) service
Versions: JBossAS-4.0.0 Final
Reporter: Thomas Diesler
Assigned to: Anil Saldhana
Fix For: JBossAS-4.0.1 Final
SourceForge Submitter: mazzgolf .
Problem when deploying a web service whose WSDL
imports/includes other WSDL/schemas.
See attached for a simple hello.war that illustrates this
problem. To replicate, simply place the war file in the
JBoss deploy directory and start.
I don't think this has anything to do with platforms, but
just in case - this is on JBoss 4.0, JDK 1.4.2, Windows
XP SP1.
Description:
My web service WSDL imports another WSDL which in
turn includes a schema (these are WSRF specification
files).
It looks like WSDLFilePublisher is not building the path
correctly to that included schema. It's missing a "/" in
one spot and has a double slash "//" in another spot.
While debugging in WSDLFilePublisher, line 206 results in
this as value for resourcePath:
WEB-INF/wsdl//services/../spec/wsrfWS-
ResourceProperties-1_1.xsd
Note that there is a "/" missing between the last
directory "wsrf" and the schema filename "WS-
ResourceProperties-1_1.xsd". There is also a double
slash "//" in there as well. The double-slash is probably
OK and most file systems will parse it fine, however,
obviously the missing slash is going to cause problems
(which it does on my box).
The value of this.expLocation was "WEB-INF/wsdl/" and
the value of schemaLocation was "WS-
ResourceProperties-1_1.xsd". baseURI had a value
of "file:/C:/mazz/jboss/jboss-
4.0.0/server/default/data/wsdl/jboss-
wsdm.war/services/../spec/wsrf/WS-ResourceProperties-
1_1.wsdl". this.di.shortName is "jboss-wsdm.war". index
is 57. All of those values are correct.
The WSDL includes the .xsd like this:
...
The resulting exception is (which is actually thrown in
line 210):
16:13:24,774 ERROR [ServiceDeployer] Cannot startup
webservice for: jboss-wsdm.war
org.jboss.deployment.DeploymentException: Cannot
publish wsdl to: C:\mazz\jboss\jboss-4.0.0
\server\default\data\wsdl\jboss-
wsdm.war\services\sensor.wsdl; - nested throwable:
(java.lang.IllegalArgumentException: Cannot find schema
import in
deployment: WEB-INF/wsdl//services/../spec/wsrfWS-
ResourceProperties-1_1.xsd)
at
org.jboss.webservice.WSDLFilePublisher.publishWsdlFile
(WSDLFilePublisher.java:106)
If, in my debugger, I fix the resourcePath evaluated on
line 205 such that the path has the proper slashes, my
web service deploys fine.
In this example, its as if I made this fix on line 205 of
WSDLFilePublisher.java
from:
resourcePath = resourcePath.substring(0,
resourcePath.lastIndexOf("/"));
to:
resourcePath = resourcePath.substring(1,
resourcePath.lastIndexOf("/") + 1);
Obviously, it would be best if no assumptions were made
about the location of "/" (that is to say, don't assume
resourcePath has a leading "/" - I do above and hence
the "1" in the first argument to substring). Probably
would be better if we do something like this for the first
parameter to that substring:
resourcePath.charAt(0) == "/" ? 1 : 0
Same holds true with that second argument. We should
not do the "+1" if we know the schemaLocation is an
absolute path. Otherwise, we'd introduce another
double slash. So, perhaps, line 205 should be the
following:
resourcePath = resourcePath.substring
(resourcePath.chatAt(0) == "/" ? 1 : 0,
resourcePath.lastIndexOf("/") + (schemaLocation.charAt
(0) == "/" ? 0 : 1));
I'll leave it up to the commiter to decide the best course
of action.
John Mazz
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBWEB-11) 505 error when connection from a .NET client
[ http://jira.jboss.com/jira/browse/JBWEB-11?page=comments#action_12314770 ] Thomas Diesler commented on JBWEB-11: - Here is a .NET workaround http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3860297#3860297 > 505 error when connection from a .NET client > > > Key: JBWEB-11 > URL: http://jira.jboss.com/jira/browse/JBWEB-11 > Project: JBoss Web > Type: Bug > Components: Tomcat > Versions: JBossWeb-4.0.1 > Reporter: Thomas Diesler > Assignee: Remy Maucherat > > > People with .NET clients have no luck connection to JBossWS since .NET > defaults to HTTP-1.1. This issue as poped up multiple times now. I don't > think it is WS specific. Is there a general HTTP-1.1 issue with Tomcat? > See: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3862668#3862668 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBWEB-11) 505 error when connection from a .NET client
505 error when connection from a .NET client Key: JBWEB-11 URL: http://jira.jboss.com/jira/browse/JBWEB-11 Project: JBoss Web Type: Bug Components: Tomcat Versions: JBossWeb-4.0.1 Reporter: Thomas Diesler Assigned to: Remy Maucherat People with .NET clients have no luck connection to JBossWS4EE since it defaults to HTTP-1.1. This issue as poped up multiple times now. I don't think it is WS specific. Is there a general HTTP-1.1 issue with Tomcat? See http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3862668#3862668 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBWEB-11) 505 error when connection from a .NET client
[ http://jira.jboss.com/jira/browse/JBWEB-11?page=history ] Thomas Diesler updated JBWEB-11: Description: People with .NET clients have no luck connection to JBossWS since .NET defaults to HTTP-1.1. This issue as poped up multiple times now. I don't think it is WS specific. Is there a general HTTP-1.1 issue with Tomcat? See: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3862668#3862668 was: People with .NET clients have no luck connection to JBossWS4EE since it defaults to HTTP-1.1. This issue as poped up multiple times now. I don't think it is WS specific. Is there a general HTTP-1.1 issue with Tomcat? See http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3862668#3862668 > 505 error when connection from a .NET client > > > Key: JBWEB-11 > URL: http://jira.jboss.com/jira/browse/JBWEB-11 > Project: JBoss Web > Type: Bug > Components: Tomcat > Versions: JBossWeb-4.0.1 > Reporter: Thomas Diesler > Assignee: Remy Maucherat > > > People with .NET clients have no luck connection to JBossWS since .NET > defaults to HTTP-1.1. This issue as poped up multiple times now. I don't > think it is WS specific. Is there a general HTTP-1.1 issue with Tomcat? > See: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3862668#3862668 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1294) commons-logging.jar should be in default/lib
[ http://jira.jboss.com/jira/browse/JBAS-1294?page=comments#action_12314717 ] Thomas Diesler commented on JBAS-1294: -- Go ahead, I don't see an issue with that. > commons-logging.jar should be in default/lib > > > Key: JBAS-1294 > URL: http://jira.jboss.com/jira/browse/JBAS-1294 > Project: JBoss Application Server > Type: Bug > Versions: JBossAS-5.0 Alpha > Reporter: Ryan Campbell > Assignee: Ryan Campbell > Priority: Minor > > > commons-logging is a dependency of Tomcat 5.5, however it is included in the > default config via the ws4ee sar. Since it is a dependency of both, > shouldn't it be removed from ws4ee and added to default lib? So that we go > from: > ./lib/commons-logging.jar > ./server/all/lib/commons-logging.jar > ./server/all/deploy/jboss-ws4ee.sar/commons-logging.jar > ./server/default/deploy/jboss-ws4ee.sar/commons-logging.jar > to: > ./lib/commons-logging.jar > ./server/all/lib/commons-logging.jar > ./server/default/lib/commons-logging.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-897) invalid ejb-link
[ http://jira.jboss.com/jira/browse/JBAS-897?page=comments#action_12314712 ] Thomas Diesler commented on JBAS-897: - Ok, please also provide a test case that shows the issue. > invalid ejb-link > > > Key: JBAS-897 > URL: http://jira.jboss.com/jira/browse/JBAS-897 > Project: JBoss Application Server > Type: Bug > Components: Web Services service > Reporter: SourceForge User > Assignee: Thomas Diesler > > > SourceForge Submitter: tdiesler . > Bill reported: > I made a typo in my ejb-jar.xml file so it didn't match the > within my webservices.xml file. No complaint > from JBoss on deployment on this. > Bill -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-27) Support for HTTP/HTTPS proxy
Support for HTTP/HTTPS proxy Key: JBREM-27 URL: http://jira.jboss.com/jira/browse/JBREM-27 Project: JBoss Remoting Type: Feature Request Components: transport Reporter: Thomas Diesler Assigned to: Tom Elrod Fix For: 1.0.1 beta This request showed up on the web services forum. Proxies are currently suported in axis-ws4ee.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] FW: annotationc in testsuite
Hi Bill, the _jars-aop target in testsuite can only be run once. When I want to rebuild the testsuite I have to clean first or comment out the annotationc. Is anybody else seeing this? cheers -thomas _jars-aop:[annotationc] Working directory ignored when same JVM is used.[annotationc] [compiled] D:\projects\jboss-head\testsuite\output\classes\org\jboss\test\aop\bean\AnnotatedSecuredPOJO.class[annotationc] [compiled] D:\projects\jboss-head\testsuite\output\classes\org\jboss\test\aop\bean\AnnotatedTxLockedPOJO.class[annotationc] [compiled] D:\projects\jboss-head\testsuite\output\classes\org\jboss\test\aop\bean\AnnotatedTxPOJO.class [jar] Building jar: D:\projects\jboss-head\testsuite\output\lib\simpleejb.jar [jar] Building jar: D:\projects\jboss-head\testsuite\output\lib\aop-invocationlog.aop [jar] Building jar: D:\projects\jboss-head\testsuite\output\lib\aop-invocationlog.sar [jar] Building jar: D:\projects\jboss-head\testsuite\output\lib\aoptest.aop [jar] Building jar: D:\projects\jboss-head\testsuite\output\lib\aoptest.sar [jar] Building jar: D:\projects\jboss-head\testsuite\output\lib\simpleejb.sar BUILD FAILEDD:\projects\jboss-head\testsuite\build.xml:1647: java.io.IOException: CreateProcess: D:\java\sun\j2sdk1.4.2_04\jre\bin\java.exe -classpath D:\projects\jboss-head\thirdparty\apache-avalon\lib\avalon-framework.jar;D:\projects\jboss-head\thirdparty\apache-commons\lib\commons-collections.jar;D:\projects\jboss-head\thirdparty\apache-commons\lib\commons-logging.jar;D:\projects\jboss-head\thirdparty\apache-commons\lib\commons-httpclient.jar;D:\projects\jboss-head\thirdparty\apache-commons\lib\commons-pool.jar;D:\projects\jboss-head\thirdparty\apache-commons\lib\commons-discovery.jar;D:\projects\jboss-head\thirdparty\apache-commons\lib\commons-lang-1.0.jar;D:\projects\jboss-head\thirdparty\apache-log4j\lib\log4j.jar;D:\projects\jboss-head\thirdparty\dom4j-dom4j\lib\dom4j.jar;D:\projects\jboss-head\thirdparty\oswego-concurrent\lib\concurrent.jar;D:\projects\jboss-head\thirdparty\ibm-wsdl4j\lib\wsdl4j.jar;D:\projects\jboss-head\thirdparty\jacorb-jacorb\lib\jacorb.jar;D:\projects\jboss-head\thirdparty\javagroups-javagroups\lib\jgroups.jar;D:\projects\jboss-head\thirdparty\junit-junit\lib\? Total time: 2 minutes 10 seconds
[JBoss-dev] Build Branch_3_2
Tom,
in CVS
jboss-head Branch_3_2 /tools/etc/buildmagic/libraries.ent I find
However, dom4j lives in
${project.thirdparty}/dom4j-dom4j.
What's the
story here, do you know?
Cheers
-Thomas
RE: [JBoss-dev] Webconsole Snapshot Recording of JMX attributes
Sacha / Bill, at my old company I implemented a HTML tree control that gets it's input from XML. The idea is, that the server assembles the XML data, either of the whole tree or parts of it and the tree control transforms it into HTML. The server does not need to know about the state of the expanded nodes / current node in the user session. Images and node names are of course freely configurable at runtime. The server receives messages when the user clicks on the tree nodes or expands/collapses a level. HTML is still the least common denominator as far as browsers go. Check it out at: http://www.softcon-itec.de/itec-site/products/sctree.html cheers -Thomas PS: I never liked the idea of using an applet -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ivelin Ivanov Sent: Mittwoch, 7. Januar 2004 07:41 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Webconsole Snapshot Recording of JMX attributes Sacha, do you remember what drove your decision to use Swing for the management tree in the web console? The reason why I am asking is because we (in our company) had to go through a long and painful round of experiments and prototypes comparing the feasibility of DHTML vs Swing for a big project. One of the prototypes showed how to efficiently implement dynamic tree that updates some of its nodes over time. At the end, DHTML came ahead because of its better cross-browser, cross-platform availability, compared to java plug-ins. Although it is much less pleasent to code to. Ivelin --- Bill Burke <[EMAIL PROTECTED]> wrote: > The web-console framework is Sacha's baby. I've just added shit. > > Ivelin Ivanov wrote: > > > Cool. > > I assume this is a feature of the web console, not > the > > jmx console? > > > > BTW, how did you make the decision to use a java applet in the web > > console vs. dhtml? > > > > Ivelin > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > >>Hi all, > >> > >>I just committed the ability to do snapshot recordings of any JMX > >>attribute within the web-console. > >> > >>To use it, you right-click a JMX attribute and choose the "create > >>snapshot" item. > >> > >> From there you can start/stop snapshotting. > Review > >>the dataset and > >>Graph the dataset. > >> > >>This is currently only available in Branch_3_2 and will be released > >>with > >>3.2.4 (or the next RC of 3.2.4) > >> > >>Regards, > >> > >> > >>Bill > >> > >> > >> > >> > >> > >> > > > > > --- > > > >>This SF.net email is sponsored by: IBM Linux Tutorials. > >>Become an expert in LINUX or just sharpen your skills. Sign up for > >>IBM's Free Linux Tutorials. Learn everything from the bash shell to > >>sys admin. > >>Click now! > >> > > > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > >>___ > >>JBoss-Development mailing list > >>[EMAIL PROTECTED] > >> > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > --- > > This SF.net email is sponsored by: IBM Linux > Tutorials. > > Become an expert in LINUX or just sharpen your > skills. Sign up for IBM's > > Free Linux Tutorials. Learn everything from the > bash shell to sys admin. > > Click now! > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > ___ > > JBoss-Development mailing list > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > -- > > Bill Burke > Chief Architect > JBoss Group LLC. > > > > > > --- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for > IBM's Free Linux Tutorials. Learn everything from the bash shell to > sys admin. > Click now! > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/per
RE: [JBoss-dev] netboot needs revamping
Bill, depends of the order of priorities we have. Next on my todo list is J2EE1.4 compatiblity tests for web services. However, we don't have the tck yet, or do we? I could start with the TCK that is on the JSR-109 homepage, but that is out of date. Meanwhile I could give it a shot. -thomas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Dienstag, 9. Dezember 2003 19:40 To: Jboss-Dev Subject: [JBoss-dev] netboot needs revamping Netboot needs some revamping and for somebody to take it over. Anybody that is interested get back to me. Thanks, Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ClientDeployer, EJBDeployer, AbstractWebContainer delegate to JSR109ClientService
Hi Scott, I put in the JSR109 client programming model, for J2EE application, EJB, end web component clients. As you suggested, I use a 'delegate to service' rather than subdeployment approach. Here a few details modified ApplicationMetaData, ClientMetaData, WebMetaData to conatain a 'Object webservicesClient' if the EJBDeployer, ClientDeployer, AbstractWebContainer find a webservicesclient.xml (in create) they delegate to JSR109ClientService to do the XML parsing after they established their respective ENC, they delegate again to JSR109ClientService to have the javax.xml.rpc.Service bound to the ENC cheers -thomas --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] WebServer: howto obtain the host and port generically
Hallo Christoph, do we realy? In case of JSR109 is it not just a matter of feeding back the user suplied WSDL in webservices.xml? How can you define (in the spirit of JSR109) webservices that spawn ofer more than one endpoint? Thanks -thomas > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Jung > , Dr. Christoph > Sent: Monday, November 24, 2003 2:11 PM > To: '[EMAIL PROTECTED]' > Subject: AW: [JBoss-dev] WebServer: howto obtain the host and port > generically > > > That is what the dynamic wsdl generation facilities of > Axis/Jboss.net use > and what I was thinking about initially, too. > > Hoever, you should consider that the wsdl file will spawn > over several web > services (ejb+war) only one of them > is hit over a particular transport (and hence msgcontext > properties) and you > would have to adjust the > other entries (for which you have no transport information) > as well to get a > valid wsdl ... > > > CGJ > > > > > > -Ursprüngliche Nachricht- > > Von: Thomas Diesler [mailto:[EMAIL PROTECTED] > > Gesendet: Samstag, 22. November 2003 17:33 > > An: [EMAIL PROTECTED] > > Betreff: RE: [JBoss-dev] WebServer: howto obtain the host and > > port generically > > > > > > It is much simpler than that, with RPCProvider.generateWSDL > > you get a MessageContext that actually contains all the info > > we need to do the mapping. It contains a (large) bag of > > random things - axis comment: 'in case somebody needs it'. > > > > I thought, I share this one :-) > > > > -thomas > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Jung , Dr. Christoph > > Sent: Freitag, 21. November 2003 10:38 > > To: '[EMAIL PROTECTED]' > > Subject: AW: [JBoss-dev] WebServer: howto obtain the host and > > port generically > > > > > > Hi, > > > > > -Ursprüngliche Nachricht- > > > Von: Thomas Diesler (E-mail) [mailto:[EMAIL PROTECTED] > > > Gesendet: Freitag, 21. November 2003 10:13 > > > An: [EMAIL PROTECTED] > > > Betreff: [JBoss-dev] WebServer: howto obtain the host and > > > port generically > > > > > > > > > Hi all, > > > > > > during webservice deployment the WSDL file may specify a > dummy port > > > location. When feeding back the deployed WSDL I would like > > to (must) > > > tweak the port location such that it reflects the actual URL the > > > webservice is available at. > > > > You may want to have a look at the servlet > > spec/implementation. From its initialisation on, any servlet > > (including our jboss.net transport servlets > > org.jboss.net.axis.server.AxisServiceServlet and > > org.jboss.net.ws4ee.server.WebInvokerServlet) has access to > > its javax.servlet.ServletConfig and hence its > > javax.servlet.ServletContext which, to my knowledge, will > > provide these bits of information. > > > > Since AxisServiceServlet is quasi-static to the webservice > > deployments, registering such data centrally (like in the > > org.jboss.net.axis.service.AxisService indexed with a > > transport protocol id "http" or so) should not be a problem. > > > > When it comes to the WebInvokerServlets, this could be a > > problem of the start order since servlet.init(config) will be > > called after > > JSR109Deployer.start() ... maybe we should implement the > > patching lazily such that the servlets register in the > > ServiceImplBean upon init(), but WSDL patching is not done > > until all related deployments have been started and the first > > WSDL request is done? > > > > CGJ > > ### > > > > This message has been scanned by F-Secure Anti-Virus for > > Microsoft Exchange. For more information, connect to > http://www.F-Secure.com/ > > > --- > This SF.net email is sponsored by: SF.net Giveback Program. Does > SourceForge.net help you be more productive? Does it help > you create better > code? SHARE THE LOVE, and help us help YOU! Click Here: > http://sourceforge.net/donate/ > ___ > JBoss-Development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > --- > This SF.net email is sponsored by: SF.net Giveback Pro
[JBoss-dev] InvokationException on model MBean creation with ClientDeployer
Title: Message Hi Scott, the client-deployer-service.xml uses a an inline model mbean definition. That causes a java.lang.NoSuchMethodException: org.jboss.mx.modelmbean.XMBean.(java.lang.Object, org.w3c.dom.Element, java.lang.String) at java.lang.Class.getConstructor0(Class.java:1929) at java.lang.Class.getConstructor(Class.java:1019) at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:932) at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:297) at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:324) at org.jboss.system.ServiceCreator.install(ServiceCreator.java:121) at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:151) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:114) ... 74 more on statup. java version "1.4.2_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03) Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode) Hm ..., an XMBean constructor with that signature however exists. Am I looking at a classloading problem? As far as I can see the client-deployer-service.xml it is the only service that does that (inline xmbean) in the 'all' deploy directory. I've taken the liberty to modify the client-deployer-service.xml to use an external mbean definition (that lives in jboss.jar), like this: name="jboss.j2ee:service=ClientDeployer" xmbean-dd="client-deployer-xmbean.xml"> cheers -thomas PS: If you can't reproduce it, I'm happy look further into it
RE: [JBoss-dev] WebServer: howto obtain the host and port generically
It is much simpler than that, with RPCProvider.generateWSDL you get a MessageContext that actually contains all the info we need to do the mapping. It contains a (large) bag of random things - axis comment: 'in case somebody needs it'. I thought, I share this one :-) -thomas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jung , Dr. Christoph Sent: Freitag, 21. November 2003 10:38 To: '[EMAIL PROTECTED]' Subject: AW: [JBoss-dev] WebServer: howto obtain the host and port generically Hi, > -Ursprüngliche Nachricht- > Von: Thomas Diesler (E-mail) [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 21. November 2003 10:13 > An: [EMAIL PROTECTED] > Betreff: [JBoss-dev] WebServer: howto obtain the host and > port generically > > > Hi all, > > during webservice deployment the WSDL file may specify a > dummy port location. When feeding back the deployed WSDL I > would like to (must) tweak the port location such that it > reflects the actual URL the webservice is available at. You may want to have a look at the servlet spec/implementation. From its initialisation on, any servlet (including our jboss.net transport servlets org.jboss.net.axis.server.AxisServiceServlet and org.jboss.net.ws4ee.server.WebInvokerServlet) has access to its javax.servlet.ServletConfig and hence its javax.servlet.ServletContext which, to my knowledge, will provide these bits of information. Since AxisServiceServlet is quasi-static to the webservice deployments, registering such data centrally (like in the org.jboss.net.axis.service.AxisService indexed with a transport protocol id "http" or so) should not be a problem. When it comes to the WebInvokerServlets, this could be a problem of the start order since servlet.init(config) will be called after JSR109Deployer.start() ... maybe we should implement the patching lazily such that the servlets register in the ServiceImplBean upon init(), but WSDL patching is not done until all related deployments have been started and the first WSDL request is done? CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Sharing classes between WebContainer and JSR109Deployer *was* AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine r
This could simplify things considerably. You're right, we had a
'delegate to JSR109Service' approach in place for the
AbstractWebContainer and the EJBDeployer. I mainly did this because I
was not happy with the order of deployment (subdepoyment start/create
before parent start/create). Realy the EJB/Webapp should be up before
the webservice.
For the client programming model we might want to consider a simmilar
'tight' integration.
-thomas
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Scott M Stark
Sent: Freitag, 21. November 2003 18:18
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Sharing classes between WebContainer and JSR109Deployer
*was* AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine
r
Its seems to me that we need to instead of having the JSR109Service be a
competely seperate deployer from the AbstractWebContainer (which by the
way needs to be broken up into a deployer + a container to address some
class override issues), that the AbstractWebContainer either needs to
incorporate the processing of the webservice.xml descriptor, or delegate
directly to the JSR109Service as part of being a j2ee1.4 web app
deployer. You actually had done this in the past, why did we decide to
make them completely seperated?
Adding the war jars to the parent web service deployment is not going to
be violating scoping as the scope of the web app and web service have to
be the same. Really the bigger issues is getting better integration with
tomcat5 so that we install or obtain the web app class loader earlier
on.
--
Scott Stark
Chief Technology Officer
JBoss Group, LLC
Jung , Dr. Christoph wrote:
>
> All right. I changed the ws4ee classloading to use the subdeployment
> ucl (which is indeed equal to the parent [EJB,WAR] ucl, see
> DeploymentInfo(parent,...)).
>
> Thanks to your hint, the observed inconsistencies in the EJB case thus
> went away.
>
> However, we still have the problem that bytecode from WEB-INF/classes
> and WEB-INF/lib (which is referenced in the webservice.xml, e.g., by
> defining a service endpoint interface, and needs to be loaded by
> JSR109Service.start(...))
>
> - either will never find its way into the war-ucl (tomcats
> useJbossClassloader=no option)
> - or wont be inserted until
> AbstractWebContainer.start(...)->performDeploy(...) is executed
>(which comes AFTER JSR109Service.start(...) due to ws4ee being
> a subdeployment to the war).
>
> The current workaround in JSR109Service.start(...) (which I know is
> certainly conflicting with the idea of allowing "scoped" war
> classloading in
> general) is to simply inject these urls into the war-ucl before trying
to
> load bytecode:
>
> //TODO CGJ: we need to share classes between a war and its
> //webservice-subdeployment. We do that, similar to the EJB
> case,
>
> //by the dis sharing the ucl. However, we need to hence
> extend the
> //ucl with web-inf/classes and lib at this point.
> //This somehow conflicts with the notion of
jboss-decoupled
> //classloading for which I would propose to add another
> //slot into DeploymentInfo that carries the
> //final "Classloader applicationClassLoader" as used by
the
> //individual containers and that should be constructed at
> //initialisation time (or is equivalent to ucl per
default).
> URL warURL = sdi.parent.localUrl != null ?
> sdi.parent.localUrl : sdi.parent.url;
> String warPath=warURL.getFile();
> try{
>File classesDir = new File(warPath, "WEB-INF/classes");
>if (classesDir.exists())
> sdi.parent.ucl.addURL(classesDir.toURL());
>File libDir = new File(warPath, "WEB-INF/lib");
>if (libDir.exists())
>{
> File[] jars = libDir.listFiles();
> int length = jars != null ? jars.length : 0;
> for (int j = 0; j < length; j++)
> sdi.parent.ucl.addURL(jars[j].toURL());
>}
> } catch(MalformedURLException e) {
>throw new DeploymentException("Could not extend ws4ee
> deployment ucl.",e);
> }
>
> As a better solution which bundles the knowledge about war structure
> in a central place and which is consistent with the existing
> classloading options, I would propose to extend DeploymentInfo with
> another "ClassLoader applicationLoader;" which could be equal to ucl
> per default, but which would be set to the actual WebCtxLoader in the
> Tomcat case or a similar construct for other web containers already
> during AbstractWebContainer.init(...) calling a new
> ConcreteWebContainer.constructWebLoader(...) method. This
> applicationLoader could then be consis
[JBoss-dev] WebServer: howto obtain the host and port generically
Hi all, during webservice deployment the WSDL file may specify a dummy port location. When feeding back the deployed WSDL I would like to (must) tweak the port location such that it reflects the actual URL the webservice is available at. For that purpose I'm looking for a generic way to figure out what host:port the JBoss WebServer is running at. I can access the tomcat4.x extra configuration and read out: Host XPath: /Server/Service/[EMAIL PROTECTED]'MainEngine'[EMAIL PROTECTED] Port XPath: /Server/Service/Connector[position()[EMAIL PROTECTED] Obviously, this will only work for tomcat4.x and gets me the port of the first Connector - assuming this is the http connector (not ideal)! Is there a better (generic) way? Cheers -thomas --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] deployment classloader in AbstractWebContainer
Hi Scott,
the AbstractWebContainer now accepts nested deployments (it looks for
WEB-INF/webservices.xml). The nested deployment is then handled by the JSR109Service,
which tries to load the service endpoint interface (SEI) from the parents class loader.
During AbstractWebContainer.init the di.localCL is setup such, that it does NOT
include the webapp classpath (WEB-INF/classes, WEB-INF/lib), but this is where the SEI
lives.
I propose extending the di.localCL in AbstractWebContainer.init to include the webapp
classpaths, rather then doing this in JSR109Service.init. What do you think?
cheers
-thomas
---
URL webServiceUrl = di.localCl.getResource("WEB-INF/webservices.xml");
DeploymentInfo sub = new DeploymentInfo(webServiceUrl, di, getServer());
sub.localUrl = di.localUrl;
// add the webapp classes to the local class loader
// the deployer needs to find the service endpoint (SEI) interface
try
{
List urlList = new ArrayList(Arrays.asList(di.localCl.getURLs()));
urlList.add(new URL(di.localUrl.toExternalForm() + "WEB-INF/classes/"));
String [] libs = new File(di.localUrl.toExternalForm() +
"WEB-INF/lib").list();
for (int i = 0; libs != null && i < libs.length; i++)
{
urlList.add(new URL(di.localUrl.getFile() + "WEB-INF/lib/" +
libs[i]));
}
URL [] urlArr = new URL[urlList.size()];
urlList.toArray(urlArr);
sub.localCl = new URLClassLoader(urlArr, di.localCl);
}
catch (MalformedURLException e)
{
throw new DeploymentException(e);
}
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JNDI binding for J2EE1.4 compliant webservices
Hi all, there seems to be some confusion about how webservices are bound to JNDI. Here is my interpretation of the JSR109 spec. Maybe you whant to throw your 2 cents in. server programming model --- No mention of JNDI. The server makes the webservice available at a URL. A potential client connects to the webservice through that URL. The service is handled by the server invoking a stateless session bean, or web component. The client does not need to know which. When the client obtains the WSDL from the URL, the port address should reflect the actual location of the webservice on the server. The deployed WSDL may contain a dummy port address, which the server will have to tweak when feeding back the WSDL to a client. A deployment that contains a webservices.xml does not cause a webservice binding in JNDI. client programming model -- The deployer provides a WSDL with a valid port address in the WSDL. The client container provides the runtime environment (javax.xml.rpc.Service) in JNDI to access that webservice, ehich may point to any webservice anywhere. The client accesses that webservice like a local object through the SEI. The client container may provide an imlementation of the SEI as static stub, dynamic proxy, or DII. A deployment that contains a webservicesclient.xml causes a global webservice binding in JNDI. A client that has the webservice mapped to his java:comp/env cheers -thomas --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
FW: [JBoss-dev] JNDI lookup problem with webservice client
Scott,
the problem with the JNDI lookup of org.apache.axis.client.Service lies
within
the org.apache.axis.client.ServiceFactory.
It wants either the service classname or the WSDL location. If neither is
set, it'll
return null.
The JNDI spec allows for a null return from ObjectFactory.getObjectInstance
when the object cannot be created.
Cheers
-thomas
-Original Message-
From: Thomas Diesler [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 9:44 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-dev] JNDI lookup problem with webservice client
... here is the test:
org.jboss.test.webservice.ws4eeclient.HelloClientTestCase
thanks
-thomas
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Behalf Of Scott
> M Stark
> Sent: Tuesday, November 11, 2003 9:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] JNDI lookup problem with webservice client
>
>
> No, not that I can see from this. Check the test in and let
> me look at it.
>
> --
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
>
> [EMAIL PROTECTED] wrote:
>
> > Scott,
> >
> > working on the webservice client programing model, I need
> to bind a javax.xml.rpc.Service to JNDI. In the test below I
> bind it to the global JNDI namespace. However, when I lookup
> the service I get null without a NamingException.
> >
> > The code below first tests if the service object can be
> serialized without JNDI involvement, then it tests if
> bind/lookup of a trival string object works. Finally the
> actual service is bound (I can see it in jmx-console) and
> then looked up again. The last assertion fails.
> >
> > Any idea?
> >
> > cheers
> > -thomas
> >
> > --
> >
> > String SERVICE_JNDI_NAME = "service/HelloWsService1";
> >
> > Service service = new org.apache.axis.client.Service();
> >
> > // first try to marshal/unmarshal the service without JNDI
> > ByteArrayOutputStream baos = new ByteArrayOutputStream(1024);
> > ObjectOutputStream oos = new ObjectOutputStream(baos);
> > oos.writeObject(service);
> > oos.close();
> > ByteArrayInputStream bais = new
> ByteArrayInputStream(baos.toByteArray());
> > ObjectInputStream ois = new ObjectInputStream(bais);
> > service = (Service)ois.readObject();
> > assertNotNull("cannot serialize service", service);
> >
> > // test JNDI lookup with a trivial String
> > InitialContext iniCtx = getInitialContext();
> > Util.bind(iniCtx, SERVICE_JNDI_NAME, "Test JNDI");
> > assertEquals("Test JNDI", iniCtx.lookup(SERVICE_JNDI_NAME));
> > Util.unbind(iniCtx, SERVICE_JNDI_NAME);
> >
> > service = new org.apache.axis.client.Service();
> >
> > // now do the actual binding and lookup
> > Util.bind(iniCtx, SERVICE_JNDI_NAME, service);
> > service = (Service)iniCtx.lookup(SERVICE_JNDI_NAME);
> > assertNotNull ("cannot lookup service", service);
> > Util.unbind(iniCtx, SERVICE_JNDI_NAME);
>
>
>
---
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JNDI lookup problem with webservice client
Scott,
working on the webservice client programing model, I need to bind a
javax.xml.rpc.Service to JNDI. In the test below I bind it to the global JNDI
namespace. However, when I lookup the service I get null without a NamingException.
The code below first tests if the service object can be serialized without JNDI
involvement, then it tests if bind/lookup of a trival string object works. Finally the
actual service is bound (I can see it in jmx-console) and then looked up again. The
last assertion fails.
Any idea?
cheers
-thomas
--
String SERVICE_JNDI_NAME = "service/HelloWsService1";
Service service = new org.apache.axis.client.Service();
// first try to marshal/unmarshal the service without JNDI
ByteArrayOutputStream baos = new ByteArrayOutputStream(1024);
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(service);
oos.close();
ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bais);
service = (Service)ois.readObject();
assertNotNull("cannot serialize service", service);
// test JNDI lookup with a trivial String
InitialContext iniCtx = getInitialContext();
Util.bind(iniCtx, SERVICE_JNDI_NAME, "Test JNDI");
assertEquals("Test JNDI", iniCtx.lookup(SERVICE_JNDI_NAME));
Util.unbind(iniCtx, SERVICE_JNDI_NAME);
service = new org.apache.axis.client.Service();
// now do the actual binding and lookup
Util.bind(iniCtx, SERVICE_JNDI_NAME, service);
service = (Service)iniCtx.lookup(SERVICE_JNDI_NAME);
assertNotNull ("cannot lookup service", service);
Util.unbind(iniCtx, SERVICE_JNDI_NAME);
---
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
