[JBoss JIRA] (WFLY-1416) Cross site replication requires totally connected graph of sites/routes
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1416?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1416 at 5/29/13 12:37 PM:
---------------------------------------------------------------------
Bela is looking to see if there is a non-performance impacting solution to this at the JGroups level.
One AS level option would be to either:
(i) require a totally connected graph
(ii) if not totally connected, allow specifying site indices in XML with the remote-site element
was (Author: rachmato):
Bela is looking to see if there is a non-performance impacting solution to this at the JGroups level.
One option would be to either:
(i) require a totally connected graph
(ii) if not totally connected, allow specifying site indices in XML with the remote-site element
> Cross site replication requires totally connected graph of sites/routes
> ------------------------------------------------------------------------
>
> Key: WFLY-1416
> URL: https://issues.jboss.org/browse/WFLY-1416
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha2
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
>
> Cross site replication is configured using JGroups subsystem <relay/> and <remote-site/> elements to define sites and multicast relay routes between sites.
> Looking at a site/route configuration as a graph of nodes and edges, xsite only works if this graph is totally connected (i.e. every site has a defined direct route to every other site). This is because <site name> -> <site id> mappings are assigned per node, with no agreement on what is happening at other nodes.
> For example, this configuration works:
> <relay site="LON">
> <remote-site name="NYC" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="NYC">
> <remote-site name="LON" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="SFO">
> <remote-site name="NYC" .../>
> <remote-site name="LON" .../>
> </relay>
> but this configuration does not:
> <relay site="LON">
> <remote-site name="NYC" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="NYC">
> <remote-site name="LON" .../>
> </relay>
> <relay site="SFO">
> <remote-site name="LON" .../>
> </relay>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (WFLY-1416) Cross site replication requires totally connected graph of sites/routes
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1416?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1416 at 5/29/13 12:36 PM:
---------------------------------------------------------------------
Bela is looking to see if there is a non-performance impacting solution to this at the JGroups level.
One option would be to either:
(i) require a totally connected graph
(ii) if not totally connected, allow specifying site indices in XML with the remote-site element
was (Author: rachmato):
Bela is looking to see if there is a non-performance impacting solution to this.
> Cross site replication requires totally connected graph of sites/routes
> ------------------------------------------------------------------------
>
> Key: WFLY-1416
> URL: https://issues.jboss.org/browse/WFLY-1416
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha2
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
>
> Cross site replication is configured using JGroups subsystem <relay/> and <remote-site/> elements to define sites and multicast relay routes between sites.
> Looking at a site/route configuration as a graph of nodes and edges, xsite only works if this graph is totally connected (i.e. every site has a defined direct route to every other site). This is because <site name> -> <site id> mappings are assigned per node, with no agreement on what is happening at other nodes.
> For example, this configuration works:
> <relay site="LON">
> <remote-site name="NYC" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="NYC">
> <remote-site name="LON" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="SFO">
> <remote-site name="NYC" .../>
> <remote-site name="LON" .../>
> </relay>
> but this configuration does not:
> <relay site="LON">
> <remote-site name="NYC" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="NYC">
> <remote-site name="LON" .../>
> </relay>
> <relay site="SFO">
> <remote-site name="LON" .../>
> </relay>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (WFLY-1416) Cross site replication requires totally connected graph of sites/routes
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1416?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-1416:
-------------------------------------------
Bela is looking to see if there is a non-performance impacting solution to this.
> Cross site replication requires totally connected graph of sites/routes
> ------------------------------------------------------------------------
>
> Key: WFLY-1416
> URL: https://issues.jboss.org/browse/WFLY-1416
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha2
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
>
> Cross site replication is configured using JGroups subsystem <relay/> and <remote-site/> elements to define sites and multicast relay routes between sites.
> Looking at a site/route configuration as a graph of nodes and edges, xsite only works if this graph is totally connected (i.e. every site has a defined direct route to every other site). This is because <site name> -> <site id> mappings are assigned per node, with no agreement on what is happening at other nodes.
> For example, this configuration works:
> <relay site="LON">
> <remote-site name="NYC" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="NYC">
> <remote-site name="LON" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="SFO">
> <remote-site name="NYC" .../>
> <remote-site name="LON" .../>
> </relay>
> but this configuration does not:
> <relay site="LON">
> <remote-site name="NYC" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="NYC">
> <remote-site name="LON" .../>
> </relay>
> <relay site="SFO">
> <remote-site name="LON" .../>
> </relay>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (WFLY-1416) Cross site replication requires totally connected graph of sites/routes
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1416?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-1416:
-------------------------------------------
The results of running probe.sh on the first example above:
{noformat}
[nrla@lenovo bin]$ ./probe.sh -addr 224.0.75.75 op=RELAY2.printRoutes
-- send probe on /224.0.75.75:7500
#1 (211 bytes):
local_addr=LON-1/web [54877f5a-7378-f542-fec5-8b89af0b6d89]
cluster=web
RELAY2.printRoutes=n/a (not site master)
physical_addr=127.0.0.1:55300
view=[LON-0/web|1] [LON-0/web, LON-1/web]
version=3.3.0.Final
#2 (274 bytes):
local_addr=LON-0/web [a033d27d-6af1-3ec7-7ee2-3241e4e62978]
cluster=web
RELAY2.printRoutes=LON --> _LON-0/web:LON [UP]
NYC --> _NYC-0/web:NYC [UP]
SFO --> _SFO-0/web:SFO [UP]
physical_addr=127.0.0.1:55200
view=[LON-0/web|1] [LON-0/web, LON-1/web]
version=3.3.0.Final
#3 (263 bytes):
local_addr=NYC-0/web [b287afd9-70a6-81cd-65ca-561838aaa51f]
cluster=web
RELAY2.printRoutes=LON --> _LON-0/web:LON [UP]
NYC --> _NYC-0/web:NYC [UP]
SFO --> _SFO-0/web:SFO [UP]
physical_addr=127.0.0.1:55400
view=[NYC-0/web|0] [NYC-0/web]
version=3.3.0.Final
#4 (263 bytes):
local_addr=SFO-0/web [b8e9a2ce-72b7-7c14-e420-9276912f827b]
cluster=web
RELAY2.printRoutes=LON --> _LON-0/web:LON [UP]
NYC --> _NYC-0/web:NYC [UP]
SFO --> _SFO-0/web:SFO [UP]
physical_addr=127.0.0.1:55500
view=[SFO-0/web|0] [SFO-0/web]
version=3.3.0.Final
4 responses (4 matches, 0 non matches)
{noformat}
> Cross site replication requires totally connected graph of sites/routes
> ------------------------------------------------------------------------
>
> Key: WFLY-1416
> URL: https://issues.jboss.org/browse/WFLY-1416
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha2
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
>
> Cross site replication is configured using JGroups subsystem <relay/> and <remote-site/> elements to define sites and multicast relay routes between sites.
> Looking at a site/route configuration as a graph of nodes and edges, xsite only works if this graph is totally connected (i.e. every site has a defined direct route to every other site). This is because <site name> -> <site id> mappings are assigned per node, with no agreement on what is happening at other nodes.
> For example, this configuration works:
> <relay site="LON">
> <remote-site name="NYC" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="NYC">
> <remote-site name="LON" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="SFO">
> <remote-site name="NYC" .../>
> <remote-site name="LON" .../>
> </relay>
> but this configuration does not:
> <relay site="LON">
> <remote-site name="NYC" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="NYC">
> <remote-site name="LON" .../>
> </relay>
> <relay site="SFO">
> <remote-site name="LON" .../>
> </relay>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (WFLY-1416) Cross site replication requires totally connected graph of sites/routes
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1416?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-1416:
-------------------------------------------
The results of running probe.sh on the second example above:
{noformat}
[nrla@lenovo bin]$ ./probe.sh -addr 224.0.75.75 op=RELAY2.printRoutes
-- send probe on /224.0.75.75:7500
#1 (235 bytes):
local_addr=SFO-0/web [b6c19793-46f8-1896-139c-4951cece8f15]
cluster=web
RELAY2.printRoutes=LON --> _LON-0/web:LON [UP]
SFO --> _SFO-0/web:SFO [UP]
physical_addr=127.0.0.1:55500
view=[SFO-0/web|0] [SFO-0/web]
version=3.3.0.Final
#2 (235 bytes):
local_addr=NYC-0/web [053e32af-c686-095a-e2ae-72daec24ea87]
cluster=web
RELAY2.printRoutes=LON --> _LON-0/web:LON [UP]
NYC --> _SFO-0/web:NYC [UP]
physical_addr=127.0.0.1:55400
view=[NYC-0/web|0] [NYC-0/web]
version=3.3.0.Final
#3 (261 bytes):
local_addr=LON-0/web [065795d7-1e4b-0f8a-438a-02d600684429]
cluster=web
RELAY2.printRoutes=LON --> _LON-0/web:LON [UP]
NYC --> _SFO-0/web:NYC [UP]
SFO --> [DOWN]
physical_addr=127.0.0.1:55200
view=[LON-0/web|1] [LON-0/web, LON-1/web]
version=3.3.0.Final
3 responses (3 matches, 0 non matches)
{noformat}
> Cross site replication requires totally connected graph of sites/routes
> ------------------------------------------------------------------------
>
> Key: WFLY-1416
> URL: https://issues.jboss.org/browse/WFLY-1416
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha2
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
>
> Cross site replication is configured using JGroups subsystem <relay/> and <remote-site/> elements to define sites and multicast relay routes between sites.
> Looking at a site/route configuration as a graph of nodes and edges, xsite only works if this graph is totally connected (i.e. every site has a defined direct route to every other site). This is because <site name> -> <site id> mappings are assigned per node, with no agreement on what is happening at other nodes.
> For example, this configuration works:
> <relay site="LON">
> <remote-site name="NYC" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="NYC">
> <remote-site name="LON" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="SFO">
> <remote-site name="NYC" .../>
> <remote-site name="LON" .../>
> </relay>
> but this configuration does not:
> <relay site="LON">
> <remote-site name="NYC" .../>
> <remote-site name="SFO" .../>
> </relay>
> <relay site="NYC">
> <remote-site name="LON" .../>
> </relay>
> <relay site="SFO">
> <remote-site name="LON" .../>
> </relay>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (WFLY-1416) Cross site replication requires totally connected graph of sites/routes
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created WFLY-1416:
-----------------------------------------
Summary: Cross site replication requires totally connected graph of sites/routes
Key: WFLY-1416
URL: https://issues.jboss.org/browse/WFLY-1416
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 8.0.0.Alpha2
Reporter: Richard Achmatowicz
Assignee: Paul Ferraro
Cross site replication is configured using JGroups subsystem <relay/> and <remote-site/> elements to define sites and multicast relay routes between sites.
Looking at a site/route configuration as a graph of nodes and edges, xsite only works if this graph is totally connected (i.e. every site has a defined direct route to every other site). This is because <site name> -> <site id> mappings are assigned per node, with no agreement on what is happening at other nodes.
For example, this configuration works:
<relay site="LON">
<remote-site name="NYC" .../>
<remote-site name="SFO" .../>
</relay>
<relay site="NYC">
<remote-site name="LON" .../>
<remote-site name="SFO" .../>
</relay>
<relay site="SFO">
<remote-site name="NYC" .../>
<remote-site name="LON" .../>
</relay>
but this configuration does not:
<relay site="LON">
<remote-site name="NYC" .../>
<remote-site name="SFO" .../>
</relay>
<relay site="NYC">
<remote-site name="LON" .../>
</relay>
<relay site="SFO">
<remote-site name="LON" .../>
</relay>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (WFLY-1406) Hibernate cannot process package-info.java any more
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-1406?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-1406:
------------------------------------
Can you show the output from "jar tf shop2.war"
> Hibernate cannot process package-info.java any more
> ---------------------------------------------------
>
> Key: WFLY-1406
> URL: https://issues.jboss.org/browse/WFLY-1406
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Scott Marlow
> Attachments: server.log
>
>
> I tried the snapshot which contains Hibernate 4.3.0.Beta2. However, package-info.java files are causing problems. For instance, the package de.shop.artikelverwaltung.domain has a package-info.java which causes a NoClassDefFoundError:
> "IllegalName: de/shop/artikelverwaltung/domain.package-info". Please see the stacktrace below.
> Here is an example for package-info.java which was working with WildFly 8.0.0.Alpha1:
> @XmlAccessorType(FIELD)
> @Vetoed
> package de.shop.artikelverwaltung.domain;
> import static javax.xml.bind.annotation.XmlAccessType.FIELD;
> import javax.enterprise.inject.Vetoed;
> import javax.xml.bind.annotation.XmlAccessorType;
> The stacktrace:
> ...
> 09:29:53,880 WARN [org.jboss.modules] Failed to define class de/shop/artikelverwaltung/domain.package-info in Module "deployment.shop2.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link de/shop/artikelverwaltung/domain/package-info (Module "deployment.shop2.war:main" from Service Module Loader)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:427) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:260) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:75) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:526) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.findClass(ClassLoaderServiceImpl.java:218) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356) [rt.jar:1.7.0_21]
> at org.hibernate.annotations.common.util.ReflectHelper.classForName(ReflectHelper.java:160) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.packageForName(JavaReflectionManager.java:121) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.cfg.AnnotationBinder.bindPackage(AnnotationBinder.java:262) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.cfg.Configuration.addPackage(Configuration.java:792) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildHibernateConfiguration(EntityManagerFactoryBuilderImpl.java:1174) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:839) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:142) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:213) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$800(PersistenceUnitServiceImpl.java:58) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:107) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.lang.NoClassDefFoundError: IllegalName: de/shop/artikelverwaltung/domain.package-info
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:646) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:785) [rt.jar:1.7.0_21]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:422) [jboss-modules.jar:1.2.0.Final]
> ... 28 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (WFLY-1415) Move away from expensive enum switch
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-1415?page=com.atlassian.jira.plugin.... ]
David Lloyd updated WFLY-1415:
------------------------------
Labels: janitor (was: )
> Move away from expensive enum switch
> ------------------------------------
>
> Key: WFLY-1415
> URL: https://issues.jboss.org/browse/WFLY-1415
> Project: WildFly
> Issue Type: Task
> Reporter: David Lloyd
> Priority: Minor
> Labels: janitor
> Fix For: 9.0.0.CR1
>
>
> We use enums and enum switch extensively. These constructs generate many, many additional classes and bloat the code base unnecessarily.
> All cases where we are using enum-based switches for our XML parsers should be converted to use Java 7 String switch instead. The enum values shall be replaced with String constant fields, all enum switches converted to String switches, and all enum types removed from these classes. The net result should be a reduction by dozens if not hundreds of .class files, and possibly a measurable performance boost as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (WFLY-1415) Move away from expensive enum switch
by David Lloyd (JIRA)
David Lloyd created WFLY-1415:
---------------------------------
Summary: Move away from expensive enum switch
Key: WFLY-1415
URL: https://issues.jboss.org/browse/WFLY-1415
Project: WildFly
Issue Type: Task
Reporter: David Lloyd
Priority: Minor
Fix For: 9.0.0.CR1
We use enums and enum switch extensively. These constructs generate many, many additional classes and bloat the code base unnecessarily.
All cases where we are using enum-based switches for our XML parsers should be converted to use Java 7 String switch instead. The enum values shall be replaced with String constant fields, all enum switches converted to String switches, and all enum types removed from these classes. The net result should be a reduction by dozens if not hundreds of .class files, and possibly a measurable performance boost as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (AS7-887) Support legacy ServiceMBeans in SAR deployments
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-887?page=com.atlassian.jira.plugin.sy... ]
Eduardo Martins commented on AS7-887:
-------------------------------------
Rajesh, if you have eap support please use it, this is a community site, no SLAs here. If you don't have EAP support please start a topic on the community forums.
Anyway, if you don't have support and want to stick with EAP I would move to the latest release instead, since EAP 6.1 includes all of this. An alternative is Wildfly, which includes latest features/fixes, such as https://issues.jboss.org/browse/WFLY-222
> Support legacy ServiceMBeans in SAR deployments
> -----------------------------------------------
>
> Key: AS7-887
> URL: https://issues.jboss.org/browse/AS7-887
> Project: Application Server 7
> Issue Type: Enhancement
> Components: JMX
> Reporter: Matt Drees
> Assignee: Eduardo Martins
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> It looks like the current SAR deployment code (jboss-as-sar) will deploy simple MBeans just fine. However, users may expect to be able to deploy older ServiceMBeans from previous Jboss AS versions. Currently, attempting to do this results in a ClassNotFoundException, since the org.jboss.system.ServiceMBean interface doesn't exist anymore.
> Ideally this would also involve supporting ServiceMBeans that extend org.jboss.system.ServiceMBeanSupport, which also doesn't exist anymore.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months