You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@juddi.apache.org by Kurt T Stam <ks...@jboss.com> on 2006/09/06 17:11:48 UTC

jUDDI embedded?

Does anyone know if jUDDI supports embedding into java? I'd like to make
straight java calls to interact (query) with the registry, thereby 
bypassing SOAP.

Thx,

--Kurt


---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-user-help@ws.apache.org


Re: jUDDI embedded?

Posted by Kurt T Stam <ks...@jboss.com>.
Hi Vishal,

I was able to use jUDDI in an embedded way, I'm happy to contribute it
back to you.

The most noticeable changes are in the org.apache.juddi.handler package.
This is where the marshaling on the way out takes place in each specific
*Handler. For processing higher up I need to have the namespace set on
each of these elements. I'm now putting this on in the marshaling step.
Where it used to say:

Element element =
parent.getOwnerDocument().createElement(AuthTokenHandler.TAG_NAME);

it now says

Element element =
parent.getOwnerDocument().createElementNS("urn:uddi-org:api_v2",AuthTokenHandler.TAG_NAME);

where "urn:uddi-org:api_v2" obviously can't be hard coded. It really
should look at the version value for 'generic'. I'm in the process of
implementing that, however there are quite a few of these classes in
that package.

I'm doing something like:

String generic = authToken.getGeneric();
generic = getGeneric(generic);
String namespace = getUDDINamespace(generic);

I defined these two getters in the AbstractHandler like so:

    /**
     * Helper function to set the generic version number
     * to a default value when null or zero length.
     *
     * @param generic version number
     * @return generic version number
     */
    public String getGeneric(String generic)
    {
        if ((generic == null) || (generic.trim().length() == 0))
        {
          // Default to UDDI v2 values
          return IRegistry.UDDI_V2_GENERIC;
        }
        return generic;
    }
    /**
     * Helper function to get the namespace given the generic
     * version number.
     *
     * @param generic - the generic version number
     * @return the namespace String
     */
    public String getUDDINamespace(String generic)
    {
        if (IRegistry.UDDI_V1_GENERIC.equals(generic)) {
            return IRegistry.UDDI_V1_NAMESPACE;
        } else if (IRegistry.UDDI_V2_GENERIC.equals(generic)) {
            return IRegistry.UDDI_V2_NAMESPACE;
        } else if (IRegistry.UDDI_V3_GENERIC.equals(generic)) {
            return IRegistry.UDDI_V3_NAMESPACE;
        } else {// Default to UDDI v2 values
           return IRegistry.UDDI_V2_GENERIC;
        }
    }

However for some objects getGeneric() is not defined. In that case I'm
assuming it is null, so it gets defaulted to v2 in getGeneric(String
generic). I have attached 3 classes that demonstrate this.

Other work includes

1. Connecting to the database using username/pw rather then a
datasource, which you may not have access to when running embedded.
2. A set of classes similar to the org.apache.juddi.registry, but then
regular POJO's, no Servlets.

If this all makes sense to you I'm happy to complete the replacement and
contribute a patch or something. I can do the same with the code I wrote
for scout.

Next I'm planning on making a RMI based connection between scout and
jUDDI. This should be a breeze now..

Let me know what you think!

Cheers,

--Kurt

