I think, we should stick with `RealmId` as it clearly means "this is the
ID of a realm". It is also a concrete type and can therefore
unambiguously @Inject'ed - whereas using CDI qualifiers for simple types
like j.l.String does not work well in practice.
I do not mind having another type or se
Thanks for starting this discussion, Yufei! I think it is important to
clarify this sooner rather than later.
>From my POV option 2 (String) is cumbersome. The biggest reasons being more
complex CDI injection (as already noted by other people) but also more
complicated usage searches in IDEs.
As
Hi all,
I guess we need to align our vision of what "RealmId" (or whatever we call
it eventually) actually represents.
Some of us seem to consider that this component is really just the unique
identifier of a realm entity, pretty much like a primary key. Under that
vision, the component is not ex
I'd prefer to keep RealmId for just the ID then, and add a separate
Realm type when there's a use case for it in Polaris.
Custom realm-specific additions can always produced when needed - e.g.
using `@Produces @RequestScoped MyRealmData produceMyRealmData(RealmId
id, OtherBeanOne one, AnotherB
Good point about entity injection. I still have reservations, but I guess
we can address any specific issues when we hit them.
If we go with entity injection, I'd think the refactoring has to go beyond
the class/interface renaming and aim at removing `Realm` method parameters.
I believe Realm will
+1 (binding)
Verified
Checksum
Signatures - Note that me and JB need to verify each other's keys next time
we meet in person :)
Build and Test
Used runApp and poked to make sure nothing was broken
On Thu, Jan 23, 2025 at 6:41 PM Dmitri Bourlatchkov
wrote:
> +1 (ns)
>
> Verified:
> * Checksum
>
-1 because I think I’ve found copied source code that is not documented in
the LICENSE file. I grepped for [Cc]opied and found that there are several
mustache files that were copied from openapi-generator that are not
documented in LICENSE. The openapi-generator project has an ALv2 LICENSE
file wit
Mustache templates for server and client code are copied and modified from
https://github.com/OpenAPITools/openapi-generator/tree/master/modules/openapi-generator/src/main/resources/JavaJaxRS/resteasy
Mike
On Mon, Jan 27, 2025 at 2:36 PM rdb...@gmail.com wrote:
> -1 because I think I’ve found c
Hi everyone,
Thanks for the proposal and all the great discussion! I also agree that we
should separate Polaris-only APIs from the IRC spec to keep the IRC spec
consistent with the upstream version. I’d like to propose another way to
achieve this, as some APIs may not need a separate prefix but ar
