JIRA housekeeping and component tracking
by Dimitris Andreadis
I know it is tedious for smaller broken out project JIRAs to be in sync with the
code/releases, especially when the initial Betas are still in progress (e.g.
http://jira.jboss.com/jira/browse/JBVFS) *but* when this stuff reaches a state that will
need to be supported, it will be very hard to track what went into a release, unless we
maintain some discipline, i.e. the obvious stuff: don't commit without a linked JIRA task
and properly mark versions as released.
Something else to avoid is …
[View More]using "foreign" JIRA tags in commit message. E.g like JBCTS /
JBWS / JBPAPP / ... tags in community AS branches/trunk, rather use JBAS tag that link back
to the other projects.
Finally, the more projects are broken out into smaller ones (with their own JIRA, etc) the
more difficult it becomes to assemble meaningful release notes, and many users have
complained about that.
My proposal would be that for every updated component (or set of components if they are
tracked together):
1) there should be a JIRA task to track the upgrade, e.g. when upgrading the jbosssx libs.
2) this JIRA should either embed or link to the release notes of the upgraded component
3) the task should be re-used if upgrading multiple times within the same target release
4) the rule would apply for both jboss and thirdparty libraries
This is something I'm trying to enforce for upgrades I'm doing myself, but it would be great
to have a wider consensus / application of this practice.
I would also like to propose that we introduce a new JIRA type next to 'feature', 'bug',
etc. called e.g. 'Component Upgrade' to mark those JIRA tasks. By doing so, the component
upgrades:
- would immediately stand out in the release notes report
- the user will be able to drill-into the jira task and find out exactly what the upgrade is
about.
That would be quite simple and effective, I think.
Thoughts?
/Dimitris
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
JBoss AS, Project Lead
JBoss, a Division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
[View Less]
17 years
AS usage of lib/endorsed jars
by Dimitris Andreadis
The lib/endorsed jars in the AS distro is a subject that comes up every once in a while.
In AS 4.0.x we have in lib/endorsed/
resolver.jar
serializer.jar
xalan.jar
xercesImpl.jar
xml-apis.jar
In trunk (AS5) there is also an additional jaxb-api.jar
And in the AS 4.2.x series resolver.jar and xml-apis.jar were left out due to some build
issue that went unnoticed until now (I'll spare you the details).
Now the question is what *really* needs to be in lib/endorsed and most importantly why?…
[View More]
Jdk5 suggests the following packages to be overridable, essentially CORBA stuff plus:
org.w3c.dom
org.xml.sax
org.xml.sax.ext
org.xml.sax.helpers
http://java.sun.com/j2se/1.5.0/docs/guide/standards/
--- resolver.jar ---
Who's using it / how? We have our own org.jboss.util.xml.JBossEntityResolver (in jboss
common) with an open JIRA to externalize its configuration:
http://jira.jboss.com/jira/browse/JBAS-2038
And another port of the apache resolver which I understand it's not yet complete?
http://jira.jboss.com/jira/browse/JBWS-678
Is the conf/jax-ws-catalog.xml file in AS5 actually in use?
--- xml-apis.jar ---
Isn't jdk5 already providing the right version of the xml apis?
--- xerces.jar ---
Can't we use the embedded jdk5 one?
--- xalan.jar / serializer.jar ---
Long discussion about moving this out of lib/endorsed:
http://jira.jboss.com/jira/browse/JBAS-2073
--- jaxb-api.jar ---
I understand this is needed for jax-ws ?
http://www.bhaskarvk.info/content/jboss/jbossws_2_0_1.html
It is often the case that users want to have different version of those libs and by putting
them in endorsed we force them to scope their deployments.
Any input and strong opinions for tiding things up is appreciated, especially from the
"heavy" XML users (WS, XB, SOA, etc.)
Thanks
/Dimitris
[View Less]
17 years
Compilation error in JBossAS trunk?
by Trustin Lee
Hi,
I did the following:
$ svn co https://svn.jboss.org/repos/jbossas/trunk/ jbossas
$ cd jbossas
$ mvn clean install
and got the following compilation error:
...
[INFO]
------------------------------------------------------------------------
[INFO] Building JBoss Application Server System JMX
[INFO] task-segment: [install]
[INFO]
------------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
…
[View More][INFO] [compiler:compile]
[INFO] Compiling 123 source files
to /home/trustin/workspace/checkout/jboss/jbossas/system-jmx/target/classes
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Compilation failure
/home/trustin/workspace/checkout/jboss/jbossas/system-jmx/src/main/org/jboss/system/deployers/ServiceClassLoaderDeployer.java:[53,7] org.jboss.system.deployers.ServiceClassLoaderDeployer is not abstract and does not override abstract method createTopLevelClassLoader(org.jboss.deployers.structure.spi.DeploymentUnit) in org.jboss.deployers.spi.deployer.helpers.AbstractTopLevelClassLoaderDeployer
/home/trustin/workspace/checkout/jboss/jbossas/system-jmx/src/main/org/jboss/system/deployers/ServiceClassLoaderDeployer.java:[119,16] visit(org.jboss.deployers.structure.spi.DeploymentContextVisitor) in org.jboss.deployers.structure.spi.DeploymentContext cannot be applied to (org.jboss.deployers.vfs.spi.structure.helpers.ClassPathVisitor)
Actually it's my first time that I try to build JBossAS, so I'd like to
know if it's my own problem or not. The following is my environment:
$ uname -a
Linux laptop 2.6.23-gentoo-r8 #1 Tue Feb 12 12:04:54 EST 2008 i686
Intel(R) Pentium(R) M processor 1400MHz GenuineIntel GNU/Linux
$ java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode)
$ mvn --version
Maven version: 2.0.8
Java version: 1.6.0_03
OS name: "linux" version: "2.6.23-gentoo-r8" arch: "i386" Family: "unix"
Thanks,
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
[View Less]
17 years, 1 month
jboss-test-jdk14
by Aleksandar Kostadinov
Hallo,
I've issues building jboss-test-jdk14 due to missing dependencies. Do we
care about it or should I release without it?
Thanks,
Aleksandar
17 years, 1 month
JBossMessaging SecurityMetaDataStore implementation changed in AS5 trunk
by Anil Saldhana
As part of JBAS-5210, I changed the messaging SecurityMetaDataStore
implementation from the messaging project, with an implementation in the
messaging module (integration) of AS5 workspace. The new implementation
is just a rip off of the old, except the usage of SecurityAssociation
has been replaced with the new security spi usage.
This fixes JBAS-4637.
17 years, 1 month
Exception occured while running jboss 4.2.2.GA
by puneetjain
Hi,
We are using JMeter to test the performance of a simple stateless bean in
JBoss in the following environment:
Environment Details
===================
Operating System - Enterprise Red Hat Linux ES 4
JBoss - jboss-4.2.2.GA
JDK - J2SDK 1.6.0_14
JMeter - jakarta-jmeter-2.3.1
We are using EJB 3.0 annotation feature in our sample application -
To read a file from the file sytem and reverse the contents of the file.
We have created a Stateless SessionBean, which is invoked through a servlet
…
[View More]and servlet is passing the SessionBean the name of the file with full path.
The SessionBean reads the file and reverses it contents.
We tried to access the servlet through JMeter with 100 requests, it is then
we get this problem.
However, note that this stateless sessionbean accepts a file as input whose
size 0.2 MB
We tried for 10 user with 0.5 MB file size but it is throwing the same
exception.
Testing Scenario in JMeter
==========================
Scenario 1:
-----------
Users - 100
Loops - 1
Input File Size - 0.2 MB
Scenario 2:
-----------
Users - 10
Loops - 1
Input File Size - 0.5 MB
Errors Encountered
==================
We are getting the following exceptions:
<<
2008-02-09 19:00:58,925 WARN [com.arjuna.ats.arjuna.logging.arjLoggerI18N]
[com.arjuna.ats.arjuna.coordinator.BasicAction_40] - Abort called on already
aborted atomic action 7f000001:8027:47ad3f6f:884
2008-02-09 19:00:48,293 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger]
Periodic recovery - second pass <Sat, 9 Feb 2008 19:00:48>
2008-02-09 19:00:58,929 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger]
AtomicActionRecoveryModule: Second pass
2008-02-09 19:00:58,929 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N]
[com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_6] -
TORecoveryModule - second pass
2008-02-09 19:00:58,929 DEBUG [com.arjuna.ats.jta.logging.loggerI18N]
[com.arjuna.ats.internal.jta.recovery.info.secondpass] Local
XARecoveryModule - second pass
2008-02-09 19:00:58,929 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/perf].[perftester]]
Servlet.service() for servlet perftester threw exception
java.lang.IllegalStateException:
[com.arjuna.ats.internal.jta.transaction.arjunacore.inactive]
[com.arjuna.ats.internal.jta.transaction.arjunacore.inactive] The
transaction is not active!
at
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1379)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
at
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:175)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
at
org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at
org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:240)
at
org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:210)
at
org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:84)
at $Proxy68.reverseString(Unknown Source)
at
com.oki.appserver.perf.web.PerfTesterServlet.doGet(PerfTesterServlet.java:46)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:619)
2008-02-09 19:00:29,972 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/perf].[perftester]]
Servlet.service() for servlet perftester threw exception
java.lang.IllegalStateException:
[com.arjuna.ats.internal.jta.transaction.arjunacore.inactive]
[com.arjuna.ats.internal.jta.transaction.arjunacore.inactive] The
transaction is not active!
at
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1379)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
at
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:175)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
at
org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at
org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:240)
at
org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:210)
at
org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:84)
at $Proxy68.reverseString(Unknown Source)
at
com.oki.appserver.perf.web.PerfTesterServlet.doGet(PerfTesterServlet.java:46)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:619)
2008-02-09 19:02:58,930 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger]
Periodic recovery - first pass <Sat, 9 Feb 2008 19:02:58>
2008-02-09 19:02:58,930 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger]
StatusModule: first pass
2008-02-09 19:02:58,931 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N]
[com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_3] -
TORecoveryModule - first pass
2008-02-09 19:02:58,931 DEBUG [com.arjuna.ats.jta.logging.loggerI18N]
[com.arjuna.ats.internal.jta.recovery.info.firstpass] Local XARecoveryModule
- first pass
2008-02-09 19:03:08,932 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger]
Periodic recovery - second pass <Sat, 9 Feb 2008 19:03:08>
2008-02-09 19:03:08,932 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger]
AtomicActionRecoveryModule: Second pass
2008-02-09 19:03:08,932 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N]
[com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_6] -
TORecoveryModule - second pass
2008-02-09 19:03:08,932 DEBUG [com.arjuna.ats.jta.logging.loggerI18N]
[com.arjuna.ats.internal.jta.recovery.info.secondpass] Local
XARecoveryModule - second pass
>>
Please help.
Thanks,
Puneet
--
View this message in context: http://www.nabble.com/Exception-occured-while-running-jboss-4.2.2.GA-tp15...
Sent from the JBoss - Dev mailing list archive at Nabble.com.
[View Less]
17 years, 1 month
AbstractTypeMetaData.preinstantiatedLookup() hides exception stacktrace
by Galder Zamarreno
Hi,
Just running some tests in trunk and I'm seeing some exceptions without
stacktrace:
2008-02-11 00:54:23,416 WARN
[org.jboss.beans.metadata.plugins.AbstractListMetaData] Exception in
preinstantiated lookup for:
TomcatClusteringEvictionConfig.evictionRegionConfigs,
org.jboss.cache.config.ConfigurationException:
org.jboss.cache.config.ConfigurationException: timeToLiveSeconds must be
configured to a value greater than or equal to 0
....
2008-02-11 00:54:59,867 WARN
[org.jboss.beans.…
[View More]metadata.plugins.AbstractListMetaData] Exception in
preinstantiated lookup for:
EJB3SFSBEvictionConfig.evictionRegionConfigs,
org.jboss.cache.config.ConfigurationException:
java.lang.ClassCastException:
org.jboss.cache.eviction.NullEvictionPolicyConfig
Shouldn't AbstractTypeMetaData.preinstantiatedLookup() print the
stacktrace? That would certainly help debugging them :)
So, instead of:
catch (Throwable t)
{
log.warn("Exception in preinstantiated lookup for: " + beanName + "."
+ propertyName + ", " + t);
}
do:
catch (Throwable t)
{
log.warn("Exception in preinstantiated lookup for: " + beanName + "."
+ propertyName, t);
}
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
[View Less]
17 years, 1 month
AS5 Beta4 has been tagged
by Dimitris Andreadis
...and will soon be released by Rajesh.
https://svn.jboss.org/repos/jbossas/tags/JBoss_5_0_0_Beta4/
Trunk is unfrozen again for everyone that wants to commit work towards CR1. Remember that we
want to stabilize things, not break them.
There are 122 tasks to choose from, for a period of 6 weeks after JBW, so plenty of work there:
http://jira.jboss.com/jira/browse/JBAS
Please note a few things:
- Current (very aggressive) target for AS5 CR1 is Mar/31st. The only way to make it is to
*deal …
[View More]only the essential stuff*. Everything else, should be pushed to a future 5.1 release,
or be unscheduled. Be ruthless with re-scheduling.
- CR1 must be 100% at TCK, so that adds an extra flavor to the deal and a very big challenge
for the EJB3 team, as it makes up a big part of the remaining work.
- Thirdparty libs & component updates are expected around mid-March.
- The relatively idle week of JBW is ideal for coming up with a viable (step-by-step?)
solution to the AS mavenization issue. Follow the discussion here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128013#4128013
We'll come up with a more detailed CR1 plan after JBW.
It has been a very productive quarter for AS5 (2 Betas in the last 3 months), so I would
like to congratulate everyone that worked on this nearly impossible mission and hope we keep
the momentum going while getting closer to the final release (or burn in hell :)
Lately, I saw some new names committing stuff and fixing testsuite failures in trunk, so
that was really great to see the help coming where we need it most.
Cheers
/Dimitris
[View Less]
17 years, 1 month
