Re: [infinispan-dev] Last Infinispan 5.1 'Brahma' CR is out!

[Kevin Pollet]

Hi,

This is bit strange because the CI job compile with no errors.

After looking at your trace it seems that Maven tries to download the
artifact on central. AFAIK, seam-bom is not present on central but it is on
JBoss repository (
https://repository.jboss.org/nexus/index.html#nexus-search;gav~org.jboss.seam~seam-bom~3.1.0.CR1~~
)

It seems that something wrong happened with repositories.
Have you try to remove references to solder-impl and seam-bom in your local
repository and start a new compilation?

--Kevin

On 11 January 2012 13:58, Manik Surtani  wrote:

> This is on master?
>
> On 10 Jan 2012, at 19:25, Pedro Ruivo wrote:
>
> > Hi guys,
> >
> > I've got an error when compiling ispn. The maven trace is below.
> >
> > Thanks.
> >
> > cheers,
> > Pedro
> >
> > -
> >
> > [INFO]
> > 
> > [INFO] Building Infinispan CDI support
> > [INFO]task-segment: [clean, install]
> > [INFO]
> > 
> > [INFO] [clean:clean {execution: default-clean}]
> > Downloading:
> >
> http://repo1.maven.org/maven2/org/jboss/seam/seam-bom/3.1.0.CR1/seam-bom-3.1.0.CR1.pom
> > [INFO] Unable to find resource 'org.jboss.seam:seam-bom:pom:3.1.0.CR1'
> > in repository central (http://repo1.maven.org/maven2)
> > [INFO]
> > 
> > [ERROR] BUILD ERROR
> > [INFO]
> > 
> > [INFO] Error building POM (may not be this project's POM).
> >
> >
> > Project ID: org.jboss.seam:seam-bom
> >
> > Reason: POM 'org.jboss.seam:seam-bom' not found in repository: Unable to
> > download the artifact from any repository
> >
> >   org.jboss.seam:seam-bom:pom:3.1.0.CR1
> >
> > from the specified remote repositories:
> >   central (http://repo1.maven.org/maven2)
> >
> >  for project org.jboss.seam:seam-bom
> >
> >
> > [INFO]
> > 
> > [INFO] Trace
> > org.apache.maven.lifecycle.LifecycleExecutionException: Unable to get
> > dependency information: Unable to read the metadata file for artifact
> > 'org.jboss.solder:solder-impl:jar': POM 'org.jboss.seam:seam-bom' not
> > found in repository: Unable to download the artifact from any repository
> >
> >   org.jboss.seam:seam-bom:pom:3.1.0.CR1
> >
> > from the specified remote repositories:
> >   central (http://repo1.maven.org/maven2)
> >
> >  for project org.jboss.seam:seam-bom
> >   org.jboss.solder:solder-impl:jar:3.1.0.CR1
> >
> > from the specified remote repositories:
> >   central (http://repo1.maven.org/maven2),
> >   jboss-public-repository
> > (https://repository.jboss.org/nexus/content/groups/public),
> >   jboss-deprecated-repository
> > (https://repository.jboss.org/nexus/content/repositories/deprecated/)
> >
> > Path to dependency:
> > 1) org.infinispan:infinispan-cdi:bundle:5.1.0-SNAPSHOT
> >
> >
> > at
> >
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711)
> > at
> >
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> > at
> >
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> > at
> >
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> > at
> >
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> > at
> >
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> > at
> > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:597)
> > at
> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> > at
> > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> > at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> > Caused by:
> > org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable
> > to get dependency information: Unable to read the metadata file for
> > artifact 'org.jboss.solder:solder-impl:jar': POM
> > 'org.jboss.seam:seam-bom' not found in repository: Unable to download
> > the artifact from any repos

Re: [infinispan-dev] Fwd: [JBoss JIRA] (ISPN-1562) Alternative needed for Cache.getConfiguration()

[Kevin Pollet]

Hi,

Just for the record, I think there is the same problem with the
EmbeddedCacheManager#getDefaultConfiguration() method.

--Kevin

On 24 November 2011 10:53, Pete Muir  wrote:

> All,
>
> Any ideas on the below? Issue is that the sane name for this method is
> getConfiguration() but this name is already taken. Options I see are:
>
> 1) Use another name (ugh)
> 2) Swap the return types with no deprecation stage (ugh)
>
> Any better ideas?
>
> Begin forwarded message:
>
> > From: Galder Zamarreño (Created) (JIRA) 
> > Subject: [JBoss JIRA] (ISPN-1562) Alternative needed for
> Cache.getConfiguration()
> > Date: 24 November 2011 09:51:41 GMT
> > To: pm...@bleepbleep.org.uk
> >
> > Alternative needed for Cache.getConfiguration()
> > ---
> >
> > Key: ISPN-1562
> > URL: https://issues.jboss.org/browse/ISPN-1562
> > Project: Infinispan
> >  Issue Type: Bug
> >  Components: Configuration, Core API
> >Affects Versions: 5.1.0.BETA5
> >Reporter: Galder Zamarreño
> >Assignee: Pete Muir
> > Fix For: 5.1.0.CR1
> >
> >
> > Provide an alternative way of retrieving a Cache's configuration instead
> of deprecated Cache.getConfiguration()
> >
> > --
> > This message is automatically generated by JIRA.
> > If you think it was sent incorrectly, please contact your JIRA
> administrators:
> https://issues.jboss.org/secure/ContactAdministrators!default.jspa
> > For more information on JIRA, see:
> http://www.atlassian.com/software/jira
> >
> >
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Reminders about GIT

[Kevin Pollet]

+1
ROFL!

--Kevin

On 27 October 2011 14:22, Manik Surtani  wrote:

> Sanne - you should add this as a warning section to
> https://docs.jboss.org/author/display/ISPN/Contributing+-+Source+Control
>  :-)
>
> On 18 Oct 2011, at 16:09, Sanne Grinovero wrote:
>
> 1) If you have warnings about "Merge made by recursive" you have to
> fix it rebasing.
>
> 2) If you have warnings about "non-fast-forward" you have to rebase.
>
> 3) If you see "non-fast-forward updates were rejected" you shall never
> use "force" on upstream! It means that another patch was merged before
> you and you have to update your master again, and rebase again.
>
> 4) "force" is allowed only in special maintenance circumstances. If
> you find you're needing it to handle a pull request, then you're doing
> it wrong, and the mistake might be a dangerous one. It's like the good
> rule of never commit when you're drunk (coding is allowed).
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Manik Surtani
> ma...@jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Abstracting javax.cache.annotation.CacheKey away from the user?

