If seems I have duplicate dll, but I have tried to elimate or then the other... they both are required - sitecore

Hi I am trying to load/install a software product called "YAF" YetAnotherForum"... it runs great as a standalone, but now I am trying to integrate it in my Sitecore CMS system so that I may utilize the single sign-on features and create an IFrame. in any case, I am making some progress but this is my current error that I cannot seem to get past, any help will be appreciated.
Compiler Error Message: CS0433: The type 'YAF.Forum' exists in both 'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\6b359048\ea17b5f1\App_Code.70udshq8.dll' and 'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\6b359048\ea17b5f1\assembly\dl3\698b7e4b\be26b750_b845ce01\YAF.DLL'
Line 18: <img src="~/images/YAFLogo.jpg" runat="server" alt="YetAnotherForum" id="imgBanner" /><br/>
Line 19: <form id="form1" runat="server" enctype="multipart/form-data">
Line 20: <YAF:Forum runat="server" ID="forum"></YAF:Forum>
Line 21: </form>
Line 22: </body>

I believe YAF uses the "Web Site Project" project type which uses dynamic compilation rather than the "Web Application" project type, which you would generally use with Sitecore and which are pre-compiled. See MSDN definition
The dynamic compilation folder is the path mentioned in the error. See this other answer about how it's used.
The GAC is something else, and isn't being cited in the error. I would expect that clearing the temporary ASP.net files folder and restarting the application should fix it. Here's a related answer about clearing this folder.

There's a number of Sitecore modules available on marketplace, which offer various types of integration with YAF:
YAF Integration
YAF Single sign-on
Sitecore YAF
I would recommend you review these options, choose the one which fits your requirements, and follow the guideline to set it up and configure.

Clear the global assembly cache, that might help.
Run the Gacuitl tool with the command gacutil /u YAF.Forum.dll
Also remove all files from the folder c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\. Stop your IIS before clearing so there won't be any locked files.
Then restart IIS and see if the issue is resolved.

Related

Error Publishing .net core 3.0 AWS Serverless Application - Ambiguous project name 'bootstrap'."

I created a new .Net Core 3.0 application as per the instructions in
https://aws.amazon.com/blogs/developer/net-core-3-0-on-lambda-with-aws-lambdas-custom-runtime/
However, as soon as I added a code library project dependency, the publish failed:
publish: C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Ambiguous project name 'bootstrap'
I eventually realised that the error is down to the line in aws-lambda-tools-defaults.json:
"msbuild-parameters": "--self-contained true /p:AssemblyName=bootstrap"
This switch renames every assembly to 'bootstrap', which is utterly useless. The workaround is to rename the assembly name to 'bootstrap' in the .csproj file and remove the rename switch.
Is there a way to specify that only the one specific assembly should be renamed?
As the author of the mentioned blog post I think I should have suggested to set bootstrap in the project file instead of the command line option. The problem with the command line way is like you are seeing when you have multiple projects the command line tries to set all of the project assembly names to bootstrap.
I think I will update the blog post to remove the /p:AssemblyName=bootstrap and in the csproj file add <AssemblyName>bootstrap</AssemblyName> like the AWSProjectType element. That would get around your issue.

Pentaho DI / Kettle / Spoon Configuration with External Jars

I am deveoloping a custom plugin for Pentaho DI / Kettle 4.4 and use custom Validation and XSLT jars as part of it.
Those jars are referenced in plugin.xml along with the plugin's jar itself and deployed in the same location as the plugin's jar.
When I try to load this plugin in Spoon GUI, I can see and run the plugin fine till I reach the reference to the external jars and after that I get ClassNotFOund Exception.
I have tried following so far but has not worked :
Add the expernal Jars to libext folder and expect those to be picked up automatically. - Failed. Jars not loaded.
Add -cp command line option to Spoon.bat and specify the Jar files - Did not work.
Turned on -verbose option and search everywhere in the output but the Jars are ignored.
Deployed the Jars next to the plugin's Jar file in the plugin's folder. - Jars are not recognized.
From Within the plugin, if I dynamically load (using Reflection and URL Class Loader) I am able to force the loading of the Jars and it works that way but I would like a simpler classpath fix.
Any class that I reference in the Jar through XSL externsion (XALAN-J Java Extension) is still not recognized / loaded and XSL terminates at the beginning of Extension call.
Searched Google and this site for something similar but did not find specific answers on why SPoon behaves so differently and avoids external code and content.
A similar issue is reported here though its too old and has not shown final conclusive fix. I tried all that it said. http://forums.pentaho.com/archive/index.php/t-77190.html
Requesting someone to help me identify whats missing. Thanks in advance,
Thanks to this seemingly obscure website and it fixed all pain.
http://www.arulraj.net/2014/09/how-to-access-external-java-libraries-with-in-pentaho.html
Basically, go to the launcher folder and edit the launcher.properties file to include any path, library etc. and it fixes all the issues I reported above. Wish Kettle documentatation had answers like this.

Why JSTL works when URI defined as /jstl/core_rt but not /jsp/jstl/core in embedded jetty?

