Hi following error I have got please let me know solution
java.lang.ClassCastException: org.apache.catalina.util.DefaultAnnotationProcessor cannot be cast to org.apache.AnnotationProcessor –
Im using tomcat 6.0
This is a known issue. This is the reason:
This was due to efforts from MYFACES-1246, proposal of annotation
processing here in list (adding method), but this of course breaks
compatibility of the same named interfaces.
If you have older code using org.apache.AnnotationProcessor you can make
it work on Tomcat.
Solution is:
Add <Loader delegate="true"/> into context.xml file (to Context element) in tomcat/conf directory.
This makes classloading in Tomcat sticking to J2EE spec.
(I couldn't make it work with suggested approach for only 1 webapp)
This is the reference: http://mail-archives.apache.org/mod_mbox/myfaces-dev/200703.mbox/%3C45F6D22B.1020803#ataco.cz%3E
Related
I have just started a new site where I am using 2sxc version 11.11.4 (started with 11.7.3 and upgraded to see if that would fix it). I have the data and views set up just like I have done on another site using version 10.25.2. On the newer version though, I'm unable to use the remove button/action. I did some searching and found a few references to adding lines to the web config file (https://github.com/2sic/2sxc/issues/1654, https://github.com/2sic/2sxc/issues/2205). I tried this and it worked great.
So, my question: will a fix be implemented for this or will we have to add these lines of code to the web config file on any site we use 2sxc on?
Also, could these lines of code affect any other DNN features, other modules, etc.?
I think you are talking about my solution here
https://github.com/2sic/2sxc/issues/2205#issuecomment-705647892
This is specific to a server where the WebDAV features have been added/enabled in Windows. I do not think its an issue that can or will be fixed in 2sxc.
I do know that it is safe to add those two items in web.config. All its doing is telling ASP.NET to NOT make WebDAV available in this application's (DNN's) context. I am not aware of any DNN feature or modules that need or use WebDAV. Its just something handed down from the server because its installed and its causing a weird change in behavior that makes the DELETE (and other) command types get ignored (IMHO, presumably because they are handled before they get to DNN).
I'm running a Camel application on Liberty Profile server. I'm taking a message from a queue, unmarshalling, mapping then marshalling. This was working fine but now I'm getting an error that JAXBDataBinding method getContextualNamespaceMap is not found.
I think this is because there is an older version of the jar in the server libs but I don't know why it started using it.
IBM Jar: com.ibm.ws.org.apache.cxf-rt-databinding-jaxb.2.6.2_1.0.12
The issue is resolved if I switch to parent last class loading but its a very hacky way to fix it and is not a great option. Any other ideas? I'm thinking some feature or other dependency in my build may have pulled this jar in.
So it does look like getContextualNamespaceMap is only available in newer versions of the org.apache.cxf-rt-databinding-jaxb JAR than what is available in Liberty.
It might be that parentLast is the best option then. (You already know how to do this but it's documented (here). If it leads to some other issues then do follow-up with another question.
I suppose it's conceivable you might be able to look at whatever is packaged within your application and try removing a set of things and picking them up from the Liberty runtime, to avoid running in parentLast mode. E.g. if you are only referencing getContextualNamespaceMap because you have other code in your app but there is some alternative path you could have gone down entirely in the Liberty-provided modules, then in theory you could be OK.
I'm not familiar enough with the code paths in the modules in the CXF or Camel "stack" to guess whether that's a real-world likelihood though.
The javaee7 feature contained a jaxsw version that clashed with the server version. Removing the javaee7 feature has resolved this issue. Remains to be seen whether or not I will to add it back in.
I am having problems with the Bluemix Monitoring and Analytics service.
I have 2 applications with bindings to a single Monitoring and Analytics service. Every ~1 minute I get the following log line in both apps:
ERR [Resource Monitoring][ERROR]: JsonSender request error: Error: unsupported certificate purpose
When I remove the bindings, the log message does not appear. I also greped my code for anything related to "JsonSender" or "Resource Monitoring" and did not find anything.
I am doing some major refactoring work on our server, which might have broken things. However, our code does not use the Monitoring service directly (we don't have a package that connects to the monitoring server or something like that) - so I will be very surprised if the problem is due to the refactoring changes. I did not check the logs before doing the changes.
Any ideas will help.
Bluemix have 3 production environments: ng, eu-gb, au-syd, and I tested with ng, and eu-gb, both using 2 applications with same M&A service, and tested with multiple instances. They are all work fine.
Meanwhile, I received a similar problem that claim they are using Node.js 4.2.6.
So there are some more information we need to know to identify the problem:
1. Which version of Node.js are you using (Bluemix Default or any other one)
2. Which production environment are you using? (ng, eu-gb, au-syd)
3. Is there any environment variables are you using in your application?
(either the creating in code one, or the one using USER-DEFINED Variables)
4. One more thing, could you please try to delete the M&A service, and create it again, in case we are trapped in a previous fault of M&A.
cf ds <your M&A service name>
cf cs MonitoringAndAnalytics <plan> <your M&A service name>
NodeJS versions 4.4.* all appear to work
NodeJS uses openssl and apparently did/does not like how one of the M&A server certificates were constructed.
Unfortunately NodeJS does not expose the openssl verify purpose API.
Please consider upgrading to 4.4 while we consider how to change the server's certificates in the least disruptive manner as there are other application types that do not have an issue with them (e.g. Liberty and Ruby)
setting node js version 4.2.4 in package.json worked for me, however this is an alternative by-passing solution. Actual fix is being handled by core team. Thanks.
I would like to use Autofac in my Sitecore project with Solr,
I have set next code to global.asax
<%#Application Language='C#' Inherits="Sitecore.ContentSearch.SolrProvider.AutoFacIntegration.AutoFacApplication" %>
but i see an error
Method not found: 'Void Autofac.RegistrationExtensions.RegisterModule(Autofac.ContainerBuilder, Autofac.Core.IModule)'.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.MissingMethodException: Method not found: 'Void Autofac.RegistrationExtensions.RegisterModule(Autofac.ContainerBuilder, Autofac.Core.IModule)'
I have checked AutoFac version and it is correct 3.5.2 like in Sitecore.ContentSearch.SolrProvider.AutoFacIntegration
What should I do to set up it correct in term of Sitecore.
This issue happens because Sitecore's Solr support package relies on an old Autofac version (3.1.5 or earlier) where the method builder.RegisterModule() was still defined in Autofac.RegistrationExtensions. Newer Autofac versions have a similar method defined in the class Autofac.ModuleRegistrationExtensions.
Without Sitecore recompiling the Solr/Autofac integration dlls, unfortunately, there are only two ways around this:
Use another DI library;
Write your own Solr/Autofac integration.
This issue is still present in the Solr support package shipped with Sitecore 8.2.
I have registered this issue with Sitecore Support.
Edit: Sitecore replied that the support of Autofac 3.2 and later is on the wish list. To track the status of this request, you can use the reference number 94626.
Have you removed all the Lucene config files and added in all the solr config files in the App_Config/Include.
You will also need to drop in all the Solr Dlls as shown below.
I'm trying to import a daml file (.daml) in protege, but I get the following exception:
Exception in thread "AWT-EventQueue-0" java.lang.noClassDefFoundError: org/apache/xerces/utils/URI$MalformedURIException
at edu.standford.smi.protegex.storage.daml.DAMLJenaParser.jenaparse(DAMLJenaParser.java:49)...
Does any of you know how to get around this? Does any of you know any other powerful ontology app. dvelopment environment other than protege for developing daml+oil documents?
Please reply as soon as you can. Thanks in advance.
Its solved. I new I needed xerces but did not know exactly which version. As my version of protege (portege 1.9 2000) is an old one it seems that I needed an old version of xerces. I just did not know which one. Now, its working fine. I think the version of xerces is 1.4x
Thanks for your time.