I have used Ktor JVM Client for doing network calls in Compose for Desktop Application.
Network calls are working fine in Debug build means when I am just running the application it's working fine.
But when I create the EXE distribution file, by executing the packageExe task in Gradle, it's creating an EXE file. I have installed it on my machine. Then I am running the application and I am seeing that network calls are not working. I have checked internet is working properly.
Please provide a solution to fix this issue. Thanks in advance.
Your question doesn't leave any details about the failure type (compile error? runtime exception? Empty data? etc.).
But if I had to speculate based on such limited information, I'd guess it's probably this: https://github.com/JetBrains/compose-jb/issues/429
Specifically, when packaging, you need to specify which JVM modules you want to be packed into your distributable app, and likely you are missing your crypto module. Try something like this:
compose.desktop {
application {
mainClass = "MainKt"
nativeDistributions {
modules("jdk.crypto.ec")
targetFormats(TargetFormat.Dmg, TargetFormat.Msi, TargetFormat.Deb)
packageName = "untitled"
}
}
}
I'm trying to get Spartacus to work with SSR. When opening the default URL, http://localhost:4200, the storefront renders, as expected, but only after I clear the site data first. When I attempt to browse the storefront, API calls fail with a 504 (Gateway timeout). Chrome dev tools indicates the error is happening in the service worker. At this point, I'm wondering if I configured Spartacus incorrectly. When running Spartacus using yarn start rather than yarn serve:ssr, I can load the home page and browse the site normally.
OS: Ubuntu 16.04.6 LTS
Chrome Version: 73.0.3683.75
Node version: 11.15.0
Angular CLI version: 8.3.8
Yarn version: 1.19.1
ng new ssr-spartacus-app --style=scss
cd ssr-spartacus-app
ng add #spartacus/schematics --baseUrl https://localhost:9002 --baseSite cmssiteuid --pwa --ssr
rm src/app/app.component.html
echo "<cx-storefront>Loading...</cx-storefront>" > src/app/app.component.html
yarn build:ssr
yarn serve:ssr
Before running yarn build:ssr, I made following change to the app.module.ts file:
Before
context: {
baseSite: ['cmssiteuid'],
},
After
authentication: {
client_id: 'mobile_android',
client_secret: 'secret',
},
context: {
urlParameters: ['baseSite', 'language', 'currency'],
baseSite: ['cmssiteuid'],
},
I also set anonymousConsents to false. With this set to true, I was getting a lot of CORs errors.
If been scratching my head with this for a little while now and I'm hoping someone with more knowledge of Spartacus' inner workings can shed some light on why Spartacus is behaving this way with SSR.
I'm not sure that I can give you some certain recipe to fix the issue, obviously I need more details and logs relates to your problem, but still, based on my experience I can share with you some tips and tricks about how we should play with such issues (which relates to SSR).
Some set of theory which relates to SSR
https://angular.io/guide/universal (you can feel free to use Angular official documentation as a primary source, cuz Spartacus uses Angular OOTB features to make it works)
https://sap.github.io/spartacus-docs/server-side-rendering-in-spartacus/
https://enable.cx.sap.com/tag/tagid/spartacus (SSR related videos)
Practical approaches for debugging SSR
You should observe and analyze console output during starting your application in Node.js
You can use SSR configuration from example Storefront application (https://github.com/SAP/spartacus/tree/develop/projects/storefrontapp) like a starting point, cuz OOTB SSR works like a charm
Something from Spartacus team https://sap.github.io/spartacus-docs/how-to-debug-server-side-rendered-storefront/
Common set of theory to ensure that application has been configured correctly
SAP Commerce Cloud configuration for working with Spartacus https://sap.github.io/spartacus-docs/installing-sap-commerce-cloud/
Take a look on the guide https://sap.github.io/spartacus-docs/building-the-spartacus-storefront-from-libraries/ to ensure, that your frontend application has correct configuration
Double check your configuration which B2cStorefrontModule is using (here you can find an example project here https://github.com/SAP/spartacus/tree/develop/projects/storefrontapp)
Take a look on Network and Console browser tabs and try to resolve all errors
did you turn off PWA?
Turn PWA off.
As soon as Spartacus is installed in PWA mode, a service worker is installed, and it serves a cached version of index.html, along with the js files. This results in SSR being completely skipped. The following steps describe how to turn off PWA:
Check that there are no service workers registered in your app. If you do find any service workers, remove them.
Turn PWA off in your app module configuration, as follows:
StorefrontModule.withConfig({
backend: {
occ: {
baseUrl: 'https://[your_enpdoint],
},
},
pwa: {
enabled: false,
},
};
Rebuild your local Spartacus libraries by running the following command:
yarn build:core:lib
Build your local Spartacus shell app by running the following command:
yarn build --prod
Build the SSR version of your shell app by running the following command:
yarn build:ssr
Start Spartacus with the SSR server by running the following command:
yarn serve:ssr
If you are getting 504 after hitting the API service you need to check your API logs.
IF you have err log:
{"instant":{"epochSecond":1644915623,"nanoOfSecond":929833000},"thread":"hybrisHTTP1","level":"ERROR","loggerName":"org.springframework.web.servlet.DispatcherServlet","message":"Context initialization failed","thrown":{"commonElementCount":0,"localizedMessage":"Error creating bean with name 'cartEntriesController': Injection of resource dependencies failed; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'defaultStockValidator' defined in ServletContext resource [/WEB-INF/config/v2/validators-v2-spring.xml]: Unsatisfied dependency expressed through constructor parameter 0: Could not convert argument value of type [de.hybris.platform.ycommercewebservices.stock.impl.DefaultCommerceStockFacade] to required type [de.hybris.platform.commercewebservices.core.stock.CommerceStockFacade]: Failed to convert value of type 'de.hybris.platform.ycommercewebservices.stock.impl.DefaultCommerceStockFacade' to required type 'de.hybris.platform.commercewebservices.core.stock.CommerceStockFacade'; nested exception is java.lang.IllegalStateException: Cannot convert value of type 'de.hybris.platform.ycommercewebservices.stock.impl.DefaultCommerceStockFacade' to required type 'de.hybris.platform.commercewebservices.core.stock.CommerceStockFacade': no matching editors or conversion strategy found","message":"Error creating bean with name 'cartEntriesController': Injection of resource dependencies failed; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'defaultStockValidator'
You can try resolution:
Remove template extension ycommercewebservices extension from manifest.json, rebuild and redeploy with "Migrate Data" mode.
I follow this example;
https://github.com/JanusGraph/janusgraph/tree/master/janusgraph-examples/example-remotegraph
and I would like to debug this project, I configured(HBase+Solr) and run Janus Graph server with
$JANUSGRAPH_HOME/bin/gremlin-server.sh $JANUSGRAPH_HOME/conf/gremlin-server/gremlin-server.yaml
command.
I passed this argument to IDEA via Run Configuration > Program Arguments
[Project Home]/conf/jgex-remote.properties
my jgex-remote.properties file is:
gremlin.remote.remoteConnectionClass=org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteConnection
# cluster file has the remote server configuration
gremlin.remote.driver.clusterFile=[Project Home]/conf/remote-objects.yaml
# source name is the global graph traversal source defined on the server
gremlin.remote.driver.sourceName=g
and my remote-objects.yaml file includes:
hosts: [127.0.0.1]
port: 8182
serializer: {
className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0,
config: {
ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry]
}
}
It tries to run this command:
cluster = Cluster.open(conf.getString("gremlin.remote.driver.clusterFile"));
And throws this exception:
Exception in thread "main" java.lang.NoSuchFieldError: V3_0 at
org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV3d0.(GryoMessageSerializerV3d0.java:41)
at
org.apache.tinkerpop.gremlin.driver.ser.Serializers.simpleInstance(Serializers.java:77)
at
org.apache.tinkerpop.gremlin.driver.Cluster$Builder.(Cluster.java:472)
at
org.apache.tinkerpop.gremlin.driver.Cluster$Builder.(Cluster.java:469)
at
org.apache.tinkerpop.gremlin.driver.Cluster.getBuilderFromSettings(Cluster.java:167)
at
org.apache.tinkerpop.gremlin.driver.Cluster.build(Cluster.java:159)
at org.apache.tinkerpop.gremlin.driver.Cluster.open(Cluster.java:233)
at
com.ets.dataplatform.init.RemoteGraphApp.openGraph(RemoteGraphApp.java:72)
at com.ets.dataplatform.init.GraphApp.runApp(GraphApp.java:290) at
com.ets.dataplatform.init.RemoteGraphApp.main(RemoteGraphApp.java:195)
It is not meaningful for me.
Thanks in advance.
I would try to align your versions. I assume that you are using JanusGraph 0.2.0. If you look at the pom.xml for that version you'll see that it is bound to TinkerPop 3.2.6:
https://github.com/JanusGraph/janusgraph/blob/v0.2.0/pom.xml#L68
Change to that version in your application and see if the connection works. Taking that approach should not only fix your problem but also ensure that you don't run into other incompatibilities. That is not to say that you can't configure later versions of TinkerPop to work with 3.2.6, but it requires a bit more configuration and you have to be aware of minor changes that might affect how certain operations might behave.
I've faced an issue with configuring RabbitMQ with Spring Boot.
I need to override host value for my application. I use JavaConfig approach. I use auto configuration feature as well.
So I put spring.rabbitmq.host=myhost.com property into application.properties but RabbitMQ ConnectionFactory still created with localhost value.
UPDATE1: Seems like my embedded Tomcat instance doesn't pick up updates in property files. I've added some custom property and Spring can't resolve the placeholder for it.
I run my application in IntellijIdea 14 as a common java app.
All class changes are picked up by IntellijIdea&Tomcat but all resources folder content is not.
Is this IntellijIdea 14 related issue?
Thanks in advance.
If you do that from test-case, be sure to use:
#ContextConfiguration(initializers = ConfigFileApplicationContextInitializer.class)
For the test class.
I think the name of the initializer should say for itself.
Issue was resolved. There was issue with IntellijIdea 14 & 13 Gradle project setup/files compatibility. So Re-Import of the project is a solution.
I'm using a VMware jar in my Tomcat webapp to gather VM information. When launching JProfiler from inside IDEA 10.5 everything runs fine until I call into the VMware jar whereupon I get an IllegalAccessException.
Is there a way to prevent JProfiler from looking into the jar? I tried an exclusion filter on com.vmware.vim25 but that had no effect.
Here's the stack trace:
java.lang.IllegalAccessException: Class com.vmware.vim25.ws.XmlGen can not access a member of class java.lang.Object with modifiers "static transient"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
at java.lang.reflect.Field.doSecurityCheck(Field.java:960)
at java.lang.reflect.Field.getFieldAccessor(Field.java:896)
at java.lang.reflect.Field.get(Field.java:358)
at com.vmware.vim25.ws.XmlGen.toXML(XmlGen.java:696)
at com.vmware.vim25.ws.XmlGen.toXML(XmlGen.java:633)
at com.vmware.vim25.ws.XmlGen.toXML(XmlGen.java:707)
at com.vmware.vim25.ws.XmlGen.toXML(XmlGen.java:633)
at com.vmware.vim25.ws.XmlGen.toXML(XmlGen.java:584)
at com.vmware.vim25.ws.WSClient.createSoapMessage(WSClient.java:219)
at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:170)
at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:124)
at com.vmware.vim25.ws.VimStub.retrieveProperties(VimStub.java:77)
at com.vmware.vim25.mo.PropertyCollector.retrieveProperties(PropertyCollector.java:107)
at com.vmware.vim25.mo.ManagedObject.retrieveObjectProperties(ManagedObject.java:155)
at com.vmware.vim25.mo.ManagedObject.getCurrentProperty(ManagedObject.java:179)
at com.vmware.vim25.mo.ManagedObject.getManagedObjects(ManagedObject.java:221)
at com.vmware.vim25.mo.ManagedObject.getManagedObjects(ManagedObject.java:268)
at com.vmware.vim25.mo.ManagedObject.getVms(ManagedObject.java:298)
at com.vmware.vim25.mo.Datastore.getVms(Datastore.java:81)
[snip]
The JProfiler people got back to me and suggested trying a pre-release version of 7.1 as they've changed the way the product works in this area. This new version does indeed solve this problem so I'm now able to move forward.