Sep/14th cutoff date for component updates in AS5 Beta3
by Dimitris Andreadis
After Sep/14th and until Beta3 is out we'll only be updating libs in order to fix bugs.
Take a look at the following JIRA to make sure your work on a particular library is properly
recorded/linked:
http://jira.jboss.com/jira/browse/JBAS-4562
--------------------------------------------------------------------
Also, for the next AS5 CRx release make sure any library updates are recorded here:
http://jira.jboss.com/jira/browse/JBAS-4647
(e.g. discussions about jbroups 2.6)
--------------------------------------------------------------------
The current Beta3 status is summarized below:
- MC 2.0.0.Beta4 and dependencies have been resolved/tagged.
- Snapshots that need to be replaced with tagged releases.
What's currently left:
<componentref name="jboss/jboss-ejb3-cache" version="0.11-SNAPSHOT"/>
<componentref name="jboss/jboss-jaspi-api" version="1.0-SNAPSHOT"/>
<componentref name="jboss/jboss-security-spi" version="2.0.1-SNAPSHOT"/>
<componentref name="jboss/jbosssx" version="2.0.1-SNAPSHOT"/>
<componentref name="jboss/jbosssx-client" version="2.0.1-SNAPSHOT"/>
- Waiting for AOP 2.0.0.beta + Javassist 3.6.0.CR2
- JBoss Transactions
(now at 4.2.3.SP5) to be updated to a 4.3.x version that implements JTA 1.1
- JBoss Messaging
waiting for the final 1.4.0.GA release
- JGroups. It's still questionable at this point if we can move to v2.5 (from 2.4.1.SP3) due
to the JBoss Messaging dependency
- Hibernate Validator
We'll be probably adding this, as it is now an independent package.
If you have any comments/concerns let me know.
Cheers
/Dimitris
18 years, 10 months
JBoss Portal Exception Error
by BAMGirl
Hi. Kindly help. We were configuring the look and feel of our JBoss
Portal...changing the portal layout, theme and rendering using the Admin
page. When we re-freshed the portal page. The error below was displayed.
We don't know how to fix it as we were updating the configuration using the
GUI and we are not developers. Please advise on which files we should look
for to do the fix. Thanks.
________________________________________________________________________________
HTTP Status 500 -
--------------------------------------------------------------------------------
type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
javax.servlet.ServletException
org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:312)
org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
root cause
java.lang.NullPointerException
org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.ensurePageNavigationalState(PageNavigationInterceptor.java:230)
org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationInterceptor.java:72)
org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:79)
org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:59)
org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:78)
org.jboss.portal.core.CoreController.handle(CoreController.java:126)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:324)
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:287)
$Proxy318.handle(Unknown Source)
org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:79)
org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
org.jboss.portal.server.aspects.server.NavigationInterceptor.invoke(NavigationInterceptor.java:64)
org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:65)
org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:74)
org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:174)
org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:92)
org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:294)
org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
note The full stack trace of the root cause is available in the Apache
Tomcat/5.5.20 logs.
--
View this message in context: http://www.nabble.com/JBoss-Portal-Exception-Error-tf4523450.html#a12904662
Sent from the JBoss - Dev mailing list archive at Nabble.com.
19 years
svn:externals and anonymous SVN access
by Thomas Diesler
Folks,
If a project uses an svn:externals definition like this
[tdiesler@tddell src]$ svn pg svn:externals .
test-framework
https://svn.jboss.org/repos/jbossws/framework/trunk/src/test
the source URL is not translated to an anonymous svn url when mirrored.
As a result anonymous checkout will fail.
Is there a way to automatically translate svn:externals definitions?
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
19 years
Build broken on trunk?
by Clebert Suconic
The build is now broken due to some changes in Corba..
I have updated my local copy to 65498:
svn update -r65498
and now I can compile it.
19 years
Re: [jboss-dev] Embedded DB for internal use
by Brian Stansberry
Forwarding a response from Elias Ross:
Elias Ross wrote:
>
> [I can't post to the dev list for some reason]
>
> I thought that the default configuration could use the JDBM cache
> loader, which is a free DBM similar to BerkeleyDB. JDBM, like
> Berkeley, uses the local file-system and doesn't have the overhead or
> management complexity of a relational database. Unfortunately, I have
> no idea what's going on with the ongoing development of the project.
> It seemed to be going strong when I wrote the JdbmCacheLoader a year
> and a half ago.
Yeah, my original hope was to use JdbmCacheLoader. But the JDBM project
seems pretty dead now; no release since mid-2005, something about a move
to codehaus but no roadmap there on the codehaus site. We looked at it a
bit this spring for 4.2 and rejected it as too inactive, and now several
months have gone by and I see no sign of change.
> Somebody from JBoss Cache could approach the current
> authors and adopt the project, perhaps.
>
Maybe that genman guy? ;)
Seriously though, I don't think the JBC guys have the bandwidth to drive
JDBM. I'd think adopting that would have to be a larger Red Hat
commitment. Dunno one way or the other if there's any appetite for that.
Part of the reason I raised this topic is every now and then replacing
HSQLDB with Derby gets tossed around. If we were going to do that
anyway, and we regard Derby as production quality, and some other
internal use cases in the AS could benefit from having it available for
internal use, then using it for cache overflow would make sense too.
> I also wonder if some of the limitations with FileCacheLoader couldn't
> be addressed, for example the way Microsoft worked around the 8.3
> filename length limitations. And for transactions, keeping a
> transaction log would be one way to address corruption. E.g. create
> files using a ".tmp" designation, then do a rename in the commit
> phase.
Whether we stick w/ FileCacheLoader for the session caches or not,
improving FCL makes sense to me. JBC users are going to want to use it
for the same reason AS did -- it's the most straightforward to setup and
use, partic if you don't have a ton of control over the environment
you're running in.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
19 years
JGroups 2.6 beta 1 and 2.5.1 released
by Bela Ban
I felt like releasing 2 JGroups releases in 1 day, which I've never done
before... :-)
2.6 beta 1 is mainly to allow JBossCache and JBoss AS 5 to include it
and possibly use the new JOIN&State transfer API. Although only beta-1,
is *very* stable (only 1 out of 600 core tests fails !). No major new
functionality will be added until we go GA, only bug fixes.
I will branch off when GA is relased, so patch releases (2.6.1, 2.6.2
etc) can easily be added to AS 5.
2.5.1 contains some important bug fixes for 2.5 GA (AUTH, VIEW_SYNC),
and is completely backward compatible to 2.5.
I also updated repository.jboss.org with the 2 new releases.
Enjoy !
Release Notes JGroups 2.6 beta 1
=========================
Version: $Id: ReleaseNotes-2.6.txt,v 1.2 2007/09/20 08:26:57 belaban Exp $
Author: Bela Ban
JGroups 2.6 is still API-backwards compatible with previous versions
(down to 2.2.5).
Below is a summary (with links to the detailed description) of the major
new features.
Join and state transfer
-----------------------
[http://jira.jboss.com/jira/browse/JGRP-236]
We added another connect() method in JChannel, which combines joining a
cluster and fetching the state from the
coordinator into one method. This is especially useful when we have
FLUSH in the stack; thus we only have to use 1 rather
than 2 (1 for JOIN, 1 for state transfer) flush phases.
Improved ReplicatedHashMap
--------------------------
[http://jira.jboss.com/jira/browse/JGRP-581]
ReplicatedHashMap was converted to use generics, and
java.util.concurrent.ConcurrentHashMap. It therefore supports 4 new
methods putIfAbsent(), remove() and the two replace() methods.
Developers can choose whether to use asynchronous or synchronous
replication, and also pick the timeout for synchronous
calls.
This class supercedes ReplicatedHashtable and DistributedHashtable,
which will be removed in version 3.0.
Reincarnation issue
-------------------
[http://jira.jboss.com/jira/browse/JGRP-130]
Using the GMS.reject_join_from_existing_member (default=false) property,
we can reject a JOIN request from a reincarnated
member X who crashed, but has not yet been removed (e.g. due to a high
timeout in FD). The member would have to retry,
and would only succeed when (the old) X has been excluded from the cluster.
For shunned members who use AUTO_RECONNECT, we loop until this is true
[http://jira.jboss.com/jira/browse/JGRP-584].
New transport property 'bind_interface'
---------------------------------------
[http://jira.jboss.com/jira/browse/JGRP-579]
This can be used when multipler network interfaces have the *same* IP
address, to define the interface to get used, e.g
bind_addr="192.168.2.5" bind_interface="eth1". Useful e.g. with IP
Bonding on Linux.
Unicast bundling can be disabled at the transport level
-------------------------------------------------------
[http://jira.jboss.com/jira/browse/JGRP-429]
When dealing with latency sensitive applications, we may want to disable
message bundling for *responses* (but not for
requests, as requests might carry large payloads). This can be done via
the enable_unicast_bundling (default=true)
property.
RpcDispatcher can now filter responses as they arrive
------------------------------------------------------
[http://jira.jboss.com/jira/browse/JGRP-518]
There's a new callRemoteMethods() method taking an RspFilter, which is
called whenever a response has been received,
allowing a request to return based on a condition (e.g. the first non
null return value) before all responses
have been received.
Manual
------
The manual is online at
http://www.jgroups.org/javagroupsnew/docs/manual/html/index.html
Performance
-----------
Links to performance tuning:
http://wiki.jboss.org/wiki/Wiki.jsp?page=PerfTuning
Bug fixes
---------
AUTH: bug in 2.5 which caused AUTH to fail on second and subsequent JOIN
attempts *if* the first
attempt was rejected by AUTH.
[http://jira.jboss.com/jira/browse/JGRP-577]
VIEW_SYNC: there was a regression in 2.5, which causes VIEW_SYNC
messages to get dropped.
Note that this bug didn't occur in 2.4.x.
[http://jira.jboss.com/jira/browse/JGRP-586]
X.509 token not marshalled correctly. This affects ENCRYPT.
[http://jira.jboss.com/jira/browse/JGRP-576]
The complete list of features and bug fixes can be found at
http://jira.jboss.com/jira/browse/JGRP.
Bela Ban, Kreuzlingen, Switzerland
Vladimir Blagojevic, Toronto, Canada
Sept 2007
Release Notes JGroups 2.5.1
===========================
Version: $Id: ReleaseNotes-2.5.1.txt,v 1.1.2.2 2007/09/20 11:44:00
belaban Exp $
Author: Bela Ban
JGroups 2.5.1 is a patch release for 2.5 GA. It contains no new
functionality, but only bug fixes.
Manual
------
The manual is online at
http://www.jgroups.org/javagroupsnew/docs/manual/html/index.html
Bug fixes
---------
AUTH: bug in 2.5 which caused AUTH to fail on second and subsequent JOIN
attempts *if* the first
attempt was rejected by AUTH.
[http://jira.jboss.com/jira/browse/JGRP-577]
VIEW_SYNC: there was a regression in 2.5, which causes VIEW_SYNC
messages to get dropped.
Note that this bug didn't occur in 2.4.x.
[http://jira.jboss.com/jira/browse/JGRP-586]
X.509 token not marshalled correctly. This affects ENCRYPT.
[http://jira.jboss.com/jira/browse/JGRP-576]
The complete list of features and bug fixes can be found at
http://jira.jboss.com/jira/browse/JGRP.
Bela Ban, Kreuzlingen, Switzerland, Sept 2007
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat
19 years