[Kevin Pollet]

Hi,

On 25 October 2011 18:11, Galder Zamarreño  wrote:

>
> On Oct 24, 2011, at 4:58 PM, Kevin Pollet wrote:
>
> > On 24 October 2011 16:51, Peter Muir  wrote:
> > If we didnt use any jsr107 annotations with this cache.
> >
> > Without any jsr107 annotations it works fine :-)
> >
> > I've just got an idea, what do you think about providing a
> SingleCacheKey interface (which extends CacheKey) used when only one
> value is used as a key?
> >
> > This interface could provide an additionnal method "T getValue"?
>
> +1
>
> Should be pretty straightfoward to implement for single type based keys as
> well.
>
>
I've opened ISPN-1491 <https://issues.jboss.org/browse/ISPN-1491> for
that. Any comments are welcome!


>  >
> >
> > --
> > Pete Muir
> > http://in.relation.to/Bloggers/Pete
> >
> > On 24 Oct 2011, at 16:38, Kevin Pollet  wrote:
> >
> >> On 24 October 2011 16:30, Pete Muir  wrote:
> >> This is just because you are interacting with the JSR-107 managed cache.
> If we used a general purpose cache, this wouldn't be a problem right?
> >>
> >> This is because the interceptors are defined like that in JSR-107.
> >> I'm not sure to understand "If we used a general purpose cache, this
> wouldn't be a problem"?
> >>
> >>
> >> On 24 Oct 2011, at 16:25, Kevin Pollet wrote:
> >>
> >> > Hi Galder,
> >> >
> >> > On 24 October 2011 15:15, Galder Zamarreño  wrote:
> >> > Pete/Kevin,
> >> >
> >> > Looking at the Infinispan CDI quickstart, I see:
> >> >
> >> >   @GreetingCache
> >> >   private Cache cache;
> >> >
> >> > The key that the user really uses here is String. So, could that be
> defined like this?
> >> >
> >> >   @GreetingCache
> >> >   private Cache cache;
> >> >
> >> > Btw, I've just tried this and when using the key I get:
> >> >
> >> > Caused by: java.lang.ClassCastException:
> org.infinispan.cdi.interceptor.DefaultCacheKey cannot be cast to
> java.lang.String
> >> >
> >> > Are we forcing the user to dephicer what's in CacheKey? Related to
> this, looking at org.infinispan.cdi.interceptor.DefaultCacheKey I see no way
> to retrieve individual elements of a key.
> >> >
> >> > That's how it's defined in JSR-107 specification "All generated cache
> keys must implement the CacheKey interface."
> >> >
> >> > If you look at the CacheKey contract there is no methods defined to
> retrieve the content of the key. Here we could provide our own methods but
> the user will be implementation dependent. Maybe you could raise this point
> on JSR-107 mailing list, an unwrap method could be defined in the CacheKey
> contract to use specific implementation features.
> >> >
> >> > Pete, Manik?
> >> >
> >> >
> >> > My point here is whether we can avoid leaking
> javax.cache.annotation.CacheKey to the user cos it can do little with it
> without being able to get its contents.
> >> > I see there;s a way to define a custom key, but that should not be
> necessary for a simple key based on a String for example.
> >> >
> >> > I'm not sure we can avoid the use of CacheKey since it's defined like
> that in the spec. As said before we can provide at least our own methods in
> the DefaultCacheKey implementation (open an issue and I'll do it).
> >> >
> >> >
> >> > Cheers,
> >> > --
> >> > Galder Zamarreño
> >> > Sr. Software Engineer
> >> > Infinispan, JBoss Cache
> >> >
> >> >
> >> > --Kevin
> >>
> >>
> >
> > ___
> > infinispan-dev mailing list
> > infinispan-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--Kevin
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Abstracting javax.cache.annotation.CacheKey away from the user?

[Kevin Pollet]

On 24 October 2011 16:51, Peter Muir  wrote:

> If we didnt use any jsr107 annotations with this cache.
>

Without any jsr107 annotations it works fine :-)

