Community Supported Tags / Clean Update Paths / Official "Usable" RHQ Releases

Andreas Dietrich adi at aspicon.de
Wed Oct 20 07:19:02 UTC 2010


  Hi there,

I just spoke with Heiko about it and would like post the outcome here 
for later reference.
The whole release structure is not to be considered cleanly streamlined 
in all places:

1) the *_GA tags/releases are the basis for the JON releases and as such 
provide "clean" update paths regarding DB updates
1.1) branch release-3.0.0 may be tagged at some point with something 
like RHQ_3_0_1_GA which should be the next official patch nb. 1 for the 
RHQ_3_0_0_GA release
1.2) interestingly (from my point of view) the official binaries based 
on RHQ_3_0_0 are kind of exceptional (likely the upgrade from RHQ_3_0_0 
to RHQ_3_0_0_GA will be ok)
1.2.1 => I would recommend to somebody that want's to start with a 
stable community-supported version to build the RHQ_3_0_0_GA release 
himself and start with this one in a production environment

2) branches release-3.0.0-patch1 and release-3.0.0-patch2 do not make 
much sense so far from a community point of view
2a) they are considered SNAPSHOT revisions that should be merged later 
into the release-3.0.0 branch

3) the *_EmbJopr* tags are used for some JBoss AppSrv Console where DB 
updates do not matter (as such they do NOT provide "clean" update paths 
and should not be used for "production" releases)

Regards
Andreas :-)


