The UDDI spec still does define pre-existing tModels and these are indeed installed with jUDDI v3. However, version three of the spec does away with pure GUID keys in favor of more human-readable keys. FYI, here is the list of pre-installed tModels:
http://svn.apache.org/repos/asf/webservices/juddi/trunk/juddi-core/src/main/ resources/juddi_install_data/UDDI_tModels.xml -----Original Message----- From: Per Hermansson [mailto:[email protected]] Sent: Monday, February 22, 2010 3:49 PM To: [email protected] Subject: Re: The technical model was not found for the given key Hi thanks again! You are right that I don't call saveClassificationSchemes so that is probably the issue here. The reason was that I got the impression that the UDDI specification defined some classification schemes which should always exist. I'm not sure why I thought it worked when I tried the first time (I've only tested with Apache Scout and jUDDI v3) maybe I just didn't test that part. I guess I still have some bits to learn about this... Anyway thanks for clarifying how this should work! /Per Kurt T Stam wrote: > Hi Per, > > 1. I don't see you call save. > > compare to this code: > http://svn.apache.org/repos/asf/webservices/scout/tags/scout-1.2/src/test/ja va/org/apache/ws/scout/registry/qa/JAXR005ClassificationSchemeTest.java > > > 2. Are you using Apache Scout as JAXR implementation? > > 3. Did you 'first' use jUDDI v2 or v3? > > 4. Can you check the j3_tmodel table to check your tmodel got saved? > > 5. Can you check the logs for any errors? > > --Kurt > > > Per Hermansson wrote: >> Kurt T Stam wrote: >>> Hi Per, >>> >>> How did you add the tModel in the first place? It looks like you did >>> not supply a key creation time, and >>> got a server generated key. If you remove and the add again you will >>> get a different (unique) key. Can that be the issue? >>> >>> --Kurt >> Hi Kurt thanks for your reply! >> >> So what I'm trying to do is to create a tModel for my ServiceBinding. >> So after creating my Conecpt I use the following code to add the wsdl >> classification scheme: >> String UUID_TYPES = "uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"; >> ClassificationScheme uddiOrgTypes = (ClassificationScheme) >> queryManager.getRegistryObject(UUID_TYPES, >> LifeCycleManager.CLASSIFICATION_SCHEME); >> /*---Create a classification, specifying the scheme and the >> taxonomy name and value defined for WSDL documents by the UDDI >> specification.*/ >> Classification wsdlSpecClassification = >> blcm.createClassification(uddiOrgTypes, "wsdlSpec", "wsdlSpec"); >> specConcept.addClassification(wsdlSpecClassification); >> >> My client fails when calling queryManager.getRegistryObject. >> Basically I do the getRegistryObject query before publishing anything >> to the UDDI repository. >> Maybe I'm doing this the wrong way but I'm mainly following the >> tutorial here >> http://java.sun.com/webservices/docs/2.0/tutorial/doc/JAXR3.html >> >> /Per >>> >>> Per Hermansson wrote: >>>> Hi >>>> I'm running juddi from tomcat as provided by >>>> juddi-portal-bundle-3.0.1. >>>> My problem is that the following SOAP query doesn't seems to work >>>> anymore: >>>> <ns1:get_tModelDetail xmlns:ns1="urn:uddi-org:api_v3"> >>>> >>>> <ns1:tModelKey>uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4</ns1:tModelKey> >>>> >>>> </ns1:get_tModelDetail> >>>> >>>> When issuing this call to the juddiv3/services/inquiry service it >>>> returns: >>>> <soap:Fault> >>>> <faultcode>soap:Server</faultcode> >>>> <faultstring>The technical model was not found for the given >>>> key: uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4</faultstring> >>>> <detail>...</detail> >>>> </soap:Fault> >>>> >>>> Since this worked when I first started testing juddi and the UIID >>>> is built-in type my guess is that the derby database has become >>>> corrupted. >>>> I tried removing the target/juddi-derby-test-db directory in tomcat >>>> but without success. >>>> Does anyone know what the problem is here? >>>> >>>> /Per >>> >> >
