VAST and SeasideREST - Do Breakpoints delete Annotation Pragmas?

Dear VAST community.

I am having trouble getting my very first, simple RESTful component to work.

Let me start by telling you what I did:

1. Created a Subclass of WARestfulHandler named CurrentTimeHandler
   
2. Implemented a method called now:
   now
       <get>
   
       
       self requestContext respond: [:r|
           r contentType: 'text/plain'; nextPutAll: Time now printString
           ]
3. Registered the component evaluating
   WAADmin register: CurrentTimeHander at: 'api'
4. Navigated to http://localhost:8080/api

And got an empty page saying:

/api not found

So I started debugging around. At first I tried setting a breakpoint in my method #now, which never fired (not surprising).

Then I debugged into WAREstfulHandler>>#createRoutes and below.

I found that in WARouteBuilder class>>#createRoutesFrom:to:

the collection of Pragmas remained empty. The method CurrentTimeHandler>>#now had no pragmas. ...???????

So I removed the Breakpoint, retried, still no pragmas. So I changed the code by adding a line break, saved the method again and retried. The method had a pragma named #get.

Is that by design? Is there a reason why setting a Breakpoint removes pragmas?

So I removed the Breakpoint, resaved the method, but still got "/api not found".

Can anybody confirm that SeasideRest works on VAST? Can anybody give me a hint as to what I am doing wrong?

Thanks,

Joachim

Okay, so here is my first learning:

The correct path for my new component / hanlder is /api/now and not api. So the method name is relevant here. Now that I know that, it is absolutely logical ;-) :facepalm:

I will now play with the Breakpoint thing again and let you know when I found out this was also a stupid thing of mine...

Joachim Tuchel schrieb am Donnerstag, 22. April 2021 um 10:58:46 UTC+2:

Dear VAST community.

I am having trouble getting my very first, simple RESTful component to work.

Let me start by telling you what I did:

1. Created a Subclass of WARestfulHandler named CurrentTimeHandler
   
2. Implemented a method called now:
   now
       <get>
   
       
       self requestContext respond: [:r|
           r contentType: 'text/plain'; nextPutAll: Time now printString
           ]
3. Registered the component evaluating
   WAADmin register: CurrentTimeHander at: 'api'
4. Navigated to http://localhost:8080/api

And got an empty page saying:

/api not found

So I started debugging around. At first I tried setting a breakpoint in my method #now, which never fired (not surprising).

Then I debugged into WAREstfulHandler>>#createRoutes and below.

I found that in WARouteBuilder class>>#createRoutesFrom:to:

the collection of Pragmas remained empty. The method CurrentTimeHandler>>#now had no pragmas. ...???????

So I removed the Breakpoint, retried, still no pragmas. So I changed the code by adding a line break, saved the method again and retried. The method had a pragma named #get.

Is that by design? Is there a reason why setting a Breakpoint removes pragmas?

So I removed the Breakpoint, resaved the method, but still got "/api not found".

Can anybody confirm that SeasideRest works on VAST? Can anybody give me a hint as to what I am doing wrong?

Thanks,

Joachim

Okay, forget about all of this.

I tried adding a breakpount to my #now method and this brings up /api not found, but removing it again yields the expected result.

So I mixed the fact that the same happens for two separated problems with the fact that these are still two separate problems leading to the same result. Meaning I observed /api not found for two separate reasons and made the wrong conclusions.

Joachim

Joachim Tuchel schrieb am Donnerstag, 22. April 2021 um 11:16:02 UTC+2:

Okay, so here is my first learning:

The correct path for my new component / hanlder is /api/now and not api. So the method name is relevant here. Now that I know that, it is absolutely logical ;-) :facepalm:

I will now play with the Breakpoint thing again and let you know when I found out this was also a stupid thing of mine...

Joachim Tuchel schrieb am Donnerstag, 22. April 2021 um 10:58:46 UTC+2:

Dear VAST community.

I am having trouble getting my very first, simple RESTful component to work.

Let me start by telling you what I did:

1. Created a Subclass of WARestfulHandler named CurrentTimeHandler
   
2. Implemented a method called now:
   now
       <get>
   
       
       self requestContext respond: [:r|
           r contentType: 'text/plain'; nextPutAll: Time now printString
           ]
3. Registered the component evaluating
   WAADmin register: CurrentTimeHander at: 'api'
4. Navigated to http://localhost:8080/api

And got an empty page saying:

/api not found

So I started debugging around. At first I tried setting a breakpoint in my method #now, which never fired (not surprising).

