Lift Mailer error: gnu.mail.handler.TextPlain cannot be cast to javax.activation.DataContentHandler - email

Using the following code:
sendMail(From(Props.get("email")), Subject("Test Email"), To("email#address"),
PlainMailBodyType("test email body"));
And in Boot.scala:
System.setProperty("mail.smtp.starttls.enable","false");
System.setProperty("mail.smtp.host", host)
System.setProperty("mail.smtp.auth", "true")
Mailer.authenticator = Full(new Authenticator {
override def getPasswordAuthentication = new PasswordAuthentication(user, password)
})
I get the following error:
2011-05-23 18:49:02,868 ERROR [pool-3-thread-4] n.l.u.MailerImpl [Logging.scala:239] Couldn't send mail
java.lang.ClassCastException: gnu.mail.handler.TextPlain cannot be cast to javax.activation.DataContentHandler
at javax.activation.MailcapCommandMap.getDataContentHandler(MailcapCommandMap.java:596) ~[activation-1.1.jar:1.1]
at javax.activation.MailcapCommandMap.createDataContentHandler(MailcapCommandMap.java:550) ~[activation-1.1.jar:1.1]
at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:611) ~[activation-1.1.jar:1.1]
at javax.activation.DataHandler.writeTo(DataHandler.java:315) ~[activation-1.1.jar:1.1]
at javax.mail.internet.MimeUtility.getEncoding(MimeUtility.java:261) ~[mail-1.4.1.jar:1.4.1]
at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1321) ~[mail-1.4.1.jar:1.4.1]
at javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2074) ~[mail-1.4.1.jar:1.4.1]
at javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2042) ~[mail-1.4.1.jar:1.4.1]
at javax.mail.Transport.send(Transport.java:117) ~[mail-1.4.1.jar:1.4.1]
at net.liftweb.util.MailerImpl$$anon$1$$anonfun$$init$$1.apply(Mailer.scala:176) ~[lift-util_2.8.1-2.3.jar:2.3]
This code works on one box and not on another. Any ideas?

Alternative solution if you want to use the Jetty package that comes with your Linux distro.
The problem only seems to occur with the GNU implementation of JavaMail. If you can use the Sun implementation instead, it works fine, or at least it did for me.
Adding Sun's javamail:
I took activation-1.1.jar and mail-1.4.1.jar that sbt had placed under the lib_managed/ folder of my Lift project, and placed them under /usr/share/jetty/lib/ on the server.
Removing GNU javamail:
Unfortunately, commenting out the gnumail.jar from /etc/jetty/start.config wasn't enough to get rid of gnumail. Jetty somehow still found the gnumail.jar and now mails just crashed in a different way. To get things to work smoothly I had to uninstall libgnumail-java and therefore also libjetty-extra which depends on it (I'm using Ubuntu). If you need libjetty-extra you'll need a different way to ensure Jetty won't see gnumail.jar.

Apparently it is an issue in versions of Jetty < 6.1.25.
http://olex.openlogic.com/packages/jetty/6.1.25 Something wrong with activation dependency.
Switching to the latest version of jetty (7.3) fixed it!

Related

matchOnUriPrefix=true does not seem to be working

