[JBoss JIRA] (WFCORE-478) log4j ConsoleAppender won't display messages with per-deployment logging
by Geert Coelmont (JIRA)
[ https://issues.jboss.org/browse/WFCORE-478?page=com.atlassian.jira.plugin... ]
Geert Coelmont commented on WFCORE-478:
---------------------------------------
Working with per-deployment configurable ConsoleAppender is IMHO essential for flexible development.
Suppose my development environment consists of several projects, each deployed to my local Wildfly server, that share a common utility project (deployed as a Jar in each of the applications). Suppose today I'm working on a single one of these projects and in the context of that I want to debug a class Foo from the utility project. I could add Foo to the log4j.properties of my current project and redeploy only this project. I would then see (in my development env. console) logging generated by Foo only from within this one project. Other deployed projects using Foo would not generate logging and thus not clutter my console output.
Currently I'm forced to alter the server's standalone.xml logging section, which impacts all other deployments, causing a lot of output that I don't want to see. This apart from the burden of having to restart the whole server with each change of logging settings.
Not sure what alternatives to ConsoleAppender exist that would allow me to do the same.
> log4j ConsoleAppender won't display messages with per-deployment logging
> ------------------------------------------------------------------------
>
> Key: WFCORE-478
> URL: https://issues.jboss.org/browse/WFCORE-478
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> Add the following log4j.properties file to a deployment and try to log.
> {code}
> # Root logger option
> log4j.rootLogger=INFO, stdout
> # Direct log messages to stdout
> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
> log4j.appender.stdout.Target=System.out
> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
> log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (JGRP-1917) FILE_PING: options to remove zombies
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1917?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1917.
----------------------------
Resolution: Done
Added {{remove_old_coords_on_view_change}} and {{remove_all_files_on_view_change}} to {{FILE_PING}}. See the manual for details.
> FILE_PING: options to remove zombies
> ------------------------------------
>
> Key: JGRP-1917
> URL: https://issues.jboss.org/browse/JGRP-1917
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.3
>
>
> In {{FILE_PING}} and subclasses ({{S3_PING}}, {{GOOGLE_PING}}), coordinators write the files (e.g. {{A.list}} for coord {{A}}).
> There's a shutdown hook that removes {{A.list}} when {{A}} crashes.
> However, when a coordinator is killed by kill -9, the file {{A.list}} won't get removed.
> The problem with this is that new members will read {{A.list}} and get delayed trying to ask {{A}} to join the cluster although {{A}}'s not alive anymore ({{B}} is and created {{B.list}}).
> Possible solution: implement a mechanism similar to JGRP-1915 where a coordinator removes *all files* on a view change with leaving members, and then writes its file again.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-1119:
---------------------------------
{code}
public static final SimpleAttributeDefinition NODE_IDENTIFIER = new SimpleAttributeDefinitionBuilder(CommonAttributes.NODE_IDENTIFIER, ModelType.STRING, true)
.setDefaultValue(new ModelNode().set("1"))
.setFlags(AttributeAccess.Flag.RESTART_ALL_SERVICES)
.setAllowExpression(true)
.setValidator(new StringBytesLengthValidator(0,23,true,true))
.build();
{code}
So it should remove the default value and if the node-identifier is undefined we need to generate a true uuid and persist in the standalone.xml
It looks like the max length for node-name is 24 ?
I will take a look at the way to check attributes of other servers.
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: WFLY-1119
> URL: https://issues.jboss.org/browse/WFLY-1119
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Clebert Suconic
> Assignee: Amos Feng
> Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4399) TransactionSynchronizationRegistry gets not propagated to @Asynchronous EJB
by Thomas Veith (JIRA)
Thomas Veith created WFLY-4399:
----------------------------------
Summary: TransactionSynchronizationRegistry gets not propagated to @Asynchronous EJB
Key: WFLY-4399
URL: https://issues.jboss.org/browse/WFLY-4399
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 8.2.0.Final
Reporter: Thomas Veith
When calling a method of an @Asynchronous EJB (in the same transaction), the TransactionSynchronizationRegistry is not propagated to the asynchronousBean.
e.g. when I store a value in the TransactionSynchronizationRegistry of the caller (registry.putResource()), in the callee it is null.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-3657) JAXWS handlers do not support injection
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3657?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-3657:
-------------------------------------
Assignee: Alessio Soldano (was: Jim Ma)
> JAXWS handlers do not support injection
> ---------------------------------------
>
> Key: WFLY-3657
> URL: https://issues.jboss.org/browse/WFLY-3657
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu 12.04
> JDK 1.8.0_11
> Reporter: Thomas Kriechbaum
> Assignee: Alessio Soldano
> Attachments: jaxws-handler-war.zip, wildfly-test-soapui-project.xml
>
>
> According to the JavaEE spec JAXWS-handlers should support injection (@Inject, @EJB), @PostConstruct and @PreDestroy.
> In my test case (top-down approach, handler class is defined within *_handler.xml) @PostCunstruct works, but managed beans (CDI, EJB) are not injected via @Inject or @EJB.
> Possible workaround for EJBs: manual JNDI-lookup within @PostConstruct method. For CDI-managed beans you have to lookup the BeanManager and load the desired bean yourself.
> It seems, that this issue should have been addressed by WFLY-2362. But it is still does not work.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-2129) @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-2129?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-2129:
-------------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2129
> URL: https://issues.jboss.org/browse/WFLY-2129
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Web Services
> Affects Versions: 8.0.0.Alpha4
> Environment: Mac OS X
> Reporter: Nicky Mølholm
> Assignee: Jim Ma
>
> Using @WebContext on EJB Web service endpoints results in the following two "bugs":
> - Normal EJB security annotations on methods are not honored
> - The EJB container does not get a chance to honor the 'missing-method-permissions-deny-access' element in jboss-ejb3.xml, standalone.xml (etc)
> A simple EJB with a Web service view can illustrate the first problem:
> {code:java}
> @Stateless
> @WebService
> @SecurityDomain("other")
> @org.jboss.ws.api.annotation.WebContext(contextRoot = "/greeterCtx", urlPattern = "/Greeter", authMethod = "BASIC", secureWSDLAccess = false))
> public class Greeter {
> @PermitAll // <-- This doesn't work
> //@RolesAllowed("SECRET_CLIENT_ROLE") // <-- Neither does this!
> // <--- unless you put them on class level
> public String sayHello(String name) {
> System.out.println("******** Greeter.sayHello(" + name + ")");
> return "Hello " + name;
> }
> }
> {code}
> So the problem here is that you are not allowed to invoke the Web Service operation (sayHello). Add to that a completely silent behavior. No stack traces. No trace logging. Nothing.
>
> Now if you take this EJB and remove the @PermitAll (and @RolesAllowed if any) annotation. And if you specify 'false' in jboss-ejb3.xml#missing-method-permissions-deny-access. Then you are not allowed to call the EJB either.
> These are my observations obtained from browsing through the source and playing around with the debugger:
> - When you add the @WebContext(authMethod = "BASIC") annotation on an EJB, you effectively enable authorization logic in addition to authentication logic. This authorization code lives in Web container code (in code from the "jboss web" project). Not in the EJB container - which otherwise is responsible for honoring the @PermitAll,@DenyAll,@RolesAllowed annotations in addition to the 'missing-method-permissions-deny-access' element.
> - This web layer code, silently rejects access to methods exposed through the EJB web service view, if there is no security annotations on the EJB bean class
> You can put @RolesAllowed or @PermitAll on your EJB's web service view methods - but they are never honored by JBoss AS
> -- ...But: if you put these annotations on your bean class, then access is granted as expected
> - You can set 'missing-method-permissions-deny-access' to false (in JBoss AS' profile configuration file or the JBoss AS specific module DD file) - but it is never used by JBoss AS
>
> Proposed solution:
> If the upper Web container layer correctly can propagate the method invocation to the EJB container - then appropriate authorizations check will follow - and ultimately fixing these issues.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-3657) JAXWS handlers do not support injection
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3657?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-3657:
-------------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> JAXWS handlers do not support injection
> ---------------------------------------
>
> Key: WFLY-3657
> URL: https://issues.jboss.org/browse/WFLY-3657
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu 12.04
> JDK 1.8.0_11
> Reporter: Thomas Kriechbaum
> Assignee: Jim Ma
> Attachments: jaxws-handler-war.zip, wildfly-test-soapui-project.xml
>
>
> According to the JavaEE spec JAXWS-handlers should support injection (@Inject, @EJB), @PostConstruct and @PreDestroy.
> In my test case (top-down approach, handler class is defined within *_handler.xml) @PostCunstruct works, but managed beans (CDI, EJB) are not injected via @Inject or @EJB.
> Possible workaround for EJBs: manual JNDI-lookup within @PostConstruct method. For CDI-managed beans you have to lookup the BeanManager and load the desired bean yourself.
> It seems, that this issue should have been addressed by WFLY-2362. But it is still does not work.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-1119:
-------------------------------------
Hi Amos, I think if the setting is "1" we should leave it alone. I think we should only do this if the entry is empty. Perhaps by default we should remove the node-identifier="1" from the standalone.xml so the new behaviour activates by default. Remember we need to make this a true uuid. Take a look at our UID implementation - remember it needs to go in the Xids we create and I think there is a max length for node-name so will need to verify that one of those will fit in before we proceed.
It would be good to be able to verify that no other server has the same node id somehow if that is possible with DMR to check attributes of other servers.
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: WFLY-1119
> URL: https://issues.jboss.org/browse/WFLY-1119
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Clebert Suconic
> Assignee: Amos Feng
> Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4384) ContextService (JSR236): transactional context always suspended
by Tobias Rötschke (JIRA)
[ https://issues.jboss.org/browse/WFLY-4384?page=com.atlassian.jira.plugin.... ]
Tobias Rötschke edited comment on WFLY-4384 at 3/3/15 3:44 AM:
---------------------------------------------------------------
Please let me eloborate on Maxim's question. What we are trying to do, is to execute code in concurrent threads, but within the same transaction. Our guiding example is Gupta's "Java EE 7 Essentials", chapter 10. I understand that invoking the contextual object -- not creating it -- is influenced by the USE_TRANSACTION_OF_EXECUTION_THREAD property value. That results from the beforeProxyMethod() of the TransactionSetupProviderImpl class. However, the code seemingly expects that the thread, where the proxy method is executed in, is already attached to the transaction of the invoking thread.
This turns out not be the case in our setting. As you point out, ManagedExecutorService runs in an internal thread outside a transaction. So we used Executors.newFixedThreadPool() instead as in Gupta's example. We passed the default ManagedThreadFactory to this method. We supplied the contextual object with the TransactionManager injected to the class inside the invoking thread. We verified that the contextual object is invoked directly from the invoking thread. However, TransactionManager.getTransaction() yielded null inside the thread of the contextual object.
Question is: What are we supposed to do in order to attach the thread of the contextual object to the transaction of the invoking thread in the first place so that TransactionSetupProviderImpl.beforeProxy does what it is meant to do? Unfortunately, the javadoc example you cited did not help to explain that to us.
Whether or not this issue is a bug depends on who is responsible for attaching the invoked thread to the transaction of the invoker. In my opinion the JSR-236-implementation is, otherwise USE_TRANSACTION_OF_EXECUTION_THREAD wouldn't make much sense to me. If the application has to take care of it, what is the point of this execution property? We might still be wrong in the way we use that implementation though.
was (Author: tobias.roetschke):
Please let me eloborate on Maxim's question. What we are trying to do, is to execute code in concurrent threads, but within the same transaction. Our guiding example is Gupta's "Java EE 7 Essentials", chapter 10. I understand that invoking the contextual object -- not creating it -- is influenced by the USE_TRANSACTION_OF_EXECUTION_THREAD property value. That results from the beforeProxyMethod() of the TransactionSetupProviderImpl class. However, the code seemingly expects that the thread, where the proxy method is executed in, is already attached to the transaction of the invoking thread.
This turns out not be the case in our setting. As you point out, ManagedExecutorService runs in an internal thread outside a transaction. So we used Executors.newFixedThreadPool() instead as in Gupta's example. We passed the default ManagedThreadFactory to this method. We supplied the contextual object with the TransactionManager injected to the class inside the invoking thread. We verified that the contextual object is invoked directly from the invoking thread. However, TransactionManager.getTransaction() yielded null inside the thread of the contextual object.
Question is: What are we supposed to do in order to attach the thread of the contextual object to the transaction of the invoking thread in the first place so that TransactionSetupProviderImpl.beforeProxy does what it is meant to do? Unfortunately, the javadoc example you cited did not help to explain that to us.
> ContextService (JSR236): transactional context always suspended
> ---------------------------------------------------------------
>
> Key: WFLY-4384
> URL: https://issues.jboss.org/browse/WFLY-4384
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 8.2.0.Final, 9.0.0.Alpha1
> Reporter: Maxim Frolov
> Assignee: Eduardo Martins
> Priority: Critical
>
> According to §3.3.5 of JSR-236 specification:
> ??By using an execution property when creating the contextual proxy object, application components can choose to not suspend the transactional context on the thread ...??
> Given the following EJB and Task:
> {code:java}
> @WebService(serviceName = "Jsr236WebService")
> @Stateless
> public class Jsr236WebService {
> @Inject Jsr236ManagedTask jsr236ManagedTask;
> @Resource ManagedExecutorService executor;
> @Resource ContextService contextService;
>
> @WebMethod(operationName = "hello")
> public String hello(@WebParam(name = "name") String txt) {
> Map<String, String> execProps = new HashMap<>();
> execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD);
> Future<String> future = executor.submit(
> contextService.createContextualProxy(jsr236ManagedTask, execProps, Callable.class));
> try {
> return future.get();
> } catch (InterruptedException | ExecutionException e) {
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> {code:java}
> @Dependent
> @Transactional(Transactional.TxType.MANDATORY)
> public class Jsr236ManagedTask implements Callable<String>, ManagedTask {
> @Override
> public String call() {
> return "called";
> }
> @Override
> public Map<String, String> getExecutionProperties() {
> Map<String, String> execProps = new HashMap<>();
> execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD);
> return execProps;
> }
> }
> {code}
> When the {{call()}} Method of the task is called the following exception occurs:
> {noformat}
> javax.transaction.TransactionalException: ARJUNA016110: Transaction is required for invocation
> {noformat}
> See maven test project [https://github.com/wrungel/bugs/tree/master/jsr236-test] on GitHub.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months