[JBoss JIRA] (DROOLS-2178) [DMN Editor] Simplify Expression Editors GridData implementation
by Michael Anstis (JIRA)
Michael Anstis created DROOLS-2178:
--------------------------------------
Summary: [DMN Editor] Simplify Expression Editors GridData implementation
Key: DROOLS-2178
URL: https://issues.jboss.org/browse/DROOLS-2178
Project: Drools
Issue Type: Task
Components: DMN Editor
Reporter: Michael Anstis
Assignee: Michael Anstis
Different Expression Editors implement their own {{GridData}} models to intercept mutations and defer the same to Commands. There are a number of different implementations and they could all be simplified to use a shared base class.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9610) Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
by Serg Pol (JIRA)
[ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.... ]
Serg Pol commented on WFLY-9610:
--------------------------------
Batch Jobs have just values for BATCHSTATUS = "STARTING" (no Status STARTED. i could not reproduce STATUS "STARTING" local) and CREATETIME in this case-issue.
Thread pool has max number of threads 10 (<max-threads count="10"/>)
In what case BATCHSTATUS can be left just "STARTING"? If there were no enough threads?
Thanks
> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9610
> URL: https://issues.jboss.org/browse/WFLY-9610
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 9.0.1.Final
> Environment: Cluster, standalone-full-ha
> Reporter: Serg Pol
> Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob).
> There are no any error nessages.
> BatchJob is not started in this case according Log.
> Any idea? Thanks
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-283 at 12/14/17 5:28 AM:
----------------------------------------------------------
Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...
{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/-1696122173
c/r/s = 0/13/0
{code}
{code}
major = d0000 = 0 / 13 / 0
Calling Error = 0
Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
Supplementary Status Bits = 0
minor = -1696122173 (signed dec) = 2598845123 (unsigned dec) = 9AE73AC3 (hex)
{code}
*Update:* the error above occure when ccache does not exists - to resolve, run *kinit* and sign in as any unrelated user - even from unrelated kerberos realm - when the ccache exists, *remote/localhost(a)JBOSS.ORG* credential is obtained correctly too. (After kdestroy the error above will return.)
*Update:* from discussion with Simo Sorce (gssproxy dev) results this is *bug of gssproxy*. For our purpose workaround by creating ccache using unrelated *kinit* is sufficient - we dont need to wait for fix for wildfly development (but it can be important for production).
was (Author: honza889):
Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...
{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/-1696122173
c/r/s = 0/13/0
{code}
{code}
major = d0000 = 0 / 13 / 0
Calling Error = 0
Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
Supplementary Status Bits = 0
minor = -1696122173 (signed dec) = 2598845123 (unsigned dec) = 9AE73AC3 (hex)
{code}
*Update:* the error above occure when ccache does not exists - to resolve, run *kinit* and sign in as any unrelated user - even from unrelated kerberos realm - when the ccache exists, *remote/localhost(a)JBOSS.ORG* credential is obtained correctly too. (After kdestroy the error above will return.)
> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
> Key: ELY-283
> URL: https://issues.jboss.org/browse/ELY-283
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Peter Skopek
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months