CF 2023 Update 15 cfmail error

[bha3986515]

CFMail will throw error after update 15 applied. Java version: 17.0.15+9-LTS-24

"Error","ajp-nio-127.0.0.1-8022-exec-3","07/11/25","13:24:45","","Bad type on operand stack
Exception Details:
Location:
coldfusion/mail/mod/MailImpl.signMail(Ljavax/mail/internet/MimeMessage;Ljavax/mail/Session;)Ljavax/mail/internet/MimeMessage; @238: invokevirtual
Reason:
Type 'org/bouncycastle/asn1/smime/SMIMEEncryptionKeyPreferenceAttribute' (current frame, stack[1]) is not assignable to 'org/bouncycastle/asn1/ASN1Encodable'
Current Frame:
bci: @238
flags: { }
locals: { 'coldfusion/mail/mod/MailImpl', 'javax/mail/internet/MimeMessage', 'javax/mail/Session', 'java/security/KeyStore', '[Ljava/security/cert/Certificate;', 'java/security/PrivateKey', 'org/bouncycastle/asn1/ASN1EncodableVector', 'java/security/cert/X509Certificate', 'java/lang/String', 'org/bouncycastle/asn1/cms/IssuerAndSerialNumber' }
stack: { 'org/bouncycastle/asn1/ASN1EncodableVector', 'org/bouncycastle/asn1/smime/SMIMEEncryptionKeyPreferenceAttribute' }
Bytecode:
0000000: 2ab4 0028 c600 212a b400 28b6 009e b600
0000010: 5e99 0014 bb00 e159 2ab4 0028 b700 e2b6
... The specific sequence of files included or processed is:

[BKBK · Accepted solution]

Key message:

Reason:
Type 'org/bouncycastle/asn1/smime/SMIMEEncryptionKeyPreferenceAttribute' (current frame, stack[1]) is not assignable to 'org/bouncycastle/asn1/ASN1Encodable'

The message suggests that, after the installation of Update 15, ColdFusion mistakenly uses an incompatible version of the Bouncy Castle library.

A solution that has often worked for such update-installation issues is to delete the Felix cache. The procedure is as follows:

1. stop ColdFusion;
2. open the directory \cfusion\bin\felix-cache and delete everything from it, then
3. restart ColdFusion.

[WolfShade]

Will Adobe ever get this fixed?  Seems like the new stock response is to stop CF, delete Felix cache, restart.

WolfShade

[Ravi Shankar266617537wjh]

Hello WolfShade,

Please send an email to cfinstal@adobe.com. We have a fix available

Thanks & Regards

Ravi

[Charlie Arehart]

Hey, Ravi. Thanks. Can you clarify if that is a fix for cfmail specifically? Or might it be a fix for the frequent need to delete the felix-cache not only after the update does it (which started with updates earlier this year), but even after we may do it ourselves after that (as some have reported having to do)? 

[WolfShade]

Hi, Ravi.

Thank you for the offer.  I think you once sent me an email asking the same thing.  The reply is no different.

I am a Federal Contractor working for the DoD, and do not have the authority to install anything on any of our servers.  And, quite frankly, even if this were my own environment I'm not going to just arbitrarily trust an update that isn't released through proper channels and made available to everyone.

I sincerely hope Adobe can find whatever is causing your new stock response of "clear Felix cache" whenever something goes awry.

WolfShade

[TheRealMC]

Hi Wolfshade, Ravi, Charlie,

I've submitted a bug request regarding the repeated need to clear the felix cache. In essence, I'm suggesting that the cache be cleared automatically whenever CF starts up. Simplistic maybe, but perhaps that's all we need? 🙂

https://tracker.adobe.com/#/view/CF-4227715

Cheers,

Mike.

[BKBK]

Not simplistic at all, @TheRealMC . I think that those "felix-cache" issues reduce ColdFusion to a fragile application server. 

[WolfShade]

@TheRealMC , it's not just a matter of clearing the Felix cache.. there have been some solutions that include copying a .jar file from a server that hasn't yet had an update over to the affected server, then clearing cache and restarting CF Server services.  Apparently some updates have been randomly deleting .jar files.  So this is a serious issue.  And a chronic one.  CF 2021 is now on update 21, I believe, and this has been going on since update 15.

It's time Adobe got every dev involved in keeping CF up to date, and discovering what the issue is, and actually fix it.  The new stock response of "Stop, clear Felix, restart" _CANNOT_ be accepted for much longer.  This needs addressing, now.

But, much like my request to be able to actually EDIT a Solr Collection instead of blanking all the fields when the edit button is clicked, I have a feeling that's not going to happen any time, soon.

WolfShade

[Charlie Arehart]

