It may be that 4.0.1 is not providing the namespace for the response that .Net
is wanting.
I would expect, then, that a SOAP response from 4.0.1 and 4.0.3 are different
in that respect. From what I've seen .Net will silently discard
request/response parameters that don't have the namespace dec
What does your .Net C# code look like?
Everything is wrapped with objects that Visual Studio should have generated.
So you basically:
1) Instantiate a proxy object. a.k.a. web reference.
| 2) Then you'll instantiate a request object and populate it's parameters.
| 3) Use the request object
Is your scenario a .Net client with JBoss 4.0.1 server? Visual Studio should
be able to build a client-side proxy okay. I actually use JBoss 4.0.2, but I
do have .Net 1.1 clients running in production. (Soon to migrate to JBoss
4.0.3sp1)
Do you have any clients that can talk to the web ser
Sorry, just noticed that you were talking about accessing the WSDL.Maybe a
URL with the user/password specified in it would work.
Something like:
| http://user:[EMAIL PROTECTED]/webservice?wsdl
|
Not sure if this will actually work, plus it limits the characters allowed for
the passwo
Been awhile since using DII. Have you tried setting the USERNAME_PROPERTY and
PASSWORD_PROPERTY on the Call object?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3904295#3904295
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=
Just wondering why you have 5 databases with authentication information. Are
you suggesting that the client provide the name of the database to authenticate
against? or that there is a 6th datastore that selects a database based on
login name? It sounds to me like this a security issue that
Ooops, I got ahead of myself.The word 'test' as a MD5 hash encodes to:
Hex: 098f6bcd4621d373cade4e832627b4f6
Base64: CY9rzUYh03PK3k6DJie09g
Here's a small perl script that I used.
| #!/usr/bin/perl
| use Digest::MD5 qw(md5_hex md5_base64);
| $digesthex = md5_hex('test');
| $digest
I don't have the answer to your problem, but you didn't use base64 encoding the
value "098f6bcd4621d373cade4e832627b4f6" is a hex encoded MD5 hash of the word
"test". The base64 encoded value is "dGVzdA==".
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3900
You should probably use wscompile instead of WSDL2Java.
Have you looked at:
http://wiki.jboss.org/wiki/Wiki.jsp?page=WSDOCClientStepByStep
and: http://wiki.jboss.org/wiki/Wiki.jsp?page=WSDOCServiceStepByStep
I would imagine that wscompile can be configured to generate the server files
from a
I have troubles like this as well with Windows and Linux machines. I believe
that JBoss is asking the operating system for it's hostname and the os resolver
is giving the short name instead of what you really wanted...the fully
qualified domain name.
What you might try is editting the /etc/ho
If your JBoss server is running on a windows machine. You may have to check
the 'jboss-service.xml' file in the 'http-invoker.sar/META-INF' directory of
your JBoss server configuration.
I've seen that a the windows server hostname may default to it's short name or
DNS alias. When the client
The WSDL document is the contract between the server and client.Unless
you're using non-standard SOAP types, i.e. passing serialized objects, the
client and server language/technology doesn't matter.Passing opaque objects
may require the client to be a particular technology and would re
I've used the SOAPMonitor from the command line, not via the applet. It
operates as a proxy like tcpmon where you'll need to point your client to an
IP/port that the SOAPMonitor is listening to and configure SOAPMonitor to relay
to the packets to the actual SOAP service IP/port. I'm assuming
One can use ethereal or tcpdump (or any other network sniffer) to capture and
look at the SOAP packets on the wire, if that's what you need to do. It can
be helpful when working out interop issues related to the SOAP packet structure
and you aren't in a situation where soapmon or other proxy t
>From what I read in the JBoss docs, the alias in the keystore needs to be the
>x509 subject line of the cert (with escapes for spaces and delimiters). So
>my advice would be to modify the keystore aliases.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=386
(Hope you don't mind me jumping in here.) Perhaps the quickest solution is
just to make the the {db}-ds.xml file read-only for the JBoss account and not
accessible for anyone else. (This should be common practice for any file
containing passwords, regardless of the application.) Further, JB
I would imagine that this capability would rest entirely with the JDBC driver.
If any drivers have such capability , JBoss could use them as with any other
JDBC driver.
r,
Lance
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3856111#3856111
Reply to the pos
I generally run some varient of RedHat Fedora, but it's still using iptables. I
don't like the way iptables is setup on RedHat, so I generally replace the RC script
at /etc/init.d/iptables with my own script/firewall rules.
You'll need to load the "iptable_nat" kernel module to get the Network
What operating system are you running? With Linux I use iptables to redirect port
443 to 8443 and run JBoss as a non-privileged user.This involves setting up
iptables for destination NAT.
r,
Lance
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3852979#
I'm a bit confused... are you running axis that you've deployed separately on JBoss or
are you using the jboss-net deployment? jboss-net is in the "all" configuration, but
can be copied in the "default" configuration.
If you're using jboss-net, you don't need to mess with deployment descriptor
I have run Axis 1.1 installed as a war under JBoss and JBoss-net services in the same
server instance without any trouble. Using JBoss-net (which is also built on Axis
1.1) has an advantange in that you don't need to mess with the Axis deploy/undeploy
descriptors or plug your apps under the Ax
Your method likely will not be named "getHello". In the Locator code generated by
wsdl2java, you should see a few methods that return your Stub. In mine, I see that
one method has no arguments and one takes a URL object as an argument to return the
Stub.
For example, I have web service named
I would use code similar to below. The idea is to:
1) locate the SOAP service (wsdl2java should have generated a Locator)
2) Instantiate the stub class.
3) Set the username and password in the stub.
4) Make the SOAP call to a remote method.
The names of the Locator and Stub classes have been
Yes, building a WSR (Web Service Archive) is exactly like building a JAR. Mine
generally contain only the "META-INF/web-service.xml" file. I don't put anything
special in the MANIFEST.MF, I just let the jar command build one.
The EAR should reference the WSR in it's "META-INF/application.xml"
Do you have a special need to access the AdminClient directly?
I generally put the WSDD in a "web-service.xml" file an build a WSR with that. The
WSR is laid out like:
| mywebservice.wsr:
| META-INF/
| META-INF/MANIFEST.MF
| META-INF/web-service.xml
|
The WSR is referenced in
I just spent about 5 painful hours working through various combinations or tags,
looking at the JBoss wiki, and eventually the source code for
JBossAuthenticationHandler and the contents of jboss-net_ejb_xml.xdt in the
xdoclet-module-jboss-net.jar that I have.
Turns out that my xdoclet-module-j
Hi fheldt,
Which version of xdoclet are you using?
The xdoclet-module-jboss-net.jar was built in October 2003. I'm not sure if it's
compatible with xdoclet-1.2.1. Plus, when I explode the xdoclet-module-jboss-net.jar
I don't see a "@jboss-net.wsdd-operation" tag.
What does your generated we
I'm not an expert on the Image object, but it would need to be a Serializable object
to send across the network as a SOAP attachment (MIME or DIME).
If you were to send common image files, such as JPeg, GIF, PNG, etc, then you could
Base64 encode the image file content and send it as XSD_BASE64.
= AxisEngine.getCurrentMessageContext();
|
| HttpServletRequest req = (HttpServletRequest)
msgctx.getProperty(HTTPConstants.MC_HTTP_SERVLETREQUEST);
|
| String userAgent = req.getHeader("User-Agent");
|
Best regards,
Lance Nehring
www.newparticles.com
View the original po
= (HttpServletRequest)
msgctx.getProperty(HTTPConstants.MC_HTTP_SERVLETREQUEST);
|
| String remoteHost = req.getRemoteHost();
Best regards,
Lance Nehring
www.newparticles.com
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3840206#3840206
Reply to
30 matches
Mail list logo
