April 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-4417) permissions for security roles are not redefined by jboss-ejb3.xml

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/AS7-4417?page=com.atlassian.jira.plugin.s... ] Stuart Douglas reopened AS7-4417: --------------------------------- Assignee: Stuart Douglas (was: jaikiran pai) Re-opening, as it turns out we do want this behaviour > permissions for security roles are not redefined by jboss-ejb3.xml > ------------------------------------------------------------------ > > Key: AS7-4417 > URL: https://issues.jboss.org/browse/AS7-4417 > Project: Application Server 7 > Issue Type: Bug > Reporter: Radim Hatlapatka > Assignee: Stuart Douglas > Labels: descriptor, security > Fix For: 7.1.2.Final-redhat1 > > > When I have defined permissions using security roles in ejb-jar.xml (ejb-spec) for certain methods and if I define them differently in jboss-ejb3.xml (jboss-spec) the permissions remain as their are defined in ejb-jar.xml. But I would expect that ejb-spec will redefine the permissions (because merging is not possible). > For details see written tests here: https://github.com/rhatlapa/jboss-as/commit/62adba59b288a53672a6b08c8a710... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-3626) EJB's that use constructor injection and do not implement Serializable cannot be serialized

by Stuart Douglas (JIRA)

Stuart Douglas created AS7-3626: ----------------------------------- Summary: EJB's that use constructor injection and do not implement Serializable cannot be serialized Key: AS7-3626 URL: https://issues.jboss.org/browse/AS7-3626 Project: Application Server 7 Issue Type: Bug Components: Clustering, EJB Affects Versions: 7.1.0.CR1b Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2372) Task - User ReceivedTime whenever Claim operation happens

by vijpan (JIRA)

Task - User ReceivedTime whenever Claim operation happens --------------------------------------------------------- Key: JBRULES-2372 URL: https://jira.jboss.org/jira/browse/JBRULES-2372 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-process-task Affects Versions: 5.1.0.M1 Reporter: vijpan Assignee: Mark Proctor Hi, Is there a way possible where "Received Time" can be stored at Task level. This datetime value should get updated with the current timestamp whenever "Claim" operation happens on the Task. The use case is that most of the time if its a 1 potential owner of the task - the task goes through "created/ready/reserved" status whenever a new Task gets created, in this case creation time would be same as received time --- but whenever the task is assigned to group or multiple potential owner or even when it is in reserved status it can be forwarded/delegated to other user/group - then in that case whenever user receives as task or in WSHT tem claim operation happens can we store the timestamp at the task level. Currently at task level we have creation time/activation time/expiration time ---- may be activation time can be used but i guess its use is very specific as detailed in WSHT/BPEL4People spec. In real world scenario it becomes quite important that when the user actually claimed the task or was assigned the task. Vijay -- 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

14 years, 2 months

5
4
0 / 0

[JBoss JIRA] (AS7-4349) Upgrade Java EE specs jars to use valid OSGi bundles

by Paul Gier (JIRA)

Paul Gier created AS7-4349: ------------------------------ Summary: Upgrade Java EE specs jars to use valid OSGi bundles Key: AS7-4349 URL: https://issues.jboss.org/browse/AS7-4349 Project: Application Server 7 Issue Type: Enhancement Components: Build System Reporter: Paul Gier Assignee: Paul Gier Fix For: 7.1.2.Final Some new releases of the Java EE spec apis have been released which fixes some licensing issues and makes the jars into valid OSGi bundles. The sources of these projects has not changed, these are just packaging fixes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
1
0 / 0

[JBoss JIRA] (AS7-2624) Determine Version / Build

by Rich Sharples (Created) (JIRA)

Determine Version / Build -------------------------- Key: AS7-2624 URL: https://issues.jboss.org/browse/AS7-2624 Project: Application Server 7 Issue Type: Enhancement Components: Build System Affects Versions: 7.1.0.Alpha1 Environment: all Reporter: Rich Sharples Assignee: Paul Gier We need a very simple way to determine the version number of AS (and also determine if it's EAP). This shouldn't require starting the server and scanning the log file, or opening jar files and looking for manifest files. Ideally I would be able to get the version / build info. from the command line (scripted) or from a Java program. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

4
4
0 / 0

[JBoss JIRA] (AS7-4672) cache-type can either be default or infinispan

by Philippe Marschall (JIRA)

Philippe Marschall created AS7-4672: --------------------------------------- Summary: cache-type can either be default or infinispan Key: AS7-4672 URL: https://issues.jboss.org/browse/AS7-4672 Project: Application Server 7 Issue Type: Enhancement Components: Build System Affects Versions: 7.1.1.Final Reporter: Philippe Marschall Assignee: Paul Gier Priority: Minor The cache-type attribute of the security-domain configuration can only have two values, "default" or "infinispan" but the XML schema does not reflect this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2749) Various rules stop firing when adding more, totally unrelated rules to a knowledge base

