For Apache Geode, How should I do to turn off the Jetty version messages when occur 404 error - geode

We are using apache geode v1.6.0 and we also use Geode rest api.
However, when our customer do vulnerability test, they found a potential security risk and we need to fix that..
The report says, http://:7070 shows the following message
HTTP ERROR 404
Problem accessing /. Reason:
Not Found
**Powered by Jetty:// 9.4.8.v20171121**
As you can see, Jetty version was shown, and this is reported as a risk.
I searched a lot and found we can turn off the message by configure Jetty setting as follows
<Item>
<New id="DefaultHandler" class="org.eclipse.jetty.server.handler.DefaultHandler">
<Set name="showContexts">false</Set>
</New>
</Item>
But, Jetty is embedded in the Geode, how should I do to set the showContexts to false?
Any suggestion will be appreciate, thanks a lot.

The Embedded Jetty Server is started and configured in Geode through the InternalHttpService class, and this internal class doesn't provide any feature to manually configure the actual server properties or settings. The showContexts property within the DefaultHandler class, on the other hand, can't be configured through environment variables (which could be used as a workaround), it can only be configured through xml files (not used within Geode) or programatically.
Long story short: I don't think there's an out of the box way to disable the DefaultHandler as of now in Geode, I'd suggest to open a ticket through the Geode JIRA System and describe with details the actual issue and impact. The actual fix shouldn't be hard to implement on your own, though: just register a custom ErrorHandler or programatically set the showContexts property to false within the DefaultHandler instead, so you could submit a PR fixing the problem to get it merged into the Geode.

Related

Upgrading CQ5.6.1 to AEM 6.1, authentication issues

