[JBoss JIRA] (JGRP-1605) API changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1605?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1605:
---------------------------
Description:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* Rsp: club {{received}}, {{suspected}}, {{unreachable}} into 1 boolean field, use 1 field for result/exception
was:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* Rsp: club {{received}}, {{suspected}}, {{unreachable}} into 1 boolean field, use 1 field got result/exception
> API changes
> -----------
>
> Key: JGRP-1605
> URL: https://issues.jboss.org/browse/JGRP-1605
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> API changes to be done in 4.0, which break code:
> * MessageDispatcher: remove MessageListener
> * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * DONE: Remove @Deprecated methods, properties or classes
> * Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
> * Make {{RspFilter}} --> {{RspFilter<T>}}
> * {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
> * Request<T>
> * RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
> * Rsp: club {{received}}, {{suspected}}, {{unreachable}} into 1 boolean field, use 1 field for result/exception
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (WFLY-5850) Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-5850:
------------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
> ----------------------------------------------------------------
>
> Key: WFLY-5850
> URL: https://issues.jboss.org/browse/WFLY-5850
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ladislav Thon
> Assignee: Stuart Douglas
> Priority: Critical
>
> I just tried to migrate a {{standalone.xml}} server from clean EAP 6.4.0 to WildFly 10.0.0.CR4 and then deploy the {{server-side}} part of the {{ejb-remote}} quickstart:
> {code}
> git clone git@github.com:jboss-developer/jboss-eap-quickstarts.git
> cd jboss-eap-quickstarts/
> git checkout -b 6.4.x origin/6.4.x
> cd ejb-remote/server-side/
> mvn clean package -s ../../settings.xml
> cd target
> unzip .../jboss-eap-6.4.0.zip
> unzip .../wildfly-10.0.0.CR4.zip
> cp jboss-eap-6.4/standalone/configuration/standalone.xml wildfly-10.0.0.CR4/standalone/configuration/test.xml
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml --admin-only
> # on a separate console
> ./wildfly-10.0.0.CR4/bin/jboss-cli.sh -c --controller=localhost:9999
> /subsystem=threads:remove
> /extension=org.jboss.as.threads:remove
> /subsystem=web:migrate
> shutdown
> # on the original console
> cp jboss-ejb-remote-server-side.jar wildfly-10.0.0.CR4/standalone/deployments/
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml
> {code}
> What I get is this horrible stack trace:
> {code}
> 15:35:50,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "jboss-ejb-remote-server-side.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
> at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:109)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_66]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_66]
> at java.lang.Class.newInstance(Class.java:442) [rt.jar:1.8.0_66]
> at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> ... 5 more
> 15:35:50,921 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jboss-ejb-remote-server-side.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"jboss-ejb-remote-server-side.jar\"
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
> {code}
> When I deploy the same JAR to a clean install of WildFly 10.0.0.CR4, it works just fine. This suggests that something (probably the EJB subsystem?) doesn't correctly parse/serialize the legacy configuration. Or something like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1048:
-------------------------------------
Description:
[~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
Preparation:
1) Get some experience
- Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
-- Once from droolsjbpm
-- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...")
- Add some local changes on both dirs.
- On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup.
- Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
-- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
-- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
-- What happened to the open PR?
2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
3) Set up roles and users of github.com/kiegroup.
4) Reach out
- Talk to each type of person involved:
-- R&D developer
-- QA
-- Productization
-- Product docs
-- Community
- Make an inventory of references to "github.com/droolsjbpm"
-- Do a find in path on all our files for "github.com/droolsjbpm")
-- Which webapps reference it?
--- jenkins
--- jira
--- www.openhub.net
--- gitter
--- stackoverflow
--- google forums / mailing lists
--- ...
- Set a date when you'll be moving the first repository.
-- Clearly communicate on all channels to let everyone know. This includes:
--- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
--- Internal mailing lists: sme-brms, pm lists, bsig, etc
--- IRC channel topics
--- Social media (Twitter accounts etc)
--- ...
- Clearly communicate:
-- What you'll do
-- When you'll do it
-- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
-- A recipe: What they need to do - step by step for dummies - after the merge is done.
-- Get someone to review this mail before it goes out.
- You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
5) Do it:
- You can do one repository at a time, or do multiple at the same time.
-- I'd recommend to start with just 1 to get a feel for it.
- Do them in reverse order of the repository-list.txt!
- DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
-- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
-- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
- In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
- Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
6) Clean up the fallout
- Go through your inventory and replace the references as far as humanly possible (stackoverflow is likely to be impossible).
Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
was:
[~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
Preparation:
1) Get some experience
- Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
-- Once from droolsjbpm
-- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...")
- Add some local changes on both dirs.
- On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup.
- Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
-- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
-- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
-- What happened to the open PR?
2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
3) Set up roles and users of github.com/kiegroup.
4) Reach out
- Talk to each type of person involved:
-- R&D developer
-- QA
-- Productization
-- Product docs
-- Community
- Make an inventory of references to "github.com/droolsjbpm"
-- Do a find in path on all our files for "github.com/droolsjbpm")
-- Which webapps reference it?
--- jenkins
--- jira
--- www.openhub.net
--- gitter
--- stackoverflow
--- google forums / mailing lists
--- ...
- Set a date when you'll be moving the first repository.
-- Clearly communicate on all channels to let everyone know. This includes:
--- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
--- Internal mailing lists: sme-brms, pm lists, bsig, etc
--- IRC channel topics
--- Social media (Twitter accounts etc)
--- ...
- Clearly communicate:
-- What you'll do
-- When you'll do it
-- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
-- A recipe: What they need to do - step by step for dummies - after the merge is done.
-- Get someone to review this mail before it goes out.
- You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
5) Do it:
- You can do one repository at a time, or do multiple at the same time.
-- I'd recommend to start with just 1 to get a feel for it.
- Do them in reverse order of the repository-list.txt!
- DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
-- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
-- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
- In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
- Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
> Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
> ---------------------------------------------------------------------
>
> Key: DROOLS-1048
> URL: https://issues.jboss.org/browse/DROOLS-1048
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
> Priority: Critical
>
> [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
> Preparation:
> 1) Get some experience
> - Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
> -- Once from droolsjbpm
> -- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...")
> - Add some local changes on both dirs.
> - On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup.
> - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
> -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
> -- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
> -- What happened to the open PR?
> 2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
> 3) Set up roles and users of github.com/kiegroup.
> 4) Reach out
> - Talk to each type of person involved:
> -- R&D developer
> -- QA
> -- Productization
> -- Product docs
> -- Community
> - Make an inventory of references to "github.com/droolsjbpm"
> -- Do a find in path on all our files for "github.com/droolsjbpm")
> -- Which webapps reference it?
> --- jenkins
> --- jira
> --- www.openhub.net
> --- gitter
> --- stackoverflow
> --- google forums / mailing lists
> --- ...
> - Set a date when you'll be moving the first repository.
> -- Clearly communicate on all channels to let everyone know. This includes:
> --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
> --- Internal mailing lists: sme-brms, pm lists, bsig, etc
> --- IRC channel topics
> --- Social media (Twitter accounts etc)
> --- ...
> - Clearly communicate:
> -- What you'll do
> -- When you'll do it
> -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
> -- A recipe: What they need to do - step by step for dummies - after the merge is done.
> -- Get someone to review this mail before it goes out.
> - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
> 5) Do it:
> - You can do one repository at a time, or do multiple at the same time.
> -- I'd recommend to start with just 1 to get a feel for it.
> - Do them in reverse order of the repository-list.txt!
> - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
> -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
> -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
> - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
> - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
> 6) Clean up the fallout
> - Go through your inventory and replace the references as far as humanly possible (stackoverflow is likely to be impossible).
> Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1048:
-------------------------------------
Description:
[~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
Preparation:
1) Get some experience
- Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
-- Once from droolsjbpm
-- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...")
- Add some local changes on both dirs.
- On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup.
- Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
-- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
-- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
-- What happened to the open PR?
2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
3) Set up roles and users of github.com/kiegroup.
4) Reach out
- Talk to each type of person involved:
-- R&D developer
-- QA
-- Productization
-- Product docs
-- Community
- Make an inventory of references to "github.com/droolsjbpm"
-- Do a find in path on all our files for "github.com/droolsjbpm")
-- Which webapps reference it?
--- jenkins
--- jira
--- www.openhub.net
--- gitter
--- stackoverflow
--- google forums / mailing lists
--- ...
- Set a date when you'll be moving the first repository.
-- Clearly communicate on all channels to let everyone know. This includes:
--- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
--- Internal mailing lists: sme-brms, pm lists, bsig, etc
--- IRC channel topics
--- Social media (Twitter accounts etc)
--- ...
- Clearly communicate:
-- What you'll do
-- When you'll do it
-- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
-- A recipe: What they need to do - step by step for dummies - after the merge is done.
-- Get someone to review this mail before it goes out.
- You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
5) Do it:
- You can do one repository at a time, or do multiple at the same time.
-- I'd recommend to start with just 1 to get a feel for it.
- Do them in reverse order of the repository-list.txt!
- DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
-- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
-- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
- In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
- Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
6) Clean up the fallout
- Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not).
Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
was:
[~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
Preparation:
1) Get some experience
- Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
-- Once from droolsjbpm
-- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...")
- Add some local changes on both dirs.
- On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup.
- Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
-- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
-- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
-- What happened to the open PR?
2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
3) Set up roles and users of github.com/kiegroup.
4) Reach out
- Talk to each type of person involved:
-- R&D developer
-- QA
-- Productization
-- Product docs
-- Community
- Make an inventory of references to "github.com/droolsjbpm"
-- Do a find in path on all our files for "github.com/droolsjbpm")
-- Which webapps reference it?
--- jenkins
--- jira
--- www.openhub.net
--- gitter
--- stackoverflow
--- google forums / mailing lists
--- ...
- Set a date when you'll be moving the first repository.
-- Clearly communicate on all channels to let everyone know. This includes:
--- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
--- Internal mailing lists: sme-brms, pm lists, bsig, etc
--- IRC channel topics
--- Social media (Twitter accounts etc)
--- ...
- Clearly communicate:
-- What you'll do
-- When you'll do it
-- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
-- A recipe: What they need to do - step by step for dummies - after the merge is done.
-- Get someone to review this mail before it goes out.
- You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
5) Do it:
- You can do one repository at a time, or do multiple at the same time.
-- I'd recommend to start with just 1 to get a feel for it.
- Do them in reverse order of the repository-list.txt!
- DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
-- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
-- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
- In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
- Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
6) Clean up the fallout
- Go through your inventory and replace the references as far as humanly possible (stackoverflow is likely to be impossible).
Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
> Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
> ---------------------------------------------------------------------
>
> Key: DROOLS-1048
> URL: https://issues.jboss.org/browse/DROOLS-1048
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
> Priority: Critical
>
> [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
> Preparation:
> 1) Get some experience
> - Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
> -- Once from droolsjbpm
> -- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...")
> - Add some local changes on both dirs.
> - On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup.
> - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
> -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
> -- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
> -- What happened to the open PR?
> 2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
> 3) Set up roles and users of github.com/kiegroup.
> 4) Reach out
> - Talk to each type of person involved:
> -- R&D developer
> -- QA
> -- Productization
> -- Product docs
> -- Community
> - Make an inventory of references to "github.com/droolsjbpm"
> -- Do a find in path on all our files for "github.com/droolsjbpm")
> -- Which webapps reference it?
> --- jenkins
> --- jira
> --- www.openhub.net
> --- gitter
> --- stackoverflow
> --- google forums / mailing lists
> --- ...
> - Set a date when you'll be moving the first repository.
> -- Clearly communicate on all channels to let everyone know. This includes:
> --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
> --- Internal mailing lists: sme-brms, pm lists, bsig, etc
> --- IRC channel topics
> --- Social media (Twitter accounts etc)
> --- ...
> - Clearly communicate:
> -- What you'll do
> -- When you'll do it
> -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
> -- A recipe: What they need to do - step by step for dummies - after the merge is done.
> -- Get someone to review this mail before it goes out.
> - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
> 5) Do it:
> - You can do one repository at a time, or do multiple at the same time.
> -- I'd recommend to start with just 1 to get a feel for it.
> - Do them in reverse order of the repository-list.txt!
> - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
> -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
> -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
> - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
> - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
> 6) Clean up the fallout
> - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not).
> Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1048:
-------------------------------------
Description:
[~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
Preparation:
1) Get some experience
- Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
-- Once from droolsjbpm
-- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...")
- Add some local changes on both dirs.
- On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup.
- Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
-- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
-- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
-- What happened to the open PR?
2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
3) Set up roles and users of github.com/kiegroup.
4) Reach out
- Talk to each type of person involved:
-- R&D developer
-- QA
-- Productization
-- Product docs
-- Community
- Make an inventory of references to "github.com/droolsjbpm"
-- Do a find in path on all our files for "github.com/droolsjbpm")
-- Which webapps reference it?
--- jenkins
--- jira
--- www.openhub.net
--- gitter
--- stackoverflow
--- google forums / mailing lists
--- ...
- Set a date when you'll be moving the first repository.
-- Clearly communicate on all channels to let everyone know. This includes:
--- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
--- Internal mailing lists: sme-brms, pm lists, bsig, etc
--- IRC channel topics
--- Social media (Twitter accounts etc)
--- ...
- Clearly communicate:
-- What you'll do
-- When you'll do it
-- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
-- A recipe: What they need to do - step by step for dummies - after the merge is done.
-- Get someone to review this mail before it goes out.
- You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
5) Do it:
- You can do one repository at a time, or do multiple at the same time.
-- I'd recommend to start with just 1 to get a feel for it.
- Do them in reverse order of the repository-list.txt!
- DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
-- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
-- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
- In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
- Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
was:
[~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
Preparation:
1) Get some experience
- Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
-- Once from droolsjbpm
-- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...")
- Add some local changes on both dirs.
- On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup.
- Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
-- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
-- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
-- What happened to the open PR?
2) Reach out
- Talk to each type of person involved:
-- R&D developer
-- QA
-- Productization
-- Product docs
-- Community
- Make an inventory of references to "github.com/droolsjbpm"
-- Do a find in path on all our files for "github.com/droolsjbpm")
-- Which webapps reference it?
--- jenkins
--- jira
--- www.openhub.net
--- gitter
--- stackoverflow
--- google forums / mailing lists
--- ...
- Set a date when you'll be moving the first repository.
-- Clearly communicate on all channels to let everyone know. This includes:
--- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
--- Internal mailing lists: sme-brms, pm lists, bsig, etc
--- IRC channel topics
--- Social media (Twitter accounts etc)
--- ...
- Clearly communicate:
-- What you'll do
-- When you'll do it
-- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
-- A recipe: What they need to do - step by step for dummies - after the merge is done.
-- Get someone to review this mail before it goes out.
- You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
Do it:
- You can do one repository at a time, or do multiple at the same time.
-- I'd recommend to start with just 1 to get a feel for it.
- Do them in reverse order of the repository-list.txt!
- DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
-- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
-- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
- In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
- Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
> Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
> ---------------------------------------------------------------------
>
> Key: DROOLS-1048
> URL: https://issues.jboss.org/browse/DROOLS-1048
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
> Priority: Critical
>
> [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
> Preparation:
> 1) Get some experience
> - Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
> -- Once from droolsjbpm
> -- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...")
> - Add some local changes on both dirs.
> - On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup.
> - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
> -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
> -- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
> -- What happened to the open PR?
> 2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
> 3) Set up roles and users of github.com/kiegroup.
> 4) Reach out
> - Talk to each type of person involved:
> -- R&D developer
> -- QA
> -- Productization
> -- Product docs
> -- Community
> - Make an inventory of references to "github.com/droolsjbpm"
> -- Do a find in path on all our files for "github.com/droolsjbpm")
> -- Which webapps reference it?
> --- jenkins
> --- jira
> --- www.openhub.net
> --- gitter
> --- stackoverflow
> --- google forums / mailing lists
> --- ...
> - Set a date when you'll be moving the first repository.
> -- Clearly communicate on all channels to let everyone know. This includes:
> --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
> --- Internal mailing lists: sme-brms, pm lists, bsig, etc
> --- IRC channel topics
> --- Social media (Twitter accounts etc)
> --- ...
> - Clearly communicate:
> -- What you'll do
> -- When you'll do it
> -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
> -- A recipe: What they need to do - step by step for dummies - after the merge is done.
> -- Get someone to review this mail before it goes out.
> - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
> 5) Do it:
> - You can do one repository at a time, or do multiple at the same time.
> -- I'd recommend to start with just 1 to get a feel for it.
> - Do them in reverse order of the repository-list.txt!
> - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
> -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
> -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
> - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
> - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
> Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-1048:
----------------------------------------
Summary: Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
Key: DROOLS-1048
URL: https://issues.jboss.org/browse/DROOLS-1048
Project: Drools
Issue Type: Task
Components: build
Reporter: Geoffrey De Smet
Assignee: Petr Široký
Priority: Critical
[~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
Preparation:
1) Get some experience
- Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
-- Once from droolsjbpm
-- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...")
- Add some local changes on both dirs.
- On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup.
- Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
-- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
-- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
-- What happened to the open PR?
2) Reach out
- Talk to each type of person involved:
-- R&D developer
-- QA
-- Productization
-- Product docs
-- Community
- Make an inventory of references to "github.com/droolsjbpm"
-- Do a find in path on all our files for "github.com/droolsjbpm")
-- Which webapps reference it?
--- jenkins
--- jira
--- www.openhub.net
--- gitter
--- stackoverflow
--- google forums / mailing lists
--- ...
- Set a date when you'll be moving the first repository.
-- Clearly communicate on all channels to let everyone know. This includes:
--- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
--- Internal mailing lists: sme-brms, pm lists, bsig, etc
--- IRC channel topics
--- Social media (Twitter accounts etc)
--- ...
- Clearly communicate:
-- What you'll do
-- When you'll do it
-- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
-- A recipe: What they need to do - step by step for dummies - after the merge is done.
-- Get someone to review this mail before it goes out.
- You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
Do it:
- You can do one repository at a time, or do multiple at the same time.
-- I'd recommend to start with just 1 to get a feel for it.
- Do them in reverse order of the repository-list.txt!
- DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
-- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
-- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
- In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
- Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (JGRP-1265) Member can not join cluster after JVM high load
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1265?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1265:
--------------------------------
You definitely need {{MERGE3}} (btw, I removed {{MERGE2}} in 4.0), as it handles more edge cases. The second node should exclude the first when the first takes a heap dump. However, the first and second node should merge again after the timeout defined in {{MERGE3}} kicks in.
I suggest copy {{udp.xml}} shipped with JGroups, and make modifications, e.g. increase the timeouts in {{FD_ALL}} (40s by default).
Please also use the latest JGroups (3.6.7 at the time of this writing) when trying to reproduce the issue.
> Member can not join cluster after JVM high load
> -----------------------------------------------
>
> Key: JGRP-1265
> URL: https://issues.jboss.org/browse/JGRP-1265
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.11
> Environment: linux, kernel 2.6.18
> Reporter: Victor N
> Assignee: Bela Ban
> Fix For: 2.12
>
> Attachments: jgroups-tcp.xml
>
>
> In our production system I can see that a node desappers from the cluster if its server was heavily-loaded. It's OK, but the node never comes back to the cluster even after its server is working normally, without load. I can easily reproduce the problem in 2 cases:
> 1) by taking a memory dump on the node: jmap -dump:format=b,file=dump.hprof <pid>
> Since we have 8-16 GB of RAM, this operation takes much time and blocks JVM - so other members exclude this node from View.
> 2) GC (garbage collection) - if JVM is doing GC constantly (and almost can not work)
> In both situations the stuck node never reappears in the cluster (even after 1 h). Below are more details.
> We have 12 nodes in our cluster, we problematic node is "gate5".
> View on gate5: [gate11.mydomain|869] [gate11.mydomain, gate2.mydomain, gate6.mydomain, gate7.mydomain, gate12.mydomain, gate4.mydomain, gate3.mydomain, gate10.mydomain, gate8.mydomain, gate9.mydomain, gate14.mydomain, gate5.mydomain]
> View on gate11 (coordinator): [gate11.mydomain|870] [gate11.mydomain, gate2.mydomain, gate6.mydomain, gate7.mydomain, gate12.mydomain, gate4.mydomain, gate3.mydomain, gate10.mydomain, gate8.mydomain, gate9.mydomain, gate14.mydomain]
> The coordinator (gate11) is sending GET_MBRS_REQ periodically - I see them in gate5. But I do NOT see response to this request!
> All jgroups threads are alive, not dead (I took stack traces).
> Another strange thing is that the problematic gate5 sends messages to other nodes and even receives messages from SOME of them! How is it possible - I double-checked that ALL other nodes have view_id=870 (without gate5)?
> The only assumption I have is race-conditions which occurs (as always) under high load.
> In normal situations such as temporary network failure everything works perfectly - gate5 joins the cluster.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (WFLY-5875) Some domain tests fail with security manager
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5875?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-5875:
-------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/8640
> Some domain tests fail with security manager
> --------------------------------------------
>
> Key: WFLY-5875
> URL: https://issues.jboss.org/browse/WFLY-5875
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Reporter: Ondrej Kotek
> Assignee: Hynek Švábek
>
> *org.jboss.as.test.integration.domain.mixed.eap640.MixedDomainDeployment640TestCase#testJsfWorks*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dts.noSmoke -Dtest=MixedDomainDeployment640TestCase#testJsfWorks -Djboss.test.mixed.domain.dir=/home/okotek/test/ -Dsecurity.manager}}
> fails with:
> {noformat}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (http-/10.16.95.147:8080-1) Error Rendering View[/home.xhtml]: javax.el.ELException: /home.xhtml: java.lang.RuntimeException: java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:88)&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82)&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:207)&#27;[0m
> [Server:server-one] &#27;[31m at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822)&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447)&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125)&#27;[0m
> [Server:server-one] &#27;[31m at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286)&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)&#27;[0m
> [Server:server-one] &#27;[31m at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)&#27;[0m
> [Server:server-one] &#27;[31m at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&#27;[0m
> [Server:server-one] &#27;[31m at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)&#27;[0m
> [Server:server-one] &#27;[31m at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)&#27;[0m
> [Server:server-one] &#27;[31m at java.lang.reflect.Method.invoke(Method.java:497)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:264)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:262)&#27;[0m
> [Server:server-one] &#27;[31m at java.security.AccessController.doPrivileged(Native Method)&#27;[0m
> [Server:server-one] &#27;[31m at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:296)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:156)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:288)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:59)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:197)&#27;[0m
> [Server:server-one] &#27;[31m at java.security.AccessController.doPrivileged(Native Method)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)&#27;[0m
> [Server:server-one] &#27;[31m at java.lang.Thread.run(Thread.java:745)&#27;[0m
> [Server:server-one] &#27;[31mCaused by: java.lang.RuntimeException: java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:65)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.util.reflection.SecureReflections.ensureAccessible(SecureReflections.java:283)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.introspector.jlr.WeldConstructorImpl.newInstance(WeldConstructorImpl.java:206)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:117)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.bean.ManagedBean.createInstance(ManagedBean.java:340)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.produce(ManagedBean.java:204)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:296)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:103)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:90)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.as.test.integration.domain.mixed.jsf.Bean$Proxy$_$$_WeldClientProxy.getMessage(Bean$Proxy$_$$_WeldClientProxy.java)&#27;[0m
> [Server:server-one] &#27;[31m at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&#27;[0m
> [Server:server-one] &#27;[31m at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)&#27;[0m
> [Server:server-one] &#27;[31m at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)&#27;[0m
> [Server:server-one] &#27;[31m at java.lang.reflect.Method.invoke(Method.java:497)&#27;[0m
> [Server:server-one] &#27;[31m at javax.el.BeanELResolver.getValue(BeanELResolver.java:304)&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.el.parser.AstValue.getValue(AstValue.java:166)&#27;[0m
> [Server:server-one] &#27;[31m at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:189)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:227)&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.facelets.el.ELText$ELTextComposite.writeText(ELText.java:150)&#27;[0m
> [Server:server-one] &#27;[31m at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85)&#27;[0m
> [Server:server-one] &#27;[31m ... 38 more&#27;[0m
> [Server:server-one] &#27;[31mCaused by: java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")&#27;[0m
> [Server:server-one] &#27;[31m at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)&#27;[0m
> [Server:server-one] &#27;[31m at java.security.AccessController.checkPermission(AccessController.java:884)&#27;[0m
> [Server:server-one] &#27;[31m at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)&#27;[0m
> [Server:server-one] &#27;[31m at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.util.reflection.SecureReflections$14.work(SecureReflections.java:288)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.util.reflection.SecureReflections$14.work(SecureReflections.java:283)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)&#27;[0m
> [Server:server-one] &#27;[31m at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63)&#27;[0m
> {noformat}
> *org.jboss.as.test.integration.domain.suites.ReadEnvironmentVariablesTestCase#testReadEnvironmentVariablesForServers*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.domain -Dts.noSmoke -Dtest=org.jboss.as.test.integration.domain.suites.ReadEnvironmentVariablesTestCase#testReadEnvironmentVariablesForServers}}
> fails with:
> {noformat}
> ERROR [io.undertow.request] (default task-43) UT005023: Exception handling request to /env-test/env: java.security.Access
> ControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getenv.*")" in code source "(vfs:/content/env-test.war/WEB-INF/classes <no signer certificates>)" of "null")
> [Server:main-one] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> [Server:main-one] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> [Server:main-one] at java.lang.System.getenv(System.java:944) [rt.jar:1.8.0_60]
> [Server:main-one] at org.jboss.as.test.integration.domain.suites.EnvironmentTestServlet.doGet(EnvironmentTestServlet.java:44) [classes:]
> [Server:main-one] at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
> [Server:main-one] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> [Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> [Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_60]
> [Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> [Server:main-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> [Server:main-one] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (JGRP-1605) API changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1605?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1605:
---------------------------
Description:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
was:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
> API changes
> -----------
>
> Key: JGRP-1605
> URL: https://issues.jboss.org/browse/JGRP-1605
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> API changes to be done in 4.0, which break code:
> * MessageDispatcher: remove MessageListener
> * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * DONE: Remove @Deprecated methods, properties or classes
> * Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
> * Make {{RspFilter}} --> {{RspFilter<T>}}
> * {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
> * Request<T>
> * RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (JGRP-1605) API changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1605?page=com.atlassian.jira.plugin.... ]
Bela Ban reopened JGRP-1605:
----------------------------
> API changes
> -----------
>
> Key: JGRP-1605
> URL: https://issues.jboss.org/browse/JGRP-1605
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> API changes to be done in 4.0, which break code:
> * MessageDispatcher: remove MessageListener
> * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * Remove @Deprecated methods, properties or classes
> * Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
> * Make {{RspFilter}} --> {{RspFilter<T>}}
> * {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
> * Request<T>
> * RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0