We Keep Coding

Grails 2.4.5 Rest API GET Request: Can't get Response Body from CUrl and from React UI, but can get it from Postman and Browser

Grails 2.4.5 REST Controller returning List of non Domain object DTO
What's the best way to turn a method/action into a REST Resource accessible through a GET request, without returning a domain class/entity, but with a non-domain/entity DTO class?
With SpringBoot, it will look like this:
#RestController
class EmployeeController { ...}
/**
**I am not sure that even in Spring/SpringBoot you can return a list of non entity class DTO.
** Can you return a random non entity
**/
#GetMapping("/employees")
List<EmployeeDTO> all() {
return repository.findAll();
}
For my Grails project, I am trying to return a list of DTO object having data from different domain/entities. Since the class is not a Grails domain class, how do you do that, since it doesn't follow the Grails convention?
I have the code as below:
class ClassNameController extends RestfulController{
/**
** Grails usually wants you to use call the parent constructor and and put a domain class as
** a parameter like super (DomainClass).
** In my case, since I have a non-conventional Controller which combines different data
** sources/domains/entities, how do I implement my method/action to turn it into a Grails REST
** Resource?
** Is there an annotation like #RestController, #ResponseBody and #GetMapping in Grails or can they be used in Grails too, since Grails 2.4.5 is built on top of Spring?
**/
/**
** I used just one of the multiple domain/entity classes as a parameter to the parent constructor,
** in order to follow that convention like this below.
**/
ClassNameController(){
super(OneDomainClassOutOfTheManyDomainClassesInsideDTOClass)
}
List<ClassDTO> getAllDTOs(){
//allClassDTOs() is a private method inside same controller returning a list of all classDTOs
List<ClassDTO> classDTOsList = allClassDTOs()
respond classDTOsList, status: 200
}
With that code, I can see the data displayed in Postman as well as inside the browser. However, I am not able to see the data when testing with CUrl, somehow looking at the log, Grails considers the request as successful and redirect to the home page. I am not sure why that's the case. I even removed any security to see if it was due to the Oauth Access token, but I can see that it's not the case, as even with #Secured(['IS_AUTHENTICATED_FULLY']), I can see in the logs of Spring Security that the user has been authenticated successfully and the authorization access has been granted successfully.
Pretty much, I am looking for a sample example of a simple Grails REST API that doesn't use the Grails convention and returns a non domain object.

Get current domain name in an OSGi service component in AEM on activation

I am writing an OSGI service component in AEM.
I want to fetch current domain name in the activate method of the service component.
Currently, I'm writing a construct method, to get request from referring class/service/model/servlet to initialize the 'request' class object and using this request object to get the server name
private SlingHttpServletRequest request;
private String domainName;
#Override
public void construct(final SlingHttpServletRequest request) {
this.request = request;
}
#Override
public void setDomainName(){
this.domainName = request.getServerName();
}
And this.domainName is used in multiple service method implementations.
So, I have to call 2 extra service method,
Construct - to initialize global request object
setDomainName - to initialize domainName global object to be used across all the other service methods
Is there anyway to get domainName in activate method, so that i do not have to call the above two methods in order to use the service.
Note:- I cannot create an OSGI config for domain name, as this domain name is already being used as key property to identify the OSGI config of a given factory

Since AEM publish servers might be used for several domains, there is no way to "know" the right domain without getting the request. There might also be some magic being done by the web server and the CDN before the request is even reaching AEM.
On top of that, the activate method is not called each time the service is used, since those components are used multiple times.
So I think no, there is no way to guess what the domain of the next incoming request will be when the component is activated.
BR,
Oliver

To add to #OliverGeberts answer, this information can be added to the content (i.e. page properties of the language root) or some sort of tenant configuration.

GWT RequestFactory client scenarios

My understanding is that the GWT RequestFactory (RF) API is for building data-oriented services whereby a client-side entity can communicate directly with it's server-side DAO.
My understanding is that when you fire a RF method from the client-side, a RequestFactoryServlet living on the server is what first receives the request. This servlet acts like a DispatchServlet and routes the request on to the correct service, which is tied to a single entity (model) in the data store.
I'm used to writing servlets that might pass the request on to some business logic (like an EJB), and then compute some response to send back. This might be a JSP view, some complicated JSON (Jackson) object, or anything else.
In all the RF examples, I see no such existence of these servlets, and I'm wondering if they even exist in GWT-RF land. If the RequestFactoryServlet is automagically routing requests to the correct DAO and method, and the DAO method is what is returned in the response, then I can see a scenario where GWT RF doesn't even utilize traditional servlets. (1) Is this the case?
Regardless, there are times in my GWT application where I want to hit a specific url, such as http://www.example.com?foo=bar. (2) Can I use RF for this, and if so, how?
I think if I could see two specific examples, side-by-side of GWT RF in action, I'd be able to connect all the dots:
Scenario #1 : I have a Person entity with methods like isHappy(), isSad(), etc. that would require interaction with a server-side DAO; and
Scenario #2 : I want to fire an HTTP request to http://www.example.com?foo=bar and manually inspect the HTTP response
If it's possible to accomplish both with the RF API, that would be my first preference. If the latter scenario can't be accomplished with RF, then please explain why and what is the GWT-preferred alternative. Thanks in advance!

1.- Request factory not only works for Entities but Services, so you could define any service in server-side with methods which you call from client. Of course when you use RF services they are able to deal with certain types (primitive, boxed primitives, sets, lists and RF proxies)
#Service(value=RfService.class, locator=RfServiceLocator.class)
public interface TwService extends RequestContext {
Request<String> parse(String value);
}
public class RfService {
public String parse(String value) {
return value.replace("a", "b");
}
2.- RF is not thought to receive other message payloads than the RF servlet produces, and the most you can do in client side with RF is ask for that services hosted in a different site (when you deploy your server and client sides in different hosts).
You can use other mechanisms in gwt world to get data from other urls, take a look to gwtquery Ajax and data-binding or this article

Apache CXF: Forwarding an information from an interceptor to the actual webservice implementation

I'm running a JAX-WS web service which is based on Apache CXF 2.3.1 on a JBoss6 server.
My service offers a function getWeight. This function should return the values in different units (kilos, pounds) depending on an additional information within the SOAP header. For that purpose I have added my own interceptor:
public class MySoapHeaderInterceptor extends AbstractSoapInterceptor
{
public MySoapHeaderInterceptor()
{
super(Phase.USER_PROTOCOL);
}
...
}
The intercepting works fine and I can parse the additional element from the SOAP header and can set up a variable based on this element:
boolean poundsRequested = true;
Now my problem occurs. I don't know how to forward the variable poundsRequested to my actual WebService implementation MyServiceImpl. This class is calling another class ValueReader where I finally need the information from the SOAP header.
I've already tried to set up a global static variable ValueReader.poundsRequested. But such a solution is not thread safe. It might happen that the calls of two clients interfere, and can overwrite each others set up variable.
To sum up: I basically need a possibility to forward a variable from an Apache CXF Interceptor to the actual webservice implementation. Moreover the value of this variable needs to be unique for each request.

In the interceptor, you can save the values that you need on the incoming message:
message.put("my.value", value);
Inside your implementation, you can do one of two things:
1) Have the standard JAXWS WebServiceContext injected via an #Resource thing and call
context.getMessageContext().get("my.value");
2) Since you are tied to CXF anyway, do:
PhaseInterceptorChain.getCurrentMessage().get("my.value");

