API, Commons, Core, OSGi, split packages, signed packages, etc
by Tristan Tarrant
Well, it seems like the creation of the -api and -commons artifacts is
causing a few problems (we knew about them, but we can no longer ignore
them):
- they have introduced split packages, i.e. classes in the same package
coming from multiple jar
- they cause breakage in the maven-bundle-plugin, forcing us to
temporarily disable OSGi bundles
- they cause problems with AS7's modular class loader which stops us
from keeping them separate
- they will not be allowed in EAP as jars there will have to be signed,
and currently they can't be
I have created an issue about this:
https://issues.jboss.org/browse/ISPN-1548
So we have two possible solutions:
- we put things back as they were, unsplitting the core artifact and
removing api and commons. This has minimal impact. I already have a
working pull for this: https://github.com/infinispan/infinispan/pull/667
- we properly refactor api and commons into their own packages. This
will cause considerable churn. I have a partial pull for this which does
it for -api, -commons and -core:
https://github.com/infinispan/infinispan/pull/665
Comments please
Tristan
Note: I really wanted the refactoring pull to have id 666 since it's
quite evil, but you can't have everything :)
13 years, 10 months
New config - next steps
by Pete Muir
All,
Now that the new config API is in, and the basic teething pains resolved (thanks to Mircea and Kevin!), this is my plan to eradicate the old config:
1) Convert test suite to use new config. This is a big job, so I'm going to ask for help on this! What I suggest is that I do a bit, and then we use this as an example/design. Anyone got a good suggestions about a good section for me to start in? (Not too in-depth domain knowledge needed, isolated, simpleish config)
2) Switch out parsers - with the test suite over this should reveal any problems in the parser
3) Switch out the usage of the config objects, changing from converting new -> legacy to vs. versa…
Pete
13 years, 10 months
adding new configuration options
by Mircea Markus
Hi,
I need to add a new configuration attribute for: https://issues.jboss.org/browse/ISPN-1297
Now that Pete's new Configuration structure is in place, wondering weather I should a) add it to both old and new hierarchy or b) add it only to the new hierarchy.
b) sounds more sensible to me, as there's no point in maintaining deprecated API. And this would also motivate users to switch to the new config - which is also not bad.
Cheers,
Mircea
13 years, 10 months
JAXB error during schema generation
by Mircea Markus
After updating from Git I get the following error[1]
Guess it has to do with the new config changes?
[1]
Generating schema file in /Users/mmarkus/github/ispn/core/src/main/resources/schema
Failed generating schema file com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 3 counts of IllegalAnnotationExceptions
JAXB annotation is placed on a method that is not a JAXB property
this problem is related to the following location:
at @javax.xml.bind.annotation.XmlAttribute(name=##default, required=false, namespace=##default)
at org.infinispan.config.GlobalConfiguration$ExecutorFactoryType
at org.infinispan.config.GlobalConfiguration$ExecutorFactoryType org.infinispan.config.GlobalConfiguration.asyncListenerExecutor
at org.infinispan.config.GlobalConfiguration
at private final org.infinispan.config.GlobalConfiguration org.infinispan.config.InfinispanConfiguration.global
at org.infinispan.config.InfinispanConfiguration
JAXB annotation is placed on a method that is not a JAXB property
this problem is related to the following location:
at @javax.xml.bind.annotation.XmlElement(nillable=false, name=properties, required=false, defaultValue=, type=class javax.xml.bind.annotation.XmlElement$DEFAULT, namespace=##default)
at org.infinispan.config.GlobalConfiguration$FactoryClassWithPropertiesType
at org.infinispan.config.GlobalConfiguration$ExecutorFactoryType
at org.infinispan.config.GlobalConfiguration$ExecutorFactoryType org.infinispan.config.GlobalConfiguration.asyncListenerExecutor
at org.infinispan.config.GlobalConfiguration
at private final org.infinispan.config.GlobalConfiguration org.infinispan.config.InfinispanConfiguration.global
at org.infinispan.config.InfinispanConfiguration
JAXB annotation is placed on a method that is not a JAXB property
this problem is related to the following location:
at @javax.xml.bind.annotation.XmlAttribute(name=##default, required=false, namespace=##default)
at org.infinispan.config.GlobalConfiguration$ScheduledExecutorFactoryType
at org.infinispan.config.GlobalConfiguration$ScheduledExecutorFactoryType org.infinispan.config.GlobalConfiguration.evictionScheduledExecutor
at org.infinispan.config.GlobalConfiguration
at private final org.infinispan.config.GlobalConfiguration org.infinispan.config.InfinispanConfiguration.global
at org.infinispan.config.InfinispanConfiguration
com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 3 counts of IllegalAnnotationExceptions
JAXB annotation is placed on a method that is not a JAXB property
this problem is related to the following location:
at @javax.xml.bind.annotation.XmlAttribute(name=##default, required=false, namespace=##default)
at org.infinispan.config.GlobalConfiguration$ExecutorFactoryType
at org.infinispan.config.GlobalConfiguration$ExecutorFactoryType org.infinispan.config.GlobalConfiguration.asyncListenerExecutor
at org.infinispan.config.GlobalConfiguration
at private final org.infinispan.config.GlobalConfiguration org.infinispan.config.InfinispanConfiguration.global
at org.infinispan.config.InfinispanConfiguration
JAXB annotation is placed on a method that is not a JAXB property
this problem is related to the following location:
at @javax.xml.bind.annotation.XmlElement(nillable=false, name=properties, required=false, defaultValue=, type=class javax.xml.bind.annotation.XmlElement$DEFAULT, namespace=##default)
at org.infinispan.config.GlobalConfiguration$FactoryClassWithPropertiesType
at org.infinispan.config.GlobalConfiguration$ExecutorFactoryType
at org.infinispan.config.GlobalConfiguration$ExecutorFactoryType org.infinispan.config.GlobalConfiguration.asyncListenerExecutor
at org.infinispan.config.GlobalConfiguration
at private final org.infinispan.config.GlobalConfiguration org.infinispan.config.InfinispanConfiguration.global
at org.infinispan.config.InfinispanConfiguration
JAXB annotation is placed on a method that is not a JAXB property
this problem is related to the following location:
at @javax.xml.bind.annotation.XmlAttribute(name=##default, required=false, namespace=##default)
at org.infinispan.config.GlobalConfiguration$ScheduledExecutorFactoryType
at org.infinispan.config.GlobalConfiguration$ScheduledExecutorFactoryType org.infinispan.config.GlobalConfiguration.evictionScheduledExecutor
at org.infinispan.config.GlobalConfiguration
at private final org.infinispan.config.GlobalConfiguration org.infinispan.config.InfinispanConfiguration.global
at org.infinispan.config.InfinispanConfiguration
at com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:91)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:436)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1100)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:143)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:110)
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 javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:376)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at org.infinispan.util.JaxbSchemaGenerator.main(JaxbSchemaGenerator.java:59)
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.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:290)
at java.lang.Thread.run(Thread.java:680)
13 years, 10 months
performance issue when using return types
by Mircea Markus
Hi,
The DistributionInterceptor can be simplified significantly now that we are supporting transactional or non transactional caches.
Looking at it I've found an significant performance issues though: seems like for each put we do, if the unreliableReturnValues is disabled (that's the default, i.e. disabled) then we do a remote get and then a put, i.e. 2 RPCs to the same remote node. That seems to be highly inefficient so just wondering is there any reason not to piggyback the return value on the put itself?
Cheers,
Mircea
13 years, 10 months