Then I debugged into WAREstfulHandler>>#createRoutes and below.

I found that in WARouteBuilder class>>#createRoutesFrom:to:

the collection of Pragmas remained empty. The method CurrentTimeHandler>>#now had no pragmas. ...???????

So I removed the Breakpoint, retried, still no pragmas. So I changed the code by adding a line break, saved the method again and retried. The method had a pragma named #get.

Is that by design? Is there a reason why setting a Breakpoint removes pragmas?

So I removed the Breakpoint, resaved the method, but still got "/api not found".

Can anybody confirm that SeasideRest works on VAST? Can anybody give me a hint as to what I am doing wrong?

Thanks,

Joachim

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/b7c280dc-4897-4e00-9989-fb256f50fb87n%40googlegroups.com.

Hi Joachim,

Just to clarify the REST questions.. yes, Seaside REST is supported in VAST, it does work and we have customers using it. 

As to the path being 'hello' you can customize that with the <path:> pragma. Example

now
    <get>
         <path: '/currenttime'>

    
    self requestContext respond: [:r|
        r contentType: 'text/plain'; nextPutAll: Time now printString

        ]'

Should work at /currenttime

BTW, I attach a simple SeasideRESTExample app that contains a few examples with POST, queries, JSON etc. Very simple example but it may help. Check the class TestRestfulHandler. 

Best, 

On Thu, Apr 22, 2021 at 6:53 AM Joachim Tuchel <[hidden email]> wrote:

Okay, forget about all of this.

I tried adding a breakpount to my #now method and this brings up /api not found, but removing it again yields the expected result.

So I mixed the fact that the same happens for two separated problems with the fact that these are still two separate problems leading to the same result. Meaning I observed /api not found for two separate reasons and made the wrong conclusions.

Joachim

Joachim Tuchel schrieb am Donnerstag, 22. April 2021 um 11:16:02 UTC+2:

Okay, so here is my first learning:

The correct path for my new component / hanlder is /api/now and not api. So the method name is relevant here. Now that I know that, it is absolutely logical ;-) :facepalm:

I will now play with the Breakpoint thing again and let you know when I found out this was also a stupid thing of mine...

Joachim Tuchel schrieb am Donnerstag, 22. April 2021 um 10:58:46 UTC+2:

Dear VAST community.

I am having trouble getting my very first, simple RESTful component to work.

Let me start by telling you what I did:

1. Created a Subclass of WARestfulHandler named CurrentTimeHandler
   
2. Implemented a method called now:
   now
       <get>
   
       
       self requestContext respond: [:r|
           r contentType: 'text/plain'; nextPutAll: Time now printString
           ]
3. Registered the component evaluating
   WAADmin register: CurrentTimeHander at: 'api'
4. Navigated to http://localhost:8080/api

And got an empty page saying:

/api not found

So I started debugging around. At first I tried setting a breakpoint in my method #now, which never fired (not surprising).

Then I debugged into WAREstfulHandler>>#createRoutes and below.

I found that in WARouteBuilder class>>#createRoutesFrom:to:

the collection of Pragmas remained empty. The method CurrentTimeHandler>>#now had no pragmas. ...???????

So I removed the Breakpoint, retried, still no pragmas. So I changed the code by adding a line break, saved the method again and retried. The method had a pragma named #get.

Is that by design? Is there a reason why setting a Breakpoint removes pragmas?

So I removed the Breakpoint, resaved the method, but still got "/api not found".

Can anybody confirm that SeasideRest works on VAST? Can anybody give me a hint as to what I am doing wrong?

Thanks,

Joachim

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/b7c280dc-4897-4e00-9989-fb256f50fb87n%40googlegroups.com.

--

Mariano Martinez Peck Senior Software Engineer  [hidden email]  @MartinezPeck  /mariano-martinez-peck  instantiations.com

Hi Mariano,

thanks for your comments and sample code. I will try to answer my pending questions with it - or I'll come back here ....

One of the questions is whether one handler is meant to handle everything in its associated subpath, meaning I register one handler at, say /garage and this handler will be responsible for everything insider the /garage path. like /garage/cars/3/wheels/front-left/pressure. Do I implement all the subpath handling methods (like for /garage/cars/{id}) in this one handler and define the paths in the method pragmas? Or do I register seprate handlers for each part of the path? Or can I mix and match handlers as I please?

Joachim

[hidden email] schrieb am Donnerstag, 22. April 2021 um 13:57:35 UTC+2:

Hi Joachim,

