I get following warnings when I try to run BLC demo application. Although there is no known issue caused by these warnings but I would like to know how can I resolve these warnings?
[ WARN] 23:05:05 MergePersistenceUnitManager - A BroadleafClassTransformer is configured for this persistence unit, but Spring reported a problem (likely that a LoadTimeWeaver is not registered). As a result, the Broadleaf Commerce ClassTransformer (org.broadleafcommerce.common.extensibility.jpa.copy.DirectCopyClassTransformer) is not being registered with the persistence unit.
[ WARN] 23:05:05 MergePersistenceUnitManager - A BroadleafClassTransformer is configured for this persistence unit, but Spring reported a problem (likely that a LoadTimeWeaver is not registered). As a result, the Broadleaf Commerce ClassTransformer (org.broadleafcommerce.common.extensibility.jpa.convert.EntityMarkerClassTransformer) is not being registered with the persistence unit.
[ WARN] 23:05:05 MergePersistenceUnitManager - A BroadleafClassTransformer is configured for this persistence unit, but Spring reported a problem (likely that a LoadTimeWeaver is not registered). As a result, the Broadleaf Commerce ClassTransformer (org.broadleafcommerce.common.extensibility.jpa.copy.DirectCopyClassTransformer) is not being registered with the persistence unit.
[ WARN] 23:05:13 AbstractEhcacheRegionFactory - HHH020003: Could not find a specific ehcache configuration for cache named [blSandBoxElements]; using defaults.
[ WARN] 23:05:29 DefaultFilterChainValidator - Possible error: Filters at position 12 and 13 are both instances of org.springframework.security.web.access.intercept.FilterSecurityInterceptor
You need to add -javaagent:/path/of/spring-instrument.jar into your Tomcat or any server VM args.
It has everything to do with spring instrument when coming from BroadleafCommerce
may be you need to add "-javaagent:spring-instrument-3.2.2.RELEASE.jar" into vm args.
Related
I'm working on upgrading our service to use 3.63.0 (upgrading from 3.57.0) and I've noticed the following warning (with stack trace) shows up in the logs that wasn't there on the previous version:
2022-02-18 14:03:41.038 WARN 1088 --- [ main] c.s.c.s.c.c.AbstractHttpClientCache : Could not get HttpClient cache.
com.sap.cloud.sdk.cloudplatform.thread.exception.ThreadContextAccessException: No ThreadContext available for thread id=1.
at com.sap.cloud.sdk.cloudplatform.thread.ThreadLocalThreadContextFacade.lambda$tryGetCurrentContext$0(ThreadLocalThreadContextFacade.java:39) ~[cloudplatform-core-3.63.0.jar:na]
at io.vavr.Value.toTry(Value.java:1414) ~[vavr-0.10.4.jar:na]
at com.sap.cloud.sdk.cloudplatform.thread.ThreadLocalThreadContextFacade.tryGetCurrentContext(ThreadLocalThreadContextFacade.java:37) ~[cloudplatform-core-3.63.0.jar:na]
at io.vavr.control.Try.flatMapTry(Try.java:490) ~[vavr-0.10.4.jar:na]
at io.vavr.control.Try.flatMap(Try.java:472) ~[vavr-0.10.4.jar:na]
at com.sap.cloud.sdk.cloudplatform.thread.ThreadContextAccessor.tryGetCurrentContext(ThreadContextAccessor.java:84) ~[cloudplatform-core-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.RequestScopedHttpClientCache.getCache(RequestScopedHttpClientCache.java:28) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.AbstractHttpClientCache.tryGetOrCreateHttpClient(AbstractHttpClientCache.java:78) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.AbstractHttpClientCache.tryGetHttpClient(AbstractHttpClientCache.java:46) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.HttpClientAccessor.tryGetHttpClient(HttpClientAccessor.java:153) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.HttpClientAccessor.getHttpClient(HttpClientAccessor.java:131) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.octanner.mca.service.MarketingCloudApiContactService.uploadContacts(MarketingCloudApiContactService.java:138) ~[classes/:na]
...
This happens when the following calls are made...
Using the lower level API
HttpClient httpClient = HttpClientAccessor.getHttpClient(destination); // warning happens here
ODataRequestResultMultipartGeneric batchResult = requestBatch.execute(httpClient);
Using the higher level API
service
.getAllContactOriginData()
.withQueryParameter("$expand", "AdditionalIDs")
.top(size)
.filter(filter)
.executeRequest(destination)); // warning happens here
Even though this warning shows up in the logs the service requests do continue to work as expected. It's just a little concerning to see this and I'm wondering if maybe I have something misconfigured. I reviewed all of the java docs and the troubleshooting page and didn't see anything out of the ordinary other than how I am fetching my destination, but even using the DestinationAccessor didn't seem to make a difference. Also, I'm not doing any asynchronous or multi-tenant processing.
Any help you or guidance you can give on this would be appreciated!
Cheers!
Such an issue is often the result of missing Spring Boot annotations - especially in synchronous executions.
Please refer to our documentation to learn more about the SAP Cloud SDK Spring Boot integration.
Edit Feb. 28th 2022
It is safe to ignore the logged warning if your application does not need any of the SAP Cloud SDK's multitenancy features.
Error Cause
The SAP Cloud SDK for Java recently (in version 3.63.0) introduced a change to the thread propagation behavior of the HttpClientCache.
With that change, we also adapted the logging in case the propagation didn't work as expected - this is often caused by not using the ThreadContextExecutor for wrapping asynchronous operations.
This is the reason for logs like the one described by the issue author.
Planned Mitigation
In the meanwhile, we realized that these WARN logs are causing confusion on the consumer side.
We are working on improving the situation by degrading the log level to INFO for the message and to DEBUG for the exception.
Have been trying to configure Reportportal withe a sample project. The following steps have been done:
1.Start a Docker and get the reportporal page up and running.
2.In the Java project, added the bintray repository, java-agent-testng, logger-java-log4j dependencies.
3.Included log4j.properties file in the project and also the log4j.appender line for reprortportal
log4j.appender.reportportal=com.epam.ta.reportportal.log4j.appender.ReportPortalAppender
log4j.appender.reportportal.layout=org.apache.log4j.PatternLayout
log4j.appender.reportportal.layout.ConversionPattern=[%d{HH:mm:ss}] %-5p (%F:%L) - %m%n
4.Included log4j info lines for one of the #Test methods.
5.Ran the Test script and made sure the log info line is seen on the console.
6.However, the reportportal dashboard still shows "No Results Found"
7.Also, added the following line for the Test Method.
#Listeners({ReportPortalTestNGListener.class})
8. This threw an exception with Jackson.
A few questions running in my mind:
1.Do we need both TestNG and Log4j to integrate with reportportal or just one of them is fine.
2. With the above steps carried out, is there anything that has been missed. Why am I not seeing data on my reportportal dashboard.
I only did this using the testNG integration. We do have log4j but didn't needed that to post the tests in RP.
I do not however, have any screenshots or attachments.I think that is log4j integration.
#Chethan Swaroop
TestNG integration will send events as testStarted, testEnded into ReportPortal.
This will help to represent structure of test cases and statuses in RP.
Log4J integration (logger appender) will forward logs output into RP server, associating log line with active test case at the moment.
You can have only testNG integration, without logs (log4j), but you can't have log4j, without testing engine integration (testNG in you case)
Please try examples with you local ReportPortal instance:
https://github.com/reportportal/example-java-TestNG/tree/master/logback/src/main/java/com/epam/rp/tests
We have implemented Hazelcast as an embedded cache in our Spring Boot app, and need a way using which Hazelcast members within a "cluster group" can discover each other dynamically so that we dont have to provide possible IP address/port where Hazelcast might be running.
We came across this hazelcast plugin on github:
https://github.com/hazelcast/hazelcast-eureka which seems to provide the same feature using Eureka as discovery/registration tool.
As mentioned in this github documentation, hazelcast-eureka-one library is included within our boot app classpath, we also disabled TCP-IP & multicast discovery and added below discovery strategy in hazelcast.xml:
<discovery-strategies>
<discovery-strategy class="com.hazelcast.eureka.one.EurekaOneDiscoveryStrategy" enabled="true">
<properties>
<property name="self-registration">true</property>
<property name="namespace">hazelcast</property>
</properties>
</discovery-strategy>
</discovery-strategies>
Our application also provides configured EurekaClient, which is what we are autowiring and inject into this plugin implementation:
*
Config hazelcastConfig = new FileSystemXmlConfig(hazelcastConfigFilePath);
**EurekaOneDiscoveryStrategyFactory.setEurekaClient(eurekaClient);**
hazelcastInstance = Hazelcast.newHazelcastInstance(hazelcastConfig);
*
Problem:
We are able to start 2 instances of our spring boot app on same machine and we notice that each app is starting hazelcast instance embedded on separate port (5701, 5702). But it doesnt seem to recognize each other running within a cluster, this is what we see in app logs when 2nd instance is starting:
Members [1] {
Member [10.41.70.143]:5702 - 7c42eb24-3fa0-45cb-9394-17175cc92b9c this
}
17-12-13 12:22:44.480 WARN [main] c.h.i.Node.log(LoggingServiceImpl.java:168) - [10.41.70.143]:5702 [domain-services] [3.8.2] Config seed port is 5701 and cluster size is 1. Some of the ports seem occupied!
which seem to indicate that both hazelcast instances are running independently and doesnt recognize other running instance in a cluster/group.
Also, immediately after restart we see this exception thrown frequently on both the nodes:
*
java.lang.ClassCastException: com.hazelcast.nio.tcp.MemberWriteHandler cannot be cast to com.hazelcast.nio.ascii.TextWriteHandler
at com.hazelcast.nio.ascii.TextReadHandler.<init>(TextReadHandler.java:109) ~[hazelcast-3.8.2.jar:3.8.2]
at com.hazelcast.nio.tcp.SocketReaderInitializerImpl.init(SocketReaderInitializerImpl.java:89) ~[hazelcast-3.8.2.jar:3.8.2]
*
which seem to indicate there is Incompatibility between hazelcast library in the classpath?
It seems like your Eureka service returns the wrong ports. Hazelcast tries to connect to 8080 and other ports in the same range, whereas Hazelcast uses 5701. Not exactly sure why this happens but it feels like you requesting the wrong service name from Eureka which ends up returning the HTTP (Tomcat?!) ports instead of the separate Hazelcast service that should be registered.
I'm written an application which uses a library (Jabber stream objects) which internally uses log4j. When I deploy the application, there are no errors. However after some time, I could see lots of error message which look like this:
[#|2013-02-26T12:48:56.147+0000|SEVERE|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=365;_ThreadName=SelectWorker 1;|java.lang.IllegalStateException: WEB9031: WebappClassLoader unable to load resource [org.apache.log4j.spi.NOPLoggerRepository], because it has not yet been started, or was already stopped
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1401)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1359)
at org.apache.log4j.LogManager.getLoggerRepository(LogManager.java:197)
at org.apache.log4j.LogManager.getLogger(LogManager.java:228)
at org.apache.log4j.Logger.getLogger(Logger.java:117)
I have log4j.jar inside the WEB-INF/lib directory of my application, along with the external library (JSO.jar)
The issue [1] looked similar, but doesn't seem to be the same.
[1] Web service is not working on GlassFish
I've found that this happens when I redeploy a Servlet and went away when I overridden destroy() for my Servlet and did some cleanup there.
There are alot of settings in all the versions of IE & windows, that may cause problems for users attempting to run xbap applications, particulary in fulltrust mode.
I seem to have gathered a long list of such cases during the last year.
However I'm pussled by this one exception, which occurs on a user on one of my systems, and was hoping that maybe someone here could point me in the right direction.
This application runs on all the used version of windows, and IE6 -> IE9, without problems so there is nothing wrong with the deployment/xbap it self.
The user gets the errorlog / stacktrace below. Have anyone of you encountered this vague trace, and know what the issue might be? This user is running IE8 & W7.
The user have the proper certificates installed in trusted root authorities & trusted publishers. The site in question has been added to list of trusted sites. Xbap has been enabled in IE.
URLs, publickeys, appname etc have been scrambeled.
Brgds,
Stian
PLATFORM VERSION INFO
Windows : 6.1.7600.0 (Win32NT)
Common Language Runtime : 2.0.50727.4963
System.Deployment.dll : 2.0.50727.4927 (NetFXspW7.050727-4900)
mscorwks.dll : 2.0.50727.4963 (win7RTMGDR.050727-4900)
dfshim.dll : 4.0.31106.0 (Main.031106-0000)
SOURCES
Deployment url : http://someurl/someapplication.xbap
Application url : http://someurl/Application%20Files/someapplication_1_0_0_29/someapplication.exe.manifest
IDENTITIES
Deployment Identity : someapplication.app, Version=1.0.0.29, Culture=neutral, PublicKeyToken=sometoken, processorArchitecture=msil
Application Identity : someapplication, Version=1.0.0.29, Culture=neutral, PublicKeyToken=sometoken, processorArchitecture=msil, type=win32
APPLICATION SUMMARY
* Online only application.
* Browser-hosted application.
ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later in the log.
* An exception occurred while determining trust. Following failure messages were detected:
+ User has refused to grant required permissions to the application.
* An exception occurred while downloading the application. Following failure messages were detected:
+ The AssertApplicationRequirements method failed. The application cannot be committed.
COMPONENT STORE TRANSACTION FAILURE SUMMARY
No transaction error was detected.
WARNINGS
There were no warnings during this operation.
OPERATION PROGRESS STATUS
No phase information is available.
ERROR DETAILS
Following errors were detected during this operation.
* [01/11/2011 09:16:02] System.Deployment.Application.TrustNotGrantedException (Unknown subtype)
- User has refused to grant required permissions to the application.
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.ApplicationTrust.RequestTrust(SubscriptionState subState, Boolean isShellVisible, Boolean isUpdate, ActivationContext actCtx, TrustManagerContext tmc)
at System.Deployment.Application.DeploymentManager.DetermineTrustCore(Boolean blocking, TrustParams tp)
at System.Deployment.Application.DeploymentManager.DetermineTrust(TrustParams trustParams)
at System.Deployment.Application.InPlaceHostingManager.AssertApplicationRequirements(Boolean grantApplicationTrust)
at System.Deployment.Application.InPlaceHostingManager.AssertApplicationRequirements()
at MS.Internal.AppModel.XappLauncherApp.AssertApplicationRequirementsAsync(Object unused)
* [01/11/2011 09:16:37] System.Deployment.Application.DeploymentException (Unknown subtype)
- The AssertApplicationRequirements method failed. The application cannot be committed.
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.DeploymentManager.WaitForAssertApplicationRequirements()
at System.Deployment.Application.DeploymentManager.SynchronizeCore(Boolean blocking)
at System.Deployment.Application.DeploymentManager.SynchronizeAsyncWorker()
COMPONENT STORE TRANSACTION DETAILS
No transaction information is available.
I should have answered this one when I "solved" the issue.
In the case above there was an issue with the client computer, a change of disk, re-install of OS etc solved the trick.
What the issue was, remains a mystery ;)