Xerces SAX Error in JBoss
by Robert Hughes
Hi everybody.
I am currently trying to upgrade an old app from JBoss 3.2.5 to the
latest version in the hope of breathing some new life into it.
I have made a number of changes suggested by the upgrade guide (changing
my Datasource config etc.), however when I deploy my app am am getting
some errors related apparently to xerces.
I get this error if I try and deploy one web-app.
14:30:08,354 ERROR [Digester] Digester.getParser:
java.lang.ClassCastException:
org.apache.xerces.jaxp.SAXParserFactoryImpl
at javax.xml.parsers.SAXParserFactory.newInstance(Unknown
Source)
I get this error when I try and access the other web-app (which seems to
deploy ok). I have checked the org.apache.xerces.parsers.SAXParser class
I am using and it definitely implements XMLReader).
org.jdom.JDOMException: Could not load default SAX parser:
org.apache.xerces.parsers.SAXParser: SAX2 driver class
org.apache.xerces.parsers.SAXParser does not implement XMLReader
I also have an ear which seems to deploy ok.
I am using JBoss 4.0.5 and have recompiled everything against the
xercesimpl.jar and xml-api.jar files found in JBoss's lib/endorsed
folder. There are no other versions of xerces in any of my ears or wars
- just that version. My initial research leads me to believe this is a
class-loading issue and that maybe my default sax parser is incorrect?
Anybody got any ideas?
Thanks for your time.
Robert Hughes
19 years, 1 month
[Design of POJO Server] - JNDI refactor and JBoss Remoting
by bill.burke＠jboss.com
Not sure if anybody pays attention to the JNDI forum, so i'll post here.
I did a refactoring of the JNDI initial context so that it can be used with JBoss Remoting and configured as a set of beans rather than a JMX service. Its pretty feature complete (security propagation for instance).
Lookin:
embedded/
org.jboss.naming.JBossRemotingContextFactory
The Bean code is:
| <bean name="Naming" class="org.jnp.server.SingletonNamingServer"/>
| <bean name="java:comp" class="org.jboss.naming.JavaCompInitializer"/>
|
| <!-- register Naming bean with dispatcher just in case we want to have a remote JNDI connection -->
| <bean name="JndiRegistration" class="org.jboss.aspects.remoting.DispatcherRegistration">
| <property name="oid">JNDI</property>
| <property name="target"><inject bean="Naming"/></property>
| </bean>
|
I just need to do some integration work with HA_JNDI so that there is request failover.
BTW, with the AOP Remoting integration you could even secure remote access to JNDI quite easily.
Bill
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016523#4016523
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016523
19 years, 1 month
[Design of JBoss Labs] - Re: Links in Labs 2
by adamw
Answering myself, and after having a conversation with Bob, here is what we decided:
* we need to get rid of /portal/
* all project links will start with /<project-name>/
* then it will be broken into groups: forums, blog, pages, other
* following it, will come the forum name, page name etc
For example, we will have:
jboss.org/<project-name> for the main project page
jboss.org/<project-name>/forums for the main forum
jboss.org/<project-name>/forums/dev for the dev forum
jboss.org/<project-name>/forums/dev/12452/462 for a post in a subject
(this implies, that each forum is named, there is a main forum and forum names are unique across a one project's pages)
jboss.org/<project-name>/pages/<page-name> for a project sub-page
jboss.org/<project-name>/pages/<page-name>/<window-name>/4 for a project sub-page window action
This leaves one unsolved problem with the My.ORG page, as users can place there any portlets - for example forums. There, we can have the [permalink] links.
--
Adam
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016485#4016485
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016485
19 years, 1 month
[Design the new POJO MicroContainer] - Re: Scoped beans deployment
by alesj
"adrian(a)jboss.org" wrote :
| 3) We check that all "PREINSTALL" dependencies are satisfied,
| basically the classloader and in future the classloading dependencies
| 4) We switch the context to the scoped controller (creating it if necessary)
| 5) We check that all "DESCRIBED" dependencies are satisfied
| (since the classloader has moved to PREINSTALL this will be none by default)
| 6) Business as usual, except the context is now in a scoped controller.
|
So PREINSTALL is before DESCRIBE.
And it does this:
| BeanMetaData metaData = context.getBeanMetaData();
| if (metaData.getBean() != null)
| {
| BeanInfo info = configurator.getBeanInfo(metaData);
| context.setBeanInfo(info);
|
| MetaData md = addMetaData(context);
|
+ sets up new child Controller (if there is a scoping annotation on the bean).
But the rest of the dependencies:
| try
| {
| DependencyInfo depends = context.getDependencyInfo();
| // add custom dependencies (e.g. AOP layer).
| List<Object> dependencies = info.getDependencies(md);
| log.trace("Extra dependencies for " + context.getName() + " " + dependencies);
| if (dependencies != null)
| {
| for (Object dependencyName : dependencies)
| {
| AbstractDependencyItem dependency = new AbstractDependencyItem(metaData.getName(), dependencyName, ControllerState.INSTANTIATED, ControllerState.INSTALLED);
| depends.addIDependOn(dependency);
| }
| }
| }
| catch (Throwable t)
| {
| removeMetaData(context);
| throw t;
| }
|
are still done in DescribeAction, right.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016454#4016454
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016454
19 years, 1 month