Just to clarify the REST questions.. yes, Seaside REST is supported in VAST, it does work and we have customers using it. 

As to the path being 'hello' you can customize that with the <path:> pragma. Example

now
    <get>
         <path: '/currenttime'>

    
    self requestContext respond: [:r|
        r contentType: 'text/plain'; nextPutAll: Time now printString

        ]'

Should work at /currenttime

BTW, I attach a simple SeasideRESTExample app that contains a few examples with POST, queries, JSON etc. Very simple example but it may help. Check the class TestRestfulHandler. 

Best, 

On Thu, Apr 22, 2021 at 6:53 AM Joachim Tuchel <[hidden email]> wrote:

Okay, forget about all of this.

I tried adding a breakpount to my #now method and this brings up /api not found, but removing it again yields the expected result.

So I mixed the fact that the same happens for two separated problems with the fact that these are still two separate problems leading to the same result. Meaning I observed /api not found for two separate reasons and made the wrong conclusions.

Joachim

Joachim Tuchel schrieb am Donnerstag, 22. April 2021 um 11:16:02 UTC+2:

Okay, so here is my first learning:

The correct path for my new component / hanlder is /api/now and not api. So the method name is relevant here. Now that I know that, it is absolutely logical ;-) :facepalm:

I will now play with the Breakpoint thing again and let you know when I found out this was also a stupid thing of mine...

Joachim Tuchel schrieb am Donnerstag, 22. April 2021 um 10:58:46 UTC+2:

Dear VAST community.

I am having trouble getting my very first, simple RESTful component to work.

Let me start by telling you what I did:

1. Created a Subclass of WARestfulHandler named CurrentTimeHandler
   
2. Implemented a method called now:
   now
       <get>
   
       
       self requestContext respond: [:r|
           r contentType: 'text/plain'; nextPutAll: Time now printString
           ]
3. Registered the component evaluating
   WAADmin register: CurrentTimeHander at: 'api'
4. Navigated to http://localhost:8080/api

And got an empty page saying:

/api not found

So I started debugging around. At first I tried setting a breakpoint in my method #now, which never fired (not surprising).

Then I debugged into WAREstfulHandler>>#createRoutes and below.

I found that in WARouteBuilder class>>#createRoutesFrom:to:

the collection of Pragmas remained empty. The method CurrentTimeHandler>>#now had no pragmas. ...???????

So I removed the Breakpoint, retried, still no pragmas. So I changed the code by adding a line break, saved the method again and retried. The method had a pragma named #get.

Is that by design? Is there a reason why setting a Breakpoint removes pragmas?

So I removed the Breakpoint, resaved the method, but still got "/api not found".

Can anybody confirm that SeasideRest works on VAST? Can anybody give me a hint as to what I am doing wrong?

Thanks,

Joachim

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/b7c280dc-4897-4e00-9989-fb256f50fb87n%40googlegroups.com.

--

Mariano Martinez Peck Senior Software Engineer  [hidden email]  @MartinezPeck  /mariano-martinez-peck  instantiations.com

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/900cf328-e636-4442-b316-32727681af63n%40googlegroups.com.

Hi Joachim,

With Seaside REST you refine a restful RequestHandler at some path (in your case /garage), and everything that is "under" that path is handled by that handler, so you don't end up registering more handlers for each subpath.

That's how I've been doing it for years with Seaside REST.

As a side note nothing stops you from having a dispatcher (WADispatcher) registered at `garage` and then inside that dispatcher you can register other handlers (WARestfulHandler), specific for each type (e.g. `cars` and `tools`). But as far as I know you cannot mix both approaches, it is to delegate `cars` and `tools` to the registered handlers, but also have a route directly handled by `garage`. For that you'd need a WARestfulDispatcher that currently does not exist (and wouldn't be hard to implement though).

A tip (that might be redundant given your expertise) is to not implement in the handler more than the logic to validate formats, etc, and dispatch the request to the proper object. So I usually have the HTTP handler with all the routes, and then another object that deals with the actual processing of such requests.

Regards!

Esteban A. Maringolo

On Fri, Apr 23, 2021 at 5:19 AM Joachim Tuchel <[hidden email]> wrote:

Hi Mariano,

thanks for your comments and sample code. I will try to answer my pending questions with it - or I'll come back here ....

One of the questions is whether one handler is meant to handle everything in its associated subpath, meaning I register one handler at, say /garage and this handler will be responsible for everything insider the /garage path. like /garage/cars/3/wheels/front-left/pressure. Do I implement all the subpath handling methods (like for /garage/cars/{id}) in this one handler and define the paths in the method pragmas? Or do I register seprate handlers for each part of the path? Or can I mix and match handlers as I please?

