No ACL deny logs for Traffic not matched by Static Object NATs and ACL. Need Help.

Question

I start noticing that I do not see any denied traffic coming in on my ACL.  To better explain, lets say I have this config.
### Sample Config ###
object network webserver
host 192.168.1.50
nat (dmz, outside) static X.X.X.X service tcp www www
access-list inbound extended permit ip any4 object webserver eq www
If I generate a traffic from the outside let's say a traffic that is trying to access X.X.X.X via TCP Port 8080 which obviously does not have any NAT entry to it going to my DMZ, I don't see the ACL denies it anymore but instead comes back with a Drop Reason: (nat-no-xlate-to-pat-pool) . On the packet trace I got this. (Below) it seems that does not even hit the ACL as there is no xlate found for it, at least to what the drop reason says.
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         Outside
Result:
input-interface: Outside
input-status: up
input-line-status: up
output-interface: Outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate
Before, using a regular Static PAT on ASA Versions 8.2(5) below, I could get the deny logs (ASA-4-106023). Generally, I use these logs, and are quite important for us specially during auditing.
My question is how can I generate logs for these type of dropped traffic on the ASA 9.1 Version? 
Any comments/suggestions are gladly appreciated :)
Regards,
John

Answer 1

I believe, but am not 100% sure, that the reason you are not seeing the ACL drop but a no NAT matched is because of the changes from 8.2 to 8.3 in the order of how things are done.  In 8.3 and later you need to secify the real IP address when allowing packets in, and this is because NAT happens before the ACL is matched.  So since there is no match on the NAT the packet is dropped then and there, never reaching the stage where ACLs are checked.
As to seeing drops in the ACL log...You might want to try adding an ACL that matches the NATed IP...but I don't think you will have much success with that either.  My guess is that there is no way around this...at least no way I know of.
Please remember to select a correct answer and rate helpful posts