The first error looks like something related to Tomcat... can you describe 
the circumstances leading up to the error? Is it on the first request?

Andrew, can you respond to the second issue (related to the scripts 
question from yesterday)?

thanks,
Dan


[EMAIL PROTECTED] wrote on 11/17/2006 08:55:10 AM:

> Hi,
> 
> I have implemented the test driver that uses the client and am using 
> eclipse as IDE (just importing all Muse jar files to fix import issues I 

> had before), but I get an error.
> My test driver class is:
> /**
>  *
>  */
> import java.net.URI;
> import org.apache.muse.ws.addressing.EndpointReference;
> import org.apache.ws.muse.test.wsrf.WsResourceProxy;
> 
> /**
>  * @author bertrand
>  *
>  */
> public class MyTestClient {
> 
>     /**
>      * @param args
>      */
>     public static void main(String[] args) {
>         // TODO Auto-generated method stub
>         try {
>             // insert your endpoint's URI here
>             URI uri = 
> URI.create("http://localhost:8080/muse_test/services/WsResource";);
>             EndpointReference epr = new EndpointReference(uri);
> 
>             WsResourceProxy proxy = new WsResourceProxy(epr);
> 
>             // optional, but useful
>             proxy.setTrace(true);
> 
>             // get the ServerName resourceproperty
>             String serverName = proxy.getServerName();
> 
>             // invoke the WSN Subscribe operation
>             URI consumerURI = 
> URI.create("http://localhost:8080/muse_test/services/WsResource";);
>             EndpointReference consumer = new 
EndpointReference(consumerURI);
>             proxy.subscribe(consumer, null, null);
> 
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
> 
>     }
> 
> }
> 
> But I receive the output/error:
> [CLIENT TRACE] SOAP envelope contents (outgoing):
> 
> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope";>
>     <soap:Header>
>         <wsa:To 
> xmlns:wsa="http://www.w3.org/2005/08/addressing";>http://localhost:
> 8080/muse_test/services/WsResource</wsa:To>
>         <wsa:Action 
> xmlns:wsa="http://www.w3.org/2005/08/addressing";>http://docs.oasis-open.
> 
org/wsrf/rpw-2/GetResourceProperty/GetResourcePropertyRequest</wsa:Action>
>         <wsa:MessageID 
> 
xmlns:wsa="http://www.w3.org/2005/08/addressing";>uuid:bc1f0683-49e1-b58b-bca8-
> a42cbb3c8502</wsa:MessageID>
>         <wsa:From xmlns:wsa="http://www.w3.org/2005/08/addressing";>
> 
> 
<wsa:Address>http://www.w3.org/2005/08/addressing/role/anonymous</wsa:Address>
>         </wsa:From>
>     </soap:Header>
>     <soap:Body>
>         <wsrf-rp:GetResourceProperty
>             xmlns:wsrf-rp="http://docs.oasis-open.org/wsrf/rp-2"; 
> 
xmlns:pfx0="http://ws.apache.org/muse/test/wsrf";>pfx0:ServerName</wsrf-rp:
> GetResourceProperty>
>     </soap:Body>
> </soap:Envelope>
> 
> org.apache.muse.ws.addressing.soap.SoapFault: Already connected
>    at 
> 
org.apache.muse.core.AbstractResourceClient.invoke(AbstractResourceClient.java:254)
>    at 
> org.apache.muse.ws.resource.remote.WsResourceClient.
> getResourceProperty(WsResourceClient.java:134)
>    at 
> org.apache.muse.ws.resource.remote.WsResourceClient.
> getPropertyAsObject(WsResourceClient.java:126)
>    at org.apache.ws.muse.test.wsrf.WsResourceProxy.getServerName(Unknown 

> Source)
>    at MyTestClient.main(MyTestClient.java:30)
> 
> Something else, there are quite some files in the binary distribution 
> that are in DOS format and all lines end at ^M such as 
> /lib/axis2/WEB-INF/conf/axis2.xml . On *nix environments that is not 
> ideal for parsing by engines/shells. It is a bit of a shame to keep 
> using the dos2unix tool manually to change the files.
> 
> I appreciate you time/effort to help.
> 
> Best regards,
>     Bertrand
> 
> 
> Daniel Jemiolo wrote:
> > Hi - I added some answers inline:
> >
> >
> > [EMAIL PROTECTED] wrote on 11/16/2006 06:55:51 AM:
> >
> > 
> >> Hi all, Dan,
> >>
> >> Thank you for your comments. After your tips I started again on the 
> >> tutorial, but found some small issues:
> >> * On this page: 
> >>
> >> 
> > 
http://ws.apache.org/muse/docs/2.0.0/tutorial/06-custom-capabilities.html 
> > 
> >> I followed the instructions and afterwards run the ant tool, however 
it 
> >> gave some errors. I looked at the sample file in 
> >>
> >> 
> > 
sample/wsn-producer/src/org/apache/ws/muse/test/wsrf/MyCapabilityImpl.java 

> >
> > 
> >> and there I saw that there were some imports I did not have and there 

> >> was a declaration I did not have:
> >> import org.apache.muse.ws.addressing.soap.SoapFault;
> >> import org.apache.muse.ws.notification.NotificationProducer;
> >> import org.apache.muse.ws.notification.WsnConstants;
> >> import org.apache.muse.util.xml.XmlUtils;
> >> import org.w3c.dom.Element;
> >> private static final QName _TOPIC_NAME = new QName(NAMESPACE_URI, 
> >> "MyTopic", PREFIX);
> >>
> >> Should these imports normally be done automatically? Maybe I skipped 
a 
> >> step or something? It might be cool to know from the start of the 
> >> tutorial that there is a sample directory where the files of this 
> >> tutorial can all be found back (they might even include the XSD and 
WSDL 
> >> 
> >
> > 
> >> files...) so you can compare your own work with how it should look.
> >> 
> >
> > <danj>
> > If you under the "Implementation Code" section on that page, we list 
the 
> > code as it was generated - not much there except getters, setters, and 

> > empty methods. The code below that is the code needed to implement the 

> > capability logic discussed - you should copy and paste it into your 
> > MyCapability.java file to make it complete. Most IDEs should help you 
fill 
> > in the imports pretty easily.
> > </danj>
> >
> > 
> >> * I found that my muse.xml file contained entries like this:
> >> <desc:capability xmlns:desc="http://ws.apache.org/muse/descriptor";>
> >>
> >> <desc:capability-uri>http://docs.oasis-open.
> >> org/wsrf/rlw-2/ImmediateResourceTermination</desc:capability-uri>
> >>
> >> 
<desc:java-capability-class>org.apache.muse.ws.resource.lifetime.impl.
> >> SimpleImmediateTermination</desc:java-capability-class> 
> >> </desc:capability>
> >>
> >> Where the one of the sample contains:
> >> <capability>
> >>
> >> <capability-uri>http://docs.oasis-open.
> >> org/wsrf/rlw-2/ImmediateResourceTermination</capability-uri>
> >>
> >> <java-capability-class>org.apache.muse.ws.resource.lifetime.impl.
> >> SimpleImmediateTermination</java-capability-class>
> >> </capability>
> >>
> >> Why is this, I would have expected them to be some sort of the same 
> >> format since they were made with the same tool?
> >> 
> >
> > <danj>
> > The XML is the same - it's just a matter of using prefixes vs. default 

> > namespaces. The sample XML you show that doesn't have prefixes wasn't 
> > created with the tool - it was created long ago, by hand, before our 
code 
> > generation utilities were completed. 
> > </danj>
> >
> > 
> >> * Section: 
> >> 
http://ws.apache.org/muse/docs/2.0.0/tutorial/03-wsdl2java.html#Section4 
> >> 
> >
> > 
> >> (about the proxy code generation)
> >> States "New OSGi generated project layout", but isn't this true for 
Axis 
> >> 
> >
> > 
> >> as well or is this really OSGi specific?
> >> 
> >
> > <danj>
> > Looks like a typo - it should read "New Client Project Layout" (or 
> > something). We'll fix it. That material is not OSGi specific.
> > </danj>
> >
> > 
> >> * In section: 
> >> http://ws.apache.org/muse/docs/2.0.0/tutorial/08-test-client.html
> >> Why not provide the entire source code of a client, allowing people 
to 
> >> just fast test/extend some things? I mean, I've done some Java in the 

> >> past (like a year ago) and figure it out finally, however within a 
> >> tutorial one just wants to test/see functionality of the presented 
> >> technology and not have to care about those minor things.
> >>
> >> 
> >
> > <danj>
> > Not sure what you mean by 'the entire source code of a client' - the 
> > client code is generated as part of the WSDL2Java steps (see last 
answer). 
> > The main() that is shown is just a test driver that uses the client.
> > </danj>
> >
> >
> > 
> >> * In that same section of the test client, it is said to replace 
> >> http://... with your personal URL. However the sample code contains 
two 
> >> instances, one for creating "uri" and one for creating "consumerURI". 

> >> Should they both be replaced? But if they are both the same, why not 
> >> just use one URI instance? If they are different, maybe explain why.
> >> 
> >
> > <danj>
> > Both URIs need to be updated with your local info.
> > </danj>
> >
> >
> > 
> >> * One more about the sample file, I seem not to get the importing of 
the 
> >> 
> >
> > 
> >> EndpointReference right..... Which file should be in its classpath 
and 
> >> how is it imported, because it seems I'm not able to manage it right. 

> >> Now using "import org.apache.ws.addressing.EndpointReference;" with 
> >> wsrf-1.1.jar in its classpath, but probably need an other one since 
muse 
> >> 
> >
> > 
> >> 2.0 came with wsrf 1.2. In one of your sample files 
> >>
> >> 
> > 
(samples/simple/src/org/apache/muse/test/simple/SimpleResourceClient.java) 

> >
> > 
> >> you used "import org.apache.muse.ws.addressing.EndpointReference;" 
> >> however again, what place needs to be in my classpath to import this 
> >> 
> > one?
> > 
> >
> > <danj>
> > Not sure I understand... what is wsrf-1.1.jar? This isn't one of our 
jar 
> > files. The non-muse EPR class is probably from Axis2, although that 
one 
> > should have 'axis2' in the package name. So I don't really know where 
that 
> > class is from. The last class you reference is the Muse EPR class you 
> > should use.
> >
> > If you want, send a list of the jar files in your application and I 
can 
> > see if you have any unintended dependencies.
> > </danj>
> >
> > 
> >> * About your questions Dan:
> >> A: I will come back to you at this, basically I think XML files will 
do 
> >> just fine for me.
> >> B: Files on a (virtual) filesystem are fine. The number of copies 
needed 
> >> 
> >
> > 
> >> to be distributed are in the range of 3-10. For larger distribution a 

> >> P2P like technologies *might* be useful in my case, but initially not 

> >> needed.
> >>
> >> Best regards,
> >>     Bertrand
> >>
> >>
> >> Daniel Jemiolo wrote:
> >> 
> >>> Hi,
> >>>
> >>> Here are some answers for the issues you raised:
> >>>
> >>> 1. The location of the Muse directory doesn't really matter - since 
> >>> everyone has a preference we just assumed not mention it. What *is* 
> >>> important is putting /bin on your path so you can invoke the tools 
> >>> 
> > from 
> > 
> >>> anywhere.
> >>>
> >>> 2. I will add a 'Note' on section 3 of the tutorial that advises 
Unix 
> >>> users to add a .sh suffix.
> >>>
> >>> 3. I will delegate to Andrew on the matter of script format and 
> >>> permissions - I also thought this was handled.
> >>>
> >>> 4. All Apache projects provide a binary and source distribution - 
the 
> >>> binary is the one that you actually need to work with the project, 
the 
> >>> 
> >
> > 
> >>> source is just a convenience for those that want to browse the code. 

> >>> 
> > Our 
> > 
> >>> build process does not even require you to download the source zip 
> >>> 
> > file, 
> > 
> >>> we just provide it because all other projects do and it's easy to 
> >>> 
> > create.
> > 
> >>> Short answer: you normally only need the binary. You can get the 
> >>> 
> > source if 
> > 
> >>> you're curious. If you want to modify some of the source and 
rebuild, 
> >>> follow the instructions here:
> >>>
> >>>         http://ws.apache.org/muse/source-code.html#build-release
> >>>
> >>> 5. You need to add the XSD/WSDL files that sample-wsn-producer.wsdl 
> >>> imports - these are the WSRF/WSN/WSDM XSDs/WSDLs. This is mentioned 
in 
> >>> 
> > the 
> > 
> >>> first 'Note' in section 2. However, we should do a better job of 
> >>> 
> > linking 
> > 
> >>> to them in the 2.1 documentation; I will fix this, in the meantime, 
> >>> 
> > the 
> > 
> >>> XSDs/WSDLs are found by clicking 'OASIS Standards' in the menu.
> >>>
> >>> 6. The default persistence mechanism is file based and will not 
write 
> >>> 
> > to 
> > 
> >>> another machine. The interface and abstract class used by the 
default 
> >>> implementation are meant to be reused in situations where you want a 

> >>> different form of persistence, such as relational database or (in 
your 
> >>> 
> >
> > 
> >>> case) simply copying to another machine. I can help you write the 
code 
> >>> 
> > you 
> > 
> >>> need, but first I need some answers myself:
> >>>
> >>>         a. Do you want to use a different format from the one used 
by 
> >>> Muse's default implementation? Or are you satisfied with it. The 
> >>> 
> > default 
> > 
> >>> implementation stores EPR reference parameters in the XML files 
under 
> >>> /router-entries.
> >>>
> >>>         b. Are you content with storing separate files on disk, or 
do 
> >>> 
> > you 
> > 
> >>> have a more robust persistence mechanism in mind? How many resource 
> >>> instances will there be? If the number is large, we won't be able to 

> >>> 
> > use 
> > 
> >>> files because of performance issues, and this will significantly 
> >>> 
> > affect 
> > 
> >>> how much code we can reuse from Muse today.
> >>>
> >>>
> >>> thanks,
> >>> Dan
> >>>
> >>>
> >>>
> >>> [EMAIL PROTECTED] wrote on 11/15/2006 06:27:35 AM:
> >>>
> >>>
> >>> 
> >>>> Hi,
> >>>>
> >>>> In the process of started to get acquainted with muse 2.0, I 
stumbled 
> >>>> 
> >
> > 
> >>>> upon a few issues and questions.
> >>>>
> >>>> I downloaded the binary distribution, however I found the 
> >>>> 
> > installation 
> > 
> >>>> page 
> >>>> 
> > http://ws.apache.org/muse/docs/2.0.0/tutorial/01-install-muse.html 
> > 
> >>>> quite  some short on the subject of installation. It does not gives 
a 
> >>>> 
> >
> > 
> >>>> suggestion where to place the unpacked directory (I placed it in 
> >>>> /usr/local/muse ) or if there need to be a PATH or other 
environment 
> >>>> variable set (it does however suggest the ./bin directory to be 
> >>>> included, so that is OK :P ).
> >>>>
> >>>> Furthermore, the shell scripts are not ready executable and have a 
> >>>> suffix (which makes them incompatible with the tutorial command 
line 
> >>>> http://ws.apache.org/muse/docs/2.0.0/tutorial/03-wsdl2java.html ).
> >>>>
> >>>> Furthermore, the shell scripts are still in binary format, even 
tough 
> >>>> 
> > I 
> > 
> >>>> found the subject already covered on the mailing list: 
> >>>> http://marc.theaimsgroup.com/?l=muse-user&m=115892779030401&w=2 .
> >>>>
> >>>> The installation page does also not state for what purpose one 
should 
> >>>> 
> >
> > 
> >>>> use the binary and for what purpose one should use the source 
> >>>> distribution (so I picked binary, but maybe source would be a 
better 
> >>>> option, I don't know...).
> >>>>
> >>>> I was also doing the tutorial and on this page 
> >>>> http://ws.apache.org/muse/docs/2.0.0/tutorial/03-wsdl2java.html I 
> >>>> 
> > came 
> > 
> >>>> into problems while (automatically) installing axis:
> >>>> wsdl2java -wsdl 
> >>>> /home/bertrand/Thesis/codebase/muse_test/sample-wsn-producer.wsdl
> >>>>
> >>>> SEVERE: [ID = 'FailedLoadingWSDL'] Got exception loading WSDL: [ID 
= 
> >>>> 'InvalidFile'] The file specified does not exist: 
> >>>> /home/bertrand/Thesis/codebase/muse_test/WS-Addressing-2005_08.xsd. 

> >>>> Remember that the location of the file is relative to the 
> >>>> 
> > application's 
> > 
> >>>> working directory..
> >>>>
> >>>> An exception was caught: [ID = 'FailedLoadingWSDL'] Got exception 
> >>>> loading WSDL: [ID = 'InvalidFile'] The file specified does not 
exist: 
> >>>> 
> >
> > 
> >>>> /home/bertrand/Thesis/codebase/muse_test/WS-Addressing-2005_08.xsd. 

> >>>> Remember that the location of the file is relative to the 
> >>>> 
> > application's 
> > 
> >>>> working directory..
> >>>>
> >>>> So can somebody give some advice on this? Should there be a PATH 
set 
> >>>> 
> > or 
> > 
> >>>> something?
> >>>>
> >>>> Final question, on the "Features" page it is stated that muse 2.0 
> >>>> contains "A persistence API so that users can recover the state of 
a 
> >>>> WS-resource after shutdown of the host." Can this also be used to 
> >>>> 
> > copy 
> > 
> >>>> the state an application using the WSRF to an other (secondary) 
> >>>> 
> > machine? 
> > 
> >>> 
> >>>> Can this be done runtime? Because I am looking for such 
> >>>> 
> > functionality. 
> > 
> >>>> If so, could somebody please point to documentation and/or examples 

> >>>> 
> > how 
> > 
> >>>> to start with this?
> >>>>
> >>>> I hope I don't sound to negative, because I really appreciate all 
the 
> >>>> 
> >
> > 
> >>>> work being done by the Muse team!
> >>>>
> >>>> Best regards,
> >>>>     Bertrand
> >>>>
> >>>> 
---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>
> >>>> 
> >>> 
---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>
> >>> 
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> 
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to