[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, 2 months
[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, 2 months
[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, 2 months
[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, 2 months
[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, 2 months
[JBoss JIRA] Created: (JBAS-8861) JSF Flash doesn't return data in the right order
by Devinder Singh (JIRA)
JSF Flash doesn't return data in the right order
------------------------------------------------
Key: JBAS-8861
URL: https://issues.jboss.org/browse/JBAS-8861
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JSF
Affects Versions: 6.0.0.Final
Environment: Redhat Linux 5.5
Reporter: Devinder Singh
Assignee: Stan Silvert
Data stored in JSF flash during a request is not returned in the next request. It's returned during the 3rd request. I have a very simple test to verify this behavior.
LoginBackingBean has two methods which are called in 2 subsequent requests. Variable kept in flash memory during request 1 doesn't return in request 2 but in request 3.
3 small files required to reproduce are attached. First referer.xhtml should be opened in a JSF app, then its login button calls doLogin method and takes you to Login.xhtml file. Now "Simulate Login" button need to be clicked twice to get the variable.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (JBAS-8343) Nmap scan results in error message on server
by Joshua Wulf (JIRA)
Nmap scan results in error message on server
--------------------------------------------
Key: JBAS-8343
URL: https://jira.jboss.org/browse/JBAS-8343
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.0.0.GA
Reporter: Joshua Wulf
When running nmap against the AS server, the following error occurs at the console:
10:05:59,639 ERROR [ServerThread] WorkerThread#0[127.0.0.1:48016] exception occurred during first invocation
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
at org.jboss.remoting.transport.socket.ServerThread.createServerSocketWrapper(ServerThread.java:937)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:515)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at java.io.ObjectOutputStream$BlockDataOutputStream.flush(ObjectOutputStream.java:1801)
at java.io.ObjectOutputStream.flush(ObjectOutputStream.java:708)
at org.jboss.remoting.marshal.serializable.SerializableMarshaller.getMarshallingStream(SerializableMarshaller.java:90)
at org.jboss.remoting.marshal.serializable.SerializableMarshaller.getMarshallingStream(SerializableMarshaller.java:72)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.createOutputStream(ClientSocketWrapper.java:223)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:181)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:67)
at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:46)
... 7 more
Nmap opens a connection then drops it. An error on the server seems like an excessive response.
--
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, 2 months
[JBoss JIRA] Created: (JBAS-8866) JBoss Cache lock UpgradeException when simultaneous requests with the same SSO create new sessions
by Dennis Reed (JIRA)
JBoss Cache lock UpgradeException when simultaneous requests with the same SSO create new sessions
--------------------------------------------------------------------------------------------------
Key: JBAS-8866
URL: https://issues.jboss.org/browse/JBAS-8866
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.2.3.GA
Reporter: Dennis Reed
Assignee: Dennis Reed
When more than one request with the same SSO ID creates a session at the same time, some may fail with an org.jboss.cache.lock.UpgradeException.
The root cause is that TreeCacheSSOClusterManager.addSession/removeSession first get a read lock, then upgrade to a write lock.
The fix is to get a write lock up front, instead of starting with a read lock then upgrading.
For AS 4.x, since JBoss Cache 1.4.x doesn't have Option.setForceWriteLock, adding something like the following
before the cache.get should force a write lock:
cache.put ( fqn, "LOCK", null, LOCAL_OPTION );
[org.jboss.web.tomcat.service.sso.TreeCacheSSOClusterManager] caught exception adding session C4851CD53FB091272E78A9395C0C15F1 to SSO id 821E74E80D46822B77FB774E8AEF67D8
...
Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/SSO/821E74E80D46822B77FB774E8AEF67D8/sessions, caller=GlobalTransaction:<10.0.0.1:61628>:4, lock=read owners=[GlobalTransaction:<10.0.0.1:61628>:4, GlobalTransaction:<10.0.0.1:61628>:5] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
at org.jboss.cache.Node.acquire(Node.java:517)
...
Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /SSO/821E74E80D46822B77FB774E8AEF67D8/sessions (caller=GlobalTransaction:<10.0.0.1:61628>:4, lock info: read owners=[GlobalTransaction:<10.0.0.1:61628>:4, GlobalTransaction:<10.0.0.1:61628>:5] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
...
Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:106)
at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:175)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months