You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@juddi.apache.org by chainerlt <ch...@gmail.com> on 2011/03/28 17:07:48 UTC
juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator)
problems with saving/deleting Publishers
So I got some problems using 'XMLDocAuthenticator'. The problem is described
below at the end of the post in the last quote.
Kurt wrote:
>
> 3. That said, on your client you should only be using the
> juddi-client.jar and the uddi-ws.jar, right now you seem to
> be using the persistence classes (any classes in org.apache.juddi.model)
> from the juddi-core.jar.
>
I were using only "org.apache.juddi.query.util.FindQualifiers" class for
getting valid abbreviations. So I replaced it with my own class and removed
it and also removed juddi-core.jar from buildpath.
But java still throws me this exception:
> javax.xml.ws.soap.SOAPFaultException:
> org.apache.juddi.model.UddiEntityPublisher cannot be cast to
> org.apache.juddi.model.Publisher
>
in
> public PublisherDetail savePublisher(SavePublisher savePublisher)
> throws Exception
> {
> return juddiApi.savePublisher(savePublisher);
> }
>
As far as I understand this exception appears from overlapping classes which
I import? So I checked my classes:
I have QueryBuilder class (builds various FindBusiness, SavePublisher,
DeleteService and similar objects in a static way) which imports:
> import org.apache.juddi.api_v3.*;
> import org.uddi.api_v3.*;
>
and Tools class (which works with UDDISecurityPortType, JUDDIApiPortType,
UDDIPublicationPortType and UDDIInquiryPortType) which imports:
> import org.apache.juddi.api_v3.*;
> import org.apache.juddi.v3.client.ClassUtil;
> import org.apache.juddi.v3.client.config.UDDIClientContainer;
> import org.apache.juddi.v3.client.transport.Transport;
> import org.apache.juddi.v3_service.JUDDIApiPortType;
> import org.uddi.api_v3.*;
> import org.uddi.v3_service.*;
>
These are the only two classes which involves into working with juddi.
Btw, my name is Martin :-)
#######################################################################
> Hi Chainerit,
>
> Glad you got that to work :).
>
> 1. As a rule, it is better to open a new thread (subject) for a new
> problem.
>
> 2. And usually it is also it is better to only bring up one problem at
> the time :)
>
> 3. That said, on your client you should only be using the
> juddi-client.jar and the uddi-ws.jar, right now you seem to
> be using the persistence classes (any classes in org.apache.juddi.model)
> from the juddi-core.jar.
>
> 4. Our mailing lists are listed here:
> http://juddi.apache.org/mail-lists.html. You can find the current thread
> here:
> http://mail-archives.apache.org/mod_mbox/juddi-user/201103.mbox/browser
>
> If you still have an issue I did not address then please start another
> thread for that.
>
> Good luck!
>
> --Kurt
>
>
> On 3/28/11 6:07 AM, chainerlt wrote:
>> Hi Kurt,
>>
>> thank you for your previous reply. Somehow I think I was trying the same
>> steps before, but they didn't work well. However now I'm able to
>> successfully set up my juddi in tomcat bundle for 'XMLDocAuthenticator'
>> or
>> 'CryptedXMLDocAuthenticator' authentications. Everything seems to be
>> working
>> except saving/deleting publishers. It throws me:
>>
>>
>> java wrote:
>>> javax.xml.ws.soap.SOAPFaultException:
>>> org.apache.juddi.model.UddiEntityPublisher cannot be cast to
>>> org.apache.juddi.model.Publisher
>>> at
>>> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
>>> at
>>> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:111)
>>> at
>>> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
>>> at
>>> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
>>> at
>>> com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
>>> at $Proxy40.savePublisher(Unknown Source)
>>>
>> I wrote such a method for getting authentication token:
>>
>> java wrote:
>>> public AuthToken getAuthToken(String userID, String cred) throws
>>> Exception
>>> {
>>> GetAuthToken getAuthToken = new GetAuthToken();
>>> getAuthToken.setUserID(userID);
>>> getAuthToken.setCred(cred);
>>> return security.getAuthToken(getAuthToken);
>>> }
>>>
>> And when I'm trying to save publisher, here is how I do it:
>>
>>
>>> public PublisherDetail savePublisher(SavePublisher
>>> savePublisher)
>>> throws Exception
>>> {
>>> return juddiApi.savePublisher(savePublisher);
>>> }
>>> ...
>>> public static SavePublisher GetSavePublisher(Publisher publisher,
>>> AuthToken authToken) throws Exception
>>> {
>>> List listPublisher = new ArrayList<Publisher>();
>>> listPublisher.add(publisher);
>>> return GetSavePublisher(listPublisher, authToken);
>>> }
>>> ...
>>> public static SavePublisher GetSavePublisher(List<Publisher>
>>> listPublisher, AuthToken authToken) throws Exception
>>> {
>>> SavePublisher sp = new SavePublisher();
>>> sp.setAuthInfo(authToken.getAuthInfo());
>>> sp.getPublisher().addAll(listPublisher);
>>> return sp;
>>> }
>>>
>> So I build SavePublisher object and pass it to the juddiApi, but it
>> throws
>> this exception somewhere in the middle of compiled libs in this line:
>> return juddiApi.savePublisher(savePublisher);
>> Maybe you are interested in what Publisher object I pass as the parameter
>> to
>> build SavePublisher. In the current situation I get PublisherDetail from:
>>
>>
>>> public PublisherDetail getAllPublisherDetail
>>> (GetAllPublisherDetail gapd) throws Exception
>>> {
>>> return juddiApi.getAllPublisherDetail(gapd);
>>> }
>>> ...
>>> public static GetAllPublisherDetail GetAllPublisherDetail(AuthToken
>>> authToken) throws Exception
>>> {
>>> GetAllPublisherDetail gapd = new GetAllPublisherDetail();
>>> gapd.setAuthInfo(authToken.getAuthInfo());
>>> return gapd;
>>> }
>>> ...
>>>
>> Next I can work with particular publisher getting it from PublisherDetail
>> object getPublisher() method getting List<Publisher>.
>>
>> And another question I was worried about. As far as I understand juddiv3
>> does not work with "juddi-users.xml"/"juddi-users-encrypted.xml". It
>> cares
>> only if there is a publisher by the given Authorized Name. So how can I
>> save/delete new/old users with their passwords? Maybe somehow with
>> CryptedXMLDocAuthentication or XMLDocAuthenticator objects in my java
>> code?
>> I've tried to create them but it throws me that mentioned exception:
>>
>> chainerlt wrote:
>>> CryptedXMLDocAuthenticator x = new CryptedXMLDocAuthenticator();
>>> But it throws me:
>>> java.util.concurrent.ExecutionException:
>>> org.apache.commons.configuration.ConfigurationException: Cannot locate
>>> configuration source juddiv3.properties
>>>
>> And finally, how can I get into this mailing list system? I've subscribed
>> here: http://old.nabble.com/mailing_list/MailingListOptions.jtp?forum=240
>> But I don't get emails when some of you guys reply to my posts. So I
>> manually check mailing list here:
>> http://mail-archives.apache.org/mod_mbox/juddi-user/201103.mbox/browser
>> And
>> these replies does not appear in the thread I've created
>> http://old.nabble.com/juddiv3-credentials-%28passwords-%29-tt31198695.html
>> .
>> I remember asking for how to get finding all services/businesses and
>> didn't
>> know you guys replied me quickly, and that took me for around a week to
>> figure it by myself :/
>>
>> Thank you for helping :-)
>
--
View this message in context: http://old.nabble.com/juddiv3-%283.0.4%29-%22juddi.authenticator%22-%28XMLDocAuthenticator%29-problems-with-saving-deleting-Publishers-tp31259207p31259207.html
Sent from the jUDDI - User mailing list archive at Nabble.com.
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator) problems
with saving/deleting Publishers
Posted by Kurt T Stam <ku...@gmail.com>.
http://juddi.apache.org/mail-lists.html
On 3/30/11 12:07 PM, Dandamudi, Kranthi wrote:
>
> How do I unsubscribe to this email?
>
> *From:*Kurt T Stam [mailto:kurt.stam@gmail.com]
> *Sent:* Wednesday, March 30, 2011 11:05 AM
> *To:* user@juddi.apache.org
> *Subject:* Re: juddiv3 (3.0.4) "juddi.authenticator"
> (XMLDocAuthenticator) problems with saving/deleting Publishers
>
> Hi Martin,
>
> All fixed. If you are using juddi-3.0.4, you should check out the
> source for juddi-3.0.4, and apply the patch:
>
> http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?p2=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&p1=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&r1=1086999&r2=1086998&view=diff&pathrev=1086999
> <http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?p2=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&p1=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&r1=1086999&r2=1086998&view=diff&pathrev=1086999>
>
> or simply replace it with
>
> http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?revision=1086999&view=markup&pathrev=1086999
> <http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?revision=1086999&view=markup&pathrev=1086999>
>
> then from the juddi-core directory, run:
>
> mvn clean install.
>
> This is create a new juddi-core-3.0.4.jar in the target directory.
>
> We will also soon release juddi-3.1.0 which will contain this fix.
>
> Thx,
>
> -Kurt
>
> p.s. the Encrypted version inherits from this one, so the patch fixes
> that one too.
>
>
> On 3/30/11 11:50 AM, Martynas A. (chainer) wrote:
>
> Kurt,
>
> Same happens with CryptedXMLDocAuthenticator. Fix that too. Btw when
> is it possible to expect the fix and in what form (new release/patch)?
>
> Martin
>
> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com <ma...@gmail.com>>
>
> Hi Martin,
>
> I can reproduce it now. The XMLDocAuthenticator has a bug and should
> be returning a Publisher.
> I reopened the issue.
>
> --Kurt
>
>
>
> On 3/30/11 10:45 AM, Martynas A. (chainer) wrote:
>
> Yes, my code worked properly with 'juddi.authenticator =
> org.apache.juddi.v3.auth.JUDDIAuthenticator' in juddi.properties,
> because it was default and I wasn't playing around with
> authentication. I just changed back to JUDDIAuthenticator to check and
> it works fine.
>
> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com <ma...@gmail.com>>
>
> OK I will try one more time. Are you saying it only happens when you
> change the authentication properties and users.xml?
>
>
> On 3/30/11 10:00 AM, Martynas A. (chainer) wrote:
>
> Kurt,
>
> Well I just simply tried to download a fresh
> 'juddi-portal-bundle-3.0.4.zip', unzip it, setup authentication in
> propeties, create users.xml, startup it and try to save publisher.
> Same exception. In my project I use only "juddi-client-3.0.4.jar" and
> "uddi-ws-.3.0.4.jar" which are related to juddi. No idea.
>
> --Martin
>
> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com <ma...@gmail.com>>
>
> Martin,
>
> The code is fine. Can it be you deployed the juddi-core.jar more then
> once? It looks to me like that classcast might be caused by
> classloading issues, or version mismatch.
>
> --Kurt
>
>
> ------------------------------------------------------------------------
> The information in this Internet Email is confidential and may be
> legally privileged. It is intended solely for the addressee. Access to
> this Email by anyone else is unauthorized. If you are not the intended
> recipient, any disclosure, copying, distribution or any action taken
> or omitted to be taken in reliance on it, is prohibited and may be
> unlawful. When addressed to our clients any opinions or advice
> contained in this Email are subject to the terms and conditions
> expressed in any applicable governing The Home Depot terms of business
> or client engagement letter. The Home Depot disclaims all
> responsibility and liability for the accuracy and content of this
> attachment and for any damages or losses arising from any
> inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or
> other items of a destructive nature, which may be contained in this
> attachment and shall not be liable for direct, indirect, consequential
> or special damages in connection with this e-mail message or its
> attachment.
RE: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator)
problems with saving/deleting Publishers
Posted by "Dandamudi, Kranthi" <Kr...@homedepot.com>.
How do I unsubscribe to this email?
From: Kurt T Stam [mailto:kurt.stam@gmail.com]
Sent: Wednesday, March 30, 2011 11:05 AM
To: user@juddi.apache.org
Subject: Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator) problems with saving/deleting Publishers
Hi Martin,
All fixed. If you are using juddi-3.0.4, you should check out the source for juddi-3.0.4, and apply the patch:
http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?p2=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&p1=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&r1=1086999&r2=1086998&view=diff&pathrev=1086999
or simply replace it with
http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?revision=1086999&view=markup&pathrev=1086999
then from the juddi-core directory, run:
mvn clean install.
This is create a new juddi-core-3.0.4.jar in the target directory.
We will also soon release juddi-3.1.0 which will contain this fix.
Thx,
-Kurt
p.s. the Encrypted version inherits from this one, so the patch fixes that one too.
On 3/30/11 11:50 AM, Martynas A. (chainer) wrote:
Kurt,
Same happens with CryptedXMLDocAuthenticator. Fix that too. Btw when is it possible to expect the fix and in what form (new release/patch)?
Martin
2011/3/30 Kurt T Stam <ku...@gmail.com>>
Hi Martin,
I can reproduce it now. The XMLDocAuthenticator has a bug and should be returning a Publisher.
I reopened the issue.
--Kurt
On 3/30/11 10:45 AM, Martynas A. (chainer) wrote:
Yes, my code worked properly with 'juddi.authenticator = org.apache.juddi.v3.auth.JUDDIAuthenticator' in juddi.properties, because it was default and I wasn't playing around with authentication. I just changed back to JUDDIAuthenticator to check and it works fine.
2011/3/30 Kurt T Stam <ku...@gmail.com>>
OK I will try one more time. Are you saying it only happens when you change the authentication properties and users.xml?
On 3/30/11 10:00 AM, Martynas A. (chainer) wrote:
Kurt,
Well I just simply tried to download a fresh 'juddi-portal-bundle-3.0.4.zip', unzip it, setup authentication in propeties, create users.xml, startup it and try to save publisher. Same exception. In my project I use only "juddi-client-3.0.4.jar" and "uddi-ws-.3.0.4.jar" which are related to juddi. No idea.
--Martin
2011/3/30 Kurt T Stam <ku...@gmail.com>>
Martin,
The code is fine. Can it be you deployed the juddi-core.jar more then once? It looks to me like that classcast might be caused by
classloading issues, or version mismatch.
--Kurt
________________________________
The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator) problems
with saving/deleting Publishers
Posted by Kurt T Stam <ku...@gmail.com>.
On 4/1/11 10:27 AM, Martynas A. (chainer) wrote:
> Hello,
>
> Okay, well I'm a bit confused here. Situation is that we have a server
> somewhere which has tomcat and juddiv3. I'm writing a specific remote
> juddiv3 manager (smth similar to uddi browser). So the data which
> holds users with passwords lays down in a server (for a now lets say I
> set up juddiv3 for '/XMLDocAuthenticator/' and that mentioned data is
> '/juddi-users.xml/'). Since from my app I can reach only juddiv3
> services seems like I cannot manage that 'juddi-users.xml' which is in
> a server. So the only way to manage users (create, edit, delete) turns
> to be from inside the server. Or do I misunderstand the purpose of
> Authenticator? Is it responsible for only and only authentication and
> not managing the users it is working with?
Right there is no way to manager that dynamically at the moment. Most
users only have a few publishers, or integrate with a larger system that
stores the passwords. Our Authentication classes work fine for the first
group (who manually update the users file), and the second group will
modify them so they talk to the larger system.
>
> If not, I had a thought of writing a class which could extend
> '/CryptedXMLDocAuthenticator/' and add some methods for managing
> users. Since I feel I cannot do that the following ways come to my head:
> 1. Creating another tool which will start from inside the server and
> manage that 'juddi-users.xml'
> or
> 2. Creating a small database for holding users and their passwords
> (also making my own Authenticator class and applying it for juddi),
> and make a remote connection to it from my app.
> or
> 3. Any suggestions?
Well you could decide to add a password field to the Publisher table in
jUDDI (and add that field to the API). Then you can write your
authenticator to check with this field, rather then the users file. I
think this would be pretty straightforward. If you contribute this back
we will probably add it as a DBAuthenticator.
>
> And as I read that I can write my own class which could implement
> Authenticator. How can I apply it to the juddi? Should I compile that
> class to .jar and add it to the '~webapps\juddiv3\WEB-INF\lib' and
> edit 'juddiv3.properties' to smth like 'juddi.authenticator =
> my.random.package.MyAuthenticator'? Or do I even have to write my own
> Authenticator class because I need managing users, maybe I miss
> something in juddi and there is a written class already (or smth else)
> to solve this problem (not talking about jboss)?
Yeah all of the above :). It's open source, just check out the 3.0.4 tag.
>
> --Martin
>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator)
problems with saving/deleting Publishers
Posted by "Martynas A. (chainer)" <ch...@gmail.com>.
Hello,
Okay, well I'm a bit confused here. Situation is that we have a server
somewhere which has tomcat and juddiv3. I'm writing a specific remote
juddiv3 manager (smth similar to uddi browser). So the data which holds
users with passwords lays down in a server (for a now lets say I set up
juddiv3 for '*XMLDocAuthenticator*' and that mentioned data is '*
juddi-users.xml*'). Since from my app I can reach only juddiv3 services
seems like I cannot manage that 'juddi-users.xml' which is in a server. So
the only way to manage users (create, edit, delete) turns to be from inside
the server. Or do I misunderstand the purpose of Authenticator? Is it
responsible for only and only authentication and not managing the users it
is working with?
If not, I had a thought of writing a class which could extend '*
CryptedXMLDocAuthenticator*' and add some methods for managing users. Since
I feel I cannot do that the following ways come to my head:
1. Creating another tool which will start from inside the server and manage
that 'juddi-users.xml'
or
2. Creating a small database for holding users and their passwords (also
making my own Authenticator class and applying it for juddi), and make a
remote connection to it from my app.
or
3. Any suggestions?
And as I read that I can write my own class which could implement
Authenticator. How can I apply it to the juddi? Should I compile that class
to .jar and add it to the '~webapps\juddiv3\WEB-INF\lib' and edit
'juddiv3.properties' to smth like 'juddi.authenticator =
my.random.package.MyAuthenticator'? Or do I even have to write my own
Authenticator class because I need managing users, maybe I miss something in
juddi and there is a written class already (or smth else) to solve this
problem (not talking about jboss)?
--Martin
2011/3/31 Kurt T Stam <ku...@gmail.com>
> Hi Martin,
>
> 1. Yes for this bug I only changed the 'identify' method. Don't worry about
> other changes if things work for you.
>
> 2. Right jUDDI does not store passwords, but does need a Publisher record.
> You will need to keep that in sync with the juddi-users.xml file (or JAAS,
> see
> http://juddi.apache.org/docs/3.0/userguide/html/chap-Authentication.html#sect-JBoss_Authentication).
> These Authenticator
> classes are 'plugin' so you can create your own and just reference that in
> the jUDDI config, as long as you implement the Authenticator interface
> it should work. So you can write one to hook up to some existing product
> with usernames/passwords (database). And/or you can write something
> so that more users can run of one shared jUDDI Publisher. Our setup should
> make it pretty straight forward to write your own Authenticator class and do
> the integration. If you some up with something that you think is useful for
> other users then we'd love hearing about it and we'll add it to jUDDI :).
>
> --Kurt
>
>
>
> On 3/31/11 6:47 AM, Martynas A. (chainer) wrote:
>
> Hi Kurt,
>
> Okay I did check out. But I still have some questions. Here is what I found
> in '*org.apache.juddi.v3.auth.XMLDocAuthenticator.java*' (in '*jUDDI Core*')
> when I made a check out: ( http://codepaste.net/gttc3a )
> Since I wasn't able to build with '*mvn clean install*' I looked deeper
> into the code.
> I see in the commit (
> http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?p2=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&p1=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&r1=1086999&r2=1086998&view=diff&pathrev=1086999) that the only changes were made to '
> *public UddiEntityPublisher identify(String authInfo, String
> authorizedName)*' method. But as if you say I could simply replace whole
> class with (
> http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?revision=1086999&view=markup&pathrev=1086999) I can see more changes in your posted class. I've checkout via NetBeans
> and after replacing class code it throw me an error in code and I noticed
> that not only '*identify*' method is changed:
>
> public synchronized void readUserFile() throws JAXBException, IOException,
>> ConfigurationException
>> {
>> ...
>> InputStream stream = ClassUtil.getResource(usersFileName,
>> this.getClass()).openStream();
>> ...
>> }
>>
>
> Error cannot find symbol symbol: method
>> getResource(java.lang.String,java.lang.Class<capture#1 of ? extends
>> org.apache.juddi.v3.auth.XMLDocAuthenticator>) location: class
>> org.apache.juddi.ClassUtil XMLDocAuthenticator.java
>> ~/juddi-3.0.4/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java:93
>>
>
> However I was able to replace '*identify*' method with the new one and
> successfully build '*jUDDI Core*' project. But maybe I have a lack of
> knowledge on what actually happens. As far as I understand '*jUDDI Core*'
> builds new '*juddi-core-3.0.4.jar*' in '*~\juddi-3.0.4\juddi-core\target*'.
> So I replaced it with the one in my tomcat:
> '~\webapps\uddi-portlets\WEB-INF\lib'. And also '*XMLDocAuthenticator*.class'
> in '*
> ~\webapps\juddiv3\WEB-INF\lib\juddi-core-openjpa-3.0.4.jar\org\apache\juddi\v3\auth\
> *'. Therefore Class cast exception disappeared and seems like problems
> went out (I can successfully save/delete publishers now). But what about
> that discrepancy in '*XMLDocAuthenticator.java'*?
>
> Nomater if I'm talking nonsense, I have a question about 'juddi-users.xml'
> (or 'juddi-users-encrypted.xml'). How should I work with this file from my
> code if I wanna create new/edit/delete users with passwords. Seems like this
> has nothing to do with juddi, so how should I take care of managing users
> (especially if I'm using CryptedXMLDocAuthenticator). Should there be any
> synchronization between this file and publishers in the database?
>
> Thanks,
> Martin
>
> 2011/3/30 Kurt T Stam <ku...@gmail.com>
>
>> Hi Martin,
>>
>> All fixed. If you are using juddi-3.0.4, you should check out the source
>> for juddi-3.0.4, and apply the patch:
>>
>>
>> http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?p2=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&p1=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&r1=1086999&r2=1086998&view=diff&pathrev=1086999
>>
>> or simply replace it with
>>
>>
>> http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?revision=1086999&view=markup&pathrev=1086999
>>
>> then from the juddi-core directory, run:
>>
>> mvn clean install.
>>
>> This is create a new juddi-core-3.0.4.jar in the target directory.
>>
>> We will also soon release juddi-3.1.0 which will contain this fix.
>>
>> Thx,
>>
>> -Kurt
>>
>> p.s. the Encrypted version inherits from this one, so the patch fixes that
>> one too.
>>
>>
>>
>> On 3/30/11 11:50 AM, Martynas A. (chainer) wrote:
>>
>> Kurt,
>>
>> Same happens with CryptedXMLDocAuthenticator. Fix that too. Btw when is it
>> possible to expect the fix and in what form (new release/patch)?
>>
>> Martin
>>
>> 2011/3/30 Kurt T Stam <ku...@gmail.com>
>>
>>> Hi Martin,
>>>
>>> I can reproduce it now. The XMLDocAuthenticator has a bug and should be
>>> returning a Publisher.
>>> I reopened the issue.
>>>
>>> --Kurt
>>>
>>>
>>> On 3/30/11 10:45 AM, Martynas A. (chainer) wrote:
>>>
>>> Yes, my code worked properly with 'juddi.authenticator =
>>> org.apache.juddi.v3.auth.JUDDIAuthenticator' in juddi.properties, because it
>>> was default and I wasn't playing around with authentication. I just changed
>>> back to JUDDIAuthenticator to check and it works fine.
>>>
>>> 2011/3/30 Kurt T Stam <ku...@gmail.com>
>>>
>>>> OK I will try one more time. Are you saying it only happens when you
>>>> change the authentication properties and users.xml?
>>>>
>>>> On 3/30/11 10:00 AM, Martynas A. (chainer) wrote:
>>>>
>>>> Kurt,
>>>>
>>>> Well I just simply tried to download a fresh
>>>> 'juddi-portal-bundle-3.0.4.zip', unzip it, setup authentication in
>>>> propeties, create users.xml, startup it and try to save publisher. Same
>>>> exception. In my project I use only "juddi-client-3.0.4.jar" and
>>>> "uddi-ws-.3.0.4.jar" which are related to juddi. No idea.
>>>>
>>>> --Martin
>>>>
>>>> 2011/3/30 Kurt T Stam <ku...@gmail.com>
>>>>
>>>>> Martin,
>>>>>
>>>>> The code is fine. Can it be you deployed the juddi-core.jar more then
>>>>> once? It looks to me like that classcast might be caused by
>>>>> classloading issues, or version mismatch.
>>>>>
>>>>> --Kurt
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator) problems
with saving/deleting Publishers
Posted by Kurt T Stam <ku...@gmail.com>.
Hi Martin,
1. Yes for this bug I only changed the 'identify' method. Don't worry
about other changes if things work for you.
2. Right jUDDI does not store passwords, but does need a Publisher
record. You will need to keep that in sync with the juddi-users.xml file
(or JAAS, see
http://juddi.apache.org/docs/3.0/userguide/html/chap-Authentication.html#sect-JBoss_Authentication).
These Authenticator
classes are 'plugin' so you can create your own and just reference that
in the jUDDI config, as long as you implement the Authenticator interface
it should work. So you can write one to hook up to some existing product
with usernames/passwords (database). And/or you can write something
so that more users can run of one shared jUDDI Publisher. Our setup
should make it pretty straight forward to write your own Authenticator
class and do the integration. If you some up with something that you
think is useful for other users then we'd love hearing about it and
we'll add it to jUDDI :).
--Kurt
On 3/31/11 6:47 AM, Martynas A. (chainer) wrote:
> Hi Kurt,
>
> Okay I did check out. But I still have some questions. Here is what I
> found in '/org.apache.juddi.v3.auth.XMLDocAuthenticator.java/' (in
> '/jUDDI Core/') when I made a check out: ( http://codepaste.net/gttc3a )
> Since I wasn't able to build with '/mvn clean install/' I looked
> deeper into the code.
> I see in the commit (
> http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?p2=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&p1=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&r1=1086999&r2=1086998&view=diff&pathrev=1086999
> <http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?p2=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&p1=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&r1=1086999&r2=1086998&view=diff&pathrev=1086999>
> ) that the only changes were made to '/public UddiEntityPublisher
> identify(String authInfo, String authorizedName)/' method. But as if
> you say I could simply replace whole class with (
> http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?revision=1086999&view=markup&pathrev=1086999
> <http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?revision=1086999&view=markup&pathrev=1086999>
> ) I can see more changes in your posted class. I've checkout via
> NetBeans and after replacing class code it throw me an error in code
> and I noticed that not only '/identify/' method is changed:
>
> public synchronized void readUserFile() throws JAXBException,
> IOException, ConfigurationException
> {
> ...
> InputStream stream = ClassUtil.getResource(usersFileName,
> this.getClass()).openStream();
> ...
> }
>
>
> Error cannot find symbol symbol: method
> getResource(java.lang.String,java.lang.Class<capture#1 of ?
> extends org.apache.juddi.v3.auth.XMLDocAuthenticator>) location:
> class org.apache.juddi.ClassUtil XMLDocAuthenticator.java
> ~/juddi-3.0.4/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java:93
>
>
> However I was able to replace '/identify/' method with the new one and
> successfully build '/jUDDI Core/' project. But maybe I have a lack of
> knowledge on what actually happens. As far as I understand '/jUDDI
> Core/' builds new '/juddi-core-3.0.4.jar/' in
> '/~\juddi-3.0.4\juddi-core\target/'. So I replaced it with the one in
> my tomcat: '~\webapps\uddi-portlets\WEB-INF\lib'. And also
> '/XMLDocAuthenticator/.class' in
> '/~\webapps\juddiv3\WEB-INF\lib\juddi-core-openjpa-3.0.4.jar\org\apache\juddi\v3\auth\/'.
> Therefore Class cast exception disappeared and seems like problems
> went out (I can successfully save/delete publishers now). But what
> about that discrepancy in '/XMLDocAuthenticator.java'/?
>
> Nomater if I'm talking nonsense, I have a question about
> 'juddi-users.xml' (or 'juddi-users-encrypted.xml'). How should I work
> with this file from my code if I wanna create new/edit/delete users
> with passwords. Seems like this has nothing to do with juddi, so how
> should I take care of managing users (especially if I'm using
> CryptedXMLDocAuthenticator). Should there be any synchronization
> between this file and publishers in the database?
>
> Thanks,
> Martin
>
> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com <ma...@gmail.com>>
>
> Hi Martin,
>
> All fixed. If you are using juddi-3.0.4, you should check out the
> source for juddi-3.0.4, and apply the patch:
>
> http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?p2=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&p1=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&r1=1086999&r2=1086998&view=diff&pathrev=1086999
> <http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?p2=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&p1=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&r1=1086999&r2=1086998&view=diff&pathrev=1086999>
>
> or simply replace it with
>
> http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?revision=1086999&view=markup&pathrev=1086999
> <http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?revision=1086999&view=markup&pathrev=1086999>
>
> then from the juddi-core directory, run:
>
> mvn clean install.
>
> This is create a new juddi-core-3.0.4.jar in the target directory.
>
> We will also soon release juddi-3.1.0 which will contain this fix.
>
> Thx,
>
> -Kurt
>
> p.s. the Encrypted version inherits from this one, so the patch
> fixes that one too.
>
>
>
> On 3/30/11 11:50 AM, Martynas A. (chainer) wrote:
>> Kurt,
>>
>> Same happens with CryptedXMLDocAuthenticator. Fix that too. Btw
>> when is it possible to expect the fix and in what form (new
>> release/patch)?
>>
>> Martin
>>
>> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com
>> <ma...@gmail.com>>
>>
>> Hi Martin,
>>
>> I can reproduce it now. The XMLDocAuthenticator has a bug and
>> should be returning a Publisher.
>> I reopened the issue.
>>
>> --Kurt
>>
>>
>> On 3/30/11 10:45 AM, Martynas A. (chainer) wrote:
>>> Yes, my code worked properly with 'juddi.authenticator =
>>> org.apache.juddi.v3.auth.JUDDIAuthenticator' in
>>> juddi.properties, because it was default and I wasn't
>>> playing around with authentication. I just changed back to
>>> JUDDIAuthenticator to check and it works fine.
>>>
>>> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com
>>> <ma...@gmail.com>>
>>>
>>> OK I will try one more time. Are you saying it only
>>> happens when you change the authentication properties
>>> and users.xml?
>>>
>>> On 3/30/11 10:00 AM, Martynas A. (chainer) wrote:
>>>> Kurt,
>>>>
>>>> Well I just simply tried to download a fresh
>>>> 'juddi-portal-bundle-3.0.4.zip', unzip it, setup
>>>> authentication in propeties, create users.xml, startup
>>>> it and try to save publisher. Same exception. In my
>>>> project I use only "juddi-client-3.0.4.jar" and
>>>> "uddi-ws-.3.0.4.jar" which are related to juddi. No idea.
>>>>
>>>> --Martin
>>>>
>>>> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com
>>>> <ma...@gmail.com>>
>>>>
>>>> Martin,
>>>>
>>>> The code is fine. Can it be you deployed the
>>>> juddi-core.jar more then once? It looks to me like
>>>> that classcast might be caused by
>>>> classloading issues, or version mismatch.
>>>>
>>>> --Kurt
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator)
problems with saving/deleting Publishers
Posted by "Martynas A. (chainer)" <ch...@gmail.com>.
Hi Kurt,
Okay I did check out. But I still have some questions. Here is what I found
in '*org.apache.juddi.v3.auth.XMLDocAuthenticator.java*' (in '*jUDDI Core*')
when I made a check out: ( http://codepaste.net/gttc3a )
Since I wasn't able to build with '*mvn clean install*' I looked deeper into
the code.
I see in the commit (
http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?p2=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&p1=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&r1=1086999&r2=1086998&view=diff&pathrev=1086999)
that the only changes were made to '
*public UddiEntityPublisher identify(String authInfo, String authorizedName)
*' method. But as if you say I could simply replace whole class with (
http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?revision=1086999&view=markup&pathrev=1086999)
I can see more changes in your posted class. I've checkout via
NetBeans
and after replacing class code it throw me an error in code and I noticed
that not only '*identify*' method is changed:
public synchronized void readUserFile() throws JAXBException, IOException,
> ConfigurationException
> {
> ...
> InputStream stream = ClassUtil.getResource(usersFileName,
> this.getClass()).openStream();
> ...
> }
>
Error cannot find symbol symbol: method
> getResource(java.lang.String,java.lang.Class<capture#1 of ? extends
> org.apache.juddi.v3.auth.XMLDocAuthenticator>) location: class
> org.apache.juddi.ClassUtil XMLDocAuthenticator.java
> ~/juddi-3.0.4/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java:93
>
However I was able to replace '*identify*' method with the new one and
successfully build '*jUDDI Core*' project. But maybe I have a lack of
knowledge on what actually happens. As far as I understand '*jUDDI Core*'
builds new '*juddi-core-3.0.4.jar*' in '*~\juddi-3.0.4\juddi-core\target*'.
So I replaced it with the one in my tomcat:
'~\webapps\uddi-portlets\WEB-INF\lib'. And also '*XMLDocAuthenticator*.class'
in '*
~\webapps\juddiv3\WEB-INF\lib\juddi-core-openjpa-3.0.4.jar\org\apache\juddi\v3\auth\
*'. Therefore Class cast exception disappeared and seems like problems went
out (I can successfully save/delete publishers now). But what about that
discrepancy in '*XMLDocAuthenticator.java'*?
Nomater if I'm talking nonsense, I have a question about 'juddi-users.xml'
(or 'juddi-users-encrypted.xml'). How should I work with this file from my
code if I wanna create new/edit/delete users with passwords. Seems like this
has nothing to do with juddi, so how should I take care of managing users
(especially if I'm using CryptedXMLDocAuthenticator). Should there be any
synchronization between this file and publishers in the database?
Thanks,
Martin
2011/3/30 Kurt T Stam <ku...@gmail.com>
> Hi Martin,
>
> All fixed. If you are using juddi-3.0.4, you should check out the source
> for juddi-3.0.4, and apply the patch:
>
>
> http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?p2=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&p1=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&r1=1086999&r2=1086998&view=diff&pathrev=1086999
>
> or simply replace it with
>
>
> http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?revision=1086999&view=markup&pathrev=1086999
>
> then from the juddi-core directory, run:
>
> mvn clean install.
>
> This is create a new juddi-core-3.0.4.jar in the target directory.
>
> We will also soon release juddi-3.1.0 which will contain this fix.
>
> Thx,
>
> -Kurt
>
> p.s. the Encrypted version inherits from this one, so the patch fixes that
> one too.
>
>
>
> On 3/30/11 11:50 AM, Martynas A. (chainer) wrote:
>
> Kurt,
>
> Same happens with CryptedXMLDocAuthenticator. Fix that too. Btw when is it
> possible to expect the fix and in what form (new release/patch)?
>
> Martin
>
> 2011/3/30 Kurt T Stam <ku...@gmail.com>
>
>> Hi Martin,
>>
>> I can reproduce it now. The XMLDocAuthenticator has a bug and should be
>> returning a Publisher.
>> I reopened the issue.
>>
>> --Kurt
>>
>>
>> On 3/30/11 10:45 AM, Martynas A. (chainer) wrote:
>>
>> Yes, my code worked properly with 'juddi.authenticator =
>> org.apache.juddi.v3.auth.JUDDIAuthenticator' in juddi.properties, because it
>> was default and I wasn't playing around with authentication. I just changed
>> back to JUDDIAuthenticator to check and it works fine.
>>
>> 2011/3/30 Kurt T Stam <ku...@gmail.com>
>>
>>> OK I will try one more time. Are you saying it only happens when you
>>> change the authentication properties and users.xml?
>>>
>>> On 3/30/11 10:00 AM, Martynas A. (chainer) wrote:
>>>
>>> Kurt,
>>>
>>> Well I just simply tried to download a fresh
>>> 'juddi-portal-bundle-3.0.4.zip', unzip it, setup authentication in
>>> propeties, create users.xml, startup it and try to save publisher. Same
>>> exception. In my project I use only "juddi-client-3.0.4.jar" and
>>> "uddi-ws-.3.0.4.jar" which are related to juddi. No idea.
>>>
>>> --Martin
>>>
>>> 2011/3/30 Kurt T Stam <ku...@gmail.com>
>>>
>>>> Martin,
>>>>
>>>> The code is fine. Can it be you deployed the juddi-core.jar more then
>>>> once? It looks to me like that classcast might be caused by
>>>> classloading issues, or version mismatch.
>>>>
>>>> --Kurt
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator) problems
with saving/deleting Publishers
Posted by Kurt T Stam <ku...@gmail.com>.
Hi Martin,
All fixed. If you are using juddi-3.0.4, you should check out the source
for juddi-3.0.4, and apply the patch:
http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?p2=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&p1=%2Fjuddi%2Ftrunk%2Fjuddi-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjuddi%2Fv3%2Fauth%2FXMLDocAuthenticator.java&r1=1086999&r2=1086998&view=diff&pathrev=1086999
or simply replace it with
http://svn.apache.org/viewvc/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/v3/auth/XMLDocAuthenticator.java?revision=1086999&view=markup&pathrev=1086999
then from the juddi-core directory, run:
mvn clean install.
This is create a new juddi-core-3.0.4.jar in the target directory.
We will also soon release juddi-3.1.0 which will contain this fix.
Thx,
-Kurt
p.s. the Encrypted version inherits from this one, so the patch fixes
that one too.
On 3/30/11 11:50 AM, Martynas A. (chainer) wrote:
> Kurt,
>
> Same happens with CryptedXMLDocAuthenticator. Fix that too. Btw when
> is it possible to expect the fix and in what form (new release/patch)?
>
> Martin
>
> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com <ma...@gmail.com>>
>
> Hi Martin,
>
> I can reproduce it now. The XMLDocAuthenticator has a bug and
> should be returning a Publisher.
> I reopened the issue.
>
> --Kurt
>
>
> On 3/30/11 10:45 AM, Martynas A. (chainer) wrote:
>> Yes, my code worked properly with 'juddi.authenticator =
>> org.apache.juddi.v3.auth.JUDDIAuthenticator' in juddi.properties,
>> because it was default and I wasn't playing around with
>> authentication. I just changed back to JUDDIAuthenticator to
>> check and it works fine.
>>
>> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com
>> <ma...@gmail.com>>
>>
>> OK I will try one more time. Are you saying it only happens
>> when you change the authentication properties and users.xml?
>>
>> On 3/30/11 10:00 AM, Martynas A. (chainer) wrote:
>>> Kurt,
>>>
>>> Well I just simply tried to download a fresh
>>> 'juddi-portal-bundle-3.0.4.zip', unzip it, setup
>>> authentication in propeties, create users.xml, startup it
>>> and try to save publisher. Same exception. In my project I
>>> use only "juddi-client-3.0.4.jar" and "uddi-ws-.3.0.4.jar"
>>> which are related to juddi. No idea.
>>>
>>> --Martin
>>>
>>> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com
>>> <ma...@gmail.com>>
>>>
>>> Martin,
>>>
>>> The code is fine. Can it be you deployed the
>>> juddi-core.jar more then once? It looks to me like that
>>> classcast might be caused by
>>> classloading issues, or version mismatch.
>>>
>>> --Kurt
>>>
>>>
>>
>>
>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator)
problems with saving/deleting Publishers
Posted by "Martynas A. (chainer)" <ch...@gmail.com>.
Kurt,
Same happens with CryptedXMLDocAuthenticator. Fix that too. Btw when is it
possible to expect the fix and in what form (new release/patch)?
Martin
2011/3/30 Kurt T Stam <ku...@gmail.com>
> Hi Martin,
>
> I can reproduce it now. The XMLDocAuthenticator has a bug and should be
> returning a Publisher.
> I reopened the issue.
>
> --Kurt
>
>
> On 3/30/11 10:45 AM, Martynas A. (chainer) wrote:
>
> Yes, my code worked properly with 'juddi.authenticator =
> org.apache.juddi.v3.auth.JUDDIAuthenticator' in juddi.properties, because it
> was default and I wasn't playing around with authentication. I just changed
> back to JUDDIAuthenticator to check and it works fine.
>
> 2011/3/30 Kurt T Stam <ku...@gmail.com>
>
>> OK I will try one more time. Are you saying it only happens when you
>> change the authentication properties and users.xml?
>>
>> On 3/30/11 10:00 AM, Martynas A. (chainer) wrote:
>>
>> Kurt,
>>
>> Well I just simply tried to download a fresh
>> 'juddi-portal-bundle-3.0.4.zip', unzip it, setup authentication in
>> propeties, create users.xml, startup it and try to save publisher. Same
>> exception. In my project I use only "juddi-client-3.0.4.jar" and
>> "uddi-ws-.3.0.4.jar" which are related to juddi. No idea.
>>
>> --Martin
>>
>> 2011/3/30 Kurt T Stam <ku...@gmail.com>
>>
>>> Martin,
>>>
>>> The code is fine. Can it be you deployed the juddi-core.jar more then
>>> once? It looks to me like that classcast might be caused by
>>> classloading issues, or version mismatch.
>>>
>>> --Kurt
>>>
>>>
>>>
>>
>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator) problems
with saving/deleting Publishers
Posted by Kurt T Stam <ku...@gmail.com>.
Hi Martin,
I can reproduce it now. The XMLDocAuthenticator has a bug and should be
returning a Publisher.
I reopened the issue.
--Kurt
On 3/30/11 10:45 AM, Martynas A. (chainer) wrote:
> Yes, my code worked properly with 'juddi.authenticator =
> org.apache.juddi.v3.auth.JUDDIAuthenticator' in juddi.properties,
> because it was default and I wasn't playing around with
> authentication. I just changed back to JUDDIAuthenticator to check and
> it works fine.
>
> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com <ma...@gmail.com>>
>
> OK I will try one more time. Are you saying it only happens when
> you change the authentication properties and users.xml?
>
> On 3/30/11 10:00 AM, Martynas A. (chainer) wrote:
>> Kurt,
>>
>> Well I just simply tried to download a fresh
>> 'juddi-portal-bundle-3.0.4.zip', unzip it, setup authentication
>> in propeties, create users.xml, startup it and try to save
>> publisher. Same exception. In my project I use only
>> "juddi-client-3.0.4.jar" and "uddi-ws-.3.0.4.jar" which are
>> related to juddi. No idea.
>>
>> --Martin
>>
>> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com
>> <ma...@gmail.com>>
>>
>> Martin,
>>
>> The code is fine. Can it be you deployed the juddi-core.jar
>> more then once? It looks to me like that classcast might be
>> caused by
>> classloading issues, or version mismatch.
>>
>> --Kurt
>>
>>
>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator)
problems with saving/deleting Publishers
Posted by "Martynas A. (chainer)" <ch...@gmail.com>.
Yes, my code worked properly with 'juddi.authenticator =
org.apache.juddi.v3.auth.JUDDIAuthenticator' in juddi.properties, because it
was default and I wasn't playing around with authentication. I just changed
back to JUDDIAuthenticator to check and it works fine.
2011/3/30 Kurt T Stam <ku...@gmail.com>
> OK I will try one more time. Are you saying it only happens when you
> change the authentication properties and users.xml?
>
> On 3/30/11 10:00 AM, Martynas A. (chainer) wrote:
>
> Kurt,
>
> Well I just simply tried to download a fresh
> 'juddi-portal-bundle-3.0.4.zip', unzip it, setup authentication in
> propeties, create users.xml, startup it and try to save publisher. Same
> exception. In my project I use only "juddi-client-3.0.4.jar" and
> "uddi-ws-.3.0.4.jar" which are related to juddi. No idea.
>
> --Martin
>
> 2011/3/30 Kurt T Stam <ku...@gmail.com>
>
>> Martin,
>>
>> The code is fine. Can it be you deployed the juddi-core.jar more then
>> once? It looks to me like that classcast might be caused by
>> classloading issues, or version mismatch.
>>
>> --Kurt
>>
>>
>>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator) problems
with saving/deleting Publishers
Posted by Kurt T Stam <ku...@gmail.com>.
OK I will try one more time. Are you saying it only happens when you
change the authentication properties and users.xml?
On 3/30/11 10:00 AM, Martynas A. (chainer) wrote:
> Kurt,
>
> Well I just simply tried to download a fresh
> 'juddi-portal-bundle-3.0.4.zip', unzip it, setup authentication in
> propeties, create users.xml, startup it and try to save publisher.
> Same exception. In my project I use only "juddi-client-3.0.4.jar" and
> "uddi-ws-.3.0.4.jar" which are related to juddi. No idea.
>
> --Martin
>
> 2011/3/30 Kurt T Stam <kurt.stam@gmail.com <ma...@gmail.com>>
>
> Martin,
>
> The code is fine. Can it be you deployed the juddi-core.jar more
> then once? It looks to me like that classcast might be caused by
> classloading issues, or version mismatch.
>
> --Kurt
>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator)
problems with saving/deleting Publishers
Posted by "Martynas A. (chainer)" <ch...@gmail.com>.
Kurt,
Well I just simply tried to download a fresh
'juddi-portal-bundle-3.0.4.zip', unzip it, setup authentication in
propeties, create users.xml, startup it and try to save publisher. Same
exception. In my project I use only "juddi-client-3.0.4.jar" and
"uddi-ws-.3.0.4.jar" which are related to juddi. No idea.
--Martin
2011/3/30 Kurt T Stam <ku...@gmail.com>
> Martin,
>
> The code is fine. Can it be you deployed the juddi-core.jar more then once?
> It looks to me like that classcast might be caused by
> classloading issues, or version mismatch.
>
> --Kurt
>
>
> On 3/30/11 9:08 AM, Kurt T Stam wrote:
>
> Hi Martin
>
> This is good info! It looks like a bug in our core code and I opened a jira
> for it:
> http://issues.apache.org/jira/browse/JUDDI-466
>
> It should be fixed soon.
>
> Thanks for finding it :)
>
> --Kurt
>
> On 3/30/11 4:16 AM, Martynas A. (chainer) wrote:
>
> Hey Kurt,
>
> Here is the log from Catalina: http://codepaste.net/abrvqa
>
> 2011/3/29 Kurt T Stam <ku...@gmail.com>
>
>> Hi Martin,
>>
>> Can you check the juddi.log on the server side for stacktraces?
>> You are doing something very similar to what we do in the unittests (and
>> it works fine there), so I'm not sure what's going on.
>>
>> It should never deal with anything org.apache.juddi.model.* on the client
>> side. And I can't tell where it is trying a cast either..
>>
>> Thx,
>>
>> --Kurt
>>
>>
>> On 3/29/11 9:17 AM, chainerlt wrote:
>>
>>>
>>> Kurt wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> Your code fragments don't really tell the whole story, can you attach
>>>> all code and the
>>>> full stack trace?
>>>>
>>>> --Kurt
>>>>
>>>> Hi again,
>>>
>>> well I'm not gonna post whole project, since it is just too big, but I'm
>>> gonna show the classes which gets involved in this problem.
>>>
>>> so Here are 2 important classes which does work around with juddiv3.
>>> Tools class which operates with juddiv3 directly:
>>> Tools - http://codepaste.net/dijvwq
>>> and QueryBuilder which builds queries in a static way:
>>> QueryBuilder - http://codepaste.net/radvpa
>>> Some classes you might be interested in:
>>> FindQualifiersAbbreviations - http://codepaste.net/bw4oye
>>> SwingWorkerCompletionWaiter - http://codepaste.net/wwygis
>>>
>>> Let me remind I already set up XMLDocAuthenticator in
>>> ~\webapps\juddiv3\WEB-INF\classes\juddiv3.properties :
>>>
>>>
>>> juddi.authenticator = org.apache.juddi.v3.auth.XMLDocAuthenticator
>>>> juddi.usersfile = juddi-users.xml
>>>>
>>>> Have ~\webapps\juddiv3\WEB-INF\classes\juddi-users.xml which is:
>>>
>>>
>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>>>> <juddi-users>
>>>> <user userid="anou_mana" password="password" />
>>>> <user userid="bozo" password="clown" />
>>>> <user userid="sviens" password="password" />
>>>> <user userid="admin" password="secret" />
>>>> </juddi-users>
>>>>
>>>> So everything seems to be working: I can get AuthToken using
>>> credentials.
>>> Also authorized users can save/delete business/services and etc. But
>>> problems appears in working with Publishers. I can view them, but cannot
>>> save/delete (throws exception).
>>> The main idea of the architecture: You build queries with QueryBuilder
>>> and
>>> pass them to Tools so it will return feedback depending on what query you
>>> gave to it.
>>> For instance let me show simplified code example of how I view all
>>> publishers:
>>>
>>>
>>> //Let's imagine we have a valid auth token with admin rights.
>>>> AuthToken authToken = ?;
>>>> //Build query (GetAllPublisherDetail)
>>>> Object query = QueryBuilder.GetAllPublisherDetail(authToken);
>>>> //Pass to the tools object so it can manage it and give me the
>>>> feedback
>>>> Object feedback = tools.submitQuery(null, query);
>>>> //the feedback should be PublisherDetail object or null.
>>>> //(I'm not adding exception handling here, so code could be more
>>>> easy to
>>>> read)
>>>> //Lets say it gives me PublisherDetail which I know contains all
>>>> publishers,
>>>> //and .getPublisher() will give me non-empty List<Publisher>.
>>>> //Lets take first Publisher from here:
>>>> Publisher p = ((PublisherDetail)feedback).getPublisher().get(0);
>>>> //Okay, lets imagine we edited this publisher a bit and now we
>>>> wanna save
>>>> it:
>>>> //Build query (SavePublisher)
>>>> query = QueryBuilder.GetSavePublisher(p ,authToken);
>>>> //Pass it to the tools, and expect PublisherDetail object as a
>>>> feedback
>>>> feedback = tools.submitQuery(null, query); //but here I get the
>>>> exception
>>>>
>>>> The exception:
>>>
>>>
>>> javax.xml.ws.soap.SOAPFaultException:
>>>> org.apache.juddi.model.UddiEntityPublisher cannot be cast to
>>>> org.apache.juddi.model.Publisher
>>>> at
>>>>
>>>> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
>>>> at
>>>>
>>>> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:111)
>>>> at
>>>>
>>>> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
>>>> at
>>>>
>>>> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
>>>> at
>>>> com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
>>>> at $Proxy40.savePublisher(Unknown Source)
>>>> at
>>>> juddiv3admin.juddiv3.Tools$PublisherWorker.savePublisher(Tools.java:200)
>>>> at juddiv3admin.juddiv3.Tools$1.doInBackground(Tools.java:170)
>>>> at javax.swing.SwingWorker$1.call(SwingWorker.java:277)
>>>> at
>>>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>>>> at javax.swing.SwingWorker.run(SwingWorker.java:316)
>>>> at
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>>> at
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>>> at java.lang.Thread.run(Thread.java:662)
>>>>
>>>> Appears in this Tools class here:
>>>
>>>
>>> public PublisherDetail savePublisher(SavePublisher savePublisher) throws
>>>> Exception
>>>> {
>>>> return juddiApi.savePublisher(savePublisher);
>>>> }
>>>>
>>>> Looking for answer, thank you.
>>> --Martin
>>>
>>
>>
>
>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator) problems
with saving/deleting Publishers
Posted by Kurt T Stam <ku...@gmail.com>.
Martin,
The code is fine. Can it be you deployed the juddi-core.jar more then
once? It looks to me like that classcast might be caused by
classloading issues, or version mismatch.
--Kurt
On 3/30/11 9:08 AM, Kurt T Stam wrote:
> Hi Martin
>
> This is good info! It looks like a bug in our core code and I opened a
> jira for it:
> http://issues.apache.org/jira/browse/JUDDI-466
>
> It should be fixed soon.
>
> Thanks for finding it :)
>
> --Kurt
>
> On 3/30/11 4:16 AM, Martynas A. (chainer) wrote:
>> Hey Kurt,
>>
>> Here is the log from Catalina: http://codepaste.net/abrvqa
>>
>> 2011/3/29 Kurt T Stam <kurt.stam@gmail.com <ma...@gmail.com>>
>>
>> Hi Martin,
>>
>> Can you check the juddi.log on the server side for stacktraces?
>> You are doing something very similar to what we do in the
>> unittests (and it works fine there), so I'm not sure what's going on.
>>
>> It should never deal with anything org.apache.juddi.model.* on
>> the client side. And I can't tell where it is trying a cast either..
>>
>> Thx,
>>
>> --Kurt
>>
>>
>> On 3/29/11 9:17 AM, chainerlt wrote:
>>
>>
>> Kurt wrote:
>>
>> Hi Martin,
>>
>> Your code fragments don't really tell the whole story,
>> can you attach
>> all code and the
>> full stack trace?
>>
>> --Kurt
>>
>> Hi again,
>>
>> well I'm not gonna post whole project, since it is just too
>> big, but I'm
>> gonna show the classes which gets involved in this problem.
>>
>> so Here are 2 important classes which does work around with
>> juddiv3.
>> Tools class which operates with juddiv3 directly:
>> Tools - http://codepaste.net/dijvwq
>> and QueryBuilder which builds queries in a static way:
>> QueryBuilder - http://codepaste.net/radvpa
>> Some classes you might be interested in:
>> FindQualifiersAbbreviations - http://codepaste.net/bw4oye
>> SwingWorkerCompletionWaiter - http://codepaste.net/wwygis
>>
>> Let me remind I already set up XMLDocAuthenticator in
>> ~\webapps\juddiv3\WEB-INF\classes\juddiv3.properties :
>>
>>
>> juddi.authenticator =
>> org.apache.juddi.v3.auth.XMLDocAuthenticator
>> juddi.usersfile = juddi-users.xml
>>
>> Have ~\webapps\juddiv3\WEB-INF\classes\juddi-users.xml which is:
>>
>>
>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>> <juddi-users>
>> <user userid="anou_mana" password="password" />
>> <user userid="bozo" password="clown" />
>> <user userid="sviens" password="password" />
>> <user userid="admin" password="secret" />
>> </juddi-users>
>>
>> So everything seems to be working: I can get AuthToken using
>> credentials.
>> Also authorized users can save/delete business/services and
>> etc. But
>> problems appears in working with Publishers. I can view them,
>> but cannot
>> save/delete (throws exception).
>> The main idea of the architecture: You build queries with
>> QueryBuilder and
>> pass them to Tools so it will return feedback depending on
>> what query you
>> gave to it.
>> For instance let me show simplified code example of how I
>> view all
>> publishers:
>>
>>
>> //Let's imagine we have a valid auth token with
>> admin rights.
>> AuthToken authToken = ?;
>> //Build query (GetAllPublisherDetail)
>> Object query = QueryBuilder.GetAllPublisherDetail(authToken);
>> //Pass to the tools object so it can manage it and
>> give me the feedback
>> Object feedback = tools.submitQuery(null, query);
>> //the feedback should be PublisherDetail object or
>> null.
>> //(I'm not adding exception handling here, so code
>> could be more easy to
>> read)
>> //Lets say it gives me PublisherDetail which I
>> know contains all
>> publishers,
>> //and .getPublisher() will give me non-empty
>> List<Publisher>.
>> //Lets take first Publisher from here:
>> Publisher p =
>> ((PublisherDetail)feedback).getPublisher().get(0);
>> //Okay, lets imagine we edited this publisher a
>> bit and now we wanna save
>> it:
>> //Build query (SavePublisher)
>> query = QueryBuilder.GetSavePublisher(p ,authToken);
>> //Pass it to the tools, and expect PublisherDetail
>> object as a feedback
>> feedback = tools.submitQuery(null, query); //but here I
>> get the exception
>>
>> The exception:
>>
>>
>> javax.xml.ws.soap.SOAPFaultException:
>> org.apache.juddi.model.UddiEntityPublisher cannot be cast to
>> org.apache.juddi.model.Publisher
>> at
>> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
>> at
>> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:111)
>> at
>> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
>> at
>> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
>> at
>> com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
>> at $Proxy40.savePublisher(Unknown Source)
>> at
>> juddiv3admin.juddiv3.Tools$PublisherWorker.savePublisher(Tools.java:200)
>> at
>> juddiv3admin.juddiv3.Tools$1.doInBackground(Tools.java:170)
>> at
>> javax.swing.SwingWorker$1.call(SwingWorker.java:277)
>> at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at
>> java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at javax.swing.SwingWorker.run(SwingWorker.java:316)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>> at java.lang.Thread.run(Thread.java:662)
>>
>> Appears in this Tools class here:
>>
>>
>> public PublisherDetail savePublisher(SavePublisher
>> savePublisher) throws
>> Exception
>> {
>> return juddiApi.savePublisher(savePublisher);
>> }
>>
>> Looking for answer, thank you.
>> --Martin
>>
>>
>>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator) problems
with saving/deleting Publishers
Posted by Kurt T Stam <ku...@gmail.com>.
Hi Martin
This is good info! It looks like a bug in our core code and I opened a
jira for it:
http://issues.apache.org/jira/browse/JUDDI-466
It should be fixed soon.
Thanks for finding it :)
--Kurt
On 3/30/11 4:16 AM, Martynas A. (chainer) wrote:
> Hey Kurt,
>
> Here is the log from Catalina: http://codepaste.net/abrvqa
>
> 2011/3/29 Kurt T Stam <kurt.stam@gmail.com <ma...@gmail.com>>
>
> Hi Martin,
>
> Can you check the juddi.log on the server side for stacktraces?
> You are doing something very similar to what we do in the
> unittests (and it works fine there), so I'm not sure what's going on.
>
> It should never deal with anything org.apache.juddi.model.* on the
> client side. And I can't tell where it is trying a cast either..
>
> Thx,
>
> --Kurt
>
>
> On 3/29/11 9:17 AM, chainerlt wrote:
>
>
> Kurt wrote:
>
> Hi Martin,
>
> Your code fragments don't really tell the whole story, can
> you attach
> all code and the
> full stack trace?
>
> --Kurt
>
> Hi again,
>
> well I'm not gonna post whole project, since it is just too
> big, but I'm
> gonna show the classes which gets involved in this problem.
>
> so Here are 2 important classes which does work around with
> juddiv3.
> Tools class which operates with juddiv3 directly:
> Tools - http://codepaste.net/dijvwq
> and QueryBuilder which builds queries in a static way:
> QueryBuilder - http://codepaste.net/radvpa
> Some classes you might be interested in:
> FindQualifiersAbbreviations - http://codepaste.net/bw4oye
> SwingWorkerCompletionWaiter - http://codepaste.net/wwygis
>
> Let me remind I already set up XMLDocAuthenticator in
> ~\webapps\juddiv3\WEB-INF\classes\juddiv3.properties :
>
>
> juddi.authenticator =
> org.apache.juddi.v3.auth.XMLDocAuthenticator
> juddi.usersfile = juddi-users.xml
>
> Have ~\webapps\juddiv3\WEB-INF\classes\juddi-users.xml which is:
>
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <juddi-users>
> <user userid="anou_mana" password="password" />
> <user userid="bozo" password="clown" />
> <user userid="sviens" password="password" />
> <user userid="admin" password="secret" />
> </juddi-users>
>
> So everything seems to be working: I can get AuthToken using
> credentials.
> Also authorized users can save/delete business/services and
> etc. But
> problems appears in working with Publishers. I can view them,
> but cannot
> save/delete (throws exception).
> The main idea of the architecture: You build queries with
> QueryBuilder and
> pass them to Tools so it will return feedback depending on
> what query you
> gave to it.
> For instance let me show simplified code example of how I view all
> publishers:
>
>
> //Let's imagine we have a valid auth token with
> admin rights.
> AuthToken authToken = ?;
> //Build query (GetAllPublisherDetail)
> Object query = QueryBuilder.GetAllPublisherDetail(authToken);
> //Pass to the tools object so it can manage it and
> give me the feedback
> Object feedback = tools.submitQuery(null, query);
> //the feedback should be PublisherDetail object or
> null.
> //(I'm not adding exception handling here, so code
> could be more easy to
> read)
> //Lets say it gives me PublisherDetail which I know
> contains all
> publishers,
> //and .getPublisher() will give me non-empty
> List<Publisher>.
> //Lets take first Publisher from here:
> Publisher p =
> ((PublisherDetail)feedback).getPublisher().get(0);
> //Okay, lets imagine we edited this publisher a bit
> and now we wanna save
> it:
> //Build query (SavePublisher)
> query = QueryBuilder.GetSavePublisher(p ,authToken);
> //Pass it to the tools, and expect PublisherDetail
> object as a feedback
> feedback = tools.submitQuery(null, query); //but here I
> get the exception
>
> The exception:
>
>
> javax.xml.ws.soap.SOAPFaultException:
> org.apache.juddi.model.UddiEntityPublisher cannot be cast to
> org.apache.juddi.model.Publisher
> at
> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
> at
> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:111)
> at
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
> at
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
> at
> com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
> at $Proxy40.savePublisher(Unknown Source)
> at
> juddiv3admin.juddiv3.Tools$PublisherWorker.savePublisher(Tools.java:200)
> at
> juddiv3admin.juddiv3.Tools$1.doInBackground(Tools.java:170)
> at
> javax.swing.SwingWorker$1.call(SwingWorker.java:277)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at
> java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at javax.swing.SwingWorker.run(SwingWorker.java:316)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
>
> Appears in this Tools class here:
>
>
> public PublisherDetail savePublisher(SavePublisher
> savePublisher) throws
> Exception
> {
> return juddiApi.savePublisher(savePublisher);
> }
>
> Looking for answer, thank you.
> --Martin
>
>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator)
problems with saving/deleting Publishers
Posted by "Martynas A. (chainer)" <ch...@gmail.com>.
Hey Kurt,
Here is the log from Catalina: http://codepaste.net/abrvqa
2011/3/29 Kurt T Stam <ku...@gmail.com>
> Hi Martin,
>
> Can you check the juddi.log on the server side for stacktraces?
> You are doing something very similar to what we do in the unittests (and it
> works fine there), so I'm not sure what's going on.
>
> It should never deal with anything org.apache.juddi.model.* on the client
> side. And I can't tell where it is trying a cast either..
>
> Thx,
>
> --Kurt
>
>
> On 3/29/11 9:17 AM, chainerlt wrote:
>
>>
>> Kurt wrote:
>>
>>> Hi Martin,
>>>
>>> Your code fragments don't really tell the whole story, can you attach
>>> all code and the
>>> full stack trace?
>>>
>>> --Kurt
>>>
>>> Hi again,
>>
>> well I'm not gonna post whole project, since it is just too big, but I'm
>> gonna show the classes which gets involved in this problem.
>>
>> so Here are 2 important classes which does work around with juddiv3.
>> Tools class which operates with juddiv3 directly:
>> Tools - http://codepaste.net/dijvwq
>> and QueryBuilder which builds queries in a static way:
>> QueryBuilder - http://codepaste.net/radvpa
>> Some classes you might be interested in:
>> FindQualifiersAbbreviations - http://codepaste.net/bw4oye
>> SwingWorkerCompletionWaiter - http://codepaste.net/wwygis
>>
>> Let me remind I already set up XMLDocAuthenticator in
>> ~\webapps\juddiv3\WEB-INF\classes\juddiv3.properties :
>>
>>
>> juddi.authenticator = org.apache.juddi.v3.auth.XMLDocAuthenticator
>>> juddi.usersfile = juddi-users.xml
>>>
>>> Have ~\webapps\juddiv3\WEB-INF\classes\juddi-users.xml which is:
>>
>>
>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>>> <juddi-users>
>>> <user userid="anou_mana" password="password" />
>>> <user userid="bozo" password="clown" />
>>> <user userid="sviens" password="password" />
>>> <user userid="admin" password="secret" />
>>> </juddi-users>
>>>
>>> So everything seems to be working: I can get AuthToken using
>> credentials.
>> Also authorized users can save/delete business/services and etc. But
>> problems appears in working with Publishers. I can view them, but cannot
>> save/delete (throws exception).
>> The main idea of the architecture: You build queries with QueryBuilder and
>> pass them to Tools so it will return feedback depending on what query you
>> gave to it.
>> For instance let me show simplified code example of how I view all
>> publishers:
>>
>>
>> //Let's imagine we have a valid auth token with admin rights.
>>> AuthToken authToken = ?;
>>> //Build query (GetAllPublisherDetail)
>>> Object query = QueryBuilder.GetAllPublisherDetail(authToken);
>>> //Pass to the tools object so it can manage it and give me the
>>> feedback
>>> Object feedback = tools.submitQuery(null, query);
>>> //the feedback should be PublisherDetail object or null.
>>> //(I'm not adding exception handling here, so code could be more
>>> easy to
>>> read)
>>> //Lets say it gives me PublisherDetail which I know contains all
>>> publishers,
>>> //and .getPublisher() will give me non-empty List<Publisher>.
>>> //Lets take first Publisher from here:
>>> Publisher p = ((PublisherDetail)feedback).getPublisher().get(0);
>>> //Okay, lets imagine we edited this publisher a bit and now we
>>> wanna save
>>> it:
>>> //Build query (SavePublisher)
>>> query = QueryBuilder.GetSavePublisher(p ,authToken);
>>> //Pass it to the tools, and expect PublisherDetail object as a
>>> feedback
>>> feedback = tools.submitQuery(null, query); //but here I get the exception
>>>
>>> The exception:
>>
>>
>> javax.xml.ws.soap.SOAPFaultException:
>>> org.apache.juddi.model.UddiEntityPublisher cannot be cast to
>>> org.apache.juddi.model.Publisher
>>> at
>>>
>>> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
>>> at
>>>
>>> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:111)
>>> at
>>>
>>> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
>>> at
>>>
>>> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
>>> at
>>> com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
>>> at $Proxy40.savePublisher(Unknown Source)
>>> at
>>> juddiv3admin.juddiv3.Tools$PublisherWorker.savePublisher(Tools.java:200)
>>> at juddiv3admin.juddiv3.Tools$1.doInBackground(Tools.java:170)
>>> at javax.swing.SwingWorker$1.call(SwingWorker.java:277)
>>> at
>>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>>> at javax.swing.SwingWorker.run(SwingWorker.java:316)
>>> at
>>>
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>> at
>>>
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>> at java.lang.Thread.run(Thread.java:662)
>>>
>>> Appears in this Tools class here:
>>
>>
>> public PublisherDetail savePublisher(SavePublisher savePublisher) throws
>>> Exception
>>> {
>>> return juddiApi.savePublisher(savePublisher);
>>> }
>>>
>>> Looking for answer, thank you.
>> --Martin
>>
>
>
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator) problems
with saving/deleting Publishers
Posted by Kurt T Stam <ku...@gmail.com>.
Hi Martin,
Can you check the juddi.log on the server side for stacktraces?
You are doing something very similar to what we do in the unittests (and
it works fine there), so I'm not sure what's going on.
It should never deal with anything org.apache.juddi.model.* on the
client side. And I can't tell where it is trying a cast either..
Thx,
--Kurt
On 3/29/11 9:17 AM, chainerlt wrote:
>
> Kurt wrote:
>> Hi Martin,
>>
>> Your code fragments don't really tell the whole story, can you attach
>> all code and the
>> full stack trace?
>>
>> --Kurt
>>
> Hi again,
>
> well I'm not gonna post whole project, since it is just too big, but I'm
> gonna show the classes which gets involved in this problem.
>
> so Here are 2 important classes which does work around with juddiv3.
> Tools class which operates with juddiv3 directly:
> Tools - http://codepaste.net/dijvwq
> and QueryBuilder which builds queries in a static way:
> QueryBuilder - http://codepaste.net/radvpa
> Some classes you might be interested in:
> FindQualifiersAbbreviations - http://codepaste.net/bw4oye
> SwingWorkerCompletionWaiter - http://codepaste.net/wwygis
>
> Let me remind I already set up XMLDocAuthenticator in
> ~\webapps\juddiv3\WEB-INF\classes\juddiv3.properties :
>
>
>> juddi.authenticator = org.apache.juddi.v3.auth.XMLDocAuthenticator
>> juddi.usersfile = juddi-users.xml
>>
> Have ~\webapps\juddiv3\WEB-INF\classes\juddi-users.xml which is:
>
>
>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>> <juddi-users>
>> <user userid="anou_mana" password="password" />
>> <user userid="bozo" password="clown" />
>> <user userid="sviens" password="password" />
>> <user userid="admin" password="secret" />
>> </juddi-users>
>>
> So everything seems to be working: I can get AuthToken using credentials.
> Also authorized users can save/delete business/services and etc. But
> problems appears in working with Publishers. I can view them, but cannot
> save/delete (throws exception).
> The main idea of the architecture: You build queries with QueryBuilder and
> pass them to Tools so it will return feedback depending on what query you
> gave to it.
> For instance let me show simplified code example of how I view all
> publishers:
>
>
>> //Let's imagine we have a valid auth token with admin rights.
>> AuthToken authToken = ?;
>> //Build query (GetAllPublisherDetail)
>> Object query = QueryBuilder.GetAllPublisherDetail(authToken);
>> //Pass to the tools object so it can manage it and give me the feedback
>> Object feedback = tools.submitQuery(null, query);
>> //the feedback should be PublisherDetail object or null.
>> //(I'm not adding exception handling here, so code could be more easy to
>> read)
>> //Lets say it gives me PublisherDetail which I know contains all
>> publishers,
>> //and .getPublisher() will give me non-empty List<Publisher>.
>> //Lets take first Publisher from here:
>> Publisher p = ((PublisherDetail)feedback).getPublisher().get(0);
>> //Okay, lets imagine we edited this publisher a bit and now we wanna save
>> it:
>> //Build query (SavePublisher)
>> query = QueryBuilder.GetSavePublisher(p ,authToken);
>> //Pass it to the tools, and expect PublisherDetail object as a feedback
>> feedback = tools.submitQuery(null, query); //but here I get the exception
>>
> The exception:
>
>
>> javax.xml.ws.soap.SOAPFaultException:
>> org.apache.juddi.model.UddiEntityPublisher cannot be cast to
>> org.apache.juddi.model.Publisher
>> at
>> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
>> at
>> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:111)
>> at
>> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
>> at
>> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
>> at
>> com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
>> at $Proxy40.savePublisher(Unknown Source)
>> at
>> juddiv3admin.juddiv3.Tools$PublisherWorker.savePublisher(Tools.java:200)
>> at juddiv3admin.juddiv3.Tools$1.doInBackground(Tools.java:170)
>> at javax.swing.SwingWorker$1.call(SwingWorker.java:277)
>> at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at javax.swing.SwingWorker.run(SwingWorker.java:316)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>> at java.lang.Thread.run(Thread.java:662)
>>
> Appears in this Tools class here:
>
>
>> public PublisherDetail savePublisher(SavePublisher savePublisher) throws
>> Exception
>> {
>> return juddiApi.savePublisher(savePublisher);
>> }
>>
> Looking for answer, thank you.
> --Martin
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator)
problems with saving/deleting Publishers
Posted by chainerlt <ch...@gmail.com>.
Kurt wrote:
>
> Hi Martin,
>
> Your code fragments don't really tell the whole story, can you attach
> all code and the
> full stack trace?
>
> --Kurt
>
Hi again,
well I'm not gonna post whole project, since it is just too big, but I'm
gonna show the classes which gets involved in this problem.
so Here are 2 important classes which does work around with juddiv3.
Tools class which operates with juddiv3 directly:
Tools - http://codepaste.net/dijvwq
and QueryBuilder which builds queries in a static way:
QueryBuilder - http://codepaste.net/radvpa
Some classes you might be interested in:
FindQualifiersAbbreviations - http://codepaste.net/bw4oye
SwingWorkerCompletionWaiter - http://codepaste.net/wwygis
Let me remind I already set up XMLDocAuthenticator in
~\webapps\juddiv3\WEB-INF\classes\juddiv3.properties :
> juddi.authenticator = org.apache.juddi.v3.auth.XMLDocAuthenticator
> juddi.usersfile = juddi-users.xml
>
Have ~\webapps\juddiv3\WEB-INF\classes\juddi-users.xml which is:
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <juddi-users>
> <user userid="anou_mana" password="password" />
> <user userid="bozo" password="clown" />
> <user userid="sviens" password="password" />
> <user userid="admin" password="secret" />
> </juddi-users>
>
So everything seems to be working: I can get AuthToken using credentials.
Also authorized users can save/delete business/services and etc. But
problems appears in working with Publishers. I can view them, but cannot
save/delete (throws exception).
The main idea of the architecture: You build queries with QueryBuilder and
pass them to Tools so it will return feedback depending on what query you
gave to it.
For instance let me show simplified code example of how I view all
publishers:
> //Let's imagine we have a valid auth token with admin rights.
> AuthToken authToken = ?;
> //Build query (GetAllPublisherDetail)
> Object query = QueryBuilder.GetAllPublisherDetail(authToken);
> //Pass to the tools object so it can manage it and give me the feedback
> Object feedback = tools.submitQuery(null, query);
> //the feedback should be PublisherDetail object or null.
> //(I'm not adding exception handling here, so code could be more easy to
> read)
> //Lets say it gives me PublisherDetail which I know contains all
> publishers,
> //and .getPublisher() will give me non-empty List<Publisher>.
> //Lets take first Publisher from here:
> Publisher p = ((PublisherDetail)feedback).getPublisher().get(0);
> //Okay, lets imagine we edited this publisher a bit and now we wanna save
> it:
> //Build query (SavePublisher)
> query = QueryBuilder.GetSavePublisher(p ,authToken);
> //Pass it to the tools, and expect PublisherDetail object as a feedback
> feedback = tools.submitQuery(null, query); //but here I get the exception
>
The exception:
> javax.xml.ws.soap.SOAPFaultException:
> org.apache.juddi.model.UddiEntityPublisher cannot be cast to
> org.apache.juddi.model.Publisher
> at
> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
> at
> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:111)
> at
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
> at
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
> at
> com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
> at $Proxy40.savePublisher(Unknown Source)
> at
> juddiv3admin.juddiv3.Tools$PublisherWorker.savePublisher(Tools.java:200)
> at juddiv3admin.juddiv3.Tools$1.doInBackground(Tools.java:170)
> at javax.swing.SwingWorker$1.call(SwingWorker.java:277)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at javax.swing.SwingWorker.run(SwingWorker.java:316)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
>
Appears in this Tools class here:
> public PublisherDetail savePublisher(SavePublisher savePublisher) throws
> Exception
> {
> return juddiApi.savePublisher(savePublisher);
> }
>
Looking for answer, thank you.
--Martin
--
View this message in context: http://old.nabble.com/juddiv3-%283.0.4%29-%22juddi.authenticator%22-%28XMLDocAuthenticator%29-problems-with-saving-deleting-Publishers-tp31259207p31267635.html
Sent from the jUDDI - User mailing list archive at Nabble.com.
Re: juddiv3 (3.0.4) "juddi.authenticator" (XMLDocAuthenticator) problems
with saving/deleting Publishers
Posted by Kurt T Stam <ku...@gmail.com>.
Hi Martin,
Your code fragments don't really tell the whole story, can you attach
all code and the
full stack trace?
--Kurt
On 3/28/11 11:07 AM, chainerlt wrote:
> So I got some problems using 'XMLDocAuthenticator'. The problem is described
> below at the end of the post in the last quote.
>
> Kurt wrote:
>> 3. That said, on your client you should only be using the
>> juddi-client.jar and the uddi-ws.jar, right now you seem to
>> be using the persistence classes (any classes in org.apache.juddi.model)
>> from the juddi-core.jar.
>>
> I were using only "org.apache.juddi.query.util.FindQualifiers" class for
> getting valid abbreviations. So I replaced it with my own class and removed
> it and also removed juddi-core.jar from buildpath.
> But java still throws me this exception:
>
>
>> javax.xml.ws.soap.SOAPFaultException:
>> org.apache.juddi.model.UddiEntityPublisher cannot be cast to
>> org.apache.juddi.model.Publisher
>>
> in
>
>
>> public PublisherDetail savePublisher(SavePublisher savePublisher)
>> throws Exception
>> {
>> return juddiApi.savePublisher(savePublisher);
>> }
>>
> As far as I understand this exception appears from overlapping classes which
> I import? So I checked my classes:
> I have QueryBuilder class (builds various FindBusiness, SavePublisher,
> DeleteService and similar objects in a static way) which imports:
>
>
>> import org.apache.juddi.api_v3.*;
>> import org.uddi.api_v3.*;
>>
> and Tools class (which works with UDDISecurityPortType, JUDDIApiPortType,
> UDDIPublicationPortType and UDDIInquiryPortType) which imports:
>
>
>> import org.apache.juddi.api_v3.*;
>> import org.apache.juddi.v3.client.ClassUtil;
>> import org.apache.juddi.v3.client.config.UDDIClientContainer;
>> import org.apache.juddi.v3.client.transport.Transport;
>> import org.apache.juddi.v3_service.JUDDIApiPortType;
>> import org.uddi.api_v3.*;
>> import org.uddi.v3_service.*;
>>
> These are the only two classes which involves into working with juddi.
>
> Btw, my name is Martin :-)
>
> #######################################################################