Infinispan issue tracking has been migrated to GitHub issues: https://github.com/infinispan/infinispan/issues
If you still want this issue to be worked on, create a new issue on GitHub and link this issue.

"So at any time it might make sense to keep in memory some of the attributes of S, but not all of them."
Not really. In WF/EAP, the sessions to be passivated are primarily expected to be abandoned sessions, that is, session that I expect to eventually expire. Our primary use case for passivation is not as a means to handle more active sessions that a given server can keep in memory - but rather to handle the abandoned, but not yet expired sessions. In this way, I would typically prefer to evict all entries of a presumably abandoned session over the attributes of an active session that have not been accessed recently. The likelihood that the former will be accessed before the latter is typically low.

But no, there isn't anything in the JEE standard about how one specifies how sessions are passivated.

Your point about this being too complex is certainly valid, so let's try a different tack...

What if we had the ability to specify that a given cache entry was never to be passivated automatically (i.e. like an immortal cache entry, but for eviction purposes)? Infinispan would then passivate based on a max-size of "auto-evictable" cache entries (i.e. some subset of the total entries in memory).
This way, I can leverage a passivation callback to manually passivate the non-auto-evictable session attributes for a given session and still be able to define my eviction settings based on a maximum number of sessions. WDYT?

Sure, S.A being accessed recently means S was also accessed recently, for any attribute A of S. But the reverse is not true: S being accessed recently doesn't mean that S.A was also accessed recently. So at any time it might make sense to keep in memory some of the attributes of S, but not all of them.

The only reason I would see to force a session to be passivated or activated all at once is if the JEE standard specifically allows the user to configure the number of sessions to be stored in memory. But even so, I think implementing group-based eviction in Infinispan would be way too complex, and storing each session in a single entry (like an AtomicMap) would be simpler.

I disagree. The likelihood that a given session attribute will be accessed is not independent of, but is correlated with, the access recency of the session with which it is associated. If a session was not accessed for a given period then we know for certain that its attributes were not accessed for at least as long.

The greater point I was trying to make is: it's not always meaningful to base eviction off of a maximum number of entries. WildFly can be configured to store sessions as either 2 entries per session (the default), or N+1 entries per session, where N is the number of attributes in the session. In both cases, all cache entries associated with a session make up a single group. As a user/administrator, I am more interested in specifying the maximum number of sessions (i.e. groups) to keep in memory - irrespective of the cache entry mapping implementation details, since the desired value of max-entries would differ widely based on the session mapping strategy.

Eviction in Infinispan assumes that evicted entry can be easily restored, either by Infinispan loading them from a store or by the user application itself. With that assumption, it doesn't make sense to evict a bunch of keys all at once: just because session S has been accessed recently, it doesn't mean that attribute S.A has also been accessed recently and it's worth keeping it in memory.

Any change you guys can address this for 7.0?