Ideally, the format in which the weights are requested should be a part of your payload - it does not make sense for it to be a header.
You may not need an interceptor for getting hold of this header, if you are using JAX-WS(recommended with CXF), you can get to this using #WebParam annotation with header attribute set to true.

Concept for reusable login session in rmi ejb calls

This is not a simple question its just because i'm rethinking our architecture for securing our EJB 3.0 service by a login and security.
We have a EJB3.0 application on JBoss 5.1 that offers various services to a SWT client to read and write data. To use a service, the client must login with a valid user and password which is looked up by SpringSecurity in a LDAP server. SpringSecurity generates a session id which is passed back to the client to be resused in any further service call.
client server
| |
|-> login(user/password)-------->|
| |
| <------- sessionId ------------|
| |
|-->serviceXy(sessionId,param1)->|
The situation seems clear. We store the sessionId in our own context object which is the first parameter of each service method. There is an interceptor on each service method which reads the sessionId from the given context object and checks if the session is still valid. The client needs to call the login service first to get a context object filled with the sessionId and reusue this context object in further service calls.
public class OurContext {
private String sessionId;
}
#Stateless
#Interceptors(SecurityInterceptor.class)
public OurServiceImpl implements OurService {
public void doSomething(OurContext context, String param1) {
[...]
}
}
The thing i don't like at this solution is the polution of each service method with the context parameter.
Isn't there a similar mechanism like a http session in rmi calls? I'm thinking of putting our context object in some kind of session that is created in the client(?) right after the login and is passed to the server on each service call so that the SecurityInterceptor can read the sessionId from this "magic context".
Something like this:
OurContext ctx = service.login("user","password");
Magical(Jboss)Session.put("securContext", ctx);
service.doSomething("just the string param");

