Switch to MongoDB
Added MongoDB support. Added random select, a few filters, BSON codecs, sorting, secret properties.
Change-Id: I613403d5586f192fd68666df234139353069f8a2 Signed-off-by: Martin Lowe martin.lowe@eclipse-foundation.org
Merge request reports
Activity
There are still superficial changes to make in these branches (comments, tidying up some code), but I wanted to create this PR to get eyes on general structure before I commit too far to the current layout. Some of the things I think are the bigger question marks are the SortableField annotations and the combintation of codecs and converters in the DTO package
18 * 19 * @author Martin Lowe 20 */ 21 public class StreamHelper { 22 private static final Logger LOGGER = LoggerFactory.getLogger(StreamHelper.class); 23 24 /** 25 * Unwraps and awaits a completion stage to complete, returning the internal 26 * result when finished. 27 * 28 * @param <T> the type of object that contains results of async call 29 * @param stage the completion stage to await results for 30 * @return the result, or null if one couldn't be found 31 */ 32 public static <T> T awaitCompletionStage(CompletionStage<T> stage) { 33 CompletableFuture<T> future = stage.toCompletableFuture(); 18 * 19 * @author Martin Lowe 20 */ 21 public class StreamHelper { 22 private static final Logger LOGGER = LoggerFactory.getLogger(StreamHelper.class); 23 24 /** 25 * Unwraps and awaits a completion stage to complete, returning the internal 26 * result when finished. 27 * 28 * @param <T> the type of object that contains results of async call 29 * @param stage the completion stage to await results for 30 * @return the result, or null if one couldn't be found 31 */ 32 public static <T> T awaitCompletionStage(CompletionStage<T> stage) { 33 CompletableFuture<T> future = stage.toCompletableFuture(); I've actioned your comments, and added a few more things, mainly the following:
- Added maintenance flag to MongoDB
- Added a MaintenanceException, and a Mapper that catches it in the resource.
- Created a few basic health (liveness/readiness) checks for the application. There is a new interface with a default implementation and 1 method to implement to standardize checking bean health.
I'll stop touching this now, as its in a stable state for alpha release.
@mbarbero I've pushed a large update that does a number of things within the project. I've documented them in the commit (which has split from the commit I was working on for base Mongo functionality).
The reason I point this out is I've hit a blocker in that CDI is fighting me tooth and nail to create something in the RequestScope of Quarkus (3. Scopes and contexts -> @RequestScoped). The class I'm trying to manage through CDI is
MongoQuery
, which I can create manually in my ResourceListing class (see commented out code in said class for how I was doing it), but not when I set it to be managed.The items all individually work, its when I put it all together that it falls apart and complains that there are unresolved dependencies. I've included a stack trace that I get when attempting to build. The only thing I can think of is that type erasure interferes with the retrieval of the resources in CDI, but I don't know how to either verify or circumvent the issue. Do you have any thoughts?
[error]: Build step io.quarkus.arc.deployment.ArcProcessor#validate threw an exception: javax.enterprise.inject.spi.DeploymentException: javax.enterprise.inject.UnsatisfiedResolutionException: Unsatisfied dependency for type org.eclipsefoundation.marketplace.model.MongoQuery<org.eclipsefoundation.marketplace.dto.Listing> and qualifiers [@Default] - java member: org.eclipsefoundation.marketplace.resource.ListingResource#mq - declared on CLASS bean [types=[org.eclipsefoundation.marketplace.resource.ListingResource, java.lang.Object], qualifiers=[@Default, @Any], target=org.eclipsefoundation.marketplace.resource.ListingResource] at io.quarkus.arc.processor.BeanDeployment.processErrors(BeanDeployment.java:835) at io.quarkus.arc.processor.BeanDeployment.init(BeanDeployment.java:214) at io.quarkus.arc.processor.BeanProcessor.initialize(BeanProcessor.java:106) at io.quarkus.arc.deployment.ArcProcessor.validate(ArcProcessor.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at io.quarkus.deployment.ExtensionLoader$1.execute(ExtensionLoader.java:768) at io.quarkus.builder.BuildContext.run(BuildContext.java:415) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:2011) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1535) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1426) at java.lang.Thread.run(Thread.java:748) at org.jboss.threads.JBossThread.run(JBossThread.java:479)
Created by: mbarbero
The issue seems to be in the ARC component of Quarkus which AFAIK is the partial CDI implementation from Quarkus (made to better work with SubstrateVM) so there may be limitations. There is nothing obvious to me from a quick look. I'd suggest you open a question on stackoverflow as specified here https://quarkus.io/community/#discussions.