I have been following the instructions on
https://docs.adobe.com/docs/en/aem/6-1/deploy/upgrade.html
I reached "Once the upgrade is finished, the AEM homepage will be shown."
However, all I get is "an HTTP 503 status for all requests except for those under http:///system/console", exactly as described at the NOTE under this step.
The problem is that I always get this error, not only during the upgrade, but also after the upgrade is finished!
The error.log states:
11.11.2015 12:38:29.888 *ERROR* [qtp231586654-77] org.apache.sling.engine.impl.SlingHttpContext handleSecurity: AuthenticationSupport service missing. Cannot authenticate request.
11.11.2015 12:38:29.888 *ERROR* [qtp231586654-77] org.apache.sling.engine.impl.SlingHttpContext handleSecurity: Possible reason is missing Repository service. Check AuthenticationSupport dependencies.
Any help is highly appreciated.
We've encountered this once:
There were issues with diskspace (the disk was simply full), make sure you have an adequate amount of space available.
There could be two possible reasons:
Some of the bundles are not active.
Lucene is corrupt and hence not able to start
Possible fix is:
Bring your bundles back to active, if it is not active.
Stop your instance. go to crx-quickstart\repository\index and delete index folder.
Restart the instance (This will regenerate Lucene indexes fully).
Quick fix:
Stop the AEM instance.
Go to folder crx-quickstart\repository\ remove folder index
Start the AEM.
Everything should working fine. (It's working for me)
Check the permissions under crx-quickstart\repository\ after you deleted the index.
For me it had nothing to do with the segmentstore or the index or any unsatisfied bundles. Instead, it was the datastore.
The permissions for the datastore directory didn’t allow the user running aem to access it. The datastore directory is configured in org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.
This error really should reveal its root cause a little bit more easily. I’m sure it was somewhere in the logs, though…

Apache Felix not binding my configuration correctly - wrong inputstream version

I had a bundle deployed in an Apache Felix (Sling, in fact) host. The bundle contained some configurable elements, and its version was 2.0.
I have updated the bundle to v2.0.1 for some small code changes, and now the bundle will not pick up its configuration correctly - it remains at the defaults set in code rather than picking up the values configured in the Felix Web Console.
There is an error message in the log: "[Configuration Updater] org.apache.felix.scr Cannot use configuration pid=com.mypackage.MyClass for bundle inputstream:my-bundle-2.0.1.jar because it belongs to bundle inputstream:my-bundle-1.0.jar" which sounds like the cause of the issue.
However:
I can't edit the inputstream value through the web interface - only by stopping the server, editing the config file manually, and restarting. Surely when I update the bundle, the config should be updated too?
Although the inputstream specifies v1.0, the bundle did not have a problem when it was upgraded to v2.0. What's made the difference here?
I have done the same thing (though perhaps not exactly!) on two servers, and one server seems to have the config specify inputstream=v2.0 (and the bundle at v2.0.1) and it works fine. What caused inputstream version to update on this server? (Presumably the same as the answer to 2 - I imagine it'll depend exactly which steps in the process have been executed and in what order.)
Any advice gratefully received - I haven't been able to find any documentation that gives instructions or troubleshooting suggestions for administering bundles through the Felix Web Console.
If at all possible, I would simply stop and remove the bundle altogether and install it using Sling , e.g. with the maven-sling-plugin or dropping it in the /apps/myapp/install folder using WebDAV .
I find it easiest to be consistent this way and the installation is nicely automated and it handles bundle upgrades properly.

Is there Any Way to Enforce RuntimeUnenhancedClasses in EE Configuration

I just spent a half hour debugging some new code that's not broken because I forgot to check (again!) my logs for this dreaded message:
WARN openjpa.Enhance - Creating subclass for ...
I'm running OpenJPA 2.1.0 inside an OpenEJB 3.2 snapshot build, Java 1.6.0_25, and Eclipse Helios. My entities are enhanced using the ant PCEnhancerTask.
My META-INF/openjpa.xml contains
<property name="openjpa.RuntimeUnenhancedClasses" value="unsupported" />
<property name="openjpa.DynamicEnhancementAgent" value="false" />
Is there anyway with this EE configuration to have OpenJPA enforce the RuntimeUnenhancedClasses option as it does in an SE configuration?
I suspect my 'real' problem stems from an Eclipse svn update that sometimes touches my JPA entity source, causing a build that overwrites my enhanced classes.
It's frustrating how often I run a unit test from the IDE that fails in some weird way, and I go digging through my code looking for a problem when all I need to do is run the enhancer.
Put the <property name="openjpa.RuntimeUnenhancedClasses" value="unsupported" /> META-INF/persistence.xml.
Looks like we're logging this action on debug level (maybe it should be info level), but OpenEJB will set that property to the default as it was in OpenJPA 1.x so that apps that worked with OpenEJB 3.1.x/OpenJPA 1.x will still work without modification in 3.2.x. If the property is already set in the persistence.xml it will never be overridden, so setting it there will have the effect you want.
Open to suggestions on how to save others in the same boat some time in the future. Seems either looking in the openjpa.xml file and seeing the property set already or issuing the log message on info would do it -- or both.
It sounds like for whatever reason your properties aren't being picked up when running in the container.
I have a number of possible solutions:
Try setting your properties in META-INF/persistence.xml. I assume you have these properties in the openjpa.xml file for a reason, but it might help us figure out where the real problem is.
Set -Dopenjpa.RuntimeUnenhancedClasses=false as a JVM property. This will apply to all PUs for a given JVM.
Move to a version of OpenJPA that is >= 2.0.0. RuntimeUnenhancedClasses was turned off as the default behavior in that release.

GWT - occasional com.google.gwt.user.client.rpc.SerializationException

we are haunted by occasional occurences of exceptions such as:
com.google.gwt.user.client.rpc.SerializationException: Type 'xxx' was not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' and did not have a custom field serializer.For security purposes, this type will not be serialized.: instance = xxx
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize(ServerSerializationStreamWriter.java:610)
at com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamWriter.writeObject(AbstractSerializationStreamWriter.java:129)
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter$ValueWriter$8.write(ServerSerializationStreamWriter.java:152)
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serializeValue(ServerSerializationStreamWriter.java:534)
at com.google.gwt.user.server.rpc.RPC.encodeResponse(RPC.java:609)
at com.google.gwt.user.server.rpc.RPC.encodeResponseForSuccess(RPC.java:467)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:564)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:188)
at de.softconex.travicemanager.server.TraviceManagerServiceImpl.processCall(TraviceManagerServiceImpl.java:615)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:224)
at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:419)
at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:378)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1508)
at java.lang.Thread.run(Thread.java:619)
The application is normally running fine. The indicated class implements Serializable (the whole object graph).
So far the only patterns / observations are:
we seem to have the issue only when the application is used inside an iframe
the problem seems to happen when a new version of the application has been deployed
running firefox in privacy mode (disabling all caches etc.) doesn't fix the problem
Any ideas?
Holger
did you check http://code.google.com/webtoolkit/doc/latest/tutorial/RPC.html#serialize
the article says:
It has a default (zero argument) constructor with any access modifier (e.g. private Foo(){} will work)
I'm allways forgetting zeroargument const. when I am making a serializable object :D
Very possible reason - older version of client is still cached in browser. It sends rpc requests, but server is already restarted and have newer versions of rpc files (*.symbolMap)
I encountered the problem when I used Tomcat6 + Devmode in Ubuntu Lucid amd64. Using com.google.gwt.user.client.rpc.IsSerializable instead of java.io.Serializable seemed solved the problem.
I assume you're running the application on localhost and in hosted mode? If so, you might want to keep an eye on the work directory (or the equivalent directory if you're not running the application in a tomcat server). Check the webapp's folder for serialization policiy files (*.gwt.rpc).
It's possible they're not loaded correctly, the only workaround we have found so far, is to restart your server after each serialization fault.
The problem is due to the fact GWT will generate its serialization policy files at run time, assuming you're running in hosted mode. In compiled mode, GWT will generate all necessary files at compile time. AFAIK, tomcat's unable to load in the resource files at run time and hence will not include the serialization files each time they are needed for the first time.
When restarting the server, tomcat's able to pick up the previously generated file and hence you shouldn't receive the same error after restarting.
Can you verify this?
If you are running on JBoss, this might be due to the fact that the previously deployed application is not deleted when undeployed. To fix this, you must modify the following file in JBoss:
${JBOSS_HOME}/server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml
and set the following attribute to true: deleteWorkDirOnContextDestroy
When the previously deployed application is not cleaned up, GWT can be confused about which RPC file it needs to load and you end up with those SerializationException
I had the same problem and I found a solution from another person:
"There is a possibility that you have a class which implements Serializable and you have an attribute field within that class which is not Serializable hence you might be getting this exception."
Many thanks to that person :)
My advice is to make all fields (which are not primitive types) in your class to implement Serializable also! This solved my problem.
This problem occurs when a GWT 2.5 application is compiled using JDK 1.7. GWT 2.5 supports JDK 1.6 and using this version of JDK will fix this issue.
So the RPC files are unique because they are loaded by servlets as well as being used in GWT. See http://code.google.com/webtoolkit/release-notes.html#Release_Notes_1_4_59 where it says "This file must be deployed to your web server as a public resource, accessible from a RemoteServiceServlet via ServletContext.getResource()"
Is it possible the new application is being reloaded dynamically and getResource is failing in some way? Does restarting the application fix things?
I've had the same error and fix this by clean the browse cache and navigation history.
I was getting a SerializationException also but I was also seeing this error showing up right before the serialization exception:
[uptimereports/2.340102563369350884].:
Example : error : cannot find template
registration-confirmation.vm
It turned out to be a problem finding my velocity template. Once I fixed that problem the SerializationException stopped showing up, so if you follow Kerem's advice and still have problems, look for other exceptions in your log.
The best way to know the exact issue is to compile your code using -logLevel DEBUG or TRACE and check inside Validating Units. I am sure you would be able to find out the exact issue with line numbers as well.
First make sure you have a 'clean' serializable class ie empty constructor, no inner classes implementing serializable and use GWT Serializable class instead of Java Serializable class.
Then simply open your site in an Incognito tab (Chrome) solves the problem. Local browser cache causes loading old rpc files.
I had this problem when running SuperDevelopmentMode with a setup where codeserver was not on the same host as tomcat server. I had codeserver on my host, while tomcat running in the docker container. It turns out in such setup app server cannot get the right serialization policy files, so quite similar as described by thomaux in one of answers above, just different setup.
I had to add -Dgwt.codeserver.port=9876 to start parameters of tomcat as described here. This causes GWT SuperDevMode to switch to mode of getting serialization policy files through network. Still the url is hardcoded in com.google.gwt.user.server.rpc.RemoteServiceServlet#getCodeServerPolicyUrl as
"http://localhost:" + codeServerPort
so you have to make sure that your tomcat can reach codeserver on that port, by tunneling or routing the traffic if necessary. Alternative is to hack GWT code to allow changing that localhost to something else too, but this doesn't look clean and secure.