Guys, I can share news that I heard from Adobe (earlier today, before Mike's new ticket) that Adobe is aware of the concern and says they plan to address it in the next update. No word on how that will happen, or when it will happen. 

For those interested to know more, read on.

I had raised this general concern (about the need to clear the felix-cache) as a tracker ticket last Dec. At that time, I was asking that it be cleared at least after an update: and they did that starting with the March updates. Some are not aware of that, so it's at least some good news.

But sadly (as this thread and others have shown), that wasn't enough as we often needed to clear it again sometimes even AFTER an update, which (like you all have said here) seemed illogical and certainly annoying (and caused a LOT of support issues here in the forums and elsewhere).

Anyway, I bring this up to say that in that other ticket, when this problem remained, I had complained in comments both last month and this month that they needed a better ultimate solution. And I had pressed them about the lack of any reply to that ticket. Then just today did report to me that they planned to address the problem in the next update. Again, there was no more info than that...but I first shared the news in that ticket, and I offer it now here.

I've added a vote to Mike's ticket. I did not bother to offer a link there to my ticket. Again, mine was proposing they clear it after an update. That was done and it was marked closed. Then I pressed them in comments about this ongoing issue. I don't suspect most will find that satisfying to read.

Hopefully Adobe will simply offer a more clear answer in Mike's ticket (or here) about what the planned update will achieve.  And it may well be what was covered by the hotfix which Ravi offered here last week. Sadly, he never replied to my question above asking whether it was just about cfmail or about this broader felix-cache problem.  (And no one from Adobe shared news of that hotfix on my ticket or to me when I pressed about the matter by email.)

Perhaps only time will tell.

[TheRealMC]

Didn't know about your ticket, Charlie. Thanks for the heads up, I'll follow any progress with interest!

Cheers,

Mike.

[Charlie Arehart]

Oh, no worries at all, Mike. I wouldn't have expected you to. 🙂 And I was focusing more on what they said regarding the issue. We shall see. 

[Charlie Arehart]

[snip] But, much like my request to be able to actually EDIT a Solr Collection instead of blanking all the fields when the edit button is clicked, I have a feeling that's not going to happen any time, soon.

By @WolfShade

Wolf, can you clarify what you mean there? I find that the only operations for (buttons offered to the left of) solr collections are reload, index, optimize, purge, and delete. When you refer to wanting to "edit" a collection, what page are you using---where you refer here to there being "the edit button"? And what would you mean to be editing? Sincere questions. 

Or might you be referring instead to a "PDF Service"? Those DO have an "edit" button--but I find it works just fine. 

[WolfShade]

Hi, Charlie.

I haven't had access to a CFAdmin since we lost our development environment, back when we were using CF Server 11, so the button for editing a Solr collection may have been removed.  Which would not surprise me, one bit.  I do not have access to staging or production CFAdmin, which is as it should be.  I'm a developer, not an admin.

Back in the days of CF11, when logging on to CFAdmin and going to Solr Collections, click a collection and there was an edit button for the collection.  I assumed that one could just click EDIT, see what is currently the value of each field, make edits and save.  But when I click the edit button, all fields were blank.. no values in any of the fields.

I went to Adobe Tracker and submitted an issue.  The link is:  https://tracker.adobe.com/#/view/CF-4159661

I believe there are comments that have been removed from that ticket.  There was at least one other person who argued with one of the Adobe developers about being lazy and not fixing what needs to be fixed.

In any case, it seems that Adobe has "fixed" this issue by removing the EDIT button from Collections, instead of actually making it possible to edit a collection.  There are developers who made collections who are no longer employed, here.  It's not always obvious what a collection was consuming, so an edit feature could be a boon.

WolfShade

[Charlie Arehart]

OK, I see now. Thanks for the clarifications (though this has gotten way off-topic for this thread!)

So first, let me clarify that even CF11 had no "edit" button. Instead, it (and even CF2025) do let you click on the NAME of the collection which goes to a page to "manage" the collection. That's not new, not different, and still fails to do what you want (which is more clear from your ticket. FWIW, it only got one other vote, even if you feel confident some comments were removed.)

But I do appreciate better now what you sought...you want to know how the collection was created originally, and I assume you mean you're thinking that whoever created the collection then edited it and used the "path" feature there, to name a folder in which docs of the type (in the type list above it) would be found and indexed. And fair enough that editing it later doesn't "show that was done".

But note that that's not the ONLY way documents get into such a collection: first, one can create a collection using the cfcollection tag/script statement and its action="create" (not using the Admin at all). Second, one can always add new documents using the "index collection" button in that UI (or the cfindex tag/script statement.  And besides naming documents in a folder, that cfindex can even populate the index with data from a database, and so on.)  So it simply wouldn't be possible for the CF Admin to reflect all those changes over time.

But again, I get it: if you did JUST that most simplistic use of creating a collection, and editing it one time to name a folder whose docuemnts should be indexed, you'd wish it would at least show what THAT was. (It would still need to have a way to warn you if OTHER documents were added another way...and I suspect that's part of what they needed to "investigate".)

But I will note, finally, that if you just wished to know "what are the documents in the index, and where did they come from", that CAN be obtained using a simple cfsearch. Or if you prefer not to write even that code, you can use instead the query feature of the solr admin panel (such as at port 8997 for CF2025, available on the machine running the CF addon service as http://localhost:8997/solr). There you can select the desired collection using the "core" UI element on the left, then choose its "query" feature. For a colleciton named test, this url would go right there: http://localhost:8997/solr/#/test/query?q=*:*&q.op=OR&indent=true&useParams=

But as for your hope to have the edit feature of the CF admin collections (choosing the name), no, it still doesn't show what you may have originally chosen the first/only time you edited it and named a directory holding documents to search. 

Hope that added context helps someone at least a bit.