[JBoss AS 7 Development] - AS8: JBoss Security Manager discussion
by Anil Saldhana
Anil Saldhana [https://community.jboss.org/people/anil.saldhana] modified the document:
"AS8: JBoss Security Manager discussion"
To view the document, visit: https://community.jboss.org/docs/DOC-48383
--------------------------------------------------------------
David M Lloyd, Stefan, Flavia and I had a high level discussion on supporting Java Security Manager in AS8 in line with the needs of EE7 and JBoss Modules.
*JIRA*: https://issues.jboss.org/browse/AS7-6572 https://issues.jboss.org/browse/AS7-6572
*Internal reference*: http://etherpad.corp.redhat.com/FaKiGVezLI http://etherpad.corp.redhat.com/FaKiGVezLI
We had an etherpad discussion.
h2. Etherpad
*Requirements*
(Let us capture general requirements here)
* Support for VMwide Security Manager policy?
* Support META-INF/permissions.xml required by EE7 for web, ejb and application clients
>From DML:
* Support EE 7 Security Manager requirements
* Maintain relationships established by JACC specification for Run As vs. AccessControlContext
* Application components must be able to support at least the permissions listed in Table EE.6-2 in EE(7).6.2.2.3.
* Deployers must support application component permissions as specified by EE.6.2.2.6.
* Server administrators must have a way of declaring permission restrictions for deployments. If a deployment with declared permissions does not meet the configured permission set, the deployment must fail as per EE.6.2.2.6.
* Perform well
* Ideally we will be able to use a more efficient mechanism to evaluate permissions than a complete execution stack scan. The JDK always grants itself all permissions - by checking the class loader for null - and generally acts as if doPrivileged is always in force. Perhaps we can utilize a similar trick to allow our provided modules to execute quickly.
*
*Discussion Points*
* Should we do permissions within module.xml? (https://issues.jboss.org/browse/MODULES-157) (https://issues.jboss.org/browse/MODULES-157%29)
*Action Items*
1. Deployment Descriptor parsing for META-INF/permissions.xml
2. Domain.xml/Standalone.xml global permission block (parsing and handling)
3. JBoss Modules permission handling (parsing and handling)
4. System to merge deployment permissions into the module defined permissions.
*Questions*
* Should permissions.xml for Web Deployments be in WEB-INF and not META-INF? JSR342 draft seems to imply they will be in META-INF (+Answer: permissions.xml is a SE requirement for the EE platform. So it is META-INF+)
*
h2.
h2. Chat Discussion
h2. February 20, 2013
Anil Saldhana: Just want to have a general chat on this topic...
12:19 Anil Saldhana: Important for Stefan to participate.
12:19 Anil Saldhana: Flavia mainly because DML mentioned modules
12:20 Stefan: Ok, so app components must now support the declaration of security permissions. Besides, we need to consider setting up permissions for the modules
12:21 Anil Saldhana: previously, ra.xml could contain security permissions
12:21 Anil Saldhana: now additionally permissions.xml can be provided
12:21 Stefan: right, I believe the model is pretty similar to the one found in ra.xml
12:22 Anil Saldhana: the bigger Q is should we support permissions in module.xml?
12:22 Anil Saldhana: we discussed that in Aug 2011 with no action. :)
12:22 Stefan: I believe we do. What do we do now when the sec manager is active and one of the modules contains code that needs permissions
12:23 Anil Saldhana: The key aspects for a security manager access check includes CodeSource, Permissions and Subject
Anil Saldhana: CodeSource is driven by the classloader
12:24 Stefan: perms come from config and subject from the underlying sec context
12:25 Stefan: what happens now if sec manager is enabled on AS7? Do we have an AllPerm for all modules?
12:25 Anil Saldhana: I dont think so. Right now, they are governed by the codesource url
12:26 Anil Saldhana: defined in the general policy file.
12:26 Anil Saldhana: DML wanted to see if we could add sec permissions at the module level
12:27 Stefan: I think it is a good idea but the amount of work required for that can be insane due to the number of modules
12:28 Anil Saldhana: it is NOT required for all modules. If admin wants to do for a select set of modules, he should be able to
12:29 Flavia: okay, so this does not affect MSC directly, it will affect Modules afaics
12:31 Anil Saldhana: Who does modules?
12:32 Flavia: I am not sure, but I think that mostly David
12:33 Flavia: I agree with Stefan that there could be a perf impact if we add this to every single module in AS
12:33 Anil Saldhana: Remember it is user's choice whether they run AS under a JSM
12:37 Anil Saldhana: hey DML. etherpad is insanely slow
12:37 dmlloyd: at least it's up. This morning there was an outage
12:40 Anil Saldhana: I brought in your comments from the other ether here.
12:40 dmlloyd: My thought with modules is that they could request to be granted AllPermission by default
12:40 dmlloyd: that way we don't have to go through and retroactively redo every one
12:40 dmlloyd: but we can, later on, restrict modules if we want to
12:41 Anil Saldhana: Agree.
12:41 dmlloyd: my main motivation is to avoid having a global security policy file
12:41 dmlloyd: that's never been anything but a PITA
12:42 dmlloyd: by supporting it in modules we can establish permissions by class loader instead of code source
12:42 Anil Saldhana: the challenge is for a complete system, you will have to evaluate every module.
12:42 Anil Saldhana: if you have ALLPerm for unspecified modules
12:42 dmlloyd: we can simply compile and install the permissions as the modules are loaded
12:43 Anil Saldhana: where are they specified?
12:43 dmlloyd: in module.xml
12:43 dmlloyd: those would be the permissions the module requests, not necessarily the permissions they are granted
12:44 Stefan: ok, so we would be adding an AllPerm to every module.xml, leaving us with something that can be refined with timeso the idea is to add an AllPerm to every module.xml?
12:44 dmlloyd: ideally an administrator would also have their vote as to what permissions to use, and the effective permissions would be the union of the two
12:44 dmlloyd: yeah that's the idea
12:44 dmlloyd: really it's not so different from the EE7 rules - the deployment contains requested permissions, the administrator can further limit them, and the result is a union
12:44 Stefan: for some reason part of what I wrote was duplicated
12:45 dmlloyd: probably because etherpad is junk :)
12:45 Stefan: union or intersection
12:45 dmlloyd: intersection, sorry
12:45 Stefan: ah, ok :)
12:45 Anil Saldhana: I am fine with it. We should discuss this with Jason and the list.
12:45 dmlloyd: cripes, I wonder how long I've been doing that.
12:46 Anil Saldhana: DML - permissions.xml can be in META-INF
12:47 Anil Saldhana: for web deployments, should they go in WEB-INF?
12:47 dmlloyd: I'd say META-INF only, unless the EE or servlet spec specifically allow for WEB-INF
12:47 Anil Saldhana: I thought web deployments typically used WEB-INF
12:47 Anil Saldhana: these are SE requirements for EE
12:47 dmlloyd: they do for web stuff
12:47 Anil Saldhana: so maybe META-INF
12:48 dmlloyd: but servlet is a rule-breaker in a lot of ways
12:48 dmlloyd: they do require META-INF for a few things too, by spec (though I think in some cases we allow WEB-INF)
12:49 Anil Saldhana: stefan , what do you think? Allperm for all modules and admin changes based on his requirement
12:49 Stefan: there are some horrible things like having a WEB-INF/classes/META-INF
12:49 Anil Saldhana: that is persistence.xml
12:50 Stefan: the only thing I would like to know is where the admin perms would be stored
12:50 Anil Saldhana: module.xml
12:50 dmlloyd: that is a big question, and also, what form should it take
12:50 Stefan: yeah
12:50 dmlloyd: for deployments I think the standalone/domain.xml should contain the admin policy, but I don't know what capabilities we should give it
12:51 dmlloyd: e.g. do we require the admin perm overrides to be present at deploy time (assume AllPermission if not present), or do we have a general config that includes matching wildcards, or what
12:52 Anil Saldhana: we can leave it to the admin - AllPerm or denyall
12:52 Anil Saldhana: when we ship, we go with allperm
12:53 dmlloyd: my gut feeling is that we'll need something more nuanced than an all-on/all-off switch
12:53 Stefan: have to agree with david on this one
12:53 Anil Saldhana: domain.xml contains the default permission policy
12:53 Anil Saldhana: overrides happen in module.xml
12:53 dmlloyd: deployments do not contain a module.xml
12:53 Anil Saldhana: and permissions.xml/rar.xml
12:54 dmlloyd: for deployments we'd rely on META-INF/permissions.xml
12:54 dmlloyd: yeah
12:54 Anil Saldhana: right
12:54 dmlloyd: on the other hand, standalone/domain.xml permissions will not affect filesystem modules
12:54 dmlloyd: that global policy (if any) has to be statically defined somewhere
12:55 dmlloyd: like I said though - if we can avoid global policy files, that's best
12:56 dmlloyd: the policy file mechanism is defined by convention, not spec, therefore we shouldn't rely on it
12:56 Anil Saldhana: no requirement to go with policy file
12:58 dmlloyd: it implies though that if we do want an overriding global policy of some sort, it has to be of our own format, and it has to come from jboss modules
12:58 dmlloyd: so that jboss modules can merge the policy with that of the individual modules
13:00 Anil Saldhana: since modules is the building block, it makes sense to have it at the module level
13:00 Anil Saldhana: we definitely should think more from securing modules
13:00 Anil Saldhana: more from the perspective of securing the system via modules
13:03 dmlloyd: I'm not 100% brushed up on how protectiondomains and ACCs and all that stuff play together though
13:04 Anil Saldhana: I think once we start playing with it, we will see the challenges
13:05 dmlloyd: if one of you guys is already an expert that'd really help
13:05 dmlloyd: save some time
13:05 Anil Saldhana: this can actually be done in the modules project
13:06 Anil Saldhana: I mean test cases and performance measures
13:06 Anil Saldhana: what the SM does is very small IMO
13:06 dmlloyd: I can wire in the basic infrastructure to modules but a second/third pair of eyes would be good to have
13:06 Anil Saldhana: setting up the protection domains at the module CL level
13:06 Anil Saldhana: we will be there, DML
13:07 Anil Saldhana: I think I will start establishing some processes around this. testing/configuration etc.
13:07 dmlloyd: that is but one task though
13:07 dmlloyd: I think that it might be a good idea to create a top-level JIRA with subtasks to track the individual work units, with a dependent relationship to the EE7 JIRA subtask
13:08 dmlloyd: work units like:
13:08 dmlloyd: descriptor parsing
13:08 Anil Saldhana: right
13:08 dmlloyd: DUP changes to install permissions into the module spec
13:08 Anil Saldhana: Action Items to the left here. :)
13:08 Anil Saldhana: I will set up the JIRA issues for the action items
13:08 dmlloyd: subsystem config
13:08 dmlloyd: etc.
13:12 Anil Saldhana: will list the action items here and start creating subtasks
13:14 dmlloyd: I guess that's about it, other than just testing
13:14 Anil Saldhana: right. few minutes - check the action items here
13:15 Anil Saldhana: once you are happy, I can transfer to subtasks in JIRA
13:15 dmlloyd: I'd feel better if we had some plan for global module config, and an idea of how the global domain config might look
13:15 Anil Saldhana: we need to have that discussion.
13:16 dmlloyd: we can create a subtask placeholder for the domain config question and then open it up for discussion on the dev list
13:16 Anil Saldhana: right
13:16 Anil Saldhana: added some action items. take a look
13:17 dmlloyd: AS DUP implementation to merge descriptor information into the module definition
13:24 dmlloyd: I guess that's it for now
13:24 dmlloyd: we can always add more later as things come up
13:25 dmlloyd: did we lose Stefan?
13:26 Anil Saldhana: probably
13:26 Anil Saldhana: they have electricity issues due to summer thunderstorms in Brazil
13:31 dmlloyd: FYI the subtask in the EE7 task should stay right where it is
13:32 dmlloyd: you can't have a task hierarchy, so we need a new top-level JIRA that links back to that subtask
13:32 dmlloyd: with notes to close one when you close the other
13:32 Anil Saldhana: ok
13:32 Anil Saldhana: did not realize it was a subtask. :)
h2. Followup
DML did some work: https://github.com/dmlloyd/jboss-modules/compare/dc534ef...f4c74be https://github.com/dmlloyd/jboss-modules/compare/dc534ef...f4c74be
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48383]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 2 months
[JBoss AS 7 Development] - AS8: JBoss Security Manager discussion
by Anil Saldhana
Anil Saldhana [https://community.jboss.org/people/anil.saldhana] created the document:
"AS8: JBoss Security Manager discussion"
To view the document, visit: https://community.jboss.org/docs/DOC-48383
--------------------------------------------------------------
David M Lloyd, Stefan, Flavia and I had a high level discussion on supporting Java Security Manager in AS8 in line with the needs of EE7 and JBoss Modules.
We had an etherpad discussion.
h2. Etherpad
Requirements
(Let us capture general requirements here)
Support for VMwide Security Manager policy?
Support META-INF/permissions.xml required by EE7 for web, ejb and application clients
>From DML:Support EE 7 Security Manager requirements
Maintain relationships established by JACC specification for Run As vs. AccessControlContext
Application components must be able to support at least the permissions listed in Table EE.6-2 in EE(7).6.2.2.3.
Deployers must support application component permissions as specified by EE.6.2.2.6.
Server administrators must have a way of declaring permission restrictions for deployments. If a deployment with declared permissions does not meet the configured permission set, the deployment must fail as per EE.6.2.2.6.
Perform wellIdeally we will be able to use a more efficient mechanism to evaluate permissions than a complete execution stack scan. The JDK always grants itself all permissions - by checking the class loader for null -
and generally acts as if doPrivileged is always in force. Perhaps we can utilize a similar trick to allow our provided modules to execute quickly.
Discussion Points
Should we do permissions within module.xml? (https://issues.jboss.org/browse/MODULES-157)
Action Items
1. Deployment Descriptor parsing for META-INF/permissions.xml
2. Domain.xml/Standalone.xml global permission block (parsing and handling)
3. JBoss Modules permission handling (parsing and handling)
4. System to merge deployment permissions into the module defined permissions.
Questions
Should permissions.xml for Web Deployments be in WEB-INF and not META-INF? JSR342 draft seems to imply they will be in META-INF (Answer: permissions.xml is a SE requirement for the EE platform. So it is META-INF)
Chat Discussion
h2. February 20, 2013
12:49 Stefan: there are some horrible things like having a WEB-INF/classes/META-INF
12:49 Anil Saldhana: that is persistence.xml
12:50 Stefan: the only thing I would like to know is where the admin perms would be stored
12:50 Anil Saldhana: module.xml
12:50 dmlloyd: that is a big question, and also, what form should it take
12:50 Stefan: yeah
12:50 dmlloyd: for deployments I think the standalone/domain.xml should contain the admin policy, but I don't know what capabilities we should give it
12:51 dmlloyd: e.g. do we require the admin perm overrides to be present at deploy time (assume AllPermission if not present), or do we have a general config that includes matching wildcards, or what
12:52 Anil Saldhana: we can leave it to the admin - AllPerm or denyall
12:52 Anil Saldhana: when we ship, we go with allperm
12:53 dmlloyd: my gut feeling is that we'll need something more nuanced than an all-on/all-off switch
12:53 Stefan: have to agree with david on this one
12:53 Anil Saldhana: domain.xml contains the default permission policy
12:53 Anil Saldhana: overrides happen in module.xml
12:53 dmlloyd: deployments do not contain a module.xml
12:53 Anil Saldhana: and permissions.xml/rar.xml
12:54 dmlloyd: for deployments we'd rely on META-INF/permissions.xml
12:54 dmlloyd: yeah
12:54 Anil Saldhana: right
12:54 dmlloyd: on the other hand, standalone/domain.xml permissions will not affect filesystem modules
12:54 dmlloyd: that global policy (if any) has to be statically defined somewhere
12:55 dmlloyd: like I said though - if we can avoid global policy files, that's best
12:56 dmlloyd: the policy file mechanism is defined by convention, not spec, therefore we shouldn't rely on it
12:56 Anil Saldhana: no requirement to go with policy file
12:58 dmlloyd: it implies though that if we do want an overriding global policy of some sort, it has to be of our own format, and it has to come from jboss modules
12:58 dmlloyd: so that jboss modules can merge the policy with that of the individual modules
13:00 Anil Saldhana: since modules is the building block, it makes sense to have it at the module level
13:00 Anil Saldhana: we definitely should think more from securing modules
13:00 Anil Saldhana: more from the perspective of securing the system via modules
13:03 dmlloyd: I'm not 100% brushed up on how protectiondomains and ACCs and all that stuff play together though
13:04 Anil Saldhana: I think once we start playing with it, we will see the challenges
13:05 dmlloyd: if one of you guys is already an expert that'd really help
13:05 dmlloyd: save some time
13:05 Anil Saldhana: this can actually be done in the modules project
13:06 Anil Saldhana: I mean test cases and performance measures
13:06 Anil Saldhana: what the SM does is very small IMO
13:06 dmlloyd: I can wire in the basic infrastructure to modules but a second/third pair of eyes would be good to have
13:06 Anil Saldhana: setting up the protection domains at the module CL level
13:06 Anil Saldhana: we will be there, DML
13:07 Anil Saldhana: I think I will start establishing some processes around this. testing/configuration etc.
13:07 dmlloyd: that is but one task though
13:07 dmlloyd: I think that it might be a good idea to create a top-level JIRA with subtasks to track the individual work units, with a dependent relationship to the EE7 JIRA subtask
13:08 dmlloyd: work units like:
13:08 dmlloyd: descriptor parsing
13:08 Anil Saldhana: right
13:08 dmlloyd: DUP changes to install permissions into the module spec
13:08 Anil Saldhana: Action Items to the left here. :)
13:08 Anil Saldhana: I will set up the JIRA issues for the action items
13:08 dmlloyd: subsystem config
13:08 dmlloyd: etc.
13:12 Anil Saldhana: will list the action items here and start creating subtasks
13:14 dmlloyd: I guess that's about it, other than just testing
13:14 Anil Saldhana: right. few minutes - check the action items here
13:15 Anil Saldhana: once you are happy, I can transfer to subtasks in JIRA
13:15 dmlloyd: I'd feel better if we had some plan for global module config, and an idea of how the global domain config might look
13:15 Anil Saldhana: we need to have that discussion.
13:16 dmlloyd: we can create a subtask placeholder for the domain config question and then open it up for discussion on the dev list
13:16 Anil Saldhana: right
13:16 Anil Saldhana: added some action items. take a look
13:17 dmlloyd: AS DUP implementation to merge descriptor information into the module definition
13:24 dmlloyd: I guess that's it for now
13:24 dmlloyd: we can always add more later as things come up
13:25 dmlloyd: did we lose Stefan?
13:26 Anil Saldhana: probably
13:26 Anil Saldhana: they have electricity issues due to summer thunderstorms in Brazil
13:31 dmlloyd: FYI the subtask in the EE7 task should stay right where it is
13:32 dmlloyd: you can't have a task hierarchy, so we need a new top-level JIRA that links back to that subtask
13:32 dmlloyd: with notes to close one when you close the other
13:32 Anil Saldhana: ok
13:32 Anil Saldhana: did not realize it was a subtask. :)
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48383]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 2 months
[JBoss AS 7 Development] - Hacking on AS8
by Tomaz Cerar
Tomaz Cerar [https://community.jboss.org/people/ctomc] modified the document:
"Hacking on AS8"
To view the document, visit: https://community.jboss.org/docs/DOC-48381
--------------------------------------------------------------
h4.
h4. 1. Create a github account
http://github.com http://github.com
h4. 2. Fork jboss-as into your account
http://github.com/jbossas/jboss-as http://github.com/jbossas/jboss-as
h4. 3. Clone your newly forked copy onto your local workspace
$ git clone git@github.com:[your user]/jboss-as.git
Initialized empty Git repository in /devel/jboss-as/.git/
remote: Counting objects: 2444, done.
remote: Compressing objects: 100% (705/705), done.
remote: Total 2444 (delta 938), reused 2444 (delta 938)
Receiving objects: 100% (2444/2444), 1.71 MiB | 205 KiB/s, done.
Resolving deltas: 100% (938/938), done.
$ cd jboss-as
h4. 4. Add a remote ref to upstream, for pulling future updates
git remote add upstream git://github.com/jbossas/jboss-as.git
h4. 5. As a precaution, disable merge commits to your master
git config branch.master.mergeoptions --ff-only
h4. 6. Use maven (via build.sh) (make sure you use maven 3)
$ ./build.sh install
.....
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: BOM ..................... SUCCESS [1.834s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [0.022s]
[INFO] JBoss Application Server: Domain Core ............. SUCCESS [3.051s]
[INFO] JBoss Application Server: Server Manager .......... SUCCESS [0.204s]
[INFO] JBoss Application Server: Server .................. SUCCESS [0.283s]
[INFO] JBoss Application Server: Domain Controller ....... SUCCESS [0.084s]
[INFO] JBoss Application Server: Process Manager ......... SUCCESS [0.314s]
[INFO] JBoss Application Server: Remoting ................ SUCCESS [0.390s]
[INFO] JBoss Application Server: Build ................... SUCCESS [5.696s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
h4. 7. Pulling later updates from upstream
$ git pull --rebase upstream master
>From git://github.com/jbossas/jboss-as
* branch master -> FETCH_HEAD
Updating 3382570..1fa25df
Fast-forward
{parent => bom}/pom.xml | 70 ++++----------
build/pom.xml | 13 +--
domain/pom.xml | 10 ++
.../src/main/resources/examples/host-example.xml | 2 +-
.../resources/examples/jboss-domain-example.xml | 28 +++---
.../main/resources/schema/jboss-domain-common.xsd | 12 +--
.../main/resources/schema/jboss-domain-host.xsd | 2 +-
domain/src/main/resources/schema/jboss-domain.xsd | 17 ++--
pom.xml | 100 ++++++++++++++++++--
process-manager/pom.xml | 3 +-
10 files changed, 156 insertions(+), 101 deletions(-)
rename {parent => bom}/pom.xml (85%)
(--rebase will automatically move your local commits, if you have any, on top of the latest branch you pull from, you can leave it off if you do not).
Please note that --rebase is very important if you do have commits. What happens is that when git pull can't fast forward, it does a merge commit, and a merge commit puts the sucked in changes ON TOP of yours whereas a rebase puts them BELOW yours. In other words a merge commit makes the history a graph, and we prefer a cleaner, easier to follow linear history (hence the rebasing). Further once you do a merge commit it will be difficult to rebase the history before that commit (say you want to combine two commits to one later) as described in point 13+. Luckily the option set in step 5 will prevent this from happening.+
One way to not forget --rebase the rebase option is you may want to create an alias
$ git config --global alias.up "pull --rebase"
and then just use the new alias instead of pull
$ git up upstream master
One last option, which some prefer, is to avoid using pull altogether, and just use fetch + rebase (this is of course more typing)
For some reasons tags are not updated (e.g. not part of an active branch). Update the tags with
$ git fetch --tags upstream
h4. 8. Pushing pulled updates (or local commits if you aren't using topic branches) to your private github repo (origin)
$ git push
Counting objects: 192, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (44/44), done.
Writing objects: 100% (100/100), 10.67 KiB, done.
Total 100 (delta 47), reused 100 (delta 47)
To git@github.com:[your user]/jboss-as.git
3382570..1fa25df master -> master
You might need to say -f to force the changes. Read the note on 12 though before you do it.
If you fetch the tags seperate you have to push the tags also
git push --tags
h4. 9. Discuss your planned changes (if you want feedback)
* On the forums - https://community.jboss.org/en/jbossas/dev/jboss_as7_development http://community.jboss.org/en/jbossas/dev/jboss_as7_development
* On IRC - irc://irc.freenode.org/jboss-as7 or https://webchat.freenode.net/?channels=jboss-as7 (http://webchat.freenode.net/?channels=jboss-as7)
h4. 10. Make sure there is a JIRA somewhere for the enhancement/fix
http://jira.jboss.org http://jira.jboss.org
h4. 11. Create a simple topic branch to isolate that work (just a recommendation)
git checkout -b my_cool_feature
h6. Note: See tips section for how to use a nice git prompt for tracking what branch you are in!
h4. 12. Make the changes and commit one or more times (Don't forget to push)
git commit -m 'JBAS-XXXX Frunubucate the Fromungulator'
git commit -m 'JBAS-YYYY Tripple Performance of Fromungulation'
git push origin my_cool_feature
+Note that git push references the branch you are pushing and defaults to master, *not your working branch*.+
h4. 13. Rebase your branch against the latest master (applies your patches on top of master)
git fetch upstream
git rebase -i upstream/master
# if you have conflicts fix them and rerun rebase
# The -f, forces the push, alters history, see note below
git push -f origin my_cool_feature
The -i triggers an interactive update which also allows you to combine commits, alter commit messages etc. It's a good idea to make the commit log very nice for external consumption. Note that this alters history, which while great for making a clean patch, is unfriendly to anyone who has forked your branch. Therefore you want to make sure that you either work in a branch that you don't share, or if you do share it, tell them you are about to revise the branch history (and thus, they will then need to rebase on top of your branch once you push it out).
h4. 14. Get your changes merged into upstream
1. Make sure your repo is in sync with other unrelated changes in upstream before requesting your changes be merged into upstream by repeating step 13.
2. Send a github pull request, by clicking the pull request link while in your repo's fork
3. An email will automatically be sent to the pull request list ( http://lists.jboss.org/pipermail/jbossas-pull-requests http://lists.jboss.org/pipermail/jbossas-pull-requests)
4. As part of the review you may see an automated test run comment on your request. Currently this link can only be viewed by Red Hat employees, but if you request a copy we can send you one. In the future we hope to make this public
5. After review a maintainer will merge your patch, update/resolve issues by request, and reply when complete
6. Don't forget to switch back to master and pull the updates1. git checkout master
git pull --ff-only upstream master
7. To update the master branch of your github repository (otherwise you will see a message like 'Your branch is ahead of 'origin/master' by XXX commits.'
if you are use 'git status' on your local master branch.1. git push origin master
h4. Appendix A. Adding a new external dependency
1. Edit pom.xml and add a property of the form "version.groupId.artifactId" which contains the Maven version of the dependency. Add your dependency to the <dependencyManagement> section, and use the property for the version. If your new dependency has any transitive dependencies, be sure to <exclude> them (or if possible, update the project so that all its dependencies are of *provided* scope).
2. Add your dependency to any AS modules that require it, but only with group/artifact.
3. Edit build/pom.xml and add your dependency with only group/artifact.
4. Create a directory in build/src/modules corresponding to the *module's* name (which will differ from the Maven group/artifact name; look at other modules to get a feel for the naming scheme), with a version of "main", like this: "build/src/modules/org/jboss/foo/main".
5. Create a module.xml file inside the "main" directory. Use a module.xml from another similar module as a template.
6. Edit build/build.xml and add a <module-def> element. The name listed in the <module-def> element corresponds to the *module* name. The group/artifact listed in the nested maven-resource element(s) refer to the *Maven* group/artifact name.
7. *Important:* Make sure you did not introduce any transitive dependencies by using "mvn dependency:tree". If you did, be sure to add <exclusion>s for each of them to your dependency as described above.
8. *Important:* Do *not* introduce a dependecy on the "*system*" module. If you need access to JDK classes which are not covered by any other dependency, use the "javax.api" module as a dependency.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix B. Adding a new AS submodule
1. Create the directory corresponding to the submodule and add it to the root pom.xml file. The convention is to leave off the "jboss-as-" portion, so "jboss-as-remoting" becomes "remoting".
2. Create a POM for your submodule (use another submodule as a template). Make sure all dependencies you specify do *not* include a version. The group ID should be "org.jboss.as", and the artifact ID should begin with "jboss-as-" and there should be a proper <name> for the new module.
3. Add the new submodule to the top section of the <dependencyManagement> of the top-level pom.xml. The version should be set to "${project.version}". This section is sorted alphabetically by artifact name so please preserve that ordering.
4. Add the new submodule to the modules section element of the top-level pom.xml
5. Add your submodule dependency to any AS modules that require it, but only with group/artifact.
6. Edit build/pom.xml and add the new submodule with only group/artifact.
7. Create a directory in build/src/main/resources/modules corresponding to the submodule, with a version of "main", like this: "build/src/main/resources/modules/org/jboss/as/new-subsystem/main".
8. Create a module.xml file inside the "main" directory. Use a module.xml from another subsystem as a template.
9. Edit build/build.xml and add a <module-def> element for the subsystem. Use the module name and Maven coordinates from steps 6 and 2 respectively. Use another submodule as a template.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix C. Profiling with JProfiler
Performance tuning is an important part of AS7 development. In order to use JProfiler on a standalone AS 7 instance, first you need to add the following to your standalone.conf file:
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=com.jprofiler -agentlib:jprofilerti -Xbootclasspath/a:/path/to/jprofiler/bin/agent.jar"
The "jboss.modules.system.pkgs" property tells JBoss Modules to allow the "com.profiler" classes to be found from any class loader, which is essential to allow the JProfiler agent to run.
It's easiest to then just set up your JProfiler session as "Remote", and start the server and the profiler in any order. That's it!
h4. Appendix D. Importing into Eclipse
The directory "ide-configs/eclipse" contains both formatter and code templates. Use these to pass the CheckStyle enforcer during the build if coding from Eclipse.
h4. Tips & Tricks!
h4. Creating a Git status prompt in your terminal
This makes it easy to not forget what branch you are working in and quickly tell if you have changes. The following will adjust the PS1 on unix (or cygwin on Windows). Note that it assumes a compiled version of git, which is also the case for the OSX packages. If you are using the bundled rpm version, change the completion path to "/etc/bash_completion.d/git"
GIT_COMPLETION_PATH="/usr/local/git/contrib/completion/git-completion.bash"
if [ -f "$GIT_COMPLETION_PATH" ]; then
GIT_PS1_SHOWDIRTYSTATE=true
. "$GIT_COMPLETION_PATH"
ADD_PS1='$(__git_ps1)'
fi
if [[ ${EUID} == 0 ]] ; then
PS1="\[\033[01;31m\]\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
else
PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
fi
h4. Partial Builds
It's common when working on a particular module to need to build that module and the overall AS distribution numerous times. Doing a full AS build can be overly time consuming in this situation. The maven rf and pl options can be helpful in limiting the build to a subset of all the AS modules. See http://java.dzone.com/articles/5-maven-tips this quick introduction to both of these maven switches.
A fairly common thing is to work on a single subsystem, so you need that subsystem built, and to also have the full AS dist rebuilt so the new version of the subsystem's jar ends up in build/target. To do this, for example with the ejb3 subsystem, you would:
mvn install -pl ejb3,build
h4. IDE Integration
h5. Eclipse
Follow the steps mentioned here https://community.jboss.org/docs/DOC-16718 http://community.jboss.org/wiki/HackingAS7usingEclipse
h3.
h3. Checkstyle Errors
If you need to first verify that your changes pass the checkstyle audit, do this first.
mvn checkstyle:checkstyle
Then you can proceed with the build.
h3.
h3. Adding Subsystem Scripts
If you have a need to add a script to AS8, then definitely it should finally land inside bin/util directory. One important thing that you will need to have as part of your subsystem pom is the following plugin.
<!-- JAR -->
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>org.jboss.as.security.vault.VaultTool</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
Substitute your main class.
h3.
h3. How do I ensure that my code does not blow up the testsuite?
First try to run the tests as part of the build before sending a pull request.
$> ./build.sh clean install -DallTests
Sometime there are test failures that are not related to your code changes. Try to discuss this on the mailing list or IRC.
You can get a full run using
$> ./build.sh clean install -DallTests -fae
1. This additional option will allow the build to continue even when there are test failures. Doing this, you can get a stock of all the test failures and figure out how many are related to your code changes.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48381]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 2 months
[jBPM Development] - Alternative to deprecated class in 5.4 - CommandBasedHornetQWSHumanTaskHandler
by João Guerra
João Guerra [https://community.jboss.org/people/ciberg] created the discussion
"Alternative to deprecated class in 5.4 - CommandBasedHornetQWSHumanTaskHandler"
To view the discussion, visit: https://community.jboss.org/message/796480#796480
--------------------------------------------------------------
Hi,
I'm new to jBPM and I'm developing a ESB service to allow a web application to manage processes and tasks.
I'm using jBPM 5.4 deployed in my own JBOSS AS 7.1.1 and persisting in postgres.
The process is deployed in Guvnor and it all works fine, persistance is working and I can do all the required operations via my ESB.
The problem is that I was using AsyncHornetQHTWorkItemHandler as work item handler and the tasks would'nt move forward when the previous was completed.
Then I changed the handler to CommandBasedHornetQWSHumanTaskHandler and it works fine, the problem is that class is deprecated so I should'nt use it and I can't find an alternative for that.
I have a workflow of this type:
Start ---> Human Task ---> Script Task ---> Human Task ---> Human Task ---> Human Task ---> End
This is the code I'm using, note that this is working fine but using the deprecated class:
KnowledgeBase kbase = null;
StatefulKnowledgeSession ksession = null;
EntityManagerFactory emf = Persistence.createEntityManagerFactory( PERSISTANCE_ENTITY_NAME );
Environment env = KnowledgeBaseFactory.newEnvironment();
env.set( EnvironmentName.ENTITY_MANAGER_FACTORY, emf );
kbase = readKnowledgeBase();
ksession = JPAKnowledgeService.newStatefulKnowledgeSession(kbase, null, env);
*CommandBasedHornetQWSHumanTaskHandler* humanTaskHandler = new *CommandBasedHornetQWSHumanTaskHandler*(ksession);
humanTaskHandler.setConnection(HUMAN_TASK_SERVER_HOST, HUMAN_TASK_SERVER_PORT);
As this is a big project I should'nt use a deprecated class, can you help me on this?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/796480#796480]
Start a new discussion in jBPM Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 2 months