[JBoss JIRA] Updated: (JBAS-2373) Need to replace PropertyEditorManager with context aware org.jboss.util.propertyeditor.PropertyEditors
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2373?page=all ]
Dimitris Andreadis updated JBAS-2373:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
> Need to replace PropertyEditorManager with context aware org.jboss.util.propertyeditor.PropertyEditors
> ------------------------------------------------------------------------------------------------------
>
> Key: JBAS-2373
> URL: http://jira.jboss.com/jira/browse/JBAS-2373
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Deployment services
> Affects Versions: JBossAS-4.0.3 Final
> Reporter: Scott M Stark
> Assigned To: Dimitris Andreadis
> Fix For: JBossAS-4.0.6.CR1
>
>
> The use of the java.beans.PropertyEditorManager as a registry for java.beans.PropertyEditor instances does not work with scoped deployments as its a vm global singleton that does not work with scoped deployments, conflicting scoped deployments and redeployments. Use of the PropertyEditorManager needs to be replaced with use of a context aware org.jboss.util.propertyeditor.PropertyEditors that allows different deployments such as a scoped sar and unscoped jmx-console to use the correct PropertyEditor and clear deployment level PropertyEditor on undeployment.
--
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
19 years, 12 months
[JBoss JIRA] Updated: (JBAS-2282) JBossEntityResolver is not using schemaLocation URIs that are valid non-file URLs
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2282?page=all ]
Dimitris Andreadis updated JBAS-2282:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
> JBossEntityResolver is not using schemaLocation URIs that are valid non-file URLs
> ---------------------------------------------------------------------------------
>
> Key: JBAS-2282
> URL: http://jira.jboss.com/jira/browse/JBAS-2282
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: XML services
> Affects Versions: JBossAS-4.0.3RC2
> Reporter: Scott M Stark
> Assigned To: Alexey Loubyansky
> Fix For: JBossAS-4.0.6.CR1
>
> Attachments: jboss-entity-resolver.zip
>
>
> The org.jboss.util.xml.JBossEntityResolver is not dealing with systemIDs that are valid non-file URLs. For example, this xml fragment from a testcase which uses the jboss resource URL:
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- $Id: config.xml,v 1.1 2005/07/31 23:13:44 starksm Exp $ -->
> <jaas:policy
> xsi:schemaLocation="urn:jboss:security-config resource:security-config_4_1.xsd"
> xmlns:jaas="urn:jboss:security-config"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >
> does map to a valid URL which can be loaded, but the parsing of this URL by the getLocalEntityName ends up throwing away the full path info to produce a resource name of schema/security-config_4_1.xsd. This would work inside the jboss server provided the security-config_4_1.xsd is bundled into a classpath location following the location conventions expected by the JBossEntityResolver, but does not work in the testsuite where this is not the case, and would not work for user defined schemas located elsewhere. It would seem we should try to load the schema from systemIDs that are valid URLs before defaulting to the jboss specific logic.
--
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
19 years, 12 months
[JBoss JIRA] Updated: (JBAS-2038) Need to externalize the JBossEntityResolver configuration and support namespace to schema resolution
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2038?page=all ]
Dimitris Andreadis updated JBAS-2038:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
> Need to externalize the JBossEntityResolver configuration and support namespace to schema resolution
> ----------------------------------------------------------------------------------------------------
>
> Key: JBAS-2038
> URL: http://jira.jboss.com/jira/browse/JBAS-2038
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: XML services
> Reporter: Scott M Stark
> Fix For: JBossAS-4.0.6.CR1
>
> Attachments: catalog.xsd
>
>
> With the increased use of JBossXB and its leveraging of the JBossEntityResolver as a means for locating element schemas, we need support for externalizing the configuration of the JBossEntityResolver. We also need to have the notion of resolving a namespace to a schema URI since in general there is no publicID for an element, and a generally unsable systemID since it can be a function of the deployment and server run dir.
> Implementing the javax.xml.transform.URIResolver resolve method:
> public javax.xml.transform.Source resolve(String href, String base)
> throws javax.xml.transform.TransformerException
> might be a better api for resolving namespaces.
> I have tried integrating the apache commons xml catalog resolver but have not been happy with its semantics and configuration support as yet. We certainly could at least use the catalog.xml schema for representing the externalized mappings.
--
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
19 years, 12 months
[JBoss JIRA] Updated: (JBAS-2113) Tables creation problem on Oracle
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2113?page=all ]
Dimitris Andreadis updated JBAS-2113:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
> Tables creation problem on Oracle
> ---------------------------------
>
> Key: JBAS-2113
> URL: http://jira.jboss.com/jira/browse/JBAS-2113
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB2
> Affects Versions: JBossAS-4.0.1 Final, JBossAS-4.0.2 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.3RC1
> Environment: WindowsXp, Oracle 9i
> Reporter: Martin Cerba
> Fix For: JBossAS-4.0.6.CR1
>
>
> When Jboss is configured to use Oracle 9i DB for tables TIMERS table is not created when user for logging is changed.
> I found problem in org.jboss.ejb.plugins.cmp.jdbc.SQLUtil class in function
> public static boolean tableExists(String tableName, DataSource dataSource)
> This function use JDBC3 functionality getTables(catalog, schema, tableName, null) to check for table existence where schema parameter is set to null.
> On Oracle this function check all schemas (users) for table existence (user had DBA privilegies set) and may find TIMERS table under different user.
> Then jboss assume TIMERS as existing.
> I put username to schema parameter and it repairs problem on oracle but then it not works under hypersonic.
--
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
19 years, 12 months
[JBoss JIRA] Updated: (JBAS-2213) Replace PooledExector usage in BasicThreadPool
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2213?page=all ]
Dimitris Andreadis updated JBAS-2213:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
No free cycles for this now.
> Replace PooledExector usage in BasicThreadPool
> ----------------------------------------------
>
> Key: JBAS-2213
> URL: http://jira.jboss.com/jira/browse/JBAS-2213
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Other
> Reporter: Scott M Stark
> Fix For: JBossAS-4.0.6.CR1
>
>
> We need to replace the use of the PooledExecutor due to its inefficient idle thread handling. From dev list messages.
> Elias Ross wrote:
> What I've noticed is a large number of mostly idle threads, some of the for the sorts of things that don't require timely processing, e.g.
> transaction and JMS message timeouts, etc. From what I hear from Adrian, the minimum pool size has been kept very large to deal with a design flaw in the concurrent.PooledExecutor that favors queueing over creating new threads to handle the work.
> Adrian Brock wrote:
> >
> > > I don't see why you need to change it anyway?.
> >
> > Probably not, but allocating 100 minimum idle threads is not a really
> > appropriate default. I should have brought this up in the development
> > list. The JavaDoc was also wrong on Min versus Max so perhaps 100 was
> > chosen as a mistake?
> >
> There are lots of examples where "bad" defaults have been chosen, sometimes for a reason. e.g. in this case, if you don't set the minimum equal to the maximum, it never uses more than minimum unless there is a very large backlog forcing the queue to become full.
> Concurrent's PooledExector should really be called QueuedExecutorWithMaybeSomePooling :-)
> There is certainly zero control over idle thread management and it is inefficient at using idle threads in a stupid attempt to reduce contention.
> There is even a race condition in there, which is why we have a subclass to work around it.
> If I had more time, I would rewrite BasicThreadPool to NOT use PooledExecutor.
--
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
19 years, 12 months
[JBoss JIRA] Updated: (JBAS-3187) Improve web-console logging
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3187?page=all ]
Dimitris Andreadis updated JBAS-3187:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
Darran, I'm deferring this, unless you want to do it for 4.0.5.CR1
> Improve web-console logging
> ---------------------------
>
> Key: JBAS-3187
> URL: http://jira.jboss.com/jira/browse/JBAS-3187
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Management services
> Affects Versions: JBossAS-4.0.3 SP1
> Reporter: Darran Lofthouse
> Assigned To: Darran Lofthouse
> Fix For: JBossAS-4.0.6.CR1
>
>
> The web-console application has been implemented so that it is not strictly dependent on the components that it makes available in the tree.
> On initialisation if there are any errors initialising the viewer for any components in the tree view an error is output but the component is not added to the tree and the remaining components are initialised correctly. The web-console continues to work correctly for the components that were correctly initialised with no negative effects from the components that failed to initialise.
> The web-console does not make use of Log4j at the moment.
> The web-console should be updated to use Log4j (Being careful with classes sent to the applet) and the initialisation failures should be logged at a low level (either DEBUG or even TRACE). This will allow the web-console to be installed in more configurations without as many dependencies.
--
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
19 years, 12 months
[JBoss JIRA] Updated: (JBAS-3188) Reduce the dependencies specified by web-console so it can be installed in more profiles.
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3188?page=all ]
Dimitris Andreadis updated JBAS-3188:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
Darran, I'm deferring this, unless you want to do it for 4.0.5.CR1
> Reduce the dependencies specified by web-console so it can be installed in more profiles.
> -----------------------------------------------------------------------------------------
>
> Key: JBAS-3188
> URL: http://jira.jboss.com/jira/browse/JBAS-3188
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Installer
> Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.GA
> Reporter: Darran Lofthouse
> Assigned To: Darran Lofthouse
> Fix For: JBossAS-4.0.6.CR1
>
>
> The web-console has been implemented to it is not strictly dependent on the components it makes available through it's interface, if any component it makes available through the interface is not installed then initialisation will fail just for that component and it will not be added to the tree. The remaining components will still be added to the tree and the web-console will continue to work correctly.
> The installer should be updated so the web-console is dependent on less components so it can be installed in more profiles.
> This will also get rid of another problem where the web console is dependent on specifc versions of components e.g. At the moment it is dependent on the JDK 1.4 version of AOP so can not be installed in any profile that uses the JDK 5.0 version of AOP.
--
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
19 years, 12 months