Menu
▾
▴
jboss-dev-forums — The jboss development forum posts
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
| 2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
| 2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
| 2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
| 2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
| 2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
| 2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
| 2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
| 2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ad...@jb...> - 2005-06-26 18:33:58
|
Is this just a case of refactoring package names? In JBoss4 I can see both package names but the org.jboss.xb stuff is more complete with some duplication across the packages. I'm going to see whether I can create a compatibility layer for now by making org.jboss.xb classes that extend org.jboss.xml.binding in head. I'm only going to do enough to get the MC tests working in jboss4. This is just a temporary solution such that I can get my stuff backported. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882768#3882768 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882768 |
|
From: <ad...@jb...> - 2005-06-26 18:25:38
|
Alex & Scott You do realize that sourceforge is not very reliable at archiving its mailing lists: http://sourceforge.net/mailarchive/forum.php?forum_id=7101&max_rows=25&style=ultimate&viewmonth=200506 Parts of your discussion are missing... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882767#3882767 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882767 |
|
From: <ad...@jb...> - 2005-06-26 18:24:10
|
Jira Task http://jira.jboss.com/jira/browse/JBXB-26 Discussion from jboss-dev mailing list http://sourceforge.net/mailarchive/forum.php?thread_id=7567668&forum_id=7101 http://sourceforge.net/mailarchive/forum.php?thread_id=7568105&forum_id=7101 http://sourceforge.net/mailarchive/forum.php?thread_id=7568106&forum_id=7101 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882766#3882766 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882766 |
|
From: jeff87 <nu...@jb...> - 2005-06-26 16:50:13
|
OK, I think I may finally have it. So here is what I tried: Authenticated as ?test?. Set from address to te...@em... I was refused sending to jboss@localhost.localdomain and jb...@jb... Then set the from address to jboss@localhost.localdomain. I was refused sending to jboss@localhost.localdomain and jb...@jb... Then set the from address to test@localhost.localdomain I was able to send to both jboss@localhost.localdomain and jb...@jb... So if this how it should behave, how do I submit the code? Just attach the file to an e-mail to Andy? Thanks everyone, Jeff View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882758#3882758 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882758 |
|
From: mikezzz <nu...@jb...> - 2005-06-26 15:17:18
|
What?! You crazy fool?! I have upgraded the hibernate code to use Hibernate 3. Also there is a problem with AOP transactions in JBoss 4.0.1 where a NPE gets thrown whenever a transacted method is called. The AOP problem kinda encouraged the hibernate code change (4.0.2 includes hibernate 3). And yes until now AOP transaction where not actually getting created. However there is a problem with the hibernate deployer in that it does not include all of the hibernate dependencies http://jira.jboss.com/jira/browse/JBAS-1786. Therefore I have included an ant task called "fix-hibernate-dependencies" which copies the latest commons-collections class to the deployer subdirectory in the jboss server. This task will need integration into cheese at some point (TODO). If you would like to use JBoss Mail on JBoss 4.x version prior to 4.0.2 then you need to the following: 1. Download and install the latest JBoss AOP deployer for your JVM. 2. Switch your hibernate deployer to hibernate 3. http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossHibernateSwitching 3. Run the fix-hibernate-dependencies task. If there is enough need I can automate this in the build scripts. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882756#3882756 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882756 |
|
From: studie <nu...@jb...> - 2005-06-26 14:20:56
|
Hi, I am starting to experiment with the portal security setup withing jboss-portlet.xml but am having problems. I have added the following to my jboss-portlet.xml file :- <portlet-app> | <portlet> | <portlet-name>NavPortlet</portlet-name> | <security></security> | </portlet> | <portlet> | <portlet-name>NstkPortlet</portlet-name> | <security> | <model> | <permission-description> | <permission-name>upload-product-data-file</permission-name> | <description>Allows a file of bulk product data to be uploaded</description> | </permission-description> | </model> | <scheme> | <domain></domain> | <item> | <path>/</path> | <permission> | <permission-name>upload-product-data-file</permission-name> | <role-name>Supplier</role-name> | </permission> | </item> | </scheme> | </security> | </portlet> | </portlet-app> However when I deploy my WAR file I get the following error (see trace below) which appears to be complaining about "org.jboss.portal.common.util.NoSuchElementException: Missing child scheme of element model" Am I missing something?, apart from the "Reference Guide" is there any further documentation on the use and syntax of jboss-portlet.xml ?. Any help would be much appreciated. Thanks, Stuart | 14:59:57,402 ERROR [MainDeployer] could not create deployment: file:/u01/jboss-4.0.2/server/default/tmp/deploy/tmp20797nstkportal.war/WEB-INF/ | org.jboss.deployment.DeploymentException: Cannot deploy portlet application; - nested throwable: (org.jboss.portal.common.util.NoSuchElementException: | Missing child scheme of element model) | at org.jboss.portal.portlet.deployment.jboss.PortletAppDeployment.create(PortletAppDeployment.java:184) | at org.jboss.portal.server.deployment.jboss.ServerDeployer.create(ServerDeployer.java:168) | at org.jboss.deployment.MainDeployer.create(MainDeployer.java:918) | at org.jboss.deployment.MainDeployer.create(MainDeployer.java:910) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:774) | at sun.reflect.GeneratedMethodAccessor117.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:324) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) | at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:121) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:74) | at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:74) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) | at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) | at $Proxy57.deploy(Unknown Source) | at org.jboss.portal.server.deployment.jboss.ServerDeployer.deploy(ServerDeployer.java:239) | at sun.reflect.GeneratedMethodAccessor116.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:324) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) | at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) | at $Proxy31.deploy(Unknown Source) | at org.jboss.portal.server.deployment.WebAppAdapter.deploy(WebAppAdapter.java:49) | at org.jboss.portal.server.deployment.WebAppIntercepter.handleNotification(WebAppIntercepter.java:137) | at org.jboss.mx.modelmbean.XMBean.handleNotification(XMBean.java:485) | at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:324) | at org.jboss.mx.notification.NotificationListenerProxy.invoke(NotificationListenerProxy.java:138) | at $Proxy38.handleNotification(Unknown Source) | at org.jboss.mx.util.JBossNotificationBroadcasterSupport.handleNotification(JBossNotificationBroadcasterSupport.java:112) | at org.jboss.mx.util.JBossNotificationBroadcasterSupport.sendNotification(JBossNotificationBroadcasterSupport.java:93) | at org.jboss.deployment.SubDeployerSupport.emitNotification(SubDeployerSupport.java:238) | at org.jboss.deployment.SubDeployerSupport.start(SubDeployerSupport.java:206) | at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:410) | at org.jboss.deployment.MainDeployer.start(MainDeployer.java:964) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:775) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738) | at sun.reflect.GeneratedMethodAccessor68.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:324) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) | at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:121) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:74) | at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:74) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) | at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) | at $Proxy8.deploy(Unknown Source) | at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:325) | at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:483) | at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:204) | at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:215) | at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:194) | Caused by: org.jboss.portal.common.util.NoSuchElementException: Missing child scheme of element model | at org.jboss.portal.common.util.XML.getUniqueChild(XML.java:401) | at org.jboss.portal.core.deployment.jboss.PortletAppDeployment.buildSecurityMetaData(PortletAppDeployment.java:129) | at org.jboss.portal.core.deployment.jboss.PortletAppDeployment.buildPortletMetaData(PortletAppDeployment.java:71) | at org.jboss.portal.portlet.deployment.jboss.PortletAppDeployment.create(PortletAppDeployment.java:155) | ... 62 more View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882753#3882753 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882753 |
|
From: paulpopa <nu...@jb...> - 2005-06-26 12:09:05
|
Hi, I've just started to work with this server (after some experience with BEA's weblogic server) and i need to know if there are any settings for starting JBoss server in development mode, like BEA's product. What i mean is, for example, if i'm modifying the static content of a war file, i shouldn't redeploy the war file, but the server will present me the modified content. Thanks in advance, Paul Popa View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882749#3882749 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882749 |
|
From: mlybarger <nu...@jb...> - 2005-06-26 00:30:52
|
i have a simple web app with a servlet or two. i'd like to use the org.jboss.aspects.logging.CallLoggingInterceptor to log method invocation on my existing running app without touching the deployed .war. i want to use the supplied interceptors and such to be able to quickly demonstrate to some folks in our group the power of using aspects. i've got a stock release of jboss-4.0.1sp1. i enabled the transformer in the deploy/jboss-aop.deployer/META-INF/jboss-service.xml. i tried adding a section to the deploy/jboss-aop.deployer/base-aop.xml to bind the interceptor to my servlet like such: | <bind pointcut="execution(* org.test.*->*(..))"> | <interceptor class="org.jboss.aspects.logging.CallLoggingInterceptor"/> | </bind> | i set the root logger to debug level in the log4j.xml. when calling my servlet i don't see any additional logging from the CallLoggingInterceptor. I'm certainly missing something here...? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882737#3882737 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882737 |
|
From: <sco...@jb...> - 2005-06-25 22:31:34
|
1) Ant should be in the repository as well, but currently we do not include it into jboss. Tomcat used to until the switch to the jdt compiler. As of now there should be no need for this in libraries.ent. 2) So really, hibernate, hibernate annotations, and hibernate entitymanager (which is what I assme has the ejb3-persistence.jar artifact, ask Bill or Emmanuel) should be seperate entries in the repository as they are three seperate releases currently: http://www.hibernate.org/6.html View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882736#3882736 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882736 |
|
From: <rl...@jb...> - 2005-06-25 21:47:42
|
Excellent! That leaves me with only two references from the collection of build.xml files that I am not sure how to handle.
1) ant
The current libraries.ent has an entry for ant.
<!-- Ant -->
| <property name="apache.ant.root" value="${project.tools}"/>
| <property name="apache.ant.lib" value="${apache.ant.root}/lib"/>
| <path id="apache.ant.classpath">
| <pathelement path="${apache.ant.lib}/ant.jar"/>
| </path>
The version of ant is found in the tools directory, not in the thirdparty. For the generated libraries.ent to have an entry for it, it would need to exist in the repository. How should we handle this?
2) EJB-Pesistence
The current libraries.ent handles ejb-persistence like this:
<!-- hibernate3 -->
| <property name="hibernate.root" value="${project.thirdparty}/hibernate"/>
| <property name="hibernate.lib" value="${hibernate.root}/lib"/>
| <path id="hibernate3.classpath">
| <pathelement path="${hibernate.lib}/hibernate3.jar"/>
| <pathelement path="${hibernate.lib}/hibernate-annotations.jar"/>
| <pathelement path="${hibernate.lib}/asm.jar"/>
| <pathelement path="${hibernate.lib}/asm-attrs.jar"/>
| <pathelement path="${hibernate.lib}/antlr*.jar"/>
| </path>
|
| <!-- ejb3-persistence -->
| <path id="ejb3-persistence.classpath">
| <pathelement path="${hibernate.lib}/hibernate-annotations.jar"/>
| <pathelement path="${hibernate.lib}/hibernate-entitymanager.jar"/>
| <pathelement path="${hibernate.lib}/ejb3-persistence.jar"/>
| </path>
An ejb3-persistence classpath is defined, but it is part of hibernate (in the directory structure). The same problem exists as with ant. For an entry to be generated, it needs to have its own repository location, but does it make sense to break this out as a seperate entity?
Ruel Loehr
JBoss QA
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882735#3882735
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882735
|
|
From: <sco...@jb...> - 2005-06-25 03:27:12
|
1) This is because there is a notion of a component and it can be either a source or binary module? The hibernate integration module can be changed in the current jboss-4.0.x definition: | jboss-4.0.x -d jboss-4.0 \ | &_jboss_aop \ | ... | -d har hibernate \ | ... | The build.xml modules reference to hibernate would have to be changed locally to do the build. 2) There certainly is tons of garbarge in there. The thirdparty build should be created by only referencing the direct dependencies of the toplevel components. Build the thirdparty strucuture and try the build and add thirdparty componentrefs as needed until it builds. 3) As Ryan said, drop the double name usage as its a cvs hack issue that we should not propagate. 4) The only place the new thirdparty lib names should be showing up at is in the libraries.ent definitions. Nearly all build files in the modules should simply be referencing the *.classpath from librariens.ent. The only problem will be that there will not be an aggregate classpath like apache.commons.classpath. You could deal with this by adding a notion of being able to merge multiple component paths to the libraries.ent generation: | <path id="apache.commons.classpath"> | <componentref id="apache-lang" /> | <componentref id="apache-logging" /> | <componentref id="apache-modeler" /> | ... | </path> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882690#3882690 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882690 |
|
From: <ju...@jb...> - 2005-06-24 23:16:20
|
I have commited the refactoring of the server in CVS head. The modules that compiles and work are : common,server,api,portlet. All the other modules are not expected to work until they are fixed. The next tasks are : 1/ to pull out of the server module the theme and make it an independant module. Martin and I discussed about it and it seem that the best idea is to have : LayoutServer and ThemeServer injected in the deployer and the controller so they can cooperate. 2/ update the core with respect to the new changes - Write a controller - write the PageContainer and the Page object and have the deployer populates page - Probably lot of things to do that View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882678#3882678 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882678 |
|
From: hbarlas <nu...@jb...> - 2005-06-24 23:14:09
|
ok got it to work but I had to use the following property:
| ${jboss.bind.address}
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882677#3882677
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882677
|
|
From: <rya...@jb...> - 2005-06-24 20:09:02
|
1. This is a by product of using the directory name as the component id. We might be able to fix jbossbuild to have two components by the same name, one in thirdparty and one source component, but I'm afraid this leads to ambiguity. We shouldn't rename the thirdparty hibernate. If anything, the hibernate integration module needs to be renamed to hibernate-intg or something. 2. just what is being used. 3. We aren't using the double named convention anymore, so just use juddi. Make sure it has the correct version from the 4.0 versions.xml 4. Yes it will, but let's commit what we have before making changes to build.xmls. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882654#3882654 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882654 |
|
From: <rl...@jb...> - 2005-06-24 19:53:52
|
I worked with this yesterday and created a build-thirdparty.xml based off of what was in the thirdparty directory in the 4.0 branch. I found a couple of things that will need clarification. 1) hibernate thirdparty vs. hibernate module Currently when we try to pull down the thirdparty modules the build sees a directory "hibernate" (our integration module). Because this module exists it will not pull down the thirdparty component "hibernate". How should we resolve this? The way the build is currently structured a thirdparty component cannot have the same name as a source module. Should the hibernate thirdparty be moved to jboss/hibernate? 2) what we use vs. what is there If I go through every module under 4.0 (e.g. iiop, varia) looking at the build.xml file and look at what library classpaths are defined, and then creating a list of all library dependencies required, the list does not match the number of items in thirdparty. I assume some items in thirdparty (the early version of tomcat for example) are no longer used. Should I base the generated libraries.ent off of the cvs thirdparty dir as a whole, or just off of what is used. 3) naming conventions Currently in the repository we have some dual directories, one called juddi, one called juddi-juddi. Which should I base off of? 4) new thirdparty items In some cases, such as apache commons, the jars have been moved to their own repository locations. Won't this necessitate a change to the build.xml files ? Thanks! Ruel Loehr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882653#3882653 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882653 |
|
From: mmindenhall <nu...@jb...> - 2005-06-24 19:40:57
|
There is a problem with XDoclet support for this tag, unless you happen to be using JBoss version 3.2.x. Within the jboss_xml.xdt file, the code that generates the depends tag is wrapped with the following, which specifies that the tag should be generated only for version 3.2: <XDtConfig:ifConfigParamEquals paramName="Version" value="3.2"> However, it should be wrapped with this instead, which specifies that the tag should be generated for all versions >3.2: <XDtConfig:ifConfigParamGreaterOrEquals paramName="Version" value="3.2"> This occurs in 3 places within the file (once each for entity, session, and message-driven beans). The same problem may or may not exist in other jboss*.xdt files -- I didn't check. I have created an issue on Xdoclet's JIRA. Here is a link to the issue, which includes a fixed jboss_xml.xdt and a fixed version of the jarfile for xdoclet version 1.2.3. http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1444 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882650#3882650 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882650 |
|
From: dpasiuk <nu...@jb...> - 2005-06-24 18:31:21
|
Hello, Where is this document now? The link is broken. Thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882640#3882640 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882640 |
|
From: <ad...@jb...> - 2005-06-24 16:17:27
|
I've also changed the track-connection-by-tx handling in the contentious case to avoid overly long locking of the transaction local. Instead I trap two threads allocating different connections when the connection should be sticky to the transaction. The second thread returns the unwanted connection to the pool and uses the connection obtained by the first thread. i.e. Thread1: getConnection - no current transaction sticky connection Thread1: get a connection from the pool, but context switch Thread2: getConnection - no current transaction sticky connection Thread2: get a connection from the pool Thread2: register sticky connection and return it Thread1: recheck for sticky connection Thread1: there is one now, so return the connection we just got Thread1: return the transaction sticky connection In the non-contentious case, this requires an extra lock on the tx local (which should be minimal overhead since there is no contention) and an extra check of the tx local value. Comment from the code (BasePool.getConnection): | // Need a new connection for this transaction | // This must be done outside the tx local lock, otherwise | // the tx timeout won't work and get connection can do a lot of other work | // with many opportunities for deadlocks. | // Instead we do a double check after we got the transaction to see | // whether another thread beat us to the punch. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882626#3882626 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882626 |
|
From: <ad...@jb...> - 2005-06-24 16:09:03
|
So I finally managed to produce a stress test that reliably reproduces the
race condition I knew exists in TxManager.
The race condition goes something like this (two enlists on the same thread):
Thread1: getConnection and enlist in transaction
Thread1: first use of transaction so flags == TMNOFLAGS
Thread1: unlock() but then a context switch before the XAResource.start()
Thread2: getConnection from sameRM and enlist in transaction
Thread2: second use in transaction so flags == TMJOIN
Thread2: does XAResource.start()
Oops, JOIN before START => XAER_PROTO (protocol error).
To avoid this problem, I have changed TxConnectionEventListener.enlist()
to serialize contentious enlistments.
This is a small overhead of an extra ArrayList allocation in the non-contentious
case (besides the transaction local locks that are required anyway).
Comment from the code:
|
| public void enlist() throws SystemException
| {
| // This method is a bit convulted, but it has to be such because
| // there is a race condition in the transaction manager where it
| // unlocks during the enlist of the XAResource. It does this
| // to avoid distributed deadlocks and to ensure the transaction
| // timeout can fail a badly behaving resource during the enlist.
| //
| // When two threads in the same transaction are trying to enlist
| // connections they could be from the same resource manager
| // or even the same connection when tracking the connection by transaction.
| //
| // For the same connection, we only want to do the real enlist once.
| // For two connections from the same resource manager we don't
| // want the join before the initial start request.
| //
| // The solution is to build up a list of unenlisted resources
| // in the TransactionSynchronizer and then choose one of the
| // threads that is contending in the transaction to enlist them
| // in order. The actual order doesn't really matter as it is the
| // transaction manager that calculates the enlist flags and determines
| // whether the XAResource was already enlisted.
| //
| // Once there are no unenlisted resources the threads are released
| // to return the result of the enlistments.
| //
| // In practice, a thread just takes a snapshot to try to avoid one
| // thread having to do all the work. If it did not do them all
| // the next waiting thread will do the next snapshot until there
| // there is either no snapshot or no waiting threads.
| //
| // A downside to this design is a thread could have its resource enlisted by
| // an earlier thread while it enlists some later thread's resource.
| // Since they are all a part of the same transaction, this is probably
| // not a real issue.
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882624#3882624
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882624
|
|
From: aubergine <nu...@jb...> - 2005-06-24 11:13:27
|
Oops - just re-read the streaming example/sample and the standard invoke(InvocationRequest invocation) is there too. ... apologies for the post View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882596#3882596 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882596 |
|
From: <ju...@jb...> - 2005-06-24 10:29:06
|
that's a good point we should put in a FAQ I think View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882594#3882594 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882594 |
|
From: kevs3d <nu...@jb...> - 2005-06-24 09:37:37
|
That worked! Thanks for that Julian! :) Cheers, Kev -- http://www.alfresco.org View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882592#3882592 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882592 |
|
From: <ju...@jb...> - 2005-06-24 07:42:28
|
did you try removing it ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882586#3882586 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882586 |
|
From: gavinc <nu...@jb...> - 2005-06-24 01:10:20
|
Yes we are packaging a portlet JAR, should we not be packaging it or should we be packaging a later version i.e. one you include in the final release? Cheers, Gav --- http://www.alfresco.org View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882570#3882570 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882570 |
|
From: <ju...@jb...> - 2005-06-23 21:29:44
|
it may be a jar packaging issue, do you have a portlet.jar in the webapp you currently deploy ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882560#3882560 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882560 |
1965 messages has been excluded from this view by a project administrator.
