[Design the new POJO MicroContainer] - Re: Heavy usage of VirtualFileURLConnection
by mstruk
"alesj" wrote :
| 2) change how we handle VFS URLs - same way we do it in pre-JBoss5
| Q1: what's the reason we don't return VFS URLs with temp paths?
|
VFS URL handling delegates to VFS handlers and contexts. The existence of a temp path is currently not guaranteed - depends on vfs settings and is an implementation detail. If contexts (handlers) were reused between URLs then there would be no performance problem. But as things are now, every getInputStream() request creates a new context.
"alesj" wrote :
| 3) implement some simple VFS caching
| Q1: use real cache, e.g. LRU, or is SoftRef enough?
|
What would you cache? The most sensible thing to cache would be VFSContext ...
"alesj" wrote :
| Q2: we need to cache intermediate paths - getting different resources from same parent faster (this requires VFURLConnection impl change)
|
As long as you hold a context 'open', intermediate paths are automatically kept 'open' for fast access.
"alesj" wrote :
| Q3: transparent AOP usage - caching is an aspect?
|
We would have to identify the most appropriate join points for this. This opens another question - do we want to put cache interception only on URL VFS integration code or at VFS API level itself.
- marko
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184798#4184798
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184798
15 years, 10 months
[Design of JBoss Identity] - API Model - Plain pojos or not...
by bdaw
Some of ideas discussed in the other topic (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=144427) ends up in a more general question on how API model objects should be designed/implemented.
Should the Identity/Group/Role objects be plain pojos or expose some of management operations.
1) Plain POJOs - Identity/Group/Role objects keep minimal information about Id/Name/Type. They are easily seriazible and there are no problems with closed session (like with detached hibernate entities). With this approach even getDescription method should be removed as it needs a session reference to retrieve the value.
2) Model objects keep reference to the associated session and expose some of management operations like
Group.associateGroup(Group group)
| Group.associateIdentity(Identity identity)
The idea is to keep all methods in the managers but duplicate some of them in Identity/Group/Role interfaces to expose convenient use:
| employeeGroup.associateIdentity(jackBlack)
|
| and
|
| identitySession.getRelationshipManager().associateIdentity(employeeGroup, jackBlack)
|
Both approaches have pros and cons.... With the second approach serialization requirements can be painful and we may end up with things like SessionClosedException...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184784#4184784
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184784
15 years, 10 months