stefangrimm commented on pull request #1:

   @bdelacretaz We need something like the suggested alternative to decouple 
what we're implementing on AEM's side from the Sling Core implementation. It's 
an important design goal for us to be able to use our implementation with other 
GraphQL frameworks as well, without requiring framework-specific code 
   With the current implementation, a scalar implementation would need to 
implement `SlingScalarConverter` directly, therefore adding a dependency on 
   The proposed solution would allow us to use framework-agnostic 
implementations of scalars for our stuff. We would then adapt these scalar 
implementations to something that's suitable for the respective framework 
within the adapter bundle (that is required for each GraphQL framework anyway).
   There might be some other solutions (although I'm by far no OSGi expert, I 
guess we could register multiple instance of the same 
`SlingScalarConverter`-implementing wrapper component (one for each scalar) 
manually within the adapter, for example, but all the additional 
lifecycle-handling (when to register/unregister) frightens me). But from our 
perspective the proposed solution would be the simplest.
   If the proposal is not acceptable for you, we can also reduce the support 
for scalars in our code to the absolute minimum. At least for now we could live 
with this.
   Note that we don't have similar problems with data fetchers, as we're 
actually only using one single data fetcher and distribute it internally with 
the help of parameters (as part of the "fetch" directive) to our own, 
Sling-unaware data fetchers.
   cc @etugarev

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:

Reply via email to