I am using:
wildlfy 10.1.0 final
Camel 2.19.1
Camel Java DSL RouteBuilder
In my RouteBuilder.configure I have the following from:
from("undertow:http://localhost:" + portNum + "/DataplatformESB/v3?matchOnUriPrefix=true&httpMethodRestrict=post,get,put,options,patch,delete")
When I test to "localhost:8080/DataplatformESB/v3" with GET, PUT, or PATCH, they all work fine. But when I test to "localhost:8080/DataplatformESB/v3/anythingelse" I'll get a 404 (page not found) in return. In the Wildfly log it stats: "Matched prefix path /DataplatformESB for path /DataplatformESB/v3/anythingelse". So for me it looks like the "matchOnUriPrefix=true" is not working.
I have already tested with from("restlet:http://localhost:" + portNum + "/DataplatformESB/v3?matchOnUriPrefix=true&httpMethodRestrict=post,get,put,options,patch,delete"), but that does not work as well.
I have also tried it with the restConfiguration and .componentProperty("matchOnUriPrefix", "true") but also no luck.
Does anyone has an idea why the matchOnUriPrefix=true does not seem to work for me?
I have done some further research and found out the folliwing:
I got the undertow test project from https://github.com/apache/camel/tree/master/components/camel-undertow/src/test/java/org/apache/camel/component/undertow/UndertowPrefixMatchingTest.java and run/tested in it in my NetBeans.
The code is:
from("undertow:http://localhost:{{port}}/bar?matchOnUriPrefix=true")
.transform(bodyAs(String.class).append(" Matching prefix"))
.to("mock:bar");
This runs fine and returns OK when the URL starts with the prefix: "bar". So "bar/foo" returns OK as well.
But when I paste this code into the Wildfly Camel Rest Swagger example (there is no Wildfly Camel Rest example) from the website https://github.com/wildfly-extras/wildfly-camel-examples/tree/master/camel-rest-swagger, then I only get an OK when testing with "bar" as path.
Using "bar/foo" result in a 404 return code.
Im still using Wildfly 10.1 final and Camel 2.19.1.
So what is causing the difference in output? What do I have to change in Wildfly to get it working?
Is the option matchOnUriPrefix default disabled/ignored on Wildfly?
When using the Wildfly-Camel 2.18.3 on the Wildlfly installation it seems to work.
It looks like the default value for matchOnUriPrefix is changed or the handling of this property.
In that case it seems to me that this introduced the bug as described above.

Failed to start Neo4j service

