We Keep Coding

I need a SOAP endpoint start page like Axis provides

I am migrating a Spring2 SOAP service to Spring 5. in the old code, if I called https://server:port/myservice/services/myserviceendpoint from a browser, it would display a page stating "And now... Some Services"
The spring-ws doesn't do that. unfortunately one of the client apps uses that page to determine if the service is up.
How do I mimic that behavior?

It's a matter of handling HTTP requests the same way Axis does. Normally, you have to deal with three combinations:
GET /myserviceendpoint
GET /myserviceendpoint?wsdl
POST /myserviceendpoint
Your SOAP service works with POST, so you have that covered by the service itself. All you have to do is create an URL mapping for GET and return the response expected by your client. If it's a plain GET, you return HTML with the "And now... Some Services". If the GET has the ?wsdl parameter, you should return a WSDL for the service. Obviously, you will need to replicate whatever else content the client is expecting.
With that being said, is there a way for the client to stop doing that? They are using something dependent on the implementation. That Axis page is there just to test everything is set up properly. Normally, it shouldn't have been exposed to clients, let alone the clients using it to make sure the service is up.
If they want to make sure the service is up, then, while you are migrating this service to Spring 5, what you can do is add another operation in the service, something called <ping> that responds with a <pong> or something. Basically, to offer an operation on the service that can be called with no side effects to see if the service is up. Since this is a new operation, it's a non breaking change (for both the service and the WSDL) so it's safe to add. Then clients can have something to use instead of relying on other mechanisms offered by your code implementation .

Identifying the calling code path for an API method

I am interested in finding a pattern or strategy for identifying which code path called a specific API method (or set of methods).
Here are some examples of differentiation in my application:
Caller calls API via an exposed REST controller
Caller calls API via some other internal API
Caller calls API via a user-created plugin
The application does use Spring for core wiring as well as Spring Security. However, the caller could be any user so using the Spring security context to inspect authentication or their associated granted authorities doesn't appear to be the right fit. The same user could call into the API method via one of the exposed REST URIs or call in via an arbitrary plugin entry-way.
How can one manage this type of identification without exposing additional or semi-duplicated APIs for different entry-points? I would like to be able to identify where a particular call originates. Slight differences in functionality can occur depending on whether the call came from one of our REST endpoints as opposed to one user-generated plugin as opposed to some other user-generated plugin.
This could hint at using some form of interception/aspect, but I do not have control over plugin code since I did not generate it. Plugins do have to register in order to get integrated so there is a programmatic hook there.
Looking for suggestions on how to manage this type of issue whether it's using additional Spring feature functionality or an alternative idea or library.

In fact this is a nice question.
As far as i see there are these options:
semi duplicated API (already mentioned above)
different users (or user-groups)
get callstack using reflection (but hard to do and not really recommended)
instead of user you can use some kind of authorization-token "per session" and see if the session is create via HTTP call or if it is an "internal" session
check some kind of session-id and save inside your session where it was created (internal or external, ...)
For now i don't see any other possibilities.
ps: to "flag" the session as internal/external can be done by adding an own spring handler.
Hope this brings you to the right point and helps you out.

Passing in objects to GWT servlets via servlet attributes (server-side) or "Dependency Injection"

How do I pass objects from non-GWT server-side code (e.g. regular server code) to the GWT "servlet" (still server-side code), specifically a RemoteServiceServlet?
My GWT server-side code consists of RPC-type RemoteServiceServlets to which I can't seem to get a reference so I can't pass in my real/fake object in testing mode or add servlet attributes. I can't see any way to simply pass objects in (dependency-injection style) as I have no access to the Server object as GWT seems to instantiate it deep within its internals, so what are my options?
P.S. I don't want to use a full-blown DI framework such as GIN/Juice - I find them to much magic. I just want a way to access the instance of a GWT servlet and pass stuff to it.

Let me start out by saying, if you haven't already, I highly recommend watching this Google I/O presentation on GWT Architecture best practices. I found it very useful and it's where most of the following came from.
What I did was create an abstract "dispatch" servlet that extends GWT's RemoteServiceServlet. Every module I have has only one service (that extends my abstract dispatch service) with which I register a set of request handlers. All GWT service calls for a given GWT module come into that module's dispatch service, which looks at the type of request and dispatches it to the appropriate request handler. The request handlers, in effect, handle the work that previously resided in the service servlet. Besides making your life easier by having fewer servlets to register in your web.xml (not to mention avoiding the extra interfaces GWT requires), you can more easily control the dispatcher object that handles all the actual dispatching. You can, for example, pass whatever real/mock object you like into these request handlers since you, and not the web container, are responsible for instantiating them.
And though I rolled my own, the gwt-dispatch project exists for this very purpose.
Hope this helps.

Servlet containers are designed to not allow direct access to the servlets that they host; that's why you've found it difficult to get any kind of handle to a servlet.
Rather, refactor the code that is currently in your servlets into separate request-handler classes, and have your serlvets call into them.
For testing purposes you can hook your testing framework, or your client code, to the request-handler classes directly. That's how people generally solve the problem you've run into.

Grails - asynchronous communication with 3rd party API

