Compilation problem w/ TomcatDeployment
by Brian Stansberry
FYI for anyone seeing $subject
I just did an update of AS trunk and build failed w/ compilation
failure, saying TomcatDeployment was trying to reduce the visibility of
a couple methods from AbstractWarDeployment. Looking at
AbstractWarDeployment showed the methods had the same protected
visibility, as they've always had.
Solution: delete
~/.m2/repository/org/jboss/jbossas/jboss-as-server/6.0.0-SNAPSHOT
I'm resisting the urge to understand what happened. ;)
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
16 years
jboss-metadata-* compatibility with latest state of jboss-metadata-common
by Jaikiran Pai
With EE6 specific things being added to jboss-metadata, i see that the
current state of jboss-metadata-common
(http://anonsvn.jboss.org/repos/jbossas/projects/metadata/common/trunk)
is no longer backward compatible (new methods being added to existing
interfaces). I believe at some point of time before 6.0.0.M2 is
released, there will be a release of this jboss-metadata-common project
and integrated to JBoss AS (although i don't exactly know what the plan
is). As a result, all dependent metadata projects (like
jboss-metadata-ejb, jboss-metadata-ear etc...) will have to do any
necessary changes to be compatible with this newer version of
jboss-metadata-common.
Specifically, these projects need to make sure that they are compatible
with the newer version:
- jboss-metadata-ejb (EJB3 team will take care of this)
- jboss-metadata-rar
- jboss-metadata-ear
- jboss-metadata-client
- jboss-metadata-web
I was planning to file JIRAs for individual components in the JBMETA
JIRA project, but except for jboss-metadata-ejb, the others don't have
owners. So who's looking after these components these days? Alexey?
P.S: With the new metadata split and with each metadata component now
having it own SVN location and release cycle, should there be separate
JIRA projects for each of these? Or is it better manageable with a
single JIRA project and multiple components?
regards,
-Jaikiran
16 years
JGroup Oddness.. GMS?
by mike cann
Hi List,
Only just joined, im not sure if this is the right place to post or not so
let me know if it isnt.
Im trying to use JGroups in a project.
First things first tried running a very simple example but couldnt get the
two machines to talk to each other, i read all the documentation but still
couldnt work out why.
I tried using the webstart demo of the draw (found here
http://www.jgroups.org/demos.html) thats actually the replicatedcache demo
and to my surprise it worked.
I downloaded the .jar that the jnlp uses and ran it from the command line
and got:
---------------------------------------------------------
GMS: address is 192.168.1.69:54939 (cluster=replcache-cluster)
---------------------------------------------------------
Now when I tried to run the ReplCacheDemo from within the jgroups-all.jar I
get the following:
java -cp jgroups-all.jar org.jgroups.demos.ReplCacheDemo
14-Dec-2009 20:17:24 org.jgroups.logging.JDKLogImpl info
INFO: JGroups version: 2.8.0.CR7
-------------------------------------------------------------------
GMS: address=M-Win7-38823, cluster=replcache-cluster, physical
address=fe80:0:0:
0:69e5:8edf:3e90:e817:62330
-------------------------------------------------------------------
So im not sure whats going on here, it looks like the jnlp demo is using a
different GMS (?) settings to the one in jgroups-all.jar, so I tried to take
the udp.xml file from the jnlp jar and use it in a simple example and I get
the follwing errors:
14-Dec-2009 21:12:12 org.jgroups.logging.JDKLogImpl info
INFO: JGroups version: 2.8.0.CR7
Exception in thread "main" org.jgroups.ChannelException: unable to setup the
protocol stack
at org.jgroups.JChannel.init(JChannel.java:1706)
at org.jgroups.JChannel.<init>(JChannel.java:243)
at org.jgroups.JChannel.<init>(JChannel.java:226)
at jgroupssimple.Main.main(Main.java:25)
Caused by: java.lang.Exception: unable to load class for protocol (either
as an absolute - - or relative - org.jgroups.protocols. - package name)!
at
org.jgroups.stack.Configurator$ProtocolConfiguration.createLayer(Configurator.java:1244)
at
org.jgroups.stack.Configurator$ProtocolConfiguration.access$000(Configurator.java:1135)
at
org.jgroups.stack.Configurator.createProtocols(Configurator.java:368)
at
org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
at
org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:54)
at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:452)
at org.jgroups.JChannel.init(JChannel.java:1702)
... 3 more
Java Result: 1
BUILD SUCCESSFUL (total time: 0 seconds)
Anyone any clues as to whats going on here?
Cheers for your time :)
Mike
--
Mike Cann
http://www.mikecann.co.uk/
http://www.artificialgames.co.uk/
16 years
Maven - best way to change versions in a project tree?
by Ondřej Žižka
Hi,
I have a multi-module Maven project, some modules again have modules,
plus there are some subdirs with "child" artifact.
=== What's the best way to change a version of certain artifact in the
whole tree? ===
This was discussed some time ago on some mailing list, and IIRC, the
unspoken conclusion was to use something like
perl -pi -e 's/1.1.0.GA-SNAPSHOT/1.1.0.GA-HTMLUnit26/g' `find . -name
pom.xml`
See http://community.jboss.org/wiki/DavidsMavenReleaseProcess
But there's a danger of replacing a version for some other artifact. I
don't want to create some crazy bash script to handle this case. XSLT
would help.
=== But first - is there some Maven plugin or tool to do this? (EXCEPT
MAVEN RELEASE PLUGIN, see the discussion.) ===
Thanks for tips,
Ondra
16 years
JBoss@FOSDEM'10
by Frederic Hornain
Dear *,
I am currently looking for speaker on JBoss for the FOSDEM'10 (Belgium EU) -
www.fosdem.org -.
FOSDEM '10 is a free and non-commercial event organized by the community,
for the community. Its goal is to provide Free and Open Source developers a
place to meet.
Indeed, FOSDEM'10 give us the possibility to use on Saturday 6th February
from 13:00 to 19:00 a devroom - speaker room - in order to discuss about
JBoss projects .
Indeed we (http://jbug.be and I) would like to talk about these folllowing
subjects :
- Infinispan
- JBoss Application server
- Seam
- Drools ( We think we found someone however you can propose yourself in a
case of the person decline)
- Hibernate
- jBPM ( We think we found someone however you can propose yourself in a
case of the person decline)
- Hibernate Search
- JBoss intergration with Fedora
If you are interested or know someone who would be interested, feel free to
contact me in letting me a reply to this post or in going to
http://fhornain.wordpress.com
Thanks for your time and your help
Kind Regards
Frederic ;)
--
-----------------------------------------------------
Fedora-ambassadors-list mailing list
Fedora-ambassadors-list(a)redhat.com
Olpc mailing list
olpc-open(a)laptop.org
16 years, 1 month
jboss.org Outage | Saturday 12th Dec 2009 - 13:00 (UTC + 1)
by Mark Newton
O U T A G E R E P O R T F O R M
===================================
Severity:
Severity Two (High)
Incident Date:
Saturday 12th Dec 2009
Incident Time:
13:00 (UTC + 1)
Elapsed Time of Incident:
29 hours
Performed By:
JBoss Community Team, Eng Ops
People/Groups Impacted:
JBoss Community
Site Affected:
jboss.org
Description:
Migration of JBoss Nukes forums to Clearspace.
Future Recommendations:
N/A
16 years, 1 month
Howto debug jndi lookup issues?
by Thomas Diesler
Folks,
java.lang.ClassCastException: javax.naming.Reference cannot be cast to
org.jboss.test.osgi.jbosgi58.ejb.StatelessBean
at
org.jboss.test.osgi.jbosgi58.OSGI58TestCase.testEJB(OSGI58TestCase.java:54)
a JNDI client lookup may fail for various reasons . AFAIK, the above CCE
happens because there is some calss missing on the client classpath.
JNDI gives up internally and simply returns the reference.
To solve the problem I could do
<dependency>
<groupId>org.jboss.jbossas</groupId>
<artifactId>jboss-as-client</artifactId>
<version>6.0.0.M1</version>
<type>pom</type>
</dependency>
but this gives me an insanely big dependency tree
(http://pastebin.com/m3776fc85). I'd much rather find out, what exactly
is missing and use a client that contains just that.
Is there a way to debug these kind of JNDI client issues?
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 1 month
Code Differences between AS trunk and 6.0.0.M1 tag
by Brian Stansberry
From comparing the component-matrix/pom.xml files, looks like there's a
fair amount of stuff to port from the JBoss_6_0_0_M1 tag to trunk.
Getting that done seems like a high priority. Diffing the tag to trunk
is a pain because trunk has moved toward a maven structure (e.g.
src/main/java/org/jboss instead of src/main/org/jboss). As an early
holiday gift to you all I went ahead and did a diff of src/main/java for
each of the modules in the AS source tree. Attached them to a wiki page.[1]
I encourage folks to have a look. I was quite anal about porting
everything I did between Branch_5_x and trunk before closing any JIRA,
but looking at these diffs I found a couple small things I need to fix
in trunk.
[1] http://www.jboss.org/community/docs/DOC-14457
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
16 years, 1 month
