Re: [slingclipse] Checking out resources fails if the DefaultGetServlet does not serve the content

2012-11-15 Thread Antonio Sanso
Hi Dan,

I had/have the same concern.
The reason why this is currently implemented in this way is that it would had 
been nice to have no server side dependency.
I would suggest to track it as a bug for now and we can look into it later  
(maybe using the approach you suggest).

Regards

Antonio

On Nov 14, 2012, at 8:32 PM, Dan Klco wrote:

 Antonio,
 
 This was something I was concerned about with using the built in get servlet 
 for retrieving the content.  Would it make any sense to create a servlet 
 which would retrieve resources without being affected by the Sling URL 
 Mapping or other application rewriting?
 
 -Dan
 
 -Original Message-
 From: Antonio Sanso [mailto:asa...@adobe.com] 
 Sent: Wednesday, November 14, 2012 5:31 AM
 To: dev@sling.apache.org
 Subject: Re: [slingclipse] Checking out resources fails if the 
 DefaultGetServlet does not serve the content
 
 Hi Robert,
 
 thanks for reporting this.
 It would be something to investigate for sure.
 Would also be interesting to know the current behavior. What's happening in 
 this failure situation?
 Does the import stops completely or it just doesn't import a part of the 
 repository?
 
 Regards
 
 Antonio
 
 On Nov 12, 2012, at 6:48 PM, Robert Munteanu wrote:
 
 Hi,
 
 By trying out Slingclipse on a larger project I found out that checking out 
 a resource fails if the DefaultGetServlet does not serve calls for a 
 specific resource, e.g.
 
 - content ( nt:folder ) 
 \- child ( my:resource )
 
 where my:resource is served by a servlet which returns 404 on JSON calls. 
 The importer correctly discovers that /content/child exists since it is 
 listed at /content.1.json but then retrieval fails for /content/child.json .
 
 What would be the best approach to handle this scenario?
 
 Thanks,
 
 Robert
 
 
 
 -
 No virus found in this message.
 Checked by AVG - www.avg.com
 Version: 2013.0.2793 / Virus Database: 2629/5892 - Release Date: 11/13/12
 



Re: [slingclipse] Checking out resources fails if the DefaultGetServlet does not serve the content

2012-11-14 Thread Antonio Sanso
Hi Robert,

thanks for reporting this.
It would be something to investigate for sure.
Would also be interesting to know the current behavior. What's happening in 
this failure situation?
Does the import stops completely or it just doesn't import a part of the 
repository?

Regards

Antonio

On Nov 12, 2012, at 6:48 PM, Robert Munteanu wrote:

 Hi,
 
 By trying out Slingclipse on a larger project I found out that checking out a 
 resource fails if the DefaultGetServlet does not serve calls for a specific 
 resource, e.g.
 
 - content ( nt:folder ) 
 \- child ( my:resource )
 
 where my:resource is served by a servlet which returns 404 on JSON calls. The 
 importer correctly discovers that /content/child exists since it is listed at 
 /content.1.json but then retrieval fails for /content/child.json .
 
 What would be the best approach to handle this scenario?
 
 Thanks,
 
 Robert



RE: [slingclipse] Checking out resources fails if the DefaultGetServlet does not serve the content

2012-11-14 Thread Robert Munteanu
Hi Antonio,

 Hi Robert,
 
 thanks for reporting this.
 It would be something to investigate for sure.
 Would also be interesting to know the current behavior. What's happening in
 this failure situation?
 Does the import stops completely or it just doesn't import a part of the
 repository?

Well, it depends. I encountered two situations in my testing:

1. The repository returns a 4xx status, which means that the command fails and 
the import continues, but the user is not notified
2. The repository returns invalid JSON due to a sloppy script/servlet mapping 
which breaks the import since the JSON error is propagated.

Robert

 
 Regards
 
 Antonio
 
 On Nov 12, 2012, at 6:48 PM, Robert Munteanu wrote:
 
  Hi,
 
  By trying out Slingclipse on a larger project I found out that checking out
 a resource fails if the DefaultGetServlet does not serve calls for a specific
 resource, e.g.
 
  - content ( nt:folder )
  \- child ( my:resource )
 
  where my:resource is served by a servlet which returns 404 on JSON calls.
 The importer correctly discovers that /content/child exists since it is
 listed at /content.1.json but then retrieval fails for /content/child.json .
 
  What would be the best approach to handle this scenario?
 
  Thanks,
 
  Robert



RE: [slingclipse] Checking out resources fails if the DefaultGetServlet does not serve the content

2012-11-14 Thread Dan Klco
Antonio,

This was something I was concerned about with using the built in get servlet 
for retrieving the content.  Would it make any sense to create a servlet which 
would retrieve resources without being affected by the Sling URL Mapping or 
other application rewriting?

-Dan

-Original Message-
From: Antonio Sanso [mailto:asa...@adobe.com] 
Sent: Wednesday, November 14, 2012 5:31 AM
To: dev@sling.apache.org
Subject: Re: [slingclipse] Checking out resources fails if the 
DefaultGetServlet does not serve the content

Hi Robert,

thanks for reporting this.
It would be something to investigate for sure.
Would also be interesting to know the current behavior. What's happening in 
this failure situation?
Does the import stops completely or it just doesn't import a part of the 
repository?

Regards

Antonio

On Nov 12, 2012, at 6:48 PM, Robert Munteanu wrote:

 Hi,
 
 By trying out Slingclipse on a larger project I found out that checking out a 
 resource fails if the DefaultGetServlet does not serve calls for a specific 
 resource, e.g.
 
 - content ( nt:folder ) 
 \- child ( my:resource )
 
 where my:resource is served by a servlet which returns 404 on JSON calls. The 
 importer correctly discovers that /content/child exists since it is listed at 
 /content.1.json but then retrieval fails for /content/child.json .
 
 What would be the best approach to handle this scenario?
 
 Thanks,
 
 Robert



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2793 / Virus Database: 2629/5892 - Release Date: 11/13/12