I am using sun AS 9.1, and web service has been tested.
Maybe someone has similar problems. I can also post sources if there
is need.
ballo0
Are the web service and applet coming from the same server?
--
Knute Johnson
email s/nospam/linux/
The applet is signed and your browser is getting it from the web server
running on your computer not off the hard disk? I know these can be
tricky. What exactly are you accessing from the applet?
--
Knute Johnson
email s/nospam/knute/
..multi-posting to two comp.lang.java.*
usenet news groups. Please cross-post,
in future.
<http://www.physci.org/codes/javafaq.html#xpost>
(Note: X-post to c.l.j.p./h., w/ f-u set
to c.l.j.h. only)
Andrew T.
Look in the Java console for your browser to see if there are any
errors/exceptions reported. The applet is most likely failing to start.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : n...@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
Can You say exactly what do you mean by signing applet? Applet runs
from web serwer, it is packaged in war, of web application that
contains a website with this applet. Exactly i have a ejb deployed,
and it has a webservice, and applet is trying to use it. If you want
here is exact code:
try { // Call Web Service Operation
gra.CardWSService service = new gra.CardWSService();
gra.CardWS port = service.getCardWSPort();
// TODO process result here
k1 = port.getCard();
k2 = port.getCard();
} catch (Exception ex) {
// TODO handle custom exceptions here
}
and I have checked what is going on with java console in firefox and
i've got:
java.lang.ExceptionInInitializerError
at
com.sun.xml.internal.ws.util.xml.XmlUtil.createDefaultCatalogResolver(XmlUtil.java:
208)
at
com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:
125)
at
com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:
52)
at javax.xml.ws.Service.<init>(Service.java:57)
at gra.CardWSService.<init>(CardWSService.java:40)
at timon.Applet.init(Applet.java:108)
at sun.applet.AppletPanel.run(AppletPanel.java:417)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.security.AccessControlException: access denied
(java.util.PropertyPermission xml.catalog.ignoreMissing read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:
323)
at
java.security.AccessController.checkPermission(AccessController.java:
546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:
532)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:
1285)
at java.lang.System.getProperty(System.java:652)
at
com.sun.org.apache.xml.internal.resolver.CatalogManager.<init>(CatalogManager.java:
140)
at
com.sun.org.apache.xml.internal.resolver.CatalogManager.<clinit>(CatalogManager.java:
134)
... 8 more
any ideas how to make it works?
ballo0
like i have written this is the problem, you are right it is thrown by
init method in applet:
any ideas how to make it work, and what exactly is wrong?
ballo0
That seems unusual to me, though I'm not an applet expert as, say, Andrew is.
I have not run across any hybrid applet/JEE applications before - what
advantages does that approach hold?
I can think of myriad disadvantages.
Signing an applet means to provide a trust certificate to the user, which they
have to accept before the applet obtains elevated privileges. Without that,
the applet cannot do things like invoke resources outside its home domain.
Is the EJB from outside the applet's home domain?
Would a more conventional approach, like having an HTML form submission
trigger servlet actions such as EJB invocation, suit your purposes? It'd be a
lot simpler to engineer.
-- Lew
I don't know the answer to this either. Simple signed applets I can do
but I don't know anything about EJB.
No, because I have no idea what gra.CardWSService is, or what it does.
You are throwing a AccessControlException. Presumably because your applet is
trying to access resources which it is not allowed to access. Your applet can
only access resources directly from the host from which the class loader
obtained the code, via something like this.getCodeBase().getHost().
Even if the resources are being accessed from the same physical machine you have
to use the same "host", i.e you can't download the applet via the loopback
address (127.0.0.1) and then access resources via the ethernet interface IP (or
vice versa), or via different IP addresses for multi-homed hosts.
of course it would be, but we are using applet as presentation layer.
We are working on card games portal, so we decicded to store all games
logic
on server and provide access to it via web services. And we there is
need to make
a sample client so we thougut that applet would be apriopriare
solution.
We have to draw lot of things, refresh it, hadle events...
ballo0
try { // Call Web Service Operation
gra.CardWSService service = new gra.CardWSService();
gra.CardWS port = service.getCardWSPort();
// TODO process result here
k1 = port.getCard();
k2 = port.getCard();
} catch (Exception ex) {
// TODO handle custom exceptions here
}
CardWs is a very simple webservice,
.getCard() returns int
do you need addtiona info?
do you know how to make an applet to comunicate with webservices on
remote machines??
is this possible?
ballo0
> so gra.CardWSService is a webservice client in applet:
>
> try { // Call Web Service Operation
> gra.CardWSService service = new gra.CardWSService();
> gra.CardWS port = service.getCardWSPort();
> // TODO process result here
> k1 = port.getCard();
> k2 = port.getCard();
>
> } catch (Exception ex) {
> // TODO handle custom exceptions here
> }
>
> CardWs is a very simple webservice,
> .getCard() returns int
> do you need addtiona info?
> do you know how to make an applet to comunicate with webservices on
> remote machines??
Not as such, no. I have never used "webservices", my only experience is with
applets communicating with servlets.
> is this possible?
>
I would have thought so. They are meant to be able to communicate, aren't they?
The trouble with all these abstraction layers is that they get in the way of
seeing what is really going on. You need to determine which line of your code
is actually throwing the Exception. Then try to resolve what is going on behind
the scenes.
My guess would be that you are serving your applet and your webservice on
different network interfaces/hostnames, but that's wild speculation. Did you by
any chance access the applet via localhost? Try using the FQDN of the machine.