[ http://jira.jboss.com/jira/browse/JBAS-539?page=history ]
Scott M Stark closed JBAS-539:
------------------------------
Resolution: Done
> BaseConnectionManager2 throws ClassCastException
> ------------------------------------------------
>
> Key: JBAS-539
> URL: http://jira.jboss.com/jira/browse/JBAS-539
> Project: JBoss Application Server
> Type: Bug
> Versions: JBossAS-3.2.6 Final
> Reporter: SourceForge User
> Assignee: Scott M Stark
>
>
> SourceForge Submitter: rodburgett .
> The startService method throws a ClassCast Exception
> when the NullLoggerPlugin is in use.
> In the neighborhood of line 323, the following lines are
> found:
> PrintWriter logWriter = new
> LoggerWriter(((org.jboss.logging.Log4jLoggerPlugin)
> log.getLoggerPlugin ()).getLogger());
> The unconditional cast only works when the actual
> logger plugin is either the default or a subclass of the
> default plugin, otherwise the ClassCastException is
> thrown.
> A few fix candidates come to mind...
> A) The simplest is to check for instanceof default plugin
> before casting. But that retains the unnecessary
> coupling of this class to the implementation of the
> default plugin. And then there's the question of what to
> do if instanceof returns false. What if a different, non-
> null, plugin is used? Is setLogWriter(null) reasonable?
> The current connection manager has additional coupling
> to the class of the type returned by getLogger and
> passed on to LogWriter constructor. But the coupling is
> implicit, hidden in the combination of calls in line above.
> This option would make that coupling explicit. I think
> that is a good thing.
> B) The LoggerPlugin interface might be updated to
> include a getLogger method returning something
> that 'new LogWriter(...)' might use. Then the null plugin
> needs to implement this method, probably returning
> null. This eliminates the need for casting and the
> coupling to the plugin, but now the connection manager
> has to handle a null returned value.
> The implicit coupling comments above apply to this
> option, too.
> C) The LoggerPlugin interface might be updated to
> include a getLogWriter method that can be used directly
> in the connection manager. This eliminates coupling to
> the plugin, but it introduces new coupling between the
> logger package and the jca LogWriter.
> D) Option B, but use an additional helper/utility class in
> the jca package to create a LogWriter from whatever is
> returned by LoggerPlugin.getLogger. This eliminates the
> coupling introduced in option C.
> Personally, I'd lean toward B or D.
> What do you think? Other alternatives?
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