I've just got an idea, what do you think about providing a SingleCacheKey
interface (which extends CacheKey) used when only one value is used as a
key?

This interface could provide an additionnal method "T getValue"?


>
>
--
> Pete Muir
> http://in.relation.to/Bloggers/Pete
>
> On 24 Oct 2011, at 16:38, Kevin Pollet  wrote:
>
> On 24 October 2011 16:30, Pete Muir  wrote:
>
>> This is just because you are interacting with the JSR-107 managed cache.
>> If we used a general purpose cache, this wouldn't be a problem right?
>>
>
> This is because the interceptors are defined like that in JSR-107.
> I'm not sure to understand "If we used a general purpose cache, this
> wouldn't be a problem"?
>
>
>>
>> On 24 Oct 2011, at 16:25, Kevin Pollet wrote:
>>
>> > Hi Galder,
>> >
>> > On 24 October 2011 15:15, Galder Zamarreño  wrote:
>> > Pete/Kevin,
>> >
>> > Looking at the Infinispan CDI quickstart, I see:
>> >
>> >   @GreetingCache
>> >   private Cache cache;
>> >
>> > The key that the user really uses here is String. So, could that be
>> defined like this?
>> >
>> >   @GreetingCache
>> >   private Cache cache;
>> >
>> > Btw, I've just tried this and when using the key I get:
>> >
>> > Caused by: java.lang.ClassCastException:
>> org.infinispan.cdi.interceptor.DefaultCacheKey cannot be cast to
>> java.lang.String
>> >
>> > Are we forcing the user to dephicer what's in CacheKey? Related to this,
>> looking at org.infinispan.cdi.interceptor.DefaultCacheKey I see no way to
>> retrieve individual elements of a key.
>> >
>> > That's how it's defined in JSR-107 specification "All generated cache
>> keys must implement the CacheKey interface."
>> >
>> > If you look at the CacheKey contract there is no methods defined to
>> retrieve the content of the key. Here we could provide our own methods but
>> the user will be implementation dependent. Maybe you could raise this point
>> on JSR-107 mailing list, an unwrap method could be defined in the CacheKey
>> contract to use specific implementation features.
>> >
>> > Pete, Manik?
>> >
>> >
>> > My point here is whether we can avoid leaking
>> javax.cache.annotation.CacheKey to the user cos it can do little with it
>> without being able to get its contents.
>> > I see there;s a way to define a custom key, but that should not be
>> necessary for a simple key based on a String for example.
>> >
>> > I'm not sure we can avoid the use of CacheKey since it's defined like
>> that in the spec. As said before we can provide at least our own methods in
>> the DefaultCacheKey implementation (open an issue and I'll do it).
>> >
>> >
>> > Cheers,
>> > --
>> > Galder Zamarreño
>> > Sr. Software Engineer
>> > Infinispan, JBoss Cache
>> >
>> >
>> > --Kevin
>>
>>
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Abstracting javax.cache.annotation.CacheKey away from the user?

[Kevin Pollet]

On 24 October 2011 16:30, Pete Muir  wrote:

> This is just because you are interacting with the JSR-107 managed cache. If
> we used a general purpose cache, this wouldn't be a problem right?
>

This is because the interceptors are defined like that in JSR-107.
I'm not sure to understand "If we used a general purpose cache, this
wouldn't be a problem"?


>
> On 24 Oct 2011, at 16:25, Kevin Pollet wrote:
>
> > Hi Galder,
> >
> > On 24 October 2011 15:15, Galder Zamarreño  wrote:
> > Pete/Kevin,
> >
> > Looking at the Infinispan CDI quickstart, I see:
> >
> >   @GreetingCache
> >   private Cache cache;
> >
> > The key that the user really uses here is String. So, could that be
> defined like this?
> >
> >   @GreetingCache
> >   private Cache cache;
> >
> > Btw, I've just tried this and when using the key I get:
> >
> > Caused by: java.lang.ClassCastException:
> org.infinispan.cdi.interceptor.DefaultCacheKey cannot be cast to
> java.lang.String
> >
> > Are we forcing the user to dephicer what's in CacheKey? Related to this,
> looking at org.infinispan.cdi.interceptor.DefaultCacheKey I see no way to
> retrieve individual elements of a key.
> >
> > That's how it's defined in JSR-107 specification "All generated cache
> keys must implement the CacheKey interface."
> >
> > If you look at the CacheKey contract there is no methods defined to
> retrieve the content of the key. Here we could provide our own methods but
> the user will be implementation dependent. Maybe you could raise this point
> on JSR-107 mailing list, an unwrap method could be defined in the CacheKey
> contract to use specific implementation features.
> >
> > Pete, Manik?
> >
> >
> > My point here is whether we can avoid leaking
> javax.cache.annotation.CacheKey to the user cos it can do little with it
> without being able to get its contents.
> > I see there;s a way to define a custom key, but that should not be
> necessary for a simple key based on a String for example.
> >
> > I'm not sure we can avoid the use of CacheKey since it's defined like
> that in the spec. As said before we can provide at least our own methods in
> the DefaultCacheKey implementation (open an issue and I'll do it).
> >
> >
> > Cheers,
> > --
> > Galder Zamarreño
> > Sr. Software Engineer
> > Infinispan, JBoss Cache
> >
> >
> > --Kevin
>
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Abstracting javax.cache.annotation.CacheKey away from the user?

[Kevin Pollet]

Hi Galder,

On 24 October 2011 15:15, Galder Zamarreño  wrote:

> Pete/Kevin,
>
> Looking at the Infinispan CDI quickstart, I see:
>
>   @GreetingCache
>   private Cache cache;
>
> The key that the user really uses here is String. So, could that be defined
> like this?
>
>   @GreetingCache
>   private Cache cache;
>
> Btw, I've just tried this and when using the key I get:
>
> Caused by: java.lang.ClassCastException:
> org.infinispan.cdi.interceptor.DefaultCacheKey cannot be cast to
> java.lang.String
>
> Are we forcing the user to dephicer what's in CacheKey? Related to this,
> looking at org.infinispan.cdi.interceptor.DefaultCacheKey I see no way to
> retrieve individual elements of a key.
>

That's how it's defined in JSR-107 specification "All generated cache keys
must implement the CacheKey interface."

If you look at the CacheKey
contract
there is no methods defined to retrieve the content of the key. Here we
could provide our own methods but the user will be implementation dependent.
Maybe you could raise this point on JSR-107 mailing list, an unwrap method
could be defined in the *CacheKey *contract to use specific implementation
features.

Pete, Manik?


>
> My point here is whether we can avoid leaking
> javax.cache.annotation.CacheKey to the user cos it can do little with it
> without being able to get its contents.

I see there;s a way to define a custom key, but that should not be necessary
> for a simple key based on a String for example.
>

I'm not sure we can avoid the use of CacheKey since it's defined like that
in the spec. As said before we can provide at least our own methods in
the *DefaultCacheKey
*implementation (open an issue and I'll do it).


>
> Cheers,
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
--Kevin
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CDI support

[Kevin Pollet]

 Hi guys,

I will be really pleased to work on docs and on a blog post :-)
What's the process for the docs? (I've seen that documentations are now on 
Confluence)
I presume that I need an editor account, right? or if you prefer I can write 
the docs and Pete will post it?

--Kevin

Le jeudi 14 juillet 2011 à 11:47, Pete Muir a écrit :

>  
> On 14 Jul 2011, at 10:36, Manik Surtani wrote:
>  
> > +1, I think so too.
> >  
> > If you have the time, could you go ahead and merge it in to master? Some 
> > docs with examples + a blog about it would be awesome too. :) I presume 
> > this is something Kevin would do?
>  
> I'll work with Kevin on this :-)
>  
> >  
> > On 13 Jul 2011, at 18:36, Sanne Grinovero wrote:
> >  
> > > Since you're the expert, if you like it and you think people could
> > > start using it, why not in 5.0 ?
> > > Being a tech preview and there are no related changes on the other
> > > modules, I think that would be fine.
> > >  
> > > Sanne
> > >  
> > > 2011/7/13 Pete Muir mailto:pm...@redhat.com)>:
> > > > Kevin has completed this up a pretty good standard, so I think it's 
> > > > ready to merge. Do we want to try to slip this into Infinispan 5? It's 
> > > > a separate module so should have no impact on the rest of the code 
> > > > base. I would label it a tech preview, moving to final status in 5.1 
> > > > but it will give people a taster.
> > > >  
> > > > WDYT?
> > > > ___
> > > > infinispan-dev mailing list
> > > > infinispan-dev@lists.jboss.org (mailto:infinispan-dev@lists.jboss.org)
> > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > >  
> > > ___
> > > infinispan-dev mailing list
> > > infinispan-dev@lists.jboss.org (mailto:infinispan-dev@lists.jboss.org)
> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >  
> > --
> > Manik Surtani
> > ma...@jboss.org (mailto:ma...@jboss.org)
> > twitter.com/maniksurtani (http://twitter.com/maniksurtani)
> >  
> > Lead, Infinispan
> > http://www.infinispan.org
> >  
> >  
> >  
> >  
> > ___
> > infinispan-dev mailing list
> > infinispan-dev@lists.jboss.org (mailto:infinispan-dev@lists.jboss.org)
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>  
>  
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org (mailto:infinispan-dev@lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev