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.

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

ISPN-5900 CDI split up (common, remote and embedded) #4249

Closed

Conversation

slaskawi
Copy link
Contributor

@slaskawi slaskawi commented Apr 18, 2016

https://issues.jboss.org/browse/ISPN-5900

This is the final part of CDI refactoring - the split between embedded, remote and common. Now all modules have their own packages so there will be no clashes in OSGi.

However CDI embedded integration is not backwards compatible when using JBoss Modules (one will need to switch from org.infinispan.cdi to org.infinispan.cdi.embedded dependency declaration).

@galderz
Copy link
Member

galderz commented Apr 19, 2016

Needs rebasing

@galderz
Copy link
Member

galderz commented Apr 19, 2016

However CDI embedded integration is not backwards compatible when using JBoss Modules (one will need to switch from org.infinispan.cdi to org.infinispan.cdi.embedded dependency declaration).

^ Has this been agreed? I don't recall a thread in infinispan-dev list.

@slaskawi
Copy link
Contributor Author

Yes it was discussed long time ago but no official summary was been sent. Probably this would be a good moment to do it.

The best summary might be found in BZ1266832. So during the split of CDI module we moved all remote stuff to org.infinispan.cdi.remote package and left common and embedded in org.infinispan.cdi (we didn't want to break embedded cache use cases). However in that case we have infinispan-common and infinispan-embedded exposing the same package, which might break OSGi use cases. So in order to do things correctly, we need to shuffle packages one more time.

//cc @tristantarrant

@slaskawi
Copy link
Contributor Author

Rebasing

@slaskawi slaskawi force-pushed the ISPN-5900-CDI-package-refactoring branch from 1c0a165 to d7fdb88 Compare April 19, 2016 13:14
@danberindei
Copy link
Member

@slaskawi Can't we keep the old annotations as deprecated? It would be nice to have a major version with a documented alternative in place before forcing the users to change their code.

@slaskawi
Copy link
Contributor Author

@danberindei Those annotations should be used only internally (the code was refactored at some point between ISPN 7 and 8 if I recall correctly). Now the clients need to produce Configuration or Embedded/RemoteCacheManager, and that's all. Here is a nice example.

@danberindei
Copy link
Member

@slaskawi I see, It's fine by me then.

@tristantarrant
Copy link
Member

Two cdi/jcache errors:
CacheRemoveAllInterceptorTest.arquillianBeforeTest
CacheResultInterceptorTest.arquillianBeforeTest

@slaskawi
Copy link
Contributor Author

@tristantarrant After the rebase I couldn't reproduce those failures. Could you please make sure that you rebuilt all modules? Server build needs to be in sync with updated CDI integration modules.

@slaskawi slaskawi force-pushed the ISPN-5900-CDI-package-refactoring branch 2 times, most recently from 9d9d444 to 73bebca Compare April 28, 2016 09:32
@tristantarrant
Copy link
Member

I'm getting consistent failures in JCacheFailoverIT.testRemoteListener:63 » Transport Could not fetch transport

@slaskawi
Copy link
Contributor Author

slaskawi commented May 4, 2016

Those failures were probably fixed by #4258

@slaskawi slaskawi force-pushed the ISPN-5900-CDI-package-refactoring branch from 73bebca to d10f3ad Compare May 4, 2016 14:06
@slaskawi
Copy link
Contributor Author

slaskawi commented May 4, 2016

Rebased

@tristantarrant
Copy link
Member

Pushed to master. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants