[JBoss JIRA] (AS7-4240) NameNotFoundException thrown when trying to read java:*/env context in Servlet container.
by Robert Edgecombe (JIRA)
Robert Edgecombe created AS7-4240:
-------------------------------------
Summary: NameNotFoundException thrown when trying to read java:*/env context in Servlet container.
Key: AS7-4240
URL: https://issues.jboss.org/browse/AS7-4240
Project: Application Server 7
Issue Type: Bug
Components: Naming
Affects Versions: 7.1.1.Final
Environment: Windows7 Enterprise x64
Intel Core 2 Duo
Oracle Java jdk1.6.0_29
Reporter: Robert Edgecombe
Assignee: John Bailey
We have many J2EE 1.4 apps that need to be migrated from Oracle Application Server
These applications rely on configuration using Environment Entries
Most of the answers to issues I have read indicate that this is done using jboss-web.xml but this is not an acceptable solutin as it requires repackaging of the deployment artifact for different servers and different environments and is therefor contrary to the spirit (and I believe the letter) of the JavaEE spec.
The documentation on this capability is either hidden or missing.
I was tasked with working out how to use the JBOSS tools to configure these values and have been unable to do so.
I modified the quickstart helloworld example to accept a value using the @Resource annotation and attempted to set this value using jboss-cli.
After several attempts to guess how to do this I modified the servlet to walk down the context tree.
This servlet throws a NameNotFoundException when trying to list the bindings at:
* java:comp/env
* java:app/env
* java:module/env
I have written the servlet to perform this walk in the following contexts:
* Ithe initial context
* java:
* java:jboss
* java:comp
* java:module
* java:app
* java:global
java:global seems to be able to accept values added using jboss-cli (not surprising)
java:comp, java:module and java:app seem to return some of the expected values (eg ModuleName and AppName) but throw the exception when trying to list entries under */env
The initial context and java: seem to display the entries added through jboss-cli
Adding a Deployment descriptor (web.xml), that provides values for these entries, results in no entries that are visible through jboss-cli or any of the contexts listed in the servlet.
I then ran the following command through jboss-cli and restarted the app
/profile=full/subsystem=naming/binding=\/java\:app\/jboss-as-helloworld-ear\/env\/GREETING_TEXT:add(binding-type="simple",value="RE")
This resulted in the same NameNotFoundException being thrown at java:app/env when walking the initial context as has been thrown all along when listing env in java:app
It also resulted in java:app appearing in the java: context but being empty.
Prior to running the add command, java:app did not appear in the initial context or java: context at all.
I then ran the following command through jboss-cli and restarted the app
/profile=full/subsystem=naming/binding=\/java\:module\/jboss-as-helloworld-ear\/jboss-as-helloworld\/env\/GREETING_TEXT:add(binding-type="simple",value="SJM")
This resulted in the same NameNotFoundException being thrown at java:module/env when walking the initial context as has been thrown all along when listing env in java:module
It also resulted in java:module appearing in the java: context but being empty.
Prior to running the add command, java:module did not appear in the initial context or java: context at all.
My conclusion is that my commands in jboss-cli may be the appropriate ones to add the correct entries but that the servlet cannot reach the java:module/env or java:app/env contexts that should be available to it according to the javaEE6 spec.
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5678) Honor the directory grouping by-type for domain server directories
by James Perkins (JIRA)
James Perkins created AS7-5678:
----------------------------------
Summary: Honor the directory grouping by-type for domain server directories
Key: AS7-5678
URL: https://issues.jboss.org/browse/AS7-5678
Project: Application Server 7
Issue Type: Enhancement
Components: Domain Management
Reporter: James Perkins
Assignee: James Perkins
Fix For: 7.2.0.CR1
Currently if one of the directories (jboss.server.log.dir, jboss.server.tmp.dir or jboss.server.data.dir) are overridden the directory grouping is ignored. It would be nicer if the directory grouping was set to {{by-type}} the base directory would be used, but the {{by-type}} configuration would be honored.
{code}
${JBOSS_HOME}/bin/domain.sh -Djboss.server.log.dir=/var/log/
{code}
host.xml
{code}
<host name="master" xmlns="urn:jboss:domain:1.3">
...
<servers directory-grouping="by-type">
<server name="server-one" group="main-server-group">
</server>
<server name="server-two" group="main-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>
<server name="server-three" group="other-server-group" auto-start="false">
<!-- server-three avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
<socket-bindings port-offset="250"/>
</server>
</servers>
</host>
{code}
Should result in a log directory for {{server-one}} of {{/var/log/server-one/logs/}}.
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5677) Split up GlobalOperationHandlers
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-5677:
-------------------------------------
Summary: Split up GlobalOperationHandlers
Key: AS7-5677
URL: https://issues.jboss.org/browse/AS7-5677
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.2.0.Alpha1
Break into multiple classes; get rid of inner classes so it's easier to see what handler is involved when debugging complex ops.
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5675) Restart fails when many bundles deployed
by David Bosschaert (JIRA)
David Bosschaert created AS7-5675:
-------------------------------------
Summary: Restart fails when many bundles deployed
Key: AS7-5675
URL: https://issues.jboss.org/browse/AS7-5675
Project: Application Server 7
Issue Type: Feature Request
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: AS7 master (Oct 3 codebase)
Reporter: David Bosschaert
Assignee: Thomas Diesler
I install a fairly large number of OSGi bundles into AS7 using a script (40+ bundles). The script installs the bundles as follows:
{{jboss-cli.sh -c --command="deploy bundle_x.jar"}}
The installation itself completes without error.
Then I stop AS7 (git ctrl-c) and restart it again. At that point I get an exception:
POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."cxf-bundle-minimal-2.5.4.jar".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "cxf-bundle-minimal-2.5.4.jar"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_35]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_35]
at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_35]
Caused by: java.lang.NullPointerException
at org.jboss.as.jaxrs.deployment.JaxrsScanningProcessor.deploy(JaxrsScanningProcessor.java:106)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
... 5 more
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5676) Failure descriptions don't propagate correctly in recursive or wildcard read-resource-description calls
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-5676:
-------------------------------------
Summary: Failure descriptions don't propagate correctly in recursive or wildcard read-resource-description calls
Key: AS7-5676
URL: https://issues.jboss.org/browse/AS7-5676
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
The response to the first and last operations below is incorrect as the root "failure-description" node is not present:
{code}
[standalone@localhost:9999 /] /subsystem=mail/mail-session=*:read-resource-description
{
"outcome" => "failed",
"result" => [{
"address" => [
("subsystem" => "mail"),
("mail-session" => "*")
],
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: Can't find resource for bundle java.util.PropertyResourceBundle, key mail.mail-session.debug",
"rolled-back" => true
}],
"rolled-back" => true
}
[standalone@localhost:9999 /] cd subsystem=mail
[standalone@localhost:9999 subsystem=mail] :read-children-names(child-type=mail-session)
{
"outcome" => "success",
"result" => ["java:jboss/mail/Default"]
}
[standalone@localhost:9999 subsystem=mail] cd mail-session=java\:jboss\/mail\/Default
[standalone@localhost:9999 mail-session=java:jboss/mail/Default] :read-resource-description
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: Can't find resource for bundle java.util.PropertyResourceBundle, key mail.mail-session.debug",
"rolled-back" => true
}
[standalone@localhost:9999 mail-session=java:jboss/mail/Default]
[standalone@localhost:9999 mail-session=java:jboss/mail/Default] cd /
[standalone@localhost:9999 /] :read-resource-description(recursive=true)
{
"outcome" => "failed",
"rolled-back" => true
}
[standalone@localhost:9999 /]
{code}
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5673) Class Loading and Modules
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-5673?page=com.atlassian.jira.plugin.s... ]
David Lloyd closed AS7-5673.
----------------------------
Questions are to be directed to the user forums; this is a bug tracker.
> Class Loading and Modules
> -------------------------
>
> Key: AS7-5673
> URL: https://issues.jboss.org/browse/AS7-5673
> Project: Application Server 7
> Issue Type: Clarification
> Components: EJB
> Reporter: Bill Rosenberg
> Assignee: jaikiran pai
> Priority: Minor
> Fix For: No Release
>
>
> here is my deployment outline:
> JB7.ear
> --jboss-deployment-structure.xml
> --JB7EJB.jar
> --JB7Web.war
> --JB7Dao.jar
> I have a question regarding AS7 module class loading. I am trying to use the quartz library and setup a module to
> do so. I updated the jboss-deployment-structure.xml to look like this after setting up my quartz module
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
> <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
> <deployment>
> <dependencies>
>
> <module name="org.hibernate" slot="3" />
> <module name="org.quartz" />
>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> when i deploy and run the app a getthis exception:
> Caused by: java.lang.NoClassDefFoundError: org/quartz/SchedulerFactory
> at com.lightspeed.ejb.Session1.hello(Session1.java:22) [JB7EJB.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_13]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_13]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_13]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_13]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> ... 37 more
>
> When i change the jboss-deployment-structure.xml to look like this, it runs fine:
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
> <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
> <deployment>
> <dependencies>
>
> <module name="org.hibernate" slot="3" />
>
>
> </dependencies>
> </deployment>
> <sub-deployment name="JB7EJB.jar">
> <dependencies>
>
> <module name="org.quartz" />
>
> </dependencies>
> </sub-deployment>
> </jboss-deployment-structure>
> I thought that if i put the dependencies under the top 'deployment' section, that all deployments will pick up the quartz module, but i have to add the
> '<sub-deployment name="JB7EJB.jar">' section to have the JB7EJB deloyment pick up the quartz module.
> What am i missing here?
>
> thank you,
>
> Bill
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5673) Class Loading and Modules
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-5673?page=com.atlassian.jira.plugin.s... ]
David Lloyd deleted AS7-5673:
-----------------------------
> Class Loading and Modules
> -------------------------
>
> Key: AS7-5673
> URL: https://issues.jboss.org/browse/AS7-5673
> Project: Application Server 7
> Issue Type: Clarification
> Reporter: Bill Rosenberg
> Assignee: jaikiran pai
> Priority: Minor
>
> here is my deployment outline:
> JB7.ear
> --jboss-deployment-structure.xml
> --JB7EJB.jar
> --JB7Web.war
> --JB7Dao.jar
> I have a question regarding AS7 module class loading. I am trying to use the quartz library and setup a module to
> do so. I updated the jboss-deployment-structure.xml to look like this after setting up my quartz module
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
> <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
> <deployment>
> <dependencies>
>
> <module name="org.hibernate" slot="3" />
> <module name="org.quartz" />
>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> when i deploy and run the app a getthis exception:
> Caused by: java.lang.NoClassDefFoundError: org/quartz/SchedulerFactory
> at com.lightspeed.ejb.Session1.hello(Session1.java:22) [JB7EJB.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_13]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_13]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_13]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_13]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> ... 37 more
>
> When i change the jboss-deployment-structure.xml to look like this, it runs fine:
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
> <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
> <deployment>
> <dependencies>
>
> <module name="org.hibernate" slot="3" />
>
>
> </dependencies>
> </deployment>
> <sub-deployment name="JB7EJB.jar">
> <dependencies>
>
> <module name="org.quartz" />
>
> </dependencies>
> </sub-deployment>
> </jboss-deployment-structure>
> I thought that if i put the dependencies under the top 'deployment' section, that all deployments will pick up the quartz module, but i have to add the
> '<sub-deployment name="JB7EJB.jar">' section to have the JB7EJB deloyment pick up the quartz module.
> What am i missing here?
>
> thank you,
>
> Bill
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5673) Class Loading and Modules
by Bill Rosenberg (JIRA)
Bill Rosenberg created AS7-5673:
-----------------------------------
Summary: Class Loading and Modules
Key: AS7-5673
URL: https://issues.jboss.org/browse/AS7-5673
Project: Application Server 7
Issue Type: Clarification
Components: EJB
Affects Versions: 7.1.1.Final
Reporter: Bill Rosenberg
Assignee: jaikiran pai
Priority: Minor
Fix For: No Release
here is my deployment outline:
JB7.ear
--jboss-deployment-structure.xml
--JB7EJB.jar
--JB7Web.war
--JB7Dao.jar
I have a question regarding AS7 module class loading. I am trying to use the quartz library and setup a module to
do so. I updated the jboss-deployment-structure.xml to look like this after setting up my quartz module
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
<ear-subdeployments-isolated>true</ear-subdeployments-isolated>
<deployment>
<dependencies>
<module name="org.hibernate" slot="3" />
<module name="org.quartz" />
</dependencies>
</deployment>
</jboss-deployment-structure>
when i deploy and run the app a getthis exception:
Caused by: java.lang.NoClassDefFoundError: org/quartz/SchedulerFactory
at com.lightspeed.ejb.Session1.hello(Session1.java:22) [JB7EJB.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_13]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_13]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_13]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_13]
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
... 37 more
When i change the jboss-deployment-structure.xml to look like this, it runs fine:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
<ear-subdeployments-isolated>true</ear-subdeployments-isolated>
<deployment>
<dependencies>
<module name="org.hibernate" slot="3" />
</dependencies>
</deployment>
<sub-deployment name="JB7EJB.jar">
<dependencies>
<module name="org.quartz" />
</dependencies>
</sub-deployment>
</jboss-deployment-structure>
I thought that if i put the dependencies under the top 'deployment' section, that all deployments will pick up the quartz module, but i have to add the
'<sub-deployment name="JB7EJB.jar">' section to have the JB7EJB deloyment pick up the quartz module.
What am i missing here?
thank you,
Bill
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5671) Configuration for default implementation of PasswordStrengthChecker specifies incorrect FQCN
by Kenneth Ljunggren (JIRA)
Kenneth Ljunggren created AS7-5671:
--------------------------------------
Summary: Configuration for default implementation of PasswordStrengthChecker specifies incorrect FQCN
Key: AS7-5671
URL: https://issues.jboss.org/browse/AS7-5671
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.2.0.Alpha1
Environment: Windows 7
java version "1.7.0_06"
Java(TM) SE Runtime Environment (build 1.7.0_06-b24)
Reporter: Kenneth Ljunggren
Assignee: Brian Stansberry
Priority: Trivial
The configuration for the default implementation of PasswordStrengthChecker in property file
jboss-as/domain-management/src/main/resources/org/jboss/as/domain/management/security/password/utility.properties
specifies an icorrect FQCN
# class of password strenght checker. If not present, utility will revert to default implementation
checker=org.jboss.as.domain.management.security.password.simple.Simple
The correct FQCN is
org.jboss.as.domain.management.security.password.simple.SimplePasswordStrengthChecker
Note, the fallback works, but a superfluous exception is thrown which could be avoided.
java.lang.ClassNotFoundException: org.jboss.as.domain.management.security.password.simple.Simple
--
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
11 years, 7 months