JBoss: What does the warning EJBTHREE-1246 from the InterceptorRegistry mean?

I am currently developing an EJB 3.0 based application on the JBoss AS 5.0.0.GA and just recently the following warning showed up in the server log:
09:50:19,735 WARN [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
09:50:19,735 WARN [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
09:50:19,735 WARN [InterceptorRegistry] applicable interceptors is non-existent for ...
...
The warnings are generated as soon as an EJB (a stateless session bean) is injected into a backing bean of my JSF web-application. The beans do work without problems though, but I still would like to know where that warning comes from and what I can do to avoid it.
I have already searched a bit around, but haven't found a good answer (some say, bean developers do not have to worry, but its a warning, so I'd like to have a better solution):
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=147292
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180366
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140136
JBoss JIRA Issue about the warning (Not that helpful in my opinion)
So has anyone an explanation what causes the warning (in terms of a bean developer, not application server developer) and what to do to avoid it?
Update: I've just upgraded JBoss to 5.0.1.GA (Download, Release-Notes) but unfortunatly the warning still appears.
As far as I understand all the available sources on this warning, it is nothing a user of JBoss 5 can do anything about and is essentially just a reminder for the developers of JBoss that they use their own classes wrong.
Following the advice from the developers, I am now ignoring it by changing my logging configuration in conf/jboss-log4j.xml. I've just added:
<category name="org.jboss.ejb3.interceptors">
<priority value="ERROR" />
</category>
Even the JBoss EJB3 tutorial/documentation says you can safely ignore these warnings. Well if everyone can ignore these don't log them! It's frustrating to see this issue isn't being fixed.
I had the same problem, modify the ejb3-interceptors-aop.xml, and now works ok.
I've tried this modification in ejb3-interceptors-aop.xml
I've comment these lines :
<aspect name="InterceptorsFactory" factory="org.jboss.ejb3.interceptors.aop.InterceptorsFactory" scope="PER_INSTANCE"/>
<advice name="invoke" aspect="InterceptorsFactory"/>
and it Works
The warnings no longer appear in JBoss 5.1.0, but adding the category as Simon posted eliminates the logging of the warnings in 5.0.x
Just follow the steps
Stop JBoss and right click on the server instance and select clean
right click on the project and select run -> run configurations
select classpath -> add jars
Add Jars from JBoss ASHOME/client - jbossall-client.jar,JBoss ASHome/common/lib - all jars.
Apply and run.