Vishal K wrote:
> Hi,
> jUDDI is basically a web-application which is built upon UDDI
> specifications.
> It accepts SOAP based requests - or you will have to call the methods
> directly, for finding the services. Direct method calls are possible
> only if the methods written in juddi have public access. jUDDI has its
> own set of method calls - which are visible from on the juddi console.
> If you take a look at the source of juddi - you may get a better
> understanding as to what it is and how can you query it.
>  
> It parses a SOAP request and gets the request-type say for finding
> publisher it would be "find_publisher" and calls the required methods
> ahead.
>  
> You will get a feel of this when you use the jsp-console to make requests.
>  
> These are my thoughts on this.
>  
> "Any modifications/corrections are always welcomed".
>  
> Regards,
> Vishal
>
> */Kurt T Stam <ks...@jboss.com>/* wrote:
>
>     Does anyone know if jUDDI supports embedding into java? I'd like
>     to make
>     straight java calls to interact (query) with the registry, thereby
>     bypassing SOAP.
>
>     Thx,
>
>     --Kurt
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
>     For additional commands, e-mail: juddi-user-help@ws.apache.org
>
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Get on board. You're invited
> <http://us.rd.yahoo.com/evt=40791/*http://advision.webevents.yahoo.com/mailbeta>
> to try the new Yahoo! Mail. 


Re: jUDDI CVS? -> SVN

Posted by Vishal K <te...@yahoo.com>.
I was trying to use the CVS repository - but seeing your mail, I thought there should be some way to download code from  the repository like CVS.
  Anyways!
  

Kurt T Stam <ks...@jboss.com> wrote:
  http://svn.apache.org/repos/asf/webservices seems to do the trick just fine for me. I'm using subeclipse. It brings up a list of projects and one of them is juddi. What are you trying to do?

--Kurt

Vishal K wrote:   I tried but it does not seem to work

Kurt T Stam <ks...@jboss.com> wrote:   I guess it all migrated under the webservices project in SVN.

http://svn.apache.org/repos/asf/webservices/



Kurt T Stam wrote:
> Is the information on http://ws.apache.org/juddi/cvs.html still correct?
> It doesn't seem to work for me.
>
> thx,
>
> --Kurt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: juddi-user-help@ws.apache.org
>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-user-help@ws.apache.org


  
  
---------------------------------
  Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail. 


 		
---------------------------------
How low will we go? Check out Yahoo! MessengerÂ’s low  PC-to-Phone call rates.

Re: jUDDI CVS? -> SVN

Posted by Kurt T Stam <ks...@jboss.com>.
http://svn.apache.org/repos/asf/webservices seems to do the trick just
fine for me. I'm using subeclipse. It brings up a list of projects and
one of them is juddi. What are you trying to do?

--Kurt

Vishal K wrote:
> I tried but it does not seem to work
>
> */Kurt T Stam <ks...@jboss.com>/* wrote:
>
>     I guess it all migrated under the webservices project in SVN.
>
>     http://svn.apache.org/repos/asf/webservices/
>
>
>
>     Kurt T Stam wrote:
>     > Is the information on http://ws.apache.org/juddi/cvs.html still
>     correct?
>     > It doesn't seem to work for me.
>     >
>     > thx,
>     >
>     > --Kurt
>     >
>     >
>     ---------------------------------------------------------------------
>     > To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
>     > For additional commands, e-mail: juddi-user-help@ws.apache.org
>     >
>     >
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
>     For additional commands, e-mail: juddi-user-help@ws.apache.org
>
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Get on board. You're invited
> <http://us.rd.yahoo.com/evt=40791/*http://advision.webevents.yahoo.com/mailbeta>
> to try the new Yahoo! Mail. 


Re: jUDDI CVS? -> SVN

Posted by Vishal K <te...@yahoo.com>.
I tried but it does not seem to work

Kurt T Stam <ks...@jboss.com> wrote:  I guess it all migrated under the webservices project in SVN.

http://svn.apache.org/repos/asf/webservices/



Kurt T Stam wrote:
> Is the information on http://ws.apache.org/juddi/cvs.html still correct?
> It doesn't seem to work for me.
>
> thx,
>
> --Kurt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: juddi-user-help@ws.apache.org
>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-user-help@ws.apache.org



 		
---------------------------------
Do you Yahoo!?
 Get on board. You're invited to try the new Yahoo! Mail.

Re: jUDDI CVS? -> SVN

Posted by Kurt T Stam <ks...@jboss.com>.
I guess it all migrated under the webservices project in SVN.

http://svn.apache.org/repos/asf/webservices/



Kurt T Stam wrote:
> Is the information on http://ws.apache.org/juddi/cvs.html still correct?
> It doesn't seem to work for me.
>
> thx,
>
> --Kurt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: juddi-user-help@ws.apache.org
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-user-help@ws.apache.org


jUDDI CVS?

Posted by Kurt T Stam <ks...@jboss.com>.
Is the information on http://ws.apache.org/juddi/cvs.html still correct?
It doesn't seem to work for me.

thx,

--Kurt

---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-user-help@ws.apache.org


Re: jUDDI on jboss 4 problem.

Posted by Kurt T Stam <ks...@jboss.com>.
This ended up being a juddi bug where juddi was setting the (wrong)
namespace on the outgoing response. I have submitted a patch here:

https://issues.apache.org/jira/browse/JUDDI-91

--Kurt

---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-user-help@ws.apache.org


jUDDI on jboss 4 problem.

Posted by Kurt T Stam <ks...@jboss.com>.
Hi guys,

I can deploy jUDDI just fine to tomcat5.5.* as well as jboss3.2.*.

On jboss4.0.* I have a happy juddi page, but when I send in *any*
request, for instance 'find_publisher' with xml:

<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <find_publisher maxRows="100" generic="1.0"
xmlns="urn:juddi-org:api_v1">
      <name>***</name>
    </find_publisher>
  </soapenv:Body>
</soapenv:Envelope>

I get:

2006-09-15 11:05:20,593 DEBUG [org.jboss.ws.soap.MessageFactoryImpl]
createMessage: [contentType=text/xml]
2006-09-15 11:05:20,859 INFO  [STDOUT] 2006-09-15 11:05:20,859
[http-0.0.0.0-8080-1] INFO  org.apache.juddi.util.Loader  - Using the
Context ClassLoader
2006-09-15 11:05:20,875 INFO  [STDOUT] 2006-09-15 11:05:20,875
[http-0.0.0.0-8080-1] INFO 
org.apache.juddi.util.jdbc.ConnectionManager  - Using JNDI to aquire a
JDBC DataSource with name: java:comp/env/jdbc/juddiDB
2006-09-15 11:05:20,984 INFO  [STDOUT] 2006-09-15 11:05:20,984
[http-0.0.0.0-8080-1] ERROR org.apache.juddi.registry.AbstractService  -
NAMESPACE_ERR: An attempt is made to create or change an object in a way
which is incorrect with regard to namespaces.
org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or
change an object in a way which is incorrect with regard to namespaces.
    at
com.sun.org.apache.xerces.internal.dom.AttrNSImpl.setName(AttrNSImpl.java:142)
    at
com.sun.org.apache.xerces.internal.dom.AttrNSImpl.<init>(AttrNSImpl.java:111)
    at
com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.createAttributeNS(CoreDocumentImpl.java:2012)
    at
com.sun.org.apache.xerces.internal.dom.ElementImpl.setAttributeNS(ElementImpl.java:684)
    at
org.jboss.ws.soap.SOAPElementImpl.setAttributeNS(SOAPElementImpl.java:616)
    at org.jboss.util.xml.DOMUtils.copyAttributes(DOMUtils.java:315)
    at
org.jboss.ws.soap.SOAPFactoryImpl.createElement(SOAPFactoryImpl.java:81)
    at org.jboss.ws.soap.SOAPBodyImpl.addDocument(SOAPBodyImpl.java:82)
    at
org.apache.juddi.registry.AbstractService.doPost(AbstractService.java:216)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
    at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
    at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
    at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
    at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
    at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
    at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
    at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
    at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
    at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
    at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
    at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
    at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
    at
org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
    at java.lang.Thread.run(Thread.java:595)
2006-09-15 11:05:21,015 INFO  [STDOUT] 2006-09-15 11:05:21,015
[http-0.0.0.0-8080-1] ERROR org.apache.juddi.registry.AbstractService  -
A serious error has occured while assembling the SOAP Fault.
java.lang.IllegalArgumentException: Invalid faultCode: Server
    at org.jboss.ws.soap.SOAPFaultImpl.setFaultCode(SOAPFaultImpl.java:152)
    at
org.apache.juddi.registry.AbstractService.doPost(AbstractService.java:341)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
    at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
    at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
    at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
    at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
    at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
    at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
    at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
    at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
    at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
    at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
    at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
    at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
    at
org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
    at java.lang.Thread.run(Thread.java:595)


I tried jboss4.0.3SP1 and jboss4.0.4).

Anyone else seeing this? Any ideas?

Thx,

--Kurt





---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-user-help@ws.apache.org


Re: jUDDI embedded?

Posted by Vishal K <te...@yahoo.com>.
Yes right I have also read about jaxr and Systinet.
  jaxr would be a good approach - I tried it for some time  but then for demo sake I used some SOAP request only.
  In case you have some finding jaxr let us know.
   
  Thanks
  Vishal

Kurt T Stam <ks...@jboss.com> wrote:
  Thx Vishal,

So it sounds to me that there is no 'public' API to do so at the moment, but that it would be possible to do what I want anyway. It'd be cool if we could decouple the SOAP handling and the 'required methods ahead' (decouple as in architectural sense, packages and deployment). I'm interested in a JAXR wrapper which natively calls in to a ([j]UDDI) registry. It's much like the freebXML where there is a setting for embedded mode execution to meet high performance needs. I think Systinet has something similar.

I will start playing with the code and see where it gets me.

--Kurt

Vishal K wrote:     Hi,
  jUDDI is basically a web-application which is built upon UDDI specifications.
  It accepts SOAP based requests - or you will have to call the methods directly, for finding the services. Direct method calls are possible only if the methods written in juddi have public access. jUDDI has its own set of method calls - which are visible from on the juddi console.
  If you take a look at the source of juddi - you may get a better understanding as to what it is and how can you query it.
   
  It parses a SOAP request and gets the request-type say for finding publisher it would be "find_publisher" and calls the required methods ahead.
   
  You will get a feel of this when you use the jsp-console to make requests.
   
  These are my thoughts on this.
   
  "Any modifications/corrections are always welcomed".
   
  Regards,
  Vishal

Kurt T Stam <ks...@jboss.com> wrote:
  Does anyone know if jUDDI supports embedding into java? I'd like to make
straight java calls to interact (query) with the registry, thereby 
bypassing SOAP.

Thx,

--Kurt


---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-user-help@ws.apache.org


  
  
---------------------------------
  Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail. 


 		
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.

Re: jUDDI embedded?

Posted by Kurt T Stam <ks...@jboss.com>.
Thx Vishal,

So it sounds to me that there is no 'public' API to do so at the moment,
but that it would be possible to do what I want anyway. It'd be cool if
we could decouple the SOAP handling and the 'required methods ahead'
(decouple as in architectural sense, packages and deployment). I'm
interested in a JAXR wrapper which natively calls in to a ([j]UDDI)
registry. It's much like the freebXML where there is a setting for
embedded mode execution to meet high performance needs. I think Systinet
has something similar.

I will start playing with the code and see where it gets me.

--Kurt

Vishal K wrote:
> Hi,
> jUDDI is basically a web-application which is built upon UDDI
> specifications.
> It accepts SOAP based requests - or you will have to call the methods
> directly, for finding the services. Direct method calls are possible
> only if the methods written in juddi have public access. jUDDI has its
> own set of method calls - which are visible from on the juddi console.
> If you take a look at the source of juddi - you may get a better
> understanding as to what it is and how can you query it.
>  
> It parses a SOAP request and gets the request-type say for finding
> publisher it would be "find_publisher" and calls the required methods
> ahead.
>  
> You will get a feel of this when you use the jsp-console to make requests.
>  
> These are my thoughts on this.
>  
> "Any modifications/corrections are always welcomed".
>  
> Regards,
> Vishal
>
> */Kurt T Stam <ks...@jboss.com>/* wrote:
>
>     Does anyone know if jUDDI supports embedding into java? I'd like
>     to make
>     straight java calls to interact (query) with the registry, thereby
>     bypassing SOAP.
>
>     Thx,
>
>     --Kurt
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
>     For additional commands, e-mail: juddi-user-help@ws.apache.org
>
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Get on board. You're invited
> <http://us.rd.yahoo.com/evt=40791/*http://advision.webevents.yahoo.com/mailbeta>
> to try the new Yahoo! Mail. 


Re: jUDDI embedded?

Posted by Vishal K <te...@yahoo.com>.
Hi,
  jUDDI is basically a web-application which is built upon UDDI specifications.
  It accepts SOAP based requests - or you will have to call the methods directly, for finding the services. Direct method calls are possible only if the methods written in juddi have public access. jUDDI has its own set of method calls - which are visible from on the juddi console.
  If you take a look at the source of juddi - you may get a better understanding as to what it is and how can you query it.
   
  It parses a SOAP request and gets the request-type say for finding publisher it would be "find_publisher" and calls the required methods ahead.
   
  You will get a feel of this when you use the jsp-console to make requests.
   
  These are my thoughts on this.
   
  "Any modifications/corrections are always welcomed".
   
  Regards,
  Vishal

Kurt T Stam <ks...@jboss.com> wrote:
  Does anyone know if jUDDI supports embedding into java? I'd like to make
straight java calls to interact (query) with the registry, thereby 
bypassing SOAP.

Thx,

--Kurt


---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-user-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-user-help@ws.apache.org



 		
---------------------------------
Do you Yahoo!?
 Get on board. You're invited to try the new Yahoo! Mail.