We don't inject services into Restful resources, I'm afraid.  One of the
things still to "get around to".

I've been doing some documentation over the last few days.  It's not yet
published, but the source is easily viewable on github.  One of the things
I did was a write-up of this thread; in doing so I made some refinements [1]

So, if you follow that approach then there should be an Isis session
running for your resource.  In which case you can just get the service from
IsisContext, as the page shows.

~~~

With respect to your design, just a note to say that I don't think you
should use HTTP GET; probably HTTP PUT is more correct so that the
registration is idempotent, or HTTP POST otherwise.  But not GET, because
the state of the system is being mutated.

HTH
Dan


[1]
https://github.com/apache/isis/blob/master/adocs/documentation/src/main/asciidoc/user-guide/_user-guide_security_usage-by-isis-viewers.adoc#user-registration-1





On 15 May 2015 at 20:39, <[email protected]> wrote:

>
>
> Hi Dan,
>
>
>
> I used this in my testResource class. It worked only once ;-)
>
> What would be a proper way to invoke the user registration service? I
> assumed I could use an inject here, but I start doubting it now...
>
>
>
>
>
>  @Inject
>
>             AppUserRegistrationService appUserRegistrationService;
>
>
>
>             @GET
>
>             @Path("/test/{logon}")
>
>             @Produces({MediaType.APPLICATION_JSON,
> RestfulMediaType.APPLICATION_JSON_OBJECT,
> RestfulMediaType.APPLICATION_JSON_ERROR })
>
>             public Response object(@PathParam("logon") String logon) {
>
>                 UserDetails userDetails = new UserDetails();
>
>                 userDetails.setUsername(logon);
>
>                 userDetails.setPassword(logon);
>
>                 userDetails.setConfirmPassword(logon);
>
>                 userDetails.setEmailAddress(logon + "@example.com");
>
>                 appUserRegistrationService.registerUser(userDetails);
>
>                 return Response.status(200).entity("user: "  + logon + "
> registered").build();
>
>             }
>
>
> grtz Johan
>
>
>
>
> Hi Johan,
>
>
>
> On 15 May 2015 at 16:59,  wrote:
>
> > Hi Dan,
> >
> >
> >
> > Two questions:
> >
> > 1. I expected 'myTestResource' to show up in restful-api but it doesn't.
> > What more needs to be done? (See code below)
> >
>
> I'm guessing when you say "show up in", you perhaps mean on the home
> resource ("/") or the services resource ("/services")?
>
> In which case, no... those representations are generate by the RO viewer,
> but your custom resource is sitting outside of RO.  It just happens to be
> hosted by RestEasy.
>
>
>
>
> >
> > 2. When running mvn clean install mvn complains that it cannot find
> > the
> org.apache.isis.viewer.restfulobjects.server.RestfulObjectsApplication
> > etc. Do I need to update a classpath somewhere? (When running in IntelliJ
> > there is no problem)
> >
> >
> Can't explain that... the
> org.apache.isis.viewer.restfulobjects.server.RestfulObjectsApplication
> class is part of the framework, so would be in your classpath anyway.  If
> you stash and revert your changes, do you still see this?
>
>
> ~~~
> What you might want to do is run a couple of generic (non-RO) RESTEasy
> tutorials / hello world, just so you can see what vanilla JAX-RS is
> like.... after all, this is what you'll need to be coding.  In fact, you
> might want to develop your code entirely outside of Isis.  Then we can
> graft it onto your Isis app later.
>
> HTH
> Dan
>
>
>
>
> >
> >
> > I subclassed like this:
> >
> >
> >
> >
> >         import
> > org.apache.isis.viewer.restfulobjects.server.RestfulObjectsApplication;
> >
> >         public class CustomRestfulObjectsApplication extends
> > RestfulObjectsApplication {
> >
> >             public CustomRestfulObjectsApplication() {
> >
> >                 addClass(MyTestResource.class);
> >
> >             }
> >
> >         }
> >
> >
> >
> >         with MyTestResource class:
> >
> >
> >
> >
> >                 @Path("/myTestResource")
> >
> >                 public class MyTestResource extends ResourceAbstract
> > implements DomainServiceResource {
> >
> >
> >
> >                     @Override
> >
> >                     @GET
> >
> >                     @Path("/")
> >
> >                     @Produces({ MediaType.APPLICATION_JSON,
> > RestfulMediaType.APPLICATION_JSON_OBJECT,
> > RestfulMediaType.APPLICATION_JSON_ERROR })
> >
> >                     public Response services() {
> >
> >                         return Response.ok("{SomeJson}").build();
> >
> >                     }
> >
> >
> >
> >
> >
> >                     @Override public Response deleteServicesNotAllowed()
> {
> >
> >                         return null;
> >
> >                     }
> >
> >
> >
> >                   ...
> >
> >                 }
> >
> >
> >         Grtz Johan
> >
> > On 7 May 2015 at 11:33,  wrote:
> >
> > > Hi,
> > >
> > >
> > >
> > > For our matching app [1] we are creating a bespoke REST (web)client and
> > > use ISIS as a backend. Can anybody give me an approach that we could
> use
> > > for user signup using the user-registration-service and the
> > > email-notification? It seems to me that there are no default facilities
> > in
> > > the REST Api at the moment or am I overlooking them?
> > >
> > >
> > You're correct, there are no default facilities in the REST API.
> >
> > However, I think the building blocks are there.  Not exactly trivial, but
> > do-able.
> >
> > Start off by subclassing RestfulObjectsApplication, eg
> > "CustomRestfulObjectsApplication", and register this in web.xml as the
> > context.param = javax.ws.rs.Application instead of
> > RestfulObjectsApplication
> >
> > Then, define some new Restful resources, cf
> > DomainServiceResourceServerside, and register these in your subclass of
> > DomainObjectResource and register in your
> CustomRestfulObjectsApplication.
> >
> > So far this is just standard javax.rs stuff.
> >
> > Next, we need to ensure that a client can hit your new resource *with*
> the
> > Isis runtime in place, but without there being an Isis session.  For
> > that....
> >
> > In the web.xml there's a filter IsisSessionFilterForRestfulObjects that
> > applies an authenticationSessionStrategy for every resource under
> > /restful/.  Since you want to make the new resource, eg
> /restful/register,
> > available without a session, then I think you'll need a custom
> > authenticationSession strategy too that allows access to this resource
> > without requiring logon.
> >
> > In the /restful/register resource, then, this will be hit without there
> > being an Isis session.  But you should be able to do a lookup of the
> > UserRegistrationService in order to allow the user to be created.  The
> > Wicket viewer does something similar in the RegisterPanel class:
> >
> >             IsisContext.doInSession(new Runnable() {
> >                 @Override
> >                 public void run() {
> >                     final UserRegistrationService
> userRegistrationService =
> >
> >
> IsisContext.getPersistenceSession().getServicesInjector().lookupService(UserRegistrationService.class);
> >
> >
> > IsisContext.getTransactionManager().executeWithinTransaction(new
> > TransactionalClosureAbstract() {
> >                         @Override
> >                         public void execute() {
> >
> > userRegistrationService.registerUser(userDetails);
> >                             removeAccountConfirmation();
> >                         }
> >                     });
> >                 }
> >             });
> >
> >
> > Hope that gives you some clues...
> >
> > Cheers
> > Dan
> >
> >
> >
> >
> >
> > >
> > >
> > > gtz Johan
> > >
> > >
> > >
> > > [1] https://github.com/johandoornenbal/matching
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>

Reply via email to