[JBoss JIRA] (AS7-1769) PU Injection across JARs (separate DeploymentUnits)
by John Franey (JIRA)
[ https://issues.jboss.org/browse/AS7-1769?page=com.atlassian.jira.plugin.s... ]
John Franey commented on AS7-1769:
----------------------------------
{quote}
John, are you saying that you would package all artifacts in one (EAR) deployment? I think that is what users currently do today.
{quote}
No. The myModel.jar would be predeployed (as module or deployment) separately from the applications that depend on it.
Applications (ear, war or deployable jars) would declare their dependency on 'external' myModel in the usual as7 way.
Each application has its own private persistence unit, named the same but not necessarily. The persistence classes and the orm are in the shared deployment/module, not the persistence unit.
> PU Injection across JARs (separate DeploymentUnits)
> ---------------------------------------------------
>
> Key: AS7-1769
> URL: https://issues.jboss.org/browse/AS7-1769
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 7.0.1.Final, 7.1.0.Final, 7.1.1.Final
> Environment: Linux, Window, MacOS, *BSD
> Reporter: Nikos Ballas
> Labels: new_and_noteworthy
>
> the following architecture of jars/wars doesn't load correctly in JBossAS 7 but it was used to load perfectly in all previous versions...i know about the new loading way so i am explaining the scenario:
>
> myjar-model.jar : Contains entities and the persistence.xml which defines also a persistence unit inside the META-INF folder.
> myjar-buisness.jar: Contains EJB's and Spring beans that uses the model.There is an annotation with @PersistenceContext(name="mypu") on this EJB's for the entity manager to work. The jboss-deployment-structure.xml has declared dependency in the deployment.mcube-model.jar.
> I am copying both of these files first the model and then the buisness in the standalone profile in deployments folder.The first one is loaded successfully.The second one that also uses classes from the previous one can see the classes but not the pu need it for the db operations.The exception follows:
> [code]
> 10:33:49,369 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."myjar-buisness.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."mcube-buisness.jar".INSTALL: Failed to process phase INSTALL of deployment "myjar-buisness.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Component class ***.**.GenericDAOImpl for component MyBean has errors:
> Can't find a deployment unit named myjar-persistence at deployment "myjar-buisness.jar"
> at org.jboss.as.ee.component.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:133)
> at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:52)
> at org.jboss.as.ee.component.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:129)
> at org.jboss.as.ee.component.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:122)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> ... 5 more
> [/code]
> Following scenario/arcs:
> Web application which is assembled by 4 different jars/wars:
> (1)myapp-model.jar -> contains the model + persistence.xml containing the definition of a CMT.
> (2)myapp-buisness.jar -> contains buisness EJB3's Spring Beans, whatever you can think of.
> (3)myapp-messaging.jar -> Contains MDB's for sending messages to several queues.
> (4)myapp-console.war -> Contains the web interface of the app.
> Now the -> define a dependency from a project to another to function,i.e. A->B means that A project has a dependency in B. Now the graph of dependencies between projects are:
> (4)->(2)->(1).
> Currently in jboss as 7 you are able to deploy your application either as module exposing several services(even though there is no clear documentation on how you do that.You follow the old way, you have to do something else?Nowhere in any documentation isn't that documented.) or you can use the deployments folder and copy everything there.Given the previous scenario if we deploy the module(2) then even if we have as dependency in the jboss-deployment-structure.xml the reference to the module(1) then we will get an exception saying that the persistence unit defined isn't accessible or undefined for the module(2). Now with the new version of jboss that allow us to manipulate the dependencies using the module mechanism and the well defined deployment and dependencies between projects it would be really useful if.
> When we define a dependency from one module to another, in my example from (2)->(1), also the mcs services defined are also exported in the target deployment, thus allowing access to the pu with the name for example is deployed. I don't know if this can be applied for the module architecture also.
> regards
> Nick
--
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, 1 month
[JBoss JIRA] (AS7-6734) @RunAs/@RunAsPrincipal are ignored for @Startup/@Singleton bean
by Derek Horton (JIRA)
[ https://issues.jboss.org/browse/AS7-6734?page=com.atlassian.jira.plugin.s... ]
Derek Horton updated AS7-6734:
------------------------------
Affects Version/s: 7.1.3.Final (EAP)
> @RunAs/@RunAsPrincipal are ignored for @Startup/@Singleton bean
> ---------------------------------------------------------------
>
> Key: AS7-6734
> URL: https://issues.jboss.org/browse/AS7-6734
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Derek Horton
>
> The @RunAs/@RunAsPrincipal annotations get ignored when used on a singleton
> bean that is annotated with @Startup. This means the the singleton bean
> is not able to call protected EJBs.
> If the protected EJB is annotated with @PermitAll, then the
> singleton is able to invoke the method because the
> AuthorizationInterceptor create an "anonymous" user that is treated as
> authenticated. However, the @RunAsPrincipal is ignored as the
> getCallerPrincipal() returns anonymous instead of the @RunAsPrincipal.
> I dug around in the code and it looks like the @RunAs/@RunAsPrincipal
> annotations are getting handled correctly during deployment:
> Step completed: "thread=MSC service thread 1-3", org.jboss.as.ejb3.deployment.processors.merging.RunAsMergingProcessor.handleDeploymentDescriptor(), line=126 bci=249
> MSC service thread 1-3[1] print componentConfiguration.getRunAs()
> componentConfiguration.getRunAs() = "JBossAdmin"
> MSC service thread 1-3[1] print componentConfiguration.getRunAsPrincipal()
> componentConfiguration.getRunAsPrincipal() = "fred"
> However, by the time the SecurityContextInterceptor is called, the
> runAs/runAsPrincipal settings are null.
--
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, 1 month
[JBoss JIRA] (AS7-6734) @RunAs/@RunAsPrincipal are ignored for @Startup/@Singleton bean
by Derek Horton (JIRA)
[ https://issues.jboss.org/browse/AS7-6734?page=com.atlassian.jira.plugin.s... ]
Derek Horton moved EJBTHREE-2297 to AS7-6734:
---------------------------------------------
Project: Application Server 7 (was: EJB 3.0)
Key: AS7-6734 (was: EJBTHREE-2297)
Workflow: GIT Pull Request workflow (was: jira)
Component/s: EJB
(was: ejb3)
> @RunAs/@RunAsPrincipal are ignored for @Startup/@Singleton bean
> ---------------------------------------------------------------
>
> Key: AS7-6734
> URL: https://issues.jboss.org/browse/AS7-6734
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Reporter: Derek Horton
>
> The @RunAs/@RunAsPrincipal annotations get ignored when used on a singleton
> bean that is annotated with @Startup. This means the the singleton bean
> is not able to call protected EJBs.
> If the protected EJB is annotated with @PermitAll, then the
> singleton is able to invoke the method because the
> AuthorizationInterceptor create an "anonymous" user that is treated as
> authenticated. However, the @RunAsPrincipal is ignored as the
> getCallerPrincipal() returns anonymous instead of the @RunAsPrincipal.
> I dug around in the code and it looks like the @RunAs/@RunAsPrincipal
> annotations are getting handled correctly during deployment:
> Step completed: "thread=MSC service thread 1-3", org.jboss.as.ejb3.deployment.processors.merging.RunAsMergingProcessor.handleDeploymentDescriptor(), line=126 bci=249
> MSC service thread 1-3[1] print componentConfiguration.getRunAs()
> componentConfiguration.getRunAs() = "JBossAdmin"
> MSC service thread 1-3[1] print componentConfiguration.getRunAsPrincipal()
> componentConfiguration.getRunAsPrincipal() = "fred"
> However, by the time the SecurityContextInterceptor is called, the
> runAs/runAsPrincipal settings are null.
--
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, 1 month
[JBoss JIRA] (JGRP-1585) Upgrade log4j
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JGRP-1585?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on JGRP-1585:
-----------------------------------
We support all of those, except for #6 (though I am pretty sure we can add that). (Also - log4j2 seriously doesn't support runtime level changes? Yikes...)
Actually #5 is actually a "so-so" kind of thing. To support the i18n stuff we're supposed to support, you do need one additional compile-time-only JAR, but it uses Javac's built-in and standard annotation processing mechanism, so it works fine even if you just run javac on the command line. If you do not use the i18n mechanism though, that part is completely optional. But beyond that, it's just one JAR at runtime (plus the backend of choice, if it != JUL).
> Upgrade log4j
> -------------
>
> Key: JGRP-1585
> URL: https://issues.jboss.org/browse/JGRP-1585
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> log4j has some heavy synchronization, which can sometimes lead to code blocking up to 30 seconds (see [1]).
> Investigate whether we should switch to log42 [2]. Perhaps we can simply program against the API (30K) and not even ship the implementation ?
> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51047
> [2] http://logging.apache.org/log4j/2.x/
--
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, 1 month
[JBoss JIRA] (JGRP-1585) Upgrade log4j
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1585?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1585 at 3/14/13 2:15 PM:
---------------------------------------------------------
Hi David,
here are my requirements:
# Add vararg log methods to Log [1], e.g. trace(String format, Object... params);
# Replace log4j, possible candidates so far:
## log4j2
## jboss-logging
# I currently support JUL and log4j as backends, and these need to be supported. If more backends can be supported, even better
# Minimize the number of JARs to be used
# No pre-processing phase (mvn or ant)
# Ability to change the log level at runtime. This is an issue for me with log4j2, which doesn't support this anymore. It's not enough to be able to periodically reparse the config file, as I want to do this across a cluster, via probe.sh op=UDP.setLevel["trace"]
## Derived from above: extensibility. I might want to extend a logging impl to provide this feature. Or users might ant to provide their own logging frameworks.
If you tell me that I need only 1 JAR (plus the backend, but that's up to the deployer), than that sounds appealing. I looked at jboss-logging on GitHub, but am unsure which project I should use there. Do you have documentation on jboss-logging ? I googled, but I think I hit old documentation...
[1] https://github.com/belaban/JGroups/tree/master/src/org/jgroups/logging
[2] https://github.com/jboss-logging
was (Author: belaban):
Hi David,
here are my requirements:
# Add vararg log methods to Log [1], e.g. trace(String format, Object... params);
# Replace log4j, possible candidates so far:
## log4j2
## jboss-logging
# I currently support JUL and log4j as backends, and these need to be supported. If more backends can be supported, even better
# Minimize the number of JARs to be used
# No pre-processing phase (mvn or ant)
# Ability to change the log level at runtime. This is an issue for log4j2, which doesn't support this anymore. It's not enough to be able to periodically reparse the config file, as I want to do this across a cluster, via probe.sh op=UDP.setLevel["trace"]
If you tell me that I need only 1 JAR (plus the backend, but that's up to the deployer), than that sounds appealing. I looked at jboss-logging on GitHub, but am unsure which project I should use there. Do you have documentation on jboss-logging ? I googled, but I think I hit old documentation...
[1] https://github.com/belaban/JGroups/tree/master/src/org/jgroups/logging
[2] https://github.com/jboss-logging
> Upgrade log4j
> -------------
>
> Key: JGRP-1585
> URL: https://issues.jboss.org/browse/JGRP-1585
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> log4j has some heavy synchronization, which can sometimes lead to code blocking up to 30 seconds (see [1]).
> Investigate whether we should switch to log42 [2]. Perhaps we can simply program against the API (30K) and not even ship the implementation ?
> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51047
> [2] http://logging.apache.org/log4j/2.x/
--
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, 1 month
[JBoss JIRA] (JGRP-1585) Upgrade log4j
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1585?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1585:
--------------------------------
Hi David,
here are my requirements:
# Add vararg log methods to Log [1], e.g. trace(String format, Object... params);
# Replace log4j, possible candidates so far:
## log4j2
## jboss-logging
# I currently support JUL and log4j as backends, and these need to be supported. If more backends can be supported, even better
# Minimize the number of JARs to be used
# No pre-processing phase (mvn or ant)
# Ability to change the log level at runtime. This is an issue for log4j2, which doesn't support this anymore. It's not enough to be able to periodically reparse the config file, as I want to do this across a cluster, via probe.sh op=UDP.setLevel["trace"]
If you tell me that I need only 1 JAR (plus the backend, but that's up to the deployer), than that sounds appealing. I looked at jboss-logging on GitHub, but am unsure which project I should use there. Do you have documentation on jboss-logging ? I googled, but I think I hit old documentation...
[1] https://github.com/belaban/JGroups/tree/master/src/org/jgroups/logging
[2] https://github.com/jboss-logging
> Upgrade log4j
> -------------
>
> Key: JGRP-1585
> URL: https://issues.jboss.org/browse/JGRP-1585
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> log4j has some heavy synchronization, which can sometimes lead to code blocking up to 30 seconds (see [1]).
> Investigate whether we should switch to log42 [2]. Perhaps we can simply program against the API (30K) and not even ship the implementation ?
> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51047
> [2] http://logging.apache.org/log4j/2.x/
--
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, 1 month