Since you are already using an app server, it seems that you should be using the built-in EJB security mechanisms, generally provided through JAAS. On the 4.x jboss line, if you implemented your own JAAS plugin for jboss, you could get access to a "special" context map (similar to what you describe) which is passed along on remote requests (by the jboss remote invocation framework). I haven't used jboss in a while, so not sure how this maps to the 5.1 product, but i have to imagine it has similar facilities. This assumes, of course, that you are willing to implement something jboss specific.

There are some kinds of session mechanisms in EJB, but they all start when the remote call starts, and ends when that ends. On old one is the transaction context ( Adam Bien wrote about this some time ago), and a newer one the CDI Session Scope.
Contrary to popular belief, this scope doesn't just mirror the http session scope, but in absence of an http session (like for remote calls), it represents a single call chain or message delivery (for mdbs).
With such a session, your remote SWT client still has to pass the sessionId to the remote service, but any local beans called from there can pick it up from this "cdi" session.
The other option is kinda like what jtahlborn says: with your own login module you can return a custom principal, instead of the default one. Your code can first request the normal principal and then try to cast it.
The problem is that this stuff is container specific and JBoss always forgets about it. It pretty much breaks after every update, and users have to kick and scream to get it fixed in some next version (only to see it break again in the version after that). Without JBoss really supporting this it's an endless battle.
Yet another option is to let the user login with the sessionId as name. The login module behind that could be a simple module that accepts everything and just puts a principal in the security context with the sessionId as 'name'. It's a little weird, but we've used this succesfully to get any data that can be expressed by a string into the security context. Of course, you would need to let your client do a regular container authentication here, which kinda defeats using Spring security in the first place.

We went for another approach which is portable and does not rely on a specific app server. In addition our security implementation frees us from the restrictions of the EJB approach (which by the way I thought were closed 2 decades ago ... but came up again).
Looking top down:
There is a server providing classes with methods to work on same data.
The client(s) provide the data and invoke specific methods.
Our approach is to put all data (and therefore communication between client and server) into a "Business Object". Every BO extends a superclass. This superclass contains a session id. The login method provides and returns that id. Every client only has to ensure to copy the id received in one BO into the next one it sends to the server. Every method which can be remotely (or locally) invoked, first obtains the session object with the received id. The method to return the session object also checks security constraints (which are based on permissions and not on roles like in the EKB approach).