by Ansgar Konermann (JIRA)

Various rules stop firing when adding more, totally unrelated rules to a knowledge base --------------------------------------------------------------------------------------- Key: JBRULES-2749 URL: https://jira.jboss.org/browse/JBRULES-2749 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert), drools-core (expert) Affects Versions: 5.1.1.FINAL Environment: Environment 1: Fedora Core 12 x86_64, Sun JVM 1.6.0_20 64-bit Server VM Environment 2: Windows XP Professional, Service Pack 3, 32 bit; Sun JVM 1.6.0_20 32-bit Server VM Reporter: Ansgar Konermann Assignee: Mark Proctor A certain rule suddenly stops firing when adding more and more rules to the knowledge base, which (not only?) on first sight have *nothing* to do with the rule in question. We created a few unit tests which show the faulty behaviour. What we observed so far: * when using declared functions plus declared data types, this error occurrs. * sometimes, one can work around this problem by renaming a package. We're not sure if this is a reliable workaround, i. e. works in all situations. * one can work around this problem by not using declared functions. We're not sure if this is a reliable workaround. Find attached a ZIPed git repository containing: * a Maven 2.1+ pom.xml suitable to trigger the unit tests via mvn test * Java source files for a TestNG-based unit test * example drools source files to illustrate the problem (used by the unit tests) Please have a look at java file RuleDoesNotFireIfUsingDeclaredFunctionAndTooManyPackages.java. This should make quite clear what we're expecting of the drools library and where it fails to fulfil these expectations. -- 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

14 years, 2 months

5
16
0 / 0

[JBoss JIRA] Created: (JBASPECT-29) Aspects Security Unit Tests

by Anil Saldhana (JIRA)

Aspects Security Unit Tests --------------------------- Key: JBASPECT-29 URL: https://jira.jboss.org/jira/browse/JBASPECT-29 Project: JBoss Aspects Issue Type: Task Components: security Reporter: Anil Saldhana Assignee: Anil Saldhana Since aspects security has been given to me based on merit, I am jittery ever since we moved it out as an external project. The unit tests are in the AS test suite. There is a need to have some unit tests for aspects security such that a change happens in aspects security, other projects (ejb3, profile services etc) do not get affected, due to regression. -- 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

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] (AS7-4669) Upgrade to Picketbox 4.0.9.Final

by Stefan Guilhen (JIRA)

Stefan Guilhen created AS7-4669: ----------------------------------- Summary: Upgrade to Picketbox 4.0.9.Final Key: AS7-4669 URL: https://issues.jboss.org/browse/AS7-4669 Project: Application Server 7 Issue Type: Task Components: Security Affects Versions: 7.1.1.Final Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: 7.1.2.Final-redhat1 PicketBox 4.0.9.Final adds fixes to the JASPI auth modules classloading process. It now checks if a jboss module has been specified and avoids using the TCCL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-4668) jboss-deployment-structure.xml works in "jboss-as-7.1.0.Beta1" for SAR files but not in jboss-as-7.1.1.Finalsa

by Jay SenSharma (JIRA)

Jay SenSharma created AS7-4668: ---------------------------------- Summary: jboss-deployment-structure.xml works in "jboss-as-7.1.0.Beta1" for SAR files but not in jboss-as-7.1.1.Finalsa Key: AS7-4668 URL: https://issues.jboss.org/browse/AS7-4668 Project: Application Server 7 Issue Type: Bug Components: Class Loading Affects Versions: 7.1.1.Final Reporter: Jay SenSharma Assignee: David Lloyd The Attached SAR file works fine in "jboss-as-7.1.0.Beta1" with the help of "jboss-deployment-structure.xml" file, but it fails to deploy in JBoss AS7.1.1.Final with the following exception: 01:37:40,891 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "ServerMonitorServiceWorking.sar" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.module.service.\"deployment.ServerMonitorServiceWorking.sar\".mainjboss.module.spec.service.\"deployment.ServerMonitorServiceWorking.sar.Test.jar\".mainMissing[jboss.module.service.\"deployment.ServerMonitorServiceWorking.sar\".mainjboss.module.spec.service.\"deployment.ServerMonitorServiceWorking.sar.Test.jar\".main]"]} 01:37:40,901 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment ServerMonitorServiceWorking.sar in 10ms 01:37:40,930 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment FormBasedAuth1.war in 39ms 01:37:40,932 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report JBAS014775: New missing/unsatisfied dependencies: service jboss.module.spec.service."deployment.ServerMonitorServiceWorking.sar.Test.jar".main (missing) dependents: [service jboss.module.service."deployment.ServerMonitorServiceWorking.sar".main] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2012