On 10/14/2010 04:28 PM, John Mazzitelli wrote:
> As for your other questions, I know Heiko has been deeply involved in
> building the latest RHQ releases so he might be able to answer your
> questions more definitively - I'll let him answer them if he can.
>
> Or, if anyone else is out there that knows how to describe what the
> different branches and tags are, please chime in.
>
> On 10/14/2010 10:11 AM, Andreas Dietrich wrote:
>> I actually worked in the release-3.0.0 branch. We are using the
>> official Version of RHQ right now (tagged RHQ_3_0_0) and wanted to
>> upgrade.
>> I did not want to take some SNAPSHOT version so I took the
>> RHQ_3_0_0_EmbJopr2 tag (which is an descendant of the last officially
>> tagged RHQ_3_0_0_GA version).
>>
>> So I cannot expect the EmbJopr releases will fit into the upgrade process?
>> My guess was that the DB updates are in a way community-supported like this?:
>> RHQ_3_0_0 =>   RHQ_3_0_0_GA =>   RHQ_EmbJopr =>   RHQ_EmbJopr2 =>   RHQ_3_0_1 =>   ...
>>
>> I just retried the deployment with the RHQ_3_0_0_GA version and get
>> the same error. Maybe the automatically downloaded JBoss installation
>> has some errors (related to the Maven build process?).
>>
>> I will retry with the RHQ_3_0_0 version and if this does not help
>> setup a new Maven repository and start from scratch.
>>
>> Another question related to this one and maybe more general is:
>> Currently I see two branches "release-3.0.0-patch1" and
>> "release-3.0.0-patch2" but they are not tagged.
>> So I guess I can't consider the latest revisions in the patch branches
>> as "community-supported to work for patches" (at least till they are
>> untagged) right?
>> I mean do I get in a "Beta-" state (especially related to the DB) if I
>> would upgrade to those revisions?
>>
>> If you should not know what I mean I'll explain with an example:
>> Let's assume:
>> Rev (ordered) | tag      |  branch  |  description
>> rev1            rhq3        rhq3       official version
>> rev3<none>        rhq3       some untagged version not contained in
>>                                           rhq3.1
>> rev6<none>        rhq3.1     some untagged patch branch revision
>> rev9            rhq3.0.1    rhq3.1     officially tagged patch version
>>
>> If I upgrade my RHQ installation based on rev1 to rev9 everything
>> should be fine. If there are bugs found in rev9 I will wait for some
>> official update and my DB will not be corrupted or at least be
>> repaired later.
>>
>> Is it correct that if I would upgrade based on rev1 to rev6 or even
>> rev3 I cannot expect a later upgrade to rev9 to work at all?
>>
>>
>> Thanks
>> Andreas :-)
>>
>>
>> -------- Original Message --------
>> Subject: 	Re: RHQ initial server startup error: NoClassDefFoundError:
>> org/jboss/wsf/spi/deployment/UnifiedVirtualFile (RHQ_3_0_0_EmbJopr2 tag)
>> Date: 	Thu, 14 Oct 2010 08:19:01 -0400
>> From: 	John Mazzitelli<mazz at redhat.com>
>> Reply-To: 	mazz at redhat.com, rhq-devel at lists.fedorahosted.org
>> To: 	rhq-devel at lists.fedorahosted.org
>>
>>
>>
>> I'm not seeing anything RHQ specific that is failing here. However, can
>> I ask what you are trying to do? Are you trying to build an RHQ Server
>> distribution or an Embedded Jopr distribution? If the former, I think
>> you are using the wrong tagged version. That "EmpJopr2" tag name infers
>> that it was needed to build the Embedded Jopr stuff - I would not use
>> that - instead, use the "release-3.0.0" branch or something like that. See:
>>
>> http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=shortlog;h=refs/heads/release-3.0.0
>>
>> If you want to build/run Embedded Jopr, I'm actually not too familiar
>> with how to build that. Hopefully Ian is around that can help or point
>> to a wiki page that explains the Embedded Jopr build process.
>>
>> On 10/14/2010 07:12 AM, Andreas Dietrich wrote:
>>> Hi,
>>>
>>> can somebody give me a hint why I get this error trying to startup the
>>> RHQ server (RHQ_3_0_0_EmbJopr2 tagged revision).
>>>
>>> I built it in Eclipse Helios using an external Maven 2.2.1 install.
>>>
>>> Thanks for any hint
>>> Andreas :-)
>>>
>>>
>>> 2010-10-12 17:30:32,960 INFO
>>> [org.jboss.resource.adapter.quartz.inflow.QuartzResourceAdapter] start
>>> quartz!!!
>>> 2010-10-12 17:30:33,008 INFO  [org.quartz.simpl.SimpleThreadPool] Job
>>> execution threads will use class loader of thread: main
>>> 2010-10-12 17:30:33,043 INFO  [org.quartz.core.SchedulerSignalerImpl]
>>> Initialized Scheduler Signaller of type: class
>>> org.quartz.core.SchedulerSignalerImpl
>>> 2010-10-12 17:30:33,043 INFO  [org.quartz.core.QuartzScheduler] Quartz
>>> Scheduler v.1.6.5 created.
>>> 2010-10-12 17:30:33,045 INFO  [org.quartz.simpl.RAMJobStore]
>>> RAMJobStore initialized.
>>> 2010-10-12 17:30:33,045 INFO  [org.quartz.impl.StdSchedulerFactory]
>>> Quartz scheduler 'DefaultQuartzScheduler' initialized from default
>>> resource file in Quartz package: 'quartz.properties'
>>> 2010-10-12 17:30:33,045 INFO  [org.quartz.impl.StdSchedulerFactory]
>>> Quartz scheduler version: 1.6.5
>>> 2010-10-12 17:30:33,045 INFO  [org.quartz.core.QuartzScheduler]
>>> Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
>>> 2010-10-12 17:30:33,060 ERROR [org.jboss.deployment.MainDeployer]
>>> Could not create deployment:
>>> file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/
>>> java.lang.NoClassDefFoundError:
>>> org/jboss/wsf/spi/deployment/UnifiedVirtualFile
>>>             at java.lang.Class.getDeclaredConstructors0(Native Method)
>>>             at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
>>>             at java.lang.Class.getConstructor0(Unknown Source)
>>>             at java.lang.Class.newInstance0(Unknown Source)
>>>             at java.lang.Class.newInstance(Unknown Source)
>>> ...
>>>             at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>             at java.lang.reflect.Method.invoke(Unknown Source)
>>>             at
>>> org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>>>             at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>>>             at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>>>             at
>>> org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>>>             at
>>> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>>>             at
>>> org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
>>>             at $Proxy0.start(Unknown Source)
>>>             at
>>> org.jboss.system.ServiceController.start(ServiceController.java:417)
>>>             at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>>>             at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>             at java.lang.reflect.Method.invoke(Unknown Source)
>>>             at
>>> org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>>>             at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>>>             at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>>>             at
>>> org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>>>             at
>>> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>>>             at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>>>             at $Proxy4.start(Unknown Source)
>>>             at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304)
>>>             at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
>>>             at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
>>>             at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
>>>             at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
>>>             at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>             at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>             at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>             at java.lang.reflect.Method.invoke(Unknown Source)
>>>             at
>>> org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>>>             at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>>>             at
>>> org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>>>             at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>>>             at
>>> org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>>>             at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>>>             at
>>> org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>>>             at
>>> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>>>             at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>>>             at $Proxy5.deploy(Unknown Source)
>>>             at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
>>>             at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
>>>             at org.jboss.Main.boot(Main.java:200)
>>>             at org.jboss.Main$1.run(Main.java:508)
>>>             at java.lang.Thread.run(Unknown Source)
>>> Caused by: java.lang.ClassNotFoundException: No ClassLoaders found
>>> for: org.jboss.wsf.spi.deployment.UnifiedVirtualFile
>>>             at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:212)
>>>             at
>>> org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:521)
>>>             at
>>> org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:415)
>>>             at java.lang.ClassLoader.loadClass(Unknown Source)
>>>             ... 89 more
>>> 2010-10-12 17:30:33,062 ERROR
>>> [org.jboss.deployment.scanner.URLDeploymentScanner] Incomplete
>>> Deployment listing:
>>>
>>> --- Incompletely deployed packages ---
>>> org.jboss.deployment.DeploymentInfo at 13642991 {
>>> url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/jboss-web.deployer/ROOT.war/
>>> }
>>>       deployer: MBeanProxyExt[jboss.web:service=WebServer]
>>>       status: Deployment FAILED reason:
>>> org/jboss/wsf/spi/deployment/UnifiedVirtualFile
>>>       state: FAILED
>>>       watch:
>>> file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/jboss-web.deployer/ROOT.war/WEB-INF/web.xml
>>>       altDD: null
>>>       lastDeployed: 1286897432575
>>>       lastModified: 1286896122000
>>>       mbeans:
>>>
>>> org.jboss.deployment.DeploymentInfo at 52727534 {
>>> url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/client-deployer-service.xml
>>> }
>>>       deployer: org.jboss.deployment.SARDeployer at 419d05
>>>       status: Deployment FAILED reason: - nested throwable:
>>> (java.lang.reflect.UndeclaredThrowableException)
>>>       state: FAILED
>>>       watch:
>>> file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/client-deployer-service.xml
>>>       altDD: null
>>>       lastDeployed: 1286897430841
>>>       lastModified: 1286897430000
>>>       mbeans:
>>>
>>> org.jboss.deployment.DeploymentInfo at 39f18328 {
>>> url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/
>>> }
>>>       deployer: MBeanProxyExt[jboss.web:service=WebServer]
>>>       status: Deployment FAILED reason:
>>> org/jboss/wsf/spi/deployment/UnifiedVirtualFile
>>>       state: FAILED
>>>       watch:
>>> file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/WEB-INF/web.xml
>>>       altDD: null
>>>       lastDeployed: 1286897433058
>>>       lastModified: 1286896118000
>>>       mbeans:
>>>
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel at lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>
>>
>>
>>
>> ----- End forwarded message -----
>>
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list