I am using neo4j enterprise 3.0.3 version for windows. Following the operations manual 3.0, I have installed the neo4j service with bin\neo4j install-service. But I can't start it with bin\neo4j start. It said
Invoke-Neo4j : Failed to start service 'Neo4j Graph Database - neo4j (neo4j)'.
And I can't start the neo4j service in windows serice either. Maybe anyone have encountered this case before?
I had the same problem: I am using neo4j community 3.1.2 for windows and installed the service with the neo4j.bat file without any problems.Then i wanted to start the service with neo4j.bat and got the same error as you
I found a solution that worked for me. My neo4j files were in a folder, where the path to the folder contained spaces (C:\Program Files\Neo4j) Then i moved the folder one level up (C:\Neo4j).
After that i could start the service without problems.
Maybe this solution helps.
I am running neo4j on windows and in my case the crux of the issue was that there was an incompatibility between the installed versions of Java (32-bit) v/s OS version. The biggest clue that led me to this is the following set of lines in neo4j-service.2018-08-03 log file
[2018-08-03 14:55:42] [info] [ 1432] Starting service...
[2018-08-03 14:55:42] [error] [ 1432] %1 is not a valid Win32 application.
[2018-08-03 14:55:42] [error] [ 1432] Failed creating java C:\JavaNew\bin\server\jvm.dll
[2018-08-03 14:55:42] [error] [ 1432] %1 is not a valid Win32 application.
[2018-08-03 14:55:42] [error] [ 1432] ServiceStart returned 1
There are a fair number of potential issues, and I have made an attempt to compile all the issues with this,
Windows services cannot deal with service names in folders that have spaces; especially if there is another folder with the same name as the one with spaces.
For example - C:\Program Files... will have issues if C:\Program\Something...
To work around this, I put Neo4j in root folder c:\Neo4j
Get-Java.ps1 (under ..\bin\Neo4j-Management folder)looks in the path variable for 'JAVA_HOME' (usually found in *nix environments). If it does not find it here, it keeps looking in registry, and finally throws up its hand!
To deal with this, I simply put in a path variable. For a good measure, I uninstalled Java and re-installed Java in the root folder under C:\JavaNew
In retrospect, this step is probably not on part of the problem, and hence can be ignored. But I am leaving it here for completeness sake.
Invoke-Neo4j.ps1 (also under ..\bin\Neo4j-Management folder) has code that determines if the OS is 32-bit (or 64-bit). Based on this it determines if it should run prunsrv-i386.exe (32-bit) or prunsrv-amd64.exe (64-bit).
This has to match the Java version installed.
Upon running java -XshowSettings:all, and inspecting the sun.arch.data.model value (32, in my case), I realized that my OS is 64 bit and the Java version is 32-bit.
To deal with this, I put in code (very klugey!). I am sure there are much better ways to get to the same outcome, but this is what I used.
switch ( (Get-WMIObject -Class Win32_Processor | Select-Object -First 1).Addresswidth ) {
32 { $PrunSrvName = 'prunsrv-i386.exe' } # 4 Bytes = 32bit
#64 { $PrunSrvName = 'prunsrv-amd64.exe' } # 8 Bytes = 64bit COMMENTED as a workaround!!!
64 { $PrunSrvName = 'prunsrv-i386.exe' } # 8 Bytes = 64bit
Now, uninstall the neo4j service, install it, and start the service.
Hope this works for you.
neo4j console
Posting for latest versions > 4.x
I had the same issue using neo4j start, Neo4j console is the right command I was looking for. It is a web-based graph that acts as an interactive tutorial.
i had the same problem , after the neo4j worked for few weeks it stoop working (without any change that i made)
i have set java_home uninstall and install and now it works
neo4j-enterprise-3.3.4
I was also having weired issue as there was no error but neo4J service did not start.
[xx#ss1 bin]$ ./neo4j console
[xx#ss1 bin]$ .
The problem was with the permission on Java directory and I tried
chmod -R 777 jdk_directory
and problem got solved.
#neo4j #neo4jnotstarting

How to resolve undef error in ejabberd hook

I have added a customized module named mod_confirm_delivery in ejabberd which has compiled and added successfully but when i am sending a message an error is coming in my ejabberd error log file, That is:
2016-03-15 17:03:38.306 [error] <0.2653.0>#ejabberd_hooks:run_fold1:368 {undef,[{mod_confirm_delivery,send_packet,[{xmlel,<<"iq">>,[{<<"xml:lang">>,<<"en">>},{<<"type">>,<<"get">>},{<<"id">>,<<"aacfa">>}],[{xmlcdata,<<"\n">>},{xmlel,<<"query">>,[{<<"xmlns">>,<<"jabber:iq:roster">>}],[]},{xmlcdata,<<"\n">>}]},{state,{socket_state,gen_tcp,#Port<0.58993>,<0.2652.0>},ejabberd_socket,#Ref<0.0.1.25301>,false,<<"12664578908237388886">>,undefined,c2s,c2s_shaper,false,false,false,false,[verify_none,compression_none],true,{jid,<<"test1">>,<<"localhost">>,<<"D-5">>,<<"test1">>,<<"localhost">>,<<"D-5">>},<<"test1">>,<<"localhost">>,<<"D-5">>,{{1458,41617,630679},<0.2653.0>},{2,{{<<"test2">>,<<"localhost">>,<<>>},{{<<"test1">>,<<"localhost">>,<<>>},nil,nil},nil}},{2,{{<<"test2">>,<<"localhost">>,<<>>},{{<<"test1">>,<<"localhost">>,<<>>},nil,nil},nil}},{0,nil},undefined,undefined,{userlist,none,[],false},c2s,ejabberd_auth_internal,{{127,0,0,1},41928},[],active,[],inactive,undefined,undefined,1000,undefined,300,300,false,0,0,true,<<"en">>},{jid,<<"test1">>,<<"localhost">>,<<"D-5">>,<<"test1">>,<<"localhost">>,<<"D-5">>},{jid,<<"test1">>,<<"localhost">>,<<>>,<<"test1">>,<<"localhost">>,<<>>}],[]},{ejabberd_hooks,safe_apply,3,[{file,"src/ejabberd_hooks.erl"},{line,382}]},{ejabberd_hooks,run_fold1,4,[{file,"src/ejabberd_hooks.erl"},{line,365}]},{ejabberd_c2s,session_established2,2,[{file,"src/ejabberd_c2s.erl"},{line,1268}]},{p1_fsm,handle_msg,10,[{file,"src/p1_fsm.erl"},{line,582}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}]}
I have ejabberd 16.02.26 and my module code is:
mod_confirm_delivery.erl
This module is working fine with ejabberd 2.1.13 but i want to upgraded my ejabberd. I can't understand what is the problem and how can I resolve this error.
undef error means the function or module is not found. The most likely error is that the mod_confirm_delivery.beam file is not in Erlang VM path.
You should try moving the compiled beam file with other ejabberd beam files or try setting the path used to launch Erlang to the directory where your mod_confirm_delivery.beam file is located. This is the -pa option of the Erlang VM.
If your code if in right place, other option is that the function is undefined. The hook tries to call mod_confirm_delivery:send_packet/4. Your code is wrong as it indeed does not defined send_packet/4 but only send_packet/3. You need to update your code to match new signature for user_send_packet hook:
user_send_packet(Packet, C2SState, From, To) -> Packet
In case of doubt, you can refer to official hook list in ejabberd documentation: https://docs.ejabberd.im/developer/hooks/

NoClassDefFoundError in openid4java

I have downloaded openid4java-0.9.6.662 and implemented a class using it. When I execute:
List discoveries = manager.discover("https://www.google.com/accounts/o8/id");
I get a
java.lang.NoClassDefFoundError: org/apache/http/protocol/ImmutableHttpProcessor
at org.apache.http.impl.client.AbstractHttpClient.getProtocolProcessor(AbstractHttpClient.java:656)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:804)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:732)
at org.openid4java.util.HttpCache.head(HttpCache.java:335)
at org.openid4java.discovery.yadis.YadisResolver.retrieveXrdsLocation(YadisResolver.java:400)
at org.openid4java.discovery.yadis.YadisResolver.discover(YadisResolver.java:248)
at org.openid4java.discovery.yadis.YadisResolver.discover(YadisResolver.java:232)
at org.openid4java.discovery.yadis.YadisResolver.discover(YadisResolver.java:166)
at org.openid4java.discovery.Discovery.discover(Discovery.java:147)
at org.openid4java.discovery.Discovery.discover(Discovery.java:129)
at org.openid4java.consumer.ConsumerManager.discover(ConsumerManager.java:542)
at com.sugra.openid.helper.OpenIDConsumer.authRequest(OpenIDConsumer.java:90)
the funny thing is this class cannot be found in any of the jars, thought it is supposed to be found in httpcore-4.0.1.jar, as it contains classes of the same package. This class is available in httpcore-4.2.1.jar. But I've tried it and got
org.openid4java.discovery.yadis.YadisException: 0x704: I/O transport error: hostname in certificate didn't match: <www.google.com/173.194.35.144> != <www.google.com>
that is reported to be an error of portability and a previous version should be used
What is supposed to be the right approach to use this method?
I found it. There was a conflict with another jar (httpclient.jar) I had in my app. I just had to upgrade it

CoffeeScript compiler errors suppressed under Node 0.5.10-pre

When my script fails to parse for any reason, I get a stack trace from the compiler, with no insight at all into where in my script the problem lies:
mpurvis#citadel:~/coffee$ coffee -c Test.coffee
/usr/local/lib/node_modules/coffee-script/lib/command.js:15
return process.binding('stdio').writeError(line + '\n');
^
Error: No such module
at /usr/local/lib/node_modules/coffee-script/lib/command.js:15:20
at /usr/local/lib/node_modules/coffee-script/lib/command.js:167:7
at /usr/local/lib/node_modules/coffee-script/lib/command.js:115:26
at [object Object].<anonymous> (fs.js:108:5)
at [object Object].emit (events.js:64:17)
at afterRead (fs.js:1074:12)
at Object.wrapper [as oncomplete] (fs.js:246:17)
For now, it's just a toy script to try the system out, so I can usually just experiment until it works again, but that would be impossible in a file of any size. Is there some trick I'm not seeing to get the line where the error occurred?
Thanks!
the latest version from node isn't full compatible with cs..the node_stdio module ws removed...a simple way for fix it is open /usr/local/lib/node_modules/coffee-script/lib/command.js and change the line 15
process.binding('stdio').writeError(line + '\n')
for
process.stderr.write(line + '\n')
always you can get more help from github issues section
https://github.com/jashkenas/coffee-script/commit/c77f7737a5d94a05a999109810ea7634f540e1e2
good luck and happy coding
This doesn't look like a syntax issue. The error is coming from command.js, which is what defines the coffee command-line utility. If it were a compiler error, it would be from coffee-script.js.
So why is the process.binding('stdio') bit in command.js failing? There are two possibilities I can think of:
You're using a weird shell (or a weirdly configured one) that doesn't play nice with Node's version of stdio. This seems unlikely, but it's possible...
You're using a version of Node.js that CoffeeScript isn't currently compatible with. What do you get when you do node -v? Your safest bet is the latest 0.4.x, since those are stable releases (0.5.x is experimental).
This question is from awhile back.
Node 0.6.x throws a similar error with CoffeeScript 1.1.x; upgrading to 1.3.x does the trick.
Likely 2 different coffee-scripts on your system. check which coffee, than track down the older one and ice it. I had one from an install last summer (v1.1), it's all cleared up now.