[JBoss JIRA] Created: (JBAS-8072) enable wrapXAResource by default
by Jonathan Halliday (JIRA)
enable wrapXAResource by default
--------------------------------
Key: JBAS-8072
URL: https://jira.jboss.org/browse/JBAS-8072
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: 6.0.0.M3
Reporter: Jonathan Halliday
Assignee: Jesper Pedersen
Fix For: 6.0.0.M4
Transaction diagnostics can be improved through the use of the information provided by XAResourceWrapper. However, this currently requires explicitly enabling. Further, it's not possible to enable it in the -ds.xml, only via JMX. This is pointless - it should be on by default.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8133) Clear, understandable relationship between the domain management API and the contents of the domain configuration files
by Brian Stansberry (JIRA)
Clear, understandable relationship between the domain management API and the contents of the domain configuration files
-----------------------------------------------------------------------------------------------------------------------
Key: JBAS-8133
URL: https://jira.jboss.org/browse/JBAS-8133
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Fix For: Unscheduled
This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
> One of the drawbacks of the WebSphere API is that it is not always clear
> what gets modified on the file system when running certain commands. It
> is common practice to save a WebSphere config, then make the edits in
> the console and save the difference for reference. Then develop your
> wsadmin jython scripts so that the changes made by the script match
> those made manually in the console. WebSphere 7 made improvements in
> this space so that the admin console can show you the jython that makes
> the same change you made in the console. I would like to be able to look
> at a JBoss config file and write the API commands knowing exactly what
> it will change on the file system. Having the command line API match
> that used by the domain controller would make things more predictable
> when using both in one's environment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8310) Optional dependencies that are not present for classes in a bean archive can cause the deployment to fail
by Stuart Douglas (JIRA)
Optional dependencies that are not present for classes in a bean archive can cause the deployment to fail
---------------------------------------------------------------------------------------------------------
Key: JBAS-8310
URL: https://jira.jboss.org/browse/JBAS-8310
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Weld/CDI
Affects Versions: 6.0.0.M4
Reporter: Stuart Douglas
Assignee: Marius Bogoevici
If you have a class with optional dependencies that are not present in a bean archive it can cause the deployment to fail if these they are part of the classes external schema (i.e. method parameters or return values, field types).
This is because the NoClassDefFoundError will not be thrown when the class is loaded, but at the first call to getMethods() or getFields(). This causes introspection to fail and the deployment will abort.
The best solution would probably be to call getDeclaredMethods/Fields on the class and all parent classes early, so the NoClassDefFoundError can be caught and handled.
If the optional dependency is used by the class but not part of the schema the deployment will work as expected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8417) Issue with loading JAXB library in JBOSS 4.3.0 with JDK6
by Pek Lee Seow (JIRA)
Issue with loading JAXB library in JBOSS 4.3.0 with JDK6
--------------------------------------------------------
Key: JBAS-8417
URL: https://jira.jboss.org/browse/JBAS-8417
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading
Affects Versions: JBossAS-4.2.1.GA
Environment: I am currently running JBoss 4.3.0 CP06 which I understand is essentially 4.2.1.
Reporter: Pek Lee Seow
Assignee: Scott M Stark
Priority: Critical
I am having ClassCastException when instantiating JAXBContext within my web application.
javax.xml.bind.JAXBException: ClassCastException: attempting to cast jar:file:/C:/Documentum/jboss4.3.0/server/DctmServer_MethodServer/deploy/dfs.ear/APP-INF/lib/jaxb-api.jar!/javax/xml/bind/JAXBContext.class to jar:file:/C:/Documentum/jboss4.3.0/jdk/jre/lib/rt.jar!/javax/xml/bind/JAXBContext.class. Please make sure that you are specifying the proper ClassLoader.
javax.xml.bind.ContextFinder.handleClassCastException(ContextFinder.java:96)
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:205)
javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
HelloWorldServlet.marshallCode(HelloWorldServlet.java:62)
HelloWorldServlet.doGet(HelloWorldServlet.java:43)
javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
Here is the line of code where the problem occurs:
JAXBContext dataContext = JAXBContext.newInstance(MySimpleSouceData.class);
Basically my web application (WAR) is deployed as part of an .EAR file with jaxb-api.jar and jaxb-impl.jar included in the .ear's APP-INF/lib. The web application does not have any of the JAXB libraries included in the .war file.
The jboss-app.xml has been set to as follows:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-app>
<loader-repository>
com.emc.documentum.fs:loader=emc-dfs.ear
<loader-repository-config>
java2ParentDelegation=false
</loader-repository-config>
</loader-repository>
<library-directory>
APP-INF/lib
</library-directory>
</jboss-app>
I do not understand why the JAXBContext class instance from rt.jar (loaded by bootstrap/system classloader) is reference here when the configuration explicitly state to use the web application instance first (i.e. java2ParentDelegation=false).
When I remove the jboss-app.xml file, the ClassCastException goes away. It seems the JAXBContext class is loaded by:
org.jboss.mx.loading.UnifiedClassLoader3@2a2cc{ url=file:/C:/Documentum/jboss4.3.0/server/DctmServer_MethodServer/deploy/jbossws.sar/ ,addedOrder=12}
Is this a JBoss classloading bug?
What actually happens when jboss-app.xml is not provided? What is the default behaviour? And how is it that ClassCastException does not happen here??
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8023) jboss-classpool.jar and jboss-classpool-scoped.jar should be copied to client dir and included in jbossall-client.jar's MANIFEST.MF Class-Path
by Ian Springer (JIRA)
jboss-classpool.jar and jboss-classpool-scoped.jar should be copied to client dir and included in jbossall-client.jar's MANIFEST.MF Class-Path
----------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-8023
URL: https://jira.jboss.org/jira/browse/JBAS-8023
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Other
Affects Versions: 6.0.0.M3
Reporter: Ian Springer
We were getting the following exception when trying to connect from the RHQ Agent to AS M3 via JNP:
Caused by: java.lang.NoClassDefFoundError:
org/jboss/classpool/spi/ClassPoolRepositoryCallback
at org.jboss.aop.AspectManager.initManager(AspectManager.java:267)
at org.jboss.aop.AspectManager.instance(AspectManager.java:246)
at org.jboss.aop.AspectManager.instance(AspectManager.java:235)
at org.jboss.aop.proxy.ProxyFactory.createProxyCtClass(ProxyFactory.java:150)
at org.jboss.aop.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:119)
at org.jboss.aop.proxy.ProxyFactory.createInterfaceProxy(ProxyFactory.java:96)
at
org.jboss.aop.proxy.MarshalledInterfaceProxy.readResolve(MarshalledInterfaceProxy.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1078)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1779)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368)
at java.rmi.MarshalledObject.get(MarshalledObject.java:159)
at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:771)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688)
at javax.naming.InitialContext.lookup(InitialContext.java:409)
at
org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.lookup(AbstractProfileServiceConnectionProvider.java:81)
at
org.rhq.plugins.jbossas5.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:108)
at
org.rhq.plugins.jbossas5.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:43)
at
org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:42)
at
org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:401)
at
org.rhq.plugins.jbossas5.ApplicationServerComponent.start(ApplicationServerComponent.java:195)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
... 5 more
Caused by: java.lang.ClassNotFoundException:
org.jboss.classpool.spi.ClassPoolRepositoryCallback
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
at
org.rhq.core.pc.plugin.PluginClassLoader.loadClass(PluginClassLoader.java:63)
at java.lang.ClassLoader.loadClass(ClassLoader.java:264)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:332)
... 36 more
Note, the exception occurs on a the call to InitialContext.lookup(). We never saw this in AS 5.x. I was able to get past the exception by adding JBOSS_HOME/lib/jboss-classpool.jar and JBOSS_HOME/lib/jboss-classpool-scoped.jar to the RHQ Agent's classpath.
So these two jars are now apparently required in the client classpath for the following basic JNP based lookup of the ProfileService to work:
Properties env = new Properties();
env.setProperty(Context.PROVIDER_URL, "jnp://127.0.0.1:1099/");
// Always use the non-login context factory, since we'll use JAAS for authentication if a username/password was
// provided.
env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
InitialContext initialContext;
try
initialContext = new InitialContext(env);
} catch (NamingException e) {
throw new RuntimeException("Failed to create JNDI InitialContext.", e);
}
ProfileService profileService = (ProfileService)initialContext.lookup("ProfileService");
Since this is the case, I think these two jars should be copied to JBOSS_HOME/client/ and also included in JBOSS_HOME/client/jbossall-client.jar's MANIFEST.MF Class-Path, to emphasize that they are needed for client connections and so that existing client code that uses jbossall-client.jar will not have to be updated to also include these two jars.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years