[JBoss JIRA] Created: (JBMICROCONT-158) Non-existent manifest Class-Path refs produce vfs IllegalStateException
by Scott M Stark (JIRA)
Non-existent manifest Class-Path refs produce vfs IllegalStateException
-----------------------------------------------------------------------
Key: JBMICROCONT-158
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-158
Project: JBoss MicroContainer
Issue Type: Bug
Components: VFS
Affects Versions: JBossMC_2_0_0 Beta3
Reporter: Scott M Stark
Assigned To: Scott M Stark
When the structure deployers parse a top-level jboss-test-entity.jar with a manifest like:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: 1.5.0_09-b01 (Sun Microsystems Inc.)
Class-Path: ejb.jar jnp-client.jar jboss-client.jar jndi.jar jboss-jmx
.jar junit.jar deploy.jar
it fails with:
Caused by: java.lang.IllegalStateException: JarHandler@28271403[path= context=file:/C:/home/svn/JBossHead/jboss-head/testsuite/output/lib/jboss-test-entity.jar
real=file:/C:/home/svn/JBossHead/jboss-head/testsuite/output/lib/jboss-test-entity.jar] has no parent.
at org.jboss.virtual.VFSUtils.addManifestLocations(VFSUtils.java:116)
at org.jboss.deployers.plugins.structure.DefaultStructureBuilder.processContext(DefaultStructureBuilder.java:131)
at org.jboss.deployers.plugins.structure.DefaultStructureBuilder.populateContext(DefaultStructureBuilder.java:89)
The invalid references should at most produce debug level warnings.
--
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
17 years, 11 months
[JBoss JIRA] Created: (JBCACHE-1169) some methods in eviction queue classes have package-only visibility - can it be changed?
by dana enescu (JIRA)
some methods in eviction queue classes have package-only visibility - can it be changed?
----------------------------------------------------------------------------------------
Key: JBCACHE-1169
URL: http://jira.jboss.com/jira/browse/JBCACHE-1169
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Eviction
Affects Versions: 2.0.0.GA
Reporter: dana enescu
Assigned To: Manik Surtani
Priority: Minor
I have been trying to implement my own cache eviction policy. The most convenient way for me was to extend LFU, instead of implementing the interfaces from scratch.
However, the ctor and the prune() method in LFUQueue have package-only visibility, so I had to do a nasty workaround. There may be similar issues in other classes of the eviction package.
IMO it would be better that these methods are made either public or protected, depending on what you want to expose to the users. I did not report it as a bug but rather as a feature request, since I do not know the developer's intent.
--
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
17 years, 11 months
[JBoss JIRA] Created: (JBCACHE-1024) Move component construction out of Cache into Configuration to allow for better configurability
by Elias Ross (JIRA)
Move component construction out of Cache into Configuration to allow for better configurability
-----------------------------------------------------------------------------------------------
Key: JBCACHE-1024
URL: http://jira.jboss.com/jira/browse/JBCACHE-1024
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Elias Ross
Assigned To: Manik Surtani
There's a lot of logic embedded in CacheImpl.start() and create() as to what specific object instances are created. For example, the JGroups Channel, or the InterceptorChainFactory are directly constructed here and users have no control on this. A bunch of other objects are also created based on class names and whatnot; these are configurable to some extent but why does the CacheImpl need to know how to build these?
What really should be done is allow the Configuration class to play the role as factory class, and take out all factory details from the Cache itself.
--
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
17 years, 11 months