[JBoss JIRA] Created: (JBMAIL-244) Fetching mail with MalformedHeader from POP3 server
by Ryan Maloney (JIRA)
Fetching mail with MalformedHeader from POP3 server
----------------------------------------------------
Key: JBMAIL-244
URL: http://jira.jboss.com/jira/browse/JBMAIL-244
Project: JBoss Mail
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss application server 4.0.4-CR2 running on Windows XP Profesional SP2
Reporter: Ryan Maloney
Assigned To: Andrew Oliver
Enabled fetchmail and added a pop3 account. Manually invoked the pop() method via the mx-console and received the following:
[Top part of the stack trace]
INFO [org.jboss.mail.fetchmail.Popper] Found 104 messages (0) new ones
INFO [org.jboss.mail.fetchmail.Popper] Trying to get message 0
INFO [org.jboss.mail.fetchmail.Popper] Message 0 Subject: EMAIL SUBJECT REMOVED
ERROR [org.jboss.mail.fetchmail.Popper]
org.jboss.mail.message.MalformedHeaderException: Malformed Header:
This is a multi-part message in MIME format.
[end snippet]
Mail retrieval ended immediately thereafter.
I have sent the offending header to acoliver(a)jboss.com
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Created: (EJBTHREE-798) Implement temporary EJBTHREE-795 workaround in EJB3 codebase
by Brian Stansberry (JIRA)
Implement temporary EJBTHREE-795 workaround in EJB3 codebase
------------------------------------------------------------
Key: EJBTHREE-798
URL: http://jira.jboss.com/jira/browse/EJBTHREE-798
Project: EJB 3.0
Issue Type: Sub-task
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: EJB 3.0 RC10 - FD
Likely long term fix is to update the org.hibernate.cache.TreeCache class. But, as a temporary workaround for the Stacks 1.1 release, I have implemented a new version of org.hibernate.cache.TreeCache in the EJB3 namespace, and updated TreeCacheProviderHook to use it.
Updated version (o.j.ejb3.entity.JBCCache):
Makes use of JBC's marshalling API to register a deployment's classloader with JBC and activate the relevant region when it is constructed. When the destroy() method is called, the region is inactivated and the classloader unregistered.
Exception to this are the special regions named "org.hibernate.cache.StandardQueryCache" and "org.hibernate.cache.UpdateTimestampsCache", which
1) should not have a particular classloader registered with them, as they may be used by multiple deployments.
2) should not be inactivated when a particular JBCCache instance is destroyed, as other deployments may be using them.
UpdateTimestampsCache does not actually replicate any custom classes, so the special handling for it in JBCCache is just to make sure JBCCache doesn't break anything.
StandardQueryCache does have the potential to replicate classes, but since no classloader can be registered with it's cache region, such a replication attempt will fail. As a workaround, if the region's name is "org.hibernate.cache.StandardQueryCache", JBCCache will not replicate any queries placed in the region, but rather will only cache them locally.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months