[JBoss JIRA] (JBNAME-61) Remote JNDI lookup failure with sun.io.serialization.extendedDebugInfo
by Dennis Reed (JIRA)
Dennis Reed created JBNAME-61:
---------------------------------
Summary: Remote JNDI lookup failure with sun.io.serialization.extendedDebugInfo
Key: JBNAME-61
URL: https://issues.jboss.org/browse/JBNAME-61
Project: JBoss Naming
Issue Type: Bug
Components: jnp-client
Affects Versions: 5.0.3.GA
Reporter: Dennis Reed
When the system property sun.io.serialization.extendedDebugInfo is set, a remote lookup fails with the exception:
java.lang.UnsupportedOperationException
at org.jnp.interfaces.FastNamingProperties.toString(FastNamingProperties.java:175)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1387)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at javax.naming.CompoundName.writeObject(CompoundName.java:541)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:274)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5978) DefaultDeploymentOperations should use ModelControllerClient.executeAsync()
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-5978:
-------------------------------------
Summary: DefaultDeploymentOperations should use ModelControllerClient.executeAsync()
Key: AS7-5978
URL: https://issues.jboss.org/browse/AS7-5978
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.3.Final (EAP)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
DefaultDeploymentOperations isn't using the async ModelControllerClient API; instead it is submitting a synchronous execute request to its own Executor. It should use the ModelControllerClient.executeAsync() API to ensure the intended task cancellation logic is invoked.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBAS-8198) DomainController discovery system
by Brian Stansberry (JIRA)
DomainController discovery system
---------------------------------
Key: JBAS-8198
URL: https://jira.jboss.org/browse/JBAS-8198
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 7.0.0.M1
Mechanism(s) by which a ServerManager finds a DomainController so it can begin the process of integrating into the domain.
Task includes the host.xml schema elements to configure this, the domain object model classes behind those elements, and the actual implementation of discovery from both the ServerManager and DomainController sides.
--
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
13 years, 6 months
[JBoss JIRA] (JBWEB-257) Filter.destroy() exceptions break application undeployment
by Aaron Ogburn (JIRA)
Aaron Ogburn created JBWEB-257:
----------------------------------
Summary: Filter.destroy() exceptions break application undeployment
Key: JBWEB-257
URL: https://issues.jboss.org/browse/JBWEB-257
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core
Affects Versions: JBossWeb-2.1.12.GA
Environment: -JBoss Enterprise Application Platform (EAP) 5.1.2 and earlier
Reporter: Aaron Ogburn
Assignee: Remy Maucherat
JBoss does not handle any exceptions from custom Filter.destroy() implementations. This is passed on to the JBoss container and disrupts the
undeployment so the app is not successfully undeployed.
That causes a potentially critical issue as the application is no longer deployed at that point, but it can't be redeployed due to conflicts with the prior incomplete undeployment. The server has to be restarted to be able to deploy the application again.
The broken undeployment could be fixed at the container level if org.apache.catalina.core.ApplicationFilterConfig.release() caught exceptions thrown by Filter.destroy()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5403) CLONE - Adding modcluster via the CLI fails.
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/AS7-5403?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar updated AS7-5403:
--------------------------------
Fix Version/s: 7.2.0.Alpha1
The way I want to fix this for 7.2 is to add 'connector' as mandatory parameter to the add operation. Making 'connector' attribute optional does not seem reasonable, as we need that as dependency for the subsystem.
Using lists instead seems to only workaround the issue of not supporting runtime mode for attributes properly. Most of the problems should go away if it gets addressed.
Objections?
> CLONE - Adding modcluster via the CLI fails.
> --------------------------------------------
>
> Key: AS7-5403
> URL: https://issues.jboss.org/browse/AS7-5403
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Tom Fonteyne
> Assignee: Joe Wertz
> Fix For: 7.2.0.Alpha1
>
>
> Adding modcluster via the CLI fails.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5077) "JBAS014101: Failed to find SFSB instance with session ID" calling @javax.ejb.Remove method
by Marek Schmidt (JIRA)
Marek Schmidt created AS7-5077:
----------------------------------
Summary: "JBAS014101: Failed to find SFSB instance with session ID" calling @javax.ejb.Remove method
Key: AS7-5077
URL: https://issues.jboss.org/browse/AS7-5077
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.2.Final (EAP)
Reporter: Marek Schmidt
Assignee: jaikiran pai
Calling a SFSB @javax.ejb.Remove method results an ugly INFO message in the logs:
e.g. (modified helloworld-jsf quickstart):
{code}
@Named
@Stateless
public class RichBean {
@Resource
SessionContext sessionContext;
public void greet() {
TestEjb testEjb = (TestEjb)sessionContext.lookup("java:app/jboss-as-helloworld-jsf/TestEjb");
System.out.println(testEjb.greet());
testEjb.remove();
}
}
{code}
{code}
@Stateful
public class TestEjb
{
@Remove
public void remove() {
}
public String greet() {
return "Hello";
}
}
{code}
{code}
<h:form id="helloWorld">
<h:commandButton action="#{richBean.greet()}" value="Greet" />
</h:form>
{code}
{noformat}
14:35:46,105 INFO [stdout] (http-/127.0.0.1:8080-1) Hello
14:35:46,106 INFO [org.jboss.as.ejb3] (http-/127.0.0.1:8080-1) JBAS014101: Failed to find SFSB instance with session ID {[95, 12, 97, -35, -110, -123, 79, -16, -116, -95, -99, -57, 52, 38, 81, 85]} in cache
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5500) Admin Console writes incorrect standalone.xml content
by Scott Matthews (JIRA)
Scott Matthews created AS7-5500:
-----------------------------------
Summary: Admin Console writes incorrect standalone.xml content
Key: AS7-5500
URL: https://issues.jboss.org/browse/AS7-5500
Project: Application Server 7
Issue Type: Bug
Environment: Mac OS x 10.6.8, JBoss 7.1.1 Final
Reporter: Scott Matthews
I added a Security Domain (manually) to my JBoss application. It included a definition of a custom login module as well as a reference to the module in which it was contained:
<login-module code="com.atlassian.crowd.application.jaas.CrowdLoginModule" flag="required" module="com.atlassian.crowd">
Through multiple startups and shutdowns my configuration worked as I expected.
When I attempted to use the Admin Console to add new module options to this security domain, my ability to login failed.
Upon further investigation I discovered that the admin console removed the module property from the login-module tag.
to prove this I repeated the process with the same result.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months