[JBoss JIRA] (ELY-577) Enhance FastUnsupportedCallbackException toString()
by David Lloyd (JIRA)
David Lloyd created ELY-577:
-------------------------------
Summary: Enhance FastUnsupportedCallbackException toString()
Key: ELY-577
URL: https://issues.jboss.org/browse/ELY-577
Project: WildFly Elytron
Issue Type: Feature Request
Components: Callbacks
Reporter: David Lloyd
Assignee: David Lloyd
Priority: Trivial
Fix For: 1.1.0.Beta7
Enhance toString() so the user can view what callback was not supported.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGMGR-139) Add maxBackupIndex to periodic-rotating-file-handlers
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-139?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-139:
--------------------------------------
This is a rather complicated problem to solve. Since the suffix can be set to nearly any supported by {{java.text.SimpleDateFormat}} it makes it very difficult to parse file names to determine which files would be available for purging. There are some things that could be done to make some assumptions about file names, but having a log manager make assumptions about files on a file system seems wrong. You wouldn't want your log manage to delete files it shouldn't be deleting because it made an assumption about a file name.
One option besides a custom handler is to use tools on the OS, like a cron job on Linux, to purge older files.
As far as not getting your custom handler to work I'm guessing you mean on WildFly or JBoss EAP. What seems to be the issue there?
> Add maxBackupIndex to periodic-rotating-file-handlers
> -----------------------------------------------------
>
> Key: LOGMGR-139
> URL: https://issues.jboss.org/browse/LOGMGR-139
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Reporter: Rémy Garrigue
> Priority: Minor
>
> That's all in the title.
> We would like to have a daily log, keeping 15 days of log. Actually there's no way to do that except maybe custom handler which we can't get to work. That'ld be far easier if there was the same maxBackupIndex option as in size rotating handler.
> Regards,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGMGR-139) Add maxBackupIndex to periodic-rotating-file-handlers
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-139?page=com.atlassian.jira.plugin... ]
James Perkins moved JBLOGGING-122 to LOGMGR-139:
------------------------------------------------
Project: JBoss Log Manager (was: JBoss Logging)
Key: LOGMGR-139 (was: JBLOGGING-122)
> Add maxBackupIndex to periodic-rotating-file-handlers
> -----------------------------------------------------
>
> Key: LOGMGR-139
> URL: https://issues.jboss.org/browse/LOGMGR-139
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Reporter: Rémy Garrigue
> Assignee: James Perkins
> Priority: Minor
>
> That's all in the title.
> We would like to have a daily log, keeping 15 days of log. Actually there's no way to do that except maybe custom handler which we can't get to work. That'ld be far easier if there was the same maxBackupIndex option as in size rotating handler.
> Regards,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1599) Completion for List of complex types
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-1599:
--------------------------------------------
Summary: Completion for List of complex types
Key: WFCORE-1599
URL: https://issues.jboss.org/browse/WFCORE-1599
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
ValueTypeCompleter doesn't support List, the current behaviour s not the expected one. Fo example:
1) When an empty list of complex types in completed, all properties of the complex types are candidates for an empty list. For example:
content=[ <TAB> ==> gives you the list of the fields contained in the complex type the only 2 candidates should be: '{' and ']'
2) No more completion when a second instance is typed content=[{url=toto},{>TAB> ==> has 0 candidates.
The new "exploded deployment" add-content operation requires the completion of List of complex type to work.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6636) WELD-001408: Unsatisfied dependencies on hot deploy of app using module-alias as dependency
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6636?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6636:
-----------------------------------------------
Vlado Pakan <vpakan(a)redhat.com> changed the Status of [bug 1338093|https://bugzilla.redhat.com/show_bug.cgi?id=1338093] from ASSIGNED to POST
> WELD-001408: Unsatisfied dependencies on hot deploy of app using module-alias as dependency
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-6636
> URL: https://issues.jboss.org/browse/WFLY-6636
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Tomas Hofman
> Attachments: test.ear
>
>
> If a sub deployment uses another sub deployment's module-alias as a dependency, it will deploy successfully, but if hot deployed, it will fail with the error below. Attached reproducer.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
> <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
> <sub-deployment name="ejb1.jar">
> <module-alias name="deployment.ejb1"/>
> </sub-deployment>
> <sub-deployment name="ejb2.jar">
> <dependencies>
> <!-- works
> <module name="deployment.test.ear.ejb1.jar" slot="main"/>
> -->
> <!-- fails with WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default on redeploy / hot deploy -->
> <module name="deployment.ejb1" slot="main"/>
> </dependencies>
> </sub-deployment>
> </jboss-deployment-structure>
> {code}
> {code}
> 10:43:42,140 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."test.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private test.TestEJB2.test1
> at test.TestEJB2.test1(TestEJB2.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 10:43:42,144 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.ear\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private test.TestEJB2.test1
> at test.TestEJB2.test1(TestEJB2.java:0)
> "}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6731) Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6731?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-6731:
--------------------------------------
Bruno, could you reproduce on WildFly master (or nightly build)?
> Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6731
> URL: https://issues.jboss.org/browse/WFLY-6731
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> {noformat}
> ay0uwkDSnTKoZNLMN9atwQhHB4KiZ url:/autenticacaosso/login.jsf;jsessionid=vrQfTnf0X0ZbbWAOEHUd-BXtb8Oa1TsfMjfqhh1C.node3
> 2016-04-08 08:41:14,766 ERROR [io.undertow.request] (default task-137) UT005023: Exception handling request to /autenticacaosso/login: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.changeSessionId(DistributableSession.java:197)
> at io.undertow.servlet.spec.HttpServletRequestImpl.changeSessionId(HttpServletRequestImpl.java:329)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler$SecurityNotificationReceiver.handleNotification(CachedAuthenticatedSessionHandler.java:95)
> at io.undertow.security.impl.AbstractSecurityContext.sendNoticiation(AbstractSecurityContext.java:127)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:85)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:78)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:103)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:257)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$2(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:123)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:98)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:91)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6402:
-----------------------------------------------
Fedor Gavrilov <fgavrilo(a)redhat.com> changed the Status of [bug 1310908|https://bugzilla.redhat.com/show_bug.cgi?id=1310908] from POST to ON_QA
> EJBs accessible too early (spec violation)
> ------------------------------------------
>
> Key: WFLY-6402
> URL: https://issues.jboss.org/browse/WFLY-6402
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Fedor Gavrilov
> Labels: downstream_dependency
> Attachments: auto-test-reproducer.zip
>
>
> {code}
> EJB 3.1 spec, section 4.8.1:
> "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application.
> {code}
> Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6680) :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6680:
---------------------------------
Fix Version/s: 10.1.0.Final
> :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6680
> URL: https://issues.jboss.org/browse/WFLY-6680
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: RHEL 6, EAP 6.1.0, mod_cluster-1.2.4-1.Final_redhat_1.ep6.el6.noarch,
> Reporter: Kristina Clair
> Assignee: Radoslav Husar
> Fix For: 10.1.0.Final
>
>
> When the modcluster subsystem is unable to connect to a proxy, the jboss-cli commands :read-proxies-configuration and :read-proxies-info fail with an unhelpful error.
> On both the domain controller and application host, :read-proxies-info and :read-proxies-configuration fail with the same error. This is the output from the application host:
> {noformat}
> [domain@localhost:9999 subsystem=modcluster] pwd
> /host=localhost/server=cluster2/subsystem=modcluster
> [domain@localhost:9999 subsystem=modcluster] :list-proxies
> {
> "outcome" => "success",
> "result" => [
> "web02:8009",
> "web01:8009"
> ]
> }
> [domain@localhost:9999 subsystem=modcluster] :read-proxies-configuration
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
> "rolled-back" => true
> }
> [domain@localhost:9999 subsystem=modcluster] :read-proxies-info
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
> "rolled-back" => true
> }
> {noformat}
> In the above example, modcluster was not able to connect to the proxies due to an ssl misconfiguration in the modcluster subsystem in domain.xml.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years