Joachim

[hidden email] schrieb am Donnerstag, 22. April 2021 um 13:57:35 UTC+2:

Hi Joachim,

Just to clarify the REST questions.. yes, Seaside REST is supported in VAST, it does work and we have customers using it. 

As to the path being 'hello' you can customize that with the <path:> pragma. Example

now
    <get>
         <path: '/currenttime'>

    
    self requestContext respond: [:r|
        r contentType: 'text/plain'; nextPutAll: Time now printString

        ]'

Should work at /currenttime

BTW, I attach a simple SeasideRESTExample app that contains a few examples with POST, queries, JSON etc. Very simple example but it may help. Check the class TestRestfulHandler. 

Best, 

On Thu, Apr 22, 2021 at 6:53 AM Joachim Tuchel <[hidden email]> wrote:

Okay, forget about all of this.

I tried adding a breakpount to my #now method and this brings up /api not found, but removing it again yields the expected result.

So I mixed the fact that the same happens for two separated problems with the fact that these are still two separate problems leading to the same result. Meaning I observed /api not found for two separate reasons and made the wrong conclusions.

Joachim

Joachim Tuchel schrieb am Donnerstag, 22. April 2021 um 11:16:02 UTC+2:

Okay, so here is my first learning:

The correct path for my new component / hanlder is /api/now and not api. So the method name is relevant here. Now that I know that, it is absolutely logical ;-) :facepalm:

I will now play with the Breakpoint thing again and let you know when I found out this was also a stupid thing of mine...

Joachim Tuchel schrieb am Donnerstag, 22. April 2021 um 10:58:46 UTC+2:

Dear VAST community.

I am having trouble getting my very first, simple RESTful component to work.

Let me start by telling you what I did:

1. Created a Subclass of WARestfulHandler named CurrentTimeHandler
   
2. Implemented a method called now:
   now
       <get>
   
       
       self requestContext respond: [:r|
           r contentType: 'text/plain'; nextPutAll: Time now printString
           ]
3. Registered the component evaluating
   WAADmin register: CurrentTimeHander at: 'api'
4. Navigated to http://localhost:8080/api

And got an empty page saying:

/api not found

So I started debugging around. At first I tried setting a breakpoint in my method #now, which never fired (not surprising).

Then I debugged into WAREstfulHandler>>#createRoutes and below.

I found that in WARouteBuilder class>>#createRoutesFrom:to:

the collection of Pragmas remained empty. The method CurrentTimeHandler>>#now had no pragmas. ...???????

So I removed the Breakpoint, retried, still no pragmas. So I changed the code by adding a line break, saved the method again and retried. The method had a pragma named #get.

Is that by design? Is there a reason why setting a Breakpoint removes pragmas?

So I removed the Breakpoint, resaved the method, but still got "/api not found".

Can anybody confirm that SeasideRest works on VAST? Can anybody give me a hint as to what I am doing wrong?

Thanks,

Joachim

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/b7c280dc-4897-4e00-9989-fb256f50fb87n%40googlegroups.com.

--

Mariano Martinez Peck Senior Software Engineer  [hidden email]  @MartinezPeck  /mariano-martinez-peck  instantiations.com

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/900cf328-e636-4442-b316-32727681af63n%40googlegroups.com.

Hi Esteban,

thanks a lot. This makes a lot of sense. My question doesn't arise from my wish to make things overly complicated, so the mx&match idea was not all to serious.

BUT: your comment makes me wonder if that WADispatcher thingie isn't too bad an idea for versioned APIs, where you register a Dispatcher for /v1 (and /v2 and so on, of course) and then register concrete handlers for each subpath of that api version....

At first sight, this sounds like not too bad an idea, because it woul allow me to reuse a handler that is unchanged between two API versions.... Just an idea, I need to chew on it a little...

Anyways: Mariano and Esteban: Thanks a million, your comments are worth their weight in gold ;-)

Joachim

[hidden email] schrieb am Freitag, 23. April 2021 um 14:22:22 UTC+2:

Hi Joachim,

With Seaside REST you refine a restful RequestHandler at some path (in your case /garage), and everything that is "under" that path is handled by that handler, so you don't end up registering more handlers for each subpath.

That's how I've been doing it for years with Seaside REST.