I'm experimenting with grails in order to interface with an online trading platform.
specifically Interactive Brokers (IB) http://interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc
The way the API works is you need to have their client program, Trader Workstation (TWS http://interactivebrokers.com/en/p.php?f=tws&ib_entity=llc) running and then we consume the API to do stuff. Consuming the API basically involves creating a "broker" object, calling a connect() member function (this makes a local port connection to the TWS software) and calling something like getData()
The value of grails in this scenario are the GORM features and the web framework provided. I want to be able to define objects abstracted from db implementation, easily do persistance operations and easily provide users with a UI to do CRUD and custom actions.
My challenge is the IB API uses asynchronous communication for requests and replies. i.e. when i call getData(), the API knows to use the callback function dataResults() when it is ready to send them. In order for dataResults() to be callable, the broker object I created still needs to be around to receive the reply.
Inside a controller function, if i create a broker object and call getData(), when the request finishes, the broker object obviously also disappears. So I'll never be able to receive the reply.
I think there might be some way to do this by kicking off background threads but i'm not sure this is the path i want to go down.
Does anyone have any recommendations on what the best approach is?
I'm not married to grails, the reasons i'm using it are above. If there is a desktop app framework that I can also easily make a web interface on top of later, I'm definitely open to that.
thanks in advance.

Create your object in Service and make the Service singleton (which is by default):
static scope = "singleton"

In terms of web UI Grails is definitely a good choice.
Then, the asynchronous operations could be handled by Ajax calls as you shouldn't block the controller waiting for results.
The following [presentation][1] has some good examples
1: http://skillsmatter.com/podcast/java-jee/high-volume-scalable-ajax-with-grails

Communication between two Web Services

I have a problem with web services. They are programed in Java and are running on a WASCE server ( both are on the same server).
My problem that i want to solve:
We have two Web services: App1 and App2
In App1 i want to call a function that is in App2. How can i do this? Is this even possible?
I tried creating a soapClient inside the App1 so i can connect to the App2 but that doesn't work.
exp:
I have a client that calls app1 gets data from app1 and send it to app2 then get back the response data from app2 and send it to an other function into the app1.
What i want to do is to skip the client part and do it directly so that app1 can send directly the data to the app2 and then receive an answer do whatever it needs to do.
For the note: Both of the web services use the connection to the database.
Thank you in advance.
(it has been edited with additional data)

What does "doesn't work" mean? Exactly what happens?
Start by generating some client code for App2. Can you use that from some simple Java environment, or say a Servlet. If that works, what happens when you try to call it from inside your App 1 Service implementation code?
However: if these are related services running in the same JVM can you not set up some simpler relationship using java libraries. My preferred way of developing a service is first to develop some useful Java code, and make sure that works, then "wrap" it as a Web Service. In which case I have a callable routine that can just be invoked as Java.

It's definitely possible, with differing levels of complexity and feasibility depending on exactly what it is you want, and the restrictions you place on it.
Probably one of the simplest ways to go about this, if you don't have a problem with the method in App2 being public, is to simply create a web service exposing that method and call if from App1.
If you want App2's method to be essentially "protected", so that it can be called by App1 but not by public clients, then there are several alternative options. Firstly, you could use firewalls or equivalent to prevent external requests to the service URL. Alternatively, you could expose the method through some form of interprocess communication; RMI would be the obvious native one for Java (set up an RMI method in App2 and export this through a manager, then obtain the reference in App1 and invoke the method remotely). Depending on exactly what it is you want to do, you may be better off with a framework that does all this under the covers; e.g. distributed objects through something like Terracotta.
You should give more detail in your question, though - currently the only thing you've really specified is that you want to call "a function" in App2 from App1. There are dozens (if not hundreds) of ways to go about this and the best one(s) will depend on the details of what you're trying to do.
EDIT (in light of comments): It's not the details of what you want to do that are lacking - I understand fine that you want to call some method in App2 from within App1. It's more the architectural details - what languages are both clients coded in, what libraries are you using to do the web services, are both clients on the same machine or separate ones (and if same machine, same JVM or not), are there any firewall issues that could inhibit certain kinds of connectivity, are there any office-political restrictions that could inhibit your options, are there any security restrictions that could do the same (such as whether you can expose the functionality of App2's method publically or not). All of these will shape what is possible and what is optimal - because at the end of the day, all networking is basically I want to use resources on that remote computer from here. Without more architectural specifics, there are literally dozens of ways that you could achieve this.
Regarding exposition: You would create a web service to expose App2's function in the same way you would create any other web service (with the details being dependent on the tool/framework you're using). As an example if you're using a tool that supports the JSR-181 annotations, you'd write a method in App2 that performs this function, and annotate it with #WebMethod. Then you'd ensure that if this method is not part of an existing webservice class you'd annotate its class with #WebService. I was presuming that since you already have a couple of web services, you'd know how to write/define them.
As for accessing the web service from App1, this can be done quite simply by a Java SOAP client. A tool such as WSDL2Java can create a stub class modelling the remote service that you can call; alternatively you can get a richer interface with something like CXF.
What WS library are you using currently, and what errors have you encountered when trying to use it to perform this interaction?