Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Spring support for Runnable tasks #244

Closed
leimer opened this issue Aug 15, 2012 · 2 comments
Closed

Spring support for Runnable tasks #244

leimer opened this issue Aug 15, 2012 · 2 comments
Labels
[OLD]Team: Integration Type: Enhancement
Milestone
2.3

Comments

@leimer
Copy link
Contributor

leimer commented Aug 15, 2012

It would be nice if we had Spring support in Runnable tasks. Currently this @SpringAware is not recognized by SpringManagedContext because the Runnable is wrapped into a DistributedRunnableAdapter.
@leimer
Copy link
Contributor Author

leimer commented Aug 15, 2012

pull request #243 contains now a fix for this issue too.

I'd like to mention, that DistributedRunnableAdapter is now a mutable interface!
There are two other ways to achieve the initialization of the Runnable:

  • Reflection: In my opinion this is the most ugly way because it exposes implementation details and is not trackable.
  • new DistributedRunnableAdapter: This would be preserve the immutability of the adapter, but we have to take care that everything gets copied into the new instance. Additionally every change in the adapter has to be respected in SpringManagedContext as well.

This considerations are the reasons for my implementation. Are you with me?

@mdogan
Copy link
Contributor

mdogan commented Aug 15, 2012

I'm ok with your implementation.

Thanks for the patch.

@mdogan mdogan closed this as completed Aug 15, 2012
SeriyBg pushed a commit to SeriyBg/hazelcast that referenced this issue Jul 9, 2021
@dependabot
Bump mockito-core from 2.28.2 to 3.5.0 (hazelcast#244)
cf59646 
Bumps [mockito-core](https://github.com/mockito/mockito) from 2.28.2 to 3.5.0.
- [Release notes](https://github.com/mockito/mockito/releases)
- [Commits](mockito/mockito@v2.28.2...v3.5.0)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
SeriyBg pushed a commit to SeriyBg/hazelcast that referenced this issue Jul 9, 2021
@dependabot
Bump actions/cache from 2.1.5 to 2.1.6 (hazelcast#244)
693faf4 
Bumps [actions/cache](https://github.com/actions/cache) from 2.1.5 to 2.1.6.
- [Release notes](https://github.com/actions/cache/releases)
- [Commits](actions/cache@v2.1.5...v2.1.6)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
devOpsHazelcast pushed a commit that referenced this issue Dec 20, 2023
@pveentjer @actions-user
[TPC] Fix NPE on onFinishConnect. (#244)
691026c 
The problem was that with the NioAsyncSocket onFinishConnect, the
OP_CONNECT was not removed from the interest-set since we just added the
OP_READ to the interest-set.

This has been changed: we only care for OP_READ and need to remove
anything else.

This unwanted remaining registration of the OP_CONNECT leads to an
OP_CONNECT ready event when the socket closes. And this is when it will
run into an NPE because connectFuture is null (since that field is
nulled after the connect).

The NPE only leads to noise in the log when closing a socket. Has no
other consequences.

Fixes https://github.com/hazelcast/hazelcast-mono/issues/243

GitOrigin-RevId: 759e67be38b2fbc13d8827289588ca87abcdc9d7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
[OLD]Team: Integration Type: Enhancement
Projects
None yet
Milestone
2.3
Development

No branches or pull requests
2 participants
@mdogan @leimer