[JBoss JIRA] Commented: (JBAS-2861) HttpSession sharing between WAR modules
by Eugeniusz Neugebauer (JIRA)
[ https://issues.jboss.org/browse/JBAS-2861?page=com.atlassian.jira.plugin.... ]
Eugeniusz Neugebauer commented on JBAS-2861:
--------------------------------------------
I'm to interesting in this improvement.
Is possible to do this in another way ?
regard
ENE
> HttpSession sharing between WAR modules
> ---------------------------------------
>
> Key: JBAS-2861
> URL: https://issues.jboss.org/browse/JBAS-2861
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering, Web (Tomcat) service
> Affects Versions: JBossAS-3.2.6 Final, JBossAS-3.2.7 Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: TBD
>
>
> Creating a redacted version of JBAS-1909, which was opened as a non-public JIRA issue by a customer.
> Our J2EE application is composed of several modules, each one addressing one facet of our business process, and currently this application has one web module (WAR) and several JAR modules (EJB).
> We need to divide this web module into several smaller web modules.
> In order to separate our unique WAR file into several WARs we must guarantee HttpSession sharing. This is due to the fact that we have a lot of session attributes that are used throughout the entire application and we cannot afford to refactor the application, in fact, that's impossible.
> The security aspects for this requirement are completely addressed by the JBoss/Tomcat Single Sign-On mechanism but the session sharing requirements are not.
> The ideal scenario is to keep the same HttpSession (same object in the heap, same session ID) when authenticating into one application (HttpSession created) and then forwarding to another application.
> The current SSO mechanism allows the user to access the second application without reauthentication, as you know, but it creates a new HttpSession object. Also, if the two WARs have different session timeouts, if you access application A, migrates to application B, stays there until session in application A expires and then returns to application A from application B, a new HttpSession is also created in application A.
> The ideal solution is to have one unique, monolithic session to all web applications configured to share a common session. IBM WebSphere and BEA WebLogic do have this configuration and feature. Please check the links below in case you want more information:
> WebSphere Application Server V5: Sharing Session Context - http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0215.ht...
> BEA Weblogic - Enabling Web applications to share the same session - http://e-docs.bea.com/wls/docs90/webapp/sessions.html
--
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: (JGRP-1297) Make generation of addresses pluggable
by Bela Ban (JIRA)
Make generation of addresses pluggable
--------------------------------------
Key: JGRP-1297
URL: https://issues.jboss.org/browse/JGRP-1297
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12
Sometimes it might be desirable to provide custom addresses (classes implementing org.jgroups.Address). One example is an address which contains additional data, e.g. an attribute that's shipped around with the address.
SOLUTION: JChannel provides a setAddressGenerator(AddressGenerator). AddressGenerator has a method generateAddress(), which returns an Address.
One could create a subclass of UUID, for instance, and add a string to it, and then create an instance of this subclass in generateAddress().
--
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] Resolved: (JBAS-8906) Service in START_FAILED state does not transition when mode is changed to REMOVE
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/JBAS-8906?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved JBAS-8906.
------------------------------------
Fix Version/s: 7.0.0.Alpha2
Resolution: Done
Resolved with commits in http://github.com/jbossas/jboss-as/compare/f232102...63046a5
> Service in START_FAILED state does not transition when mode is changed to REMOVE
> --------------------------------------------------------------------------------
>
> Key: JBAS-8906
> URL: https://issues.jboss.org/browse/JBAS-8906
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: David Lloyd
> Assignee: Brian Stansberry
> Fix For: 7.0.0.Alpha2
>
> Attachments: forceNPE.patch, w2.war
>
>
> Here's an example service dump:
> ^C13:22:49,405 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-2) Stopping Coyote HTTP/1.1 on http-8080
> 13:22:49,425 INFO [org.jboss.as.logging] Restored bootstrap log handlers
> 13:22:49,431 INFO [org.hornetq.core.server.impl.HornetQServerImpl] HornetQ Server version 2.1.2.Final (Colmeia, 120) stopped
> ^C
> 13:27:25,270 INFO [stdout] Services for jboss-as:
> 13:27:25,276 INFO [stdout] Service "jboss.as" (class org.jboss.as.server.ApplicationServerService) mode REMOVE state UP (STOP_REQUESTED)
> 13:27:25,276 INFO [stdout] Service "jboss.as.external-module-service" (class org.jboss.as.server.moduleservice.ExternalModuleService) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.as)
> 13:27:25,279 INFO [stdout] Service "jboss.as.server-controller" (class org.jboss.as.server.ServerControllerService) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.as) (dependencies: jboss.as.external-module-service, jboss.as.service-module-loader, jboss.deployment-repository)
> 13:27:25,279 INFO [stdout] Service "jboss.as.service-module-loader" (class org.jboss.as.server.moduleservice.ServiceModuleLoader) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.as)
> 13:27:25,280 INFO [stdout] Service "jboss.deployment.chains" (class org.jboss.as.server.deployment.DeployerChainsService) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.as.server-controller)
> 13:27:25,280 INFO [stdout] Service "jboss.deployment.unit."test3.jar"" (class org.jboss.as.server.deployment.RootDeploymentUnitService) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.as.server-controller) (dependencies: jboss.deployment.chains, jboss.deployment-repository)
> 13:27:25,282 INFO [stdout] Service "jboss.deployment.unit."test3.jar".CONFIGURE_MODULE" (class org.jboss.as.server.deployment.DeploymentUnitPhaseService) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.deployment.unit."test3.jar".DEPENDENCIES) (dependencies: jboss.deployment.chains, jboss.deployment.unit."test3.jar".DEPENDENCIES)
> 13:27:25,283 INFO [stdout] Service "jboss.deployment.unit."test3.jar".DEPENDENCIES" (class org.jboss.as.server.deployment.DeploymentUnitPhaseService) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.deployment.unit."test3.jar".PARSE) (dependencies: jboss.deployment.unit."test3.jar".PARSE, jboss.deployment.chains)
> 13:27:25,283 INFO [stdout] Service "jboss.deployment.unit."test3.jar".INSTALL" (class org.jboss.as.server.deployment.DeploymentUnitPhaseService) mode REMOVE state START_FAILED (parent: jboss.deployment.unit."test3.jar".POST_MODULE) (dependencies: jboss.deployment.unit."test3.jar".POST_MODULE, jboss.deployment.chains) (has failed dependency)
> 13:27:25,284 INFO [stdout] Service "jboss.deployment.unit."test3.jar".PARSE" (class org.jboss.as.server.deployment.DeploymentUnitPhaseService) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.deployment.unit."test3.jar".STRUCTURE) (dependencies: jboss.deployment.unit."test3.jar".STRUCTURE, jboss.deployment.chains)
> 13:27:25,284 INFO [stdout] Service "jboss.deployment.unit."test3.jar".POST_MODULE" (class org.jboss.as.server.deployment.DeploymentUnitPhaseService) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.deployment.unit."test3.jar".CONFIGURE_MODULE) (dependencies: module.service."deployment.test3.jar".main, jboss.deployment.unit."test3.jar".CONFIGURE_MODULE, jboss.deployment.chains)
> 13:27:25,285 INFO [stdout] Service "jboss.deployment.unit."test3.jar".STRUCTURE" (class org.jboss.as.server.deployment.DeploymentUnitPhaseService) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.deployment.unit."test3.jar") (dependencies: jboss.deployment.chains)
> 13:27:25,285 INFO [stdout] Service "jboss.deployment-repository" (class org.jboss.as.server.deployment.impl.ServerDeploymentRepositoryImpl) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.as)
> 13:27:25,285 INFO [stdout] Service "module.service."deployment.test3.jar".main" (class org.jboss.as.server.moduleservice.ModuleLoadService) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.deployment.unit."test3.jar".CONFIGURE_MODULE) (dependencies: jboss.as.service-module-loader, module.spec.service."deployment.test3.jar".main)
> 13:27:25,286 INFO [stdout] Service "module.spec.service."deployment.test3.jar".main" (class org.jboss.msc.service.ValueService) mode REMOVE state UP (STOP_REQUESTED) (parent: jboss.deployment.unit."test3.jar".CONFIGURE_MODULE) (dependencies: jboss.deployment.unit."test3.jar".CONFIGURE_MODULE, jboss.deployment.unit."test3.jar")
> 13:27:25,286 INFO [stdout] 15 services displayed
--
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: (JBMDR-74) scanning-deployers-jboss-beans.xml should ignore MalformedParameterizedTypeException
by Richard Kennard (JIRA)
scanning-deployers-jboss-beans.xml should ignore MalformedParameterizedTypeException
------------------------------------------------------------------------------------
Key: JBMDR-74
URL: https://issues.jboss.org/browse/JBMDR-74
Project: JBoss MetaData Repository
Issue Type: Bug
Components: MetaData
Environment: JBoss AS 6 Final
Reporter: Richard Kennard
Priority: Minor
When deploying my app (which works on JBoss 5.1.0.GA) under JBoss 6 AS Final, the deployment fails citing:
Caused by: java.lang.reflect.MalformedParameterizedTypeException
...non JBoss methods...
at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl$2.run(IntrospectionTypeInfoFactoryImpl.java:230) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl$2.run(IntrospectionTypeInfoFactoryImpl.java:218) [jboss-reflect.jar:2.2.0.GA]
at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_23]
at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getMethods(IntrospectionTypeInfoFactoryImpl.java:217) [jboss-reflect.jar:2.2.0.GA]
It appears this code is already configured (in scanning-deployers-jboss-beans.xml) to ignore a number of such Exceptions, but not MalformedParameterizedTypeException. So I believe this one needs to be added:
<install method="addIgnored">
<parameter>java.lang.reflect.MalformedParameterizedTypeException</parameter>
</install>
Regards,
Richard.
--
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-8839) Initialize-in-order in application.xml not honored
by henk de boer (JIRA)
Initialize-in-order in application.xml not honored
--------------------------------------------------
Key: JBAS-8839
URL: https://issues.jboss.org/browse/JBAS-8839
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployers
Affects Versions: 6.0.0.Final
Environment: Mac OS X 10.6, Ubuntu 10.10
Reporter: henk de boer
Assignee: Ales Justin
The initialize-in-order element in application.xml does not seem to be honored by JBoss AS 6. In an ear application with an EJB and WEB module, reversing the order in which those two modules are listed in application.xml with initialize-in-order set to true does not seem to have any effect.
--
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-8420) Error installing to PostClassLoader, java.lang.VerifyError
by Volker Berlin (JIRA)
Error installing to PostClassLoader, java.lang.VerifyError
----------------------------------------------------------
Key: JBAS-8420
URL: https://jira.jboss.org/browse/JBAS-8420
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading
Affects Versions: 6.0.0.M4
Environment: Vista 32 bit
Reporter: Volker Berlin
Assignee: Scott M Stark
Priority: Critical
With 6.0 M4 a deploying of our application is not possible. It occur the follow error. With 6.0 M1 is has work.
The cause of the problem is that in the war file are multiple jar files with different versions of a utils package. Only one of this package is needed. It seems that the ClassLoader will load all versions of the same package. This produce the problem.
If you need to preload of all classes (also many which never needed) then you should you create only a warning if a single class can not loaded.
16:50:32,828 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfs:///D:/jboss-6.0.0.20100721-M4/server/default/deploy/CrystalClear.war state=ClassLoader mode=Manual requiredState=PostClassLoader: org.jboss.deployers.spi.DeploymentException: Error during deploy: vfs:///D:/jboss-6.0.0.20100721-M4/server/default/deploy/CrystalClear.war
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) [:2.2.0.Alpha6]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:185) [:2.2.0.Alpha6]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.Alpha6]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.Alpha6]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.Alpha6]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.Alpha6]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.Alpha6]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha6]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.20100721-M4]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:130) [:0.1.0.Alpha1]
at org.jboss.profileservice.dependency.ProfileDeployAction.deploy(ProfileDeployAction.java:148) [:0.1.0.Alpha1]
at org.jboss.profileservice.dependency.ProfileDeployAction.installActionInternal(ProfileDeployAction.java:94) [:0.1.0.Alpha1]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.profileservice.dependency.ProfileServiceController.activate(ProfileServiceController.java:188) [:0.1.0.Alpha1]
at org.jboss.profileservice.AbstractProfileService.activateProfile(AbstractProfileService.java:170) [:0.1.0.Alpha1]
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.activate(AbstractProfileServiceBootstrap.java:117) [:0.1.0.Alpha1]
at org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolverFacade.deploy(BasicResolverFactory.java:89) [:0.1.0.Alpha1]
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.start(AbstractProfileServiceBootstrap.java:97) [:0.1.0.Alpha1]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:130) [:6.0.0.20100721-M4]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:56) [:6.0.0.20100721-M4]
at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at java.lang.Thread.run(Unknown Source) [:1.6.0_21-ea]
Caused by: java.lang.Error: Error visiting "/D:/jboss-6.0.0.20100721-M4/server/default/deploy/CrystalClear.war/WEB-INF/lib/Syto.jar/com/inet/pool/Pool3Factory.class"
at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:268) [jboss-classloading-vfs.jar:2.2.0.Alpha7]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:407) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:395) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:102) [jboss-classloading-vfs.jar:2.2.0.Alpha7]
at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.visit(VFSDeploymentClassLoaderPolicyModule.java:181) [:2.2.0.Alpha6]
at org.jboss.scanning.plugins.DeploymentUnitScanner.scan(DeploymentUnitScanner.java:111) [:1.0.0.Alpha5]
at org.jboss.scanning.spi.helpers.UrlScanner.scan(UrlScanner.java:96) [:1.0.0.Alpha5]
at org.jboss.scanning.deployers.ScanningDeployer.deploy(ScanningDeployer.java:90) [:1.0.0.Alpha5]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha6]
... 41 more
Caused by: java.lang.RuntimeException: Error visiting resource: org.jboss.classloading.plugins.vfs.VFSResourceContext@14fea9a, visitor: org.jboss.scanning.annotations.plugins.GenericAnnotationVisitor@17153a4
at org.jboss.scanning.plugins.visitor.IgnoreSetErrorHandler.handleError(IgnoreSetErrorHandler.java:57) [:1.0.0.Alpha5]
at org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.visit(ReflectResourceVisitor.java:91) [:1.0.0.Alpha5]
at org.jboss.scanning.annotations.plugins.AnnotationsScanningPlugin.visit(AnnotationsScanningPlugin.java:89) [:1.0.0.Alpha5]
at org.jboss.scanning.spi.helpers.ScanningPluginWrapper.visit(ScanningPluginWrapper.java:112) [:1.0.0.Alpha5]
at org.jboss.classloading.plugins.visitor.FederatedResourceVisitor.visit(FederatedResourceVisitor.java:101) [jboss-classloading.jar:2.2.0.Alpha7]
at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:264) [jboss-classloading-vfs.jar:2.2.0.Alpha7]
... 52 more
Caused by: java.lang.VerifyError: (class: com/inet/pool/Pool3Factory, method: createPConnection signature: (Ljava/sql/Connection;Lcom/inet/pool/b;Ljava/lang/String;)Lcom/inet/pool/x;) Wrong return type in function
at java.lang.Class.getDeclaredConstructors0(Native Method) [:1.6.0_21-ea]
at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) [:1.6.0_21-ea]
at java.lang.Class.getDeclaredConstructors(Unknown Source) [:1.6.0_21-ea]
at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getDeclaredConstructors(IntrospectionTypeInfoFactoryImpl.java:559) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getConstructors(IntrospectionTypeInfoFactoryImpl.java:158) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.reflect.plugins.ClassInfoImpl.getDeclaredConstructors(ClassInfoImpl.java:446) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.scanning.plugins.visitor.ClassHierarchyResourceVisitor.handleClass(ClassHierarchyResourceVisitor.java:79) [:1.0.0.Alpha5]
at org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.doVisit(ReflectResourceVisitor.java:108) [:1.0.0.Alpha5]
at org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.visit(ReflectResourceVisitor.java:86) [:1.0.0.Alpha5]
... 56 more
--
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-6843) Metadata not created for deployments listed through Classpath attribute of Manifest.MF files
by jaikiran pai (JIRA)
Metadata not created for deployments listed through Classpath attribute of Manifest.MF files
--------------------------------------------------------------------------------------------
Key: JBAS-6843
URL: https://jira.jboss.org/jira/browse/JBAS-6843
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployers
Affects Versions: JBossAS-5.1.0.CR1, JBossAS-5.1.0.Beta1
Reporter: jaikiran pai
Assignee: Ales Justin
If a (EJB) *deployment* jar contains a MANIFEST.MF which points to another *deployment* (not a plain jar) through the ClassPath attribute, then the deployment framework does not generate metadata for the deployment listed in MANIFEST.MF
Ex: A.jar is an EJB3 deployment which contains a MANIFEST.MF pointing to B.jar (another EJB3 deployment). While processing A.jar (and its entries in MANIFEST.MF), the deployment framework does not generate metadata for B.jar
As per EJB3.0 core spec, section 20.3:
The ejb-jar file must contain, either by inclusion or by reference, the class files of each enterprise bean as follows:
- The enterprise bean class.
- The enterprise bean business interfaces, web service endpoint interfaces, and home and component interfaces.
- Interceptor classes.
- The primary key class if the bean is an entity bean.
We say that a jar file contains a second file "by reference" if the second file is named in the Class-Path attribute in the Manifest file of the referencing jar file or is contained (either by inclusion or by reference) in another jar file that is named in the Class-Path attribute in the Manifest file of the referencing jar file.
--
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