[JBoss JIRA] Created: (JBAS-5900) jars are not loaded from the lib directory of a sar in JBoss AS 5
by Matt Wringe (JIRA)
jars are not loaded from the lib directory of a sar in JBoss AS 5
-----------------------------------------------------------------
Key: JBAS-5900
URL: https://jira.jboss.org/jira/browse/JBAS-5900
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading
Affects Versions: JBossAS-5.0.0.CR2
Reporter: Matt Wringe
Assignee: Scott M Stark
Attachments: testsar.tar.gz
In JBoss AS 5, any jars placed in the lib directory of a sar are not loaded and results in a class not found exception. The classes are loaded if the jar is placed in the root directory of the sar.
On previous versions of JBoss AS, the classes would be loaded from either location. This prevents sars that would have worked on JBoss AS 4 to fail on JBoss AS 5.
Steps to reproduce:
1) take zip attached to this report.
2) deploy test-in-lib.sar to JBoss AS 5. The sar will not deploy and will fail with a classNotFoundException
3) deploy test-in-lib.sar to JBoss AS 4, the sar will deploy without issue.
test-in-root.sar will work on both versions of JBoss. The only difference between these sars is the location of the jar.
--
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
13 years, 10 months
[JBoss JIRA] (AS7-3854) MimeMappingAdd and MimeMappingRemove don't affect the runtime
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-3854:
-------------------------------------
Summary: MimeMappingAdd and MimeMappingRemove don't affect the runtime
Key: AS7-3854
URL: https://issues.jboss.org/browse/AS7-3854
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, Web
Reporter: Brian Stansberry
Assignee: Tomaz Cerar
Fix For: 7.1.1.Final
While reviewing https://github.com/jbossas/jboss-as/pull/1549 I see that MimeMappingAdd and MimeMappingRemove just update the model but have no effect on the runtime services. If context.isNormalServer() == true, they should either impact a runtime service or put the server into reload-required.
Note that the current behavior may make sense during boot if the overall subsystem design has a parent resource adding a Stage.RUNTIME handler that reads child resources and uses their state to set up runtime services. But it's definitely not correct if these operations are performed independently.
As part of processing pull request 1549 I'll add TODO comments in these classes referencing this JIRA.
--
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, 10 months
[JBoss JIRA] (AS7-4858) jconsole.sh does not start on Mac OSX
by Jim Tyrrell (JIRA)
Jim Tyrrell created AS7-4858:
--------------------------------
Summary: jconsole.sh does not start on Mac OSX
Key: AS7-4858
URL: https://issues.jboss.org/browse/AS7-4858
Project: Application Server 7
Issue Type: Feature Request
Components: Server
Reporter: Jim Tyrrell
Assignee: Jason Greene
jconsole.sh does not work on Mac OSX:
Jim-Tyrrells-MacBook-Pro-2:bin jimtyrrell$ ./jconsole.sh
CLASSPATH /lib/jconsole.jar:/lib/tools.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/remoting3/remoting-jmx/main/remoting-jmx-1.0.3.CR1-redhat-0-todo.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/remoting3/main/jboss-remoting-3.2.4.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/logging/main/jboss-logging-3.1.0.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/xnio/main/xnio-api-3.0.3.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/xnio/nio/main/xnio-nio-3.0.3.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/sasl/main/jboss-sasl-1.0.0.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/marshalling/main/jboss-marshalling-1.3.13.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/marshalling/river/main/jboss-marshalling-river-1.3.13.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/as/cli/main/jboss-as-cli-7.1.1.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/staxmapper/main/staxmapper-1.1.0.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/as/protocol/main/jboss-as-protocol-7.1.1.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/dmr/main/jboss-dmr-1.1.1.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/as/controller-client/main/jboss-as-controller-client-7.1.1.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/threads/main/jboss-threads-2.0.0.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/as/controller/main/jboss-as-controller-7.1.1.Final-redhat-1.jar
Exception in thread "main" java.lang.NoClassDefFoundError: sun/tools/jconsole/JConsole
Caused by: java.lang.ClassNotFoundException: sun.tools.jconsole.JConsole
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
--
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, 10 months
[JBoss JIRA] (AS7-5110) Destructive Change to the .xml file ie Losing comments in the file.
by Jim Tyrrell (JIRA)
Jim Tyrrell created AS7-5110:
--------------------------------
Summary: Destructive Change to the .xml file ie Losing comments in the file.
Key: AS7-5110
URL: https://issues.jboss.org/browse/AS7-5110
Project: Application Server 7
Issue Type: Feature Request
Components: Console
Affects Versions: 7.1.2.Final (EAP)
Reporter: Jim Tyrrell
Assignee: Heiko Braun
Run the following commands with a clean EAP install:
./domain.sh --host-config=host-master.xml
Edit the host-slave.xml file, by changing the default 9999 port to 29999 as shown:
<native-interface security-realm="ManagementRealm">
<socket interface="management" port="${jboss.management.native.port:29999}"/>
</native-interface>
Start up the host slave:
./domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1
Create a generic admin user of your choosing.
Look at the host-slave.xml file and note this section:
<!-- server-two avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
Add in an auto-start="true" flag as shown:
<server name="server-two" group="other-server-group" auto-start="true">
<!-- server-two avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
<socket-bindings port-offset="150"/>
</server>
Change in the console auto start to false:
Now more the contents of the host-slave.xml file:
<server name="server-two" group="other-server-group" auto-start="false">
<socket-bindings port-offset="150"/>
</server>
Note your comments are gone.
Imagine I was an admin for whatever reason and I had commented out a section and it was now removed. This is kind of bad.
--
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, 10 months
[JBoss JIRA] (AS7-5114) JACC EJB permissions are not deployed
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/AS7-5114?page=com.atlassian.jira.plugin.s... ]
Josef Cacek commented on AS7-5114:
----------------------------------
A basic test is already in the TS (with @Ignore annotation):
org.jboss.as.test.integration.security.jacc.JACCForEarModulesTestCase.testEJBPermissions(URL)
> JACC EJB permissions are not deployed
> -------------------------------------
>
> Key: AS7-5114
> URL: https://issues.jboss.org/browse/AS7-5114
> Project: Application Server 7
> Issue Type: Bug
> Components: Security
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Josef Cacek
> Assignee: Anil Saldhana
> Priority: Critical
>
> It seems, there is a problem with DeploymentUnitProcessor ordering in AS, which causes JACC permissions are not created for EJBs. The JaccEjbDeploymentProcessor (uses JACC permissions) runs before the EEModuleConfigurationProcessor (creates JACC permissions - calling EjbJaccConfigurator.configure()).
> Both processors are registered to INSTALL phase:
> {noformat}
> ./ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemAdd.java:207: processorTarget.addDeploymentProcessor(EJB3Extension.SUBSYSTEM_NAME, Phase.INSTALL, Phase.INSTALL_EJB_JACC_PROCESSING, new JaccEjbDeploymentProcessor());
> {noformat}
> {noformat}
> ./ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java:181: processorTarget.addDeploymentProcessor(EeExtension.SUBSYSTEM_NAME, Phase.INSTALL, Phase.INSTALL_EE_MODULE_CONFIG, new EEModuleConfigurationProcessor());
> {noformat}
> and stacktraces with usage:
> {panel}
> Thread [MSC service thread 1-1] (Suspended (breakpoint at line 44 in EjbSecurityDeployer))
> EjbSecurityDeployer.getMetaDataType() line: 44
> EjbSecurityDeployer(AbstractSecurityDeployer<T>).deploy(DeploymentUnit) line: 38
> JaccEjbDeploymentProcessor.deploy(DeploymentPhaseContext) line: 54
> DeploymentUnitPhaseService<T>.start(StartContext) line: 116
> ServiceControllerImpl$StartTask.startService(Service<? extends S>, StartContext) line: 1811
> ServiceControllerImpl$StartTask.run() line: 1746
> ThreadPoolExecutor$Worker.runTask(Runnable) line: 886
> ThreadPoolExecutor$Worker.run() line: 908
> ServiceContainerImpl$ServiceThread(Thread).run() line: 662
> Thread [MSC service thread 1-1] (Suspended (breakpoint at line 40 in EjbJaccConfigurator))
> EjbJaccConfigurator.configure(DeploymentPhaseContext, ComponentDescription, ComponentConfiguration) line: 40
> EEModuleConfigurationProcessor.deploy(DeploymentPhaseContext) line: 83
> DeploymentUnitPhaseService<T>.start(StartContext) line: 116
> ServiceControllerImpl$StartTask.startService(Service<? extends S>, StartContext) line: 1811
> ServiceControllerImpl$StartTask.run() line: 1746
> ThreadPoolExecutor$Worker.runTask(Runnable) line: 886
> ThreadPoolExecutor$Worker.run() line: 908
> ServiceContainerImpl$ServiceThread(Thread).run() line: 662
> {panel}
--
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, 10 months
[JBoss JIRA] (AS7-5115) Report master SHA1 before pull request gets rebased
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-5115:
-----------------------------------
Summary: Report master SHA1 before pull request gets rebased
Key: AS7-5115
URL: https://issues.jboss.org/browse/AS7-5115
Project: Application Server 7
Issue Type: Task
Components: Test Suite
Reporter: Thomas Diesler
Assignee: Jason Greene
Fix For: 7.2.0.Alpha1
For a successful merge like [this|http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-param-pul...], see
{code}
+ git init
Initialized empty Git repository in /home/jenkins/jenkins-work/workspace/as7-param-pull/.git/
+ git config user.email jenkins(a)example.com
+ git config user.name 'Mr. Jenkins'
+ git remote add origin git://github.com/jbossas/jboss-as.git
+ git fetch origin master:refs/remotes/origin/master
>From git://github.com/jbossas/jboss-as
* [new branch] master -> origin/master
>From git://github.com/jbossas/jboss-as
...
* [new tag] 7.1.2.Final -> 7.1.2.Final
+ git fetch origin refs/pull/2593/head
>From git://github.com/jbossas/jboss-as
* branch refs/pull/2593/head -> FETCH_HEAD
+ git checkout FETCH_HEAD
...
Checking out files: 100% (9519/9519), done.
Note: checking out 'FETCH_HEAD'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at 3a64ae5... [AS7-5052] Allow WAR deployments as OSGi bundles
+ git rebase origin/master
First, rewinding head to replay your work on top of it...
Applying: [AS7-4918] Registered module using OSGi capability not visible as a bundle
Applying: [AS7-5049] Allow bundles to get resolved/activated during deployment unit processing
Applying: [AS7-5104] Remove no-start behaviour for test bundle deployments
Applying: [AS7-5093] Allow JDBC driver deployments as OSGi bundles
Applying: [AS7-5052] Allow WAR deployments as OSGi bundles
{code}
This tells me that the rebase was ok, but not onto what master revision it happened. Hence I cannot reproduce this run locally.
--
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, 10 months
[JBoss JIRA] (AS7-5114) JACC EJB permissions are not deployed
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-5114?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas commented on AS7-5114:
-------------------------------------
It sounds like the fix is simply a matter of fixing the DUP ordering, but we really should make sure that we have some tests for this.
> JACC EJB permissions are not deployed
> -------------------------------------
>
> Key: AS7-5114
> URL: https://issues.jboss.org/browse/AS7-5114
> Project: Application Server 7
> Issue Type: Bug
> Components: Security
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Josef Cacek
> Assignee: Anil Saldhana
> Priority: Critical
>
> It seems, there is a problem with DeploymentUnitProcessor ordering in AS, which causes JACC permissions are not created for EJBs. The JaccEjbDeploymentProcessor (uses JACC permissions) runs before the EEModuleConfigurationProcessor (creates JACC permissions - calling EjbJaccConfigurator.configure()).
> Both processors are registered to INSTALL phase:
> {noformat}
> ./ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemAdd.java:207: processorTarget.addDeploymentProcessor(EJB3Extension.SUBSYSTEM_NAME, Phase.INSTALL, Phase.INSTALL_EJB_JACC_PROCESSING, new JaccEjbDeploymentProcessor());
> {noformat}
> {noformat}
> ./ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java:181: processorTarget.addDeploymentProcessor(EeExtension.SUBSYSTEM_NAME, Phase.INSTALL, Phase.INSTALL_EE_MODULE_CONFIG, new EEModuleConfigurationProcessor());
> {noformat}
> and stacktraces with usage:
> {panel}
> Thread [MSC service thread 1-1] (Suspended (breakpoint at line 44 in EjbSecurityDeployer))
> EjbSecurityDeployer.getMetaDataType() line: 44
> EjbSecurityDeployer(AbstractSecurityDeployer<T>).deploy(DeploymentUnit) line: 38
> JaccEjbDeploymentProcessor.deploy(DeploymentPhaseContext) line: 54
> DeploymentUnitPhaseService<T>.start(StartContext) line: 116
> ServiceControllerImpl$StartTask.startService(Service<? extends S>, StartContext) line: 1811
> ServiceControllerImpl$StartTask.run() line: 1746
> ThreadPoolExecutor$Worker.runTask(Runnable) line: 886
> ThreadPoolExecutor$Worker.run() line: 908
> ServiceContainerImpl$ServiceThread(Thread).run() line: 662
> Thread [MSC service thread 1-1] (Suspended (breakpoint at line 40 in EjbJaccConfigurator))
> EjbJaccConfigurator.configure(DeploymentPhaseContext, ComponentDescription, ComponentConfiguration) line: 40
> EEModuleConfigurationProcessor.deploy(DeploymentPhaseContext) line: 83
> DeploymentUnitPhaseService<T>.start(StartContext) line: 116
> ServiceControllerImpl$StartTask.startService(Service<? extends S>, StartContext) line: 1811
> ServiceControllerImpl$StartTask.run() line: 1746
> ThreadPoolExecutor$Worker.runTask(Runnable) line: 886
> ThreadPoolExecutor$Worker.run() line: 908
> ServiceContainerImpl$ServiceThread(Thread).run() line: 662
> {panel}
--
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, 10 months
[JBoss JIRA] (AS7-5114) JACC EJB permissions are not deployed
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-5114?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas moved JBPAPP-9443 to AS7-5114:
---------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-5114 (was: JBPAPP-9443)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.2.Final (EAP)
(was: EAP 6.0.0 (CR1))
Component/s: Security
(was: Security)
Security: (was: JBoss Internal)
Docs QE Status: (was: NEW)
> JACC EJB permissions are not deployed
> -------------------------------------
>
> Key: AS7-5114
> URL: https://issues.jboss.org/browse/AS7-5114
> Project: Application Server 7
> Issue Type: Bug
> Components: Security
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Josef Cacek
> Assignee: Anil Saldhana
> Priority: Critical
>
> It seems, there is a problem with DeploymentUnitProcessor ordering in AS, which causes JACC permissions are not created for EJBs. The JaccEjbDeploymentProcessor (uses JACC permissions) runs before the EEModuleConfigurationProcessor (creates JACC permissions - calling EjbJaccConfigurator.configure()).
> Both processors are registered to INSTALL phase:
> {noformat}
> ./ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemAdd.java:207: processorTarget.addDeploymentProcessor(EJB3Extension.SUBSYSTEM_NAME, Phase.INSTALL, Phase.INSTALL_EJB_JACC_PROCESSING, new JaccEjbDeploymentProcessor());
> {noformat}
> {noformat}
> ./ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java:181: processorTarget.addDeploymentProcessor(EeExtension.SUBSYSTEM_NAME, Phase.INSTALL, Phase.INSTALL_EE_MODULE_CONFIG, new EEModuleConfigurationProcessor());
> {noformat}
> and stacktraces with usage:
> {panel}
> Thread [MSC service thread 1-1] (Suspended (breakpoint at line 44 in EjbSecurityDeployer))
> EjbSecurityDeployer.getMetaDataType() line: 44
> EjbSecurityDeployer(AbstractSecurityDeployer<T>).deploy(DeploymentUnit) line: 38
> JaccEjbDeploymentProcessor.deploy(DeploymentPhaseContext) line: 54
> DeploymentUnitPhaseService<T>.start(StartContext) line: 116
> ServiceControllerImpl$StartTask.startService(Service<? extends S>, StartContext) line: 1811
> ServiceControllerImpl$StartTask.run() line: 1746
> ThreadPoolExecutor$Worker.runTask(Runnable) line: 886
> ThreadPoolExecutor$Worker.run() line: 908
> ServiceContainerImpl$ServiceThread(Thread).run() line: 662
> Thread [MSC service thread 1-1] (Suspended (breakpoint at line 40 in EjbJaccConfigurator))
> EjbJaccConfigurator.configure(DeploymentPhaseContext, ComponentDescription, ComponentConfiguration) line: 40
> EEModuleConfigurationProcessor.deploy(DeploymentPhaseContext) line: 83
> DeploymentUnitPhaseService<T>.start(StartContext) line: 116
> ServiceControllerImpl$StartTask.startService(Service<? extends S>, StartContext) line: 1811
> ServiceControllerImpl$StartTask.run() line: 1746
> ThreadPoolExecutor$Worker.runTask(Runnable) line: 886
> ThreadPoolExecutor$Worker.run() line: 908
> ServiceContainerImpl$ServiceThread(Thread).run() line: 662
> {panel}
--
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, 10 months