As a side note nothing stops you from having a dispatcher (WADispatcher) registered at `garage` and then inside that dispatcher you can register other handlers (WARestfulHandler), specific for each type (e.g. `cars` and `tools`). But as far as I know you cannot mix both approaches, it is to delegate `cars` and `tools` to the registered handlers, but also have a route directly handled by `garage`. For that you'd need a WARestfulDispatcher that currently does not exist (and wouldn't be hard to implement though).

A tip (that might be redundant given your expertise) is to not implement in the handler more than the logic to validate formats, etc, and dispatch the request to the proper object. So I usually have the HTTP handler with all the routes, and then another object that deals with the actual processing of such requests.

Regards!

Esteban A. Maringolo

On Fri, Apr 23, 2021 at 5:19 AM Joachim Tuchel <[hidden email]> wrote:

Hi Mariano,

thanks for your comments and sample code. I will try to answer my pending questions with it - or I'll come back here ....

One of the questions is whether one handler is meant to handle everything in its associated subpath, meaning I register one handler at, say /garage and this handler will be responsible for everything insider the /garage path. like /garage/cars/3/wheels/front-left/pressure. Do I implement all the subpath handling methods (like for /garage/cars/{id}) in this one handler and define the paths in the method pragmas? Or do I register seprate handlers for each part of the path? Or can I mix and match handlers as I please?

Joachim

[hidden email] schrieb am Donnerstag, 22. April 2021 um 13:57:35 UTC+2:

Hi Joachim,

Just to clarify the REST questions.. yes, Seaside REST is supported in VAST, it does work and we have customers using it. 

As to the path being 'hello' you can customize that with the <path:> pragma. Example

now
    <get>
         <path: '/currenttime'>

    
    self requestContext respond: [:r|
        r contentType: 'text/plain'; nextPutAll: Time now printString

        ]'

Should work at /currenttime

BTW, I attach a simple SeasideRESTExample app that contains a few examples with POST, queries, JSON etc. Very simple example but it may help. Check the class TestRestfulHandler. 

Best, 

On Thu, Apr 22, 2021 at 6:53 AM Joachim Tuchel <[hidden email]> wrote:

Okay, forget about all of this.

I tried adding a breakpount to my #now method and this brings up /api not found, but removing it again yields the expected result.

So I mixed the fact that the same happens for two separated problems with the fact that these are still two separate problems leading to the same result. Meaning I observed /api not found for two separate reasons and made the wrong conclusions.

Joachim

Joachim Tuchel schrieb am Donnerstag, 22. April 2021 um 11:16:02 UTC+2:

Okay, so here is my first learning:

The correct path for my new component / hanlder is /api/now and not api. So the method name is relevant here. Now that I know that, it is absolutely logical ;-) :facepalm:

I will now play with the Breakpoint thing again and let you know when I found out this was also a stupid thing of mine...

Joachim Tuchel schrieb am Donnerstag, 22. April 2021 um 10:58:46 UTC+2:

Dear VAST community.

I am having trouble getting my very first, simple RESTful component to work.

Let me start by telling you what I did:

1. Created a Subclass of WARestfulHandler named CurrentTimeHandler
   
2. Implemented a method called now:
   now
       <get>
   
       
       self requestContext respond: [:r|
           r contentType: 'text/plain'; nextPutAll: Time now printString
           ]
3. Registered the component evaluating
   WAADmin register: CurrentTimeHander at: 'api'
4. Navigated to http://localhost:8080/api

And got an empty page saying:

/api not found

So I started debugging around. At first I tried setting a breakpoint in my method #now, which never fired (not surprising).

Then I debugged into WAREstfulHandler>>#createRoutes and below.

I found that in WARouteBuilder class>>#createRoutesFrom:to:

the collection of Pragmas remained empty. The method CurrentTimeHandler>>#now had no pragmas. ...???????

So I removed the Breakpoint, retried, still no pragmas. So I changed the code by adding a line break, saved the method again and retried. The method had a pragma named #get.

Is that by design? Is there a reason why setting a Breakpoint removes pragmas?

So I removed the Breakpoint, resaved the method, but still got "/api not found".

Can anybody confirm that SeasideRest works on VAST? Can anybody give me a hint as to what I am doing wrong?

Thanks,

Joachim

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/b7c280dc-4897-4e00-9989-fb256f50fb87n%40googlegroups.com.

--

Mariano Martinez Peck Senior Software Engineer  [hidden email]  @MartinezPeck  /mariano-martinez-peck  instantiations.com

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/900cf328-e636-4442-b316-32727681af63n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/c43c0ffd-6b6a-4d74-9d32-7d4ebeac45d6n%40googlegroups.com.