I can't seem to get my JSTL library working in my embedded jetty project working.
My taglib line seems to be giving me grief, and it all changes when I use different URIs. Here is the line I would want to use:
<%#taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
I first tried using the normal URI http://java.sun.com/jsp/jstl/core but that throws the error:
org.apache.jasper.JasperException: /bad.jsp(1,61) PWC6188: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
However when I change the URI to http://java.sun.com/jstl/core_rt. It works!
Another thing I noticed, if I have the old JSTL 1.0 url (http://java.sun.com/jstl/core) I get the following error:
org.apache.jasper.JasperException: /bad-el.jsp(4,0) PWC6236: According to TLD or attribute directive in tag file, attribute value does not accept any expressions
Now another preplexing thing I have noticed, this all works in IntelliJ! Which leads me to believe that there is a classpath problem, but the libraries should be all the same when I embed them inside the war. I think I am missing something.
So, what my question boils down to, what library do I need, or what configuration do I need to have to make this work properly?
Here are the current questions I have tried to follow but did not resolve my issues:
cannot load JSTL taglib within embedded Jetty server
Embedded Jetty fails to load JSP taglibs when classpath specified in jar
Jetty 8 standalone doesn't detect jstl taglib jar
JSTL not parsed in a JSP page running on an embedded Jetty instance
and many others
I have a sample project that one could checkout and try out.
if you want the JSTL uri to work, you should know that jstl is two files.
jstl-1.2.jar
jstl-api-1.2.jar
so look for them in the internet or go to the maven repo and download the jars

Default documents in web.xml not being respected (developer/stand-alone server)

For some reason, when browsing to URL that ends in a folder (ex. //localhost:8500/website/directory/), index.cfm is not loading and instead a 404 error page is returned. I have confirmed that the ...\web-inf\web.xml file is being used by modifying filter-mappings to enable the display of .htm and .txt files. In fact, none of the files in the welcome-file-list section are being used even if they exist which leads me to believe that there is something wrong with this section of the web.xml file.
The web.xml files are as follows:
{install-root}\cfusion\runtime\conf\web.xml
{install-root}\cfusion\wwwroot\web-inf\web.xml
Both files contain the same XML listed below.
<web-app>
...
<welcome-file-list id="WelcomeFileList_1034013110672">
<welcome-file>index.cfm</welcome-file>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.txt</welcome-file>
</welcome-file-list>
...
</web-app>
I have just recently patched to Update 6, but I believe that the problem was always there from the initial install. Please note that this is the development stand-alone server.
Has anyone already solved this or have any ideas on how to proceed other than re-installing CF10 and using IIS?
Late to the party, IMO there are two possible reasons that i can think of for this issue
Either your have additional mapping like "/" in place which is taking over servletcontainer's builtin default servlet who is the one responsible for going to the right root path
your folder name is something which CF already have a mapping for e.g. /flashservices/gateway/, CFFormGateway, cfform-internal, WSRPProducer, JSDebugServlet, flex2gateway
I think sharing your web.xml could have helped pin point the issue here.
I had this issue recently and it was a case-sensitivity issue in Tomcat (despite this being a ColdFusion 10 install on Windows).
My default index.cfm would load when I navigated to http://127.0.0.1 but as soon as I went to http://127.0.0.1/mysite, I got a 404. The folder was named mySite in Windows. As soon as I changed my URL to http://127.0.0.1/mySite it began working.

Gradle Jetty plugin locking files

Is there a way to fix the file locking issue caused by jetty entirely from gradle?
Some clarification:
When using the Gradle Jetty plugin by running gradle jettyRun, jetty causes the static resource files (html, css, js, etc.) to be locked when using Windows.
You can see a description of the problem in Files locked on Windows.
The same article also describes how you can fix that. Basically you have to either:
Disable the use of file mapped buffer
Not use NIO at all.
Both things require to add some jetty specific configuration files to the project, which I do not want to do - the jetty plugin is used only for convenience, and maintaining configuration for it does not feel right.
I do not need NIO for testing on the local machine, so any solution works.
Edit:
For now, I picked the option at which you set useFileMappedBuffer to false. This is how to do it:
Specify a path to your webdefault.xml like
[jettyRun, jettyRunWar,jettyStop]*.with {
//other configs
webDefaultXml = file("${project.webAppDir}/WEB-INF/jetty-webdefault.xml")
}
Get file from the latest 6.1.x distribution of jetty. The plugin seems to support only jetty 6. You can localte it at jetty-6.1.26\etc\webdefault.xml. Obviously, you have to place it at the path specified at the previous step.
Change the default servlet init parameter useFileMappedBuffer to false
I will research the option of using embeded jetty insted of the plugin.
I found a plugin that seem to be a better alternative:
https://github.com/akhikhl/gretty
Positives
Does not lock your files and support hot deployment (even something Gretty call "fast reload")
Gretty 1.2.0 uses Jetty 9.2.9.v20150224. Jetty plugin provided by Gradle 2.2.1 uses Jetty 6.1.25.
same task is used jettyRun (or more simply run).
"Press any key to stop the server". Jetty plugin required CTRL+C then Y.
From what I can tell, the documentation seem to be awesome (Gradle's not so much)
Negatives
A bit more bloated code to setup the buildscript's classpath dependency or apply plugin directly from URL (see doc)
Gretty crash unless you explicitly apply plugin: 'war' (Jetty plugin extends the War plugin)
Kiril answered his own question, many thanks. You should follow Kiril's instructions and this will help you find the appropriate webdefault.xml.
To find out what version of Jetty is started by Gradle, execute
gradle jettyRun -i
And you'll see something like this:
...
Tmp directory = determined at runtime
Web defaults = org/mortbay/jetty/webapp/webdefault.xml
Web overrides = none
Webapp directory = C:\dev\my-project\src\main\webapp
Starting jetty 6.1.25 ...
jetty-6.1.25
...
It took me a while to find a copy of Jetty 6.1.25 as it is no longer listed on the Jetty download page (not even in the archive section!).
You can then grab the appropriate copy of webdefault.xml from here, adjusting the version number as appropriate for your needs:
http://grepcode.com/file/repo1.maven.org/maven2/org.mortbay.jetty/jetty/6.1.25/org/mortbay/jetty/webapp/webdefault.xml