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: ctoohey <nu...@jb...> - 2005-06-01 18:46:48
|
I'm trying to install the JBoss Eclipse IDE using Eclipse's Update Manager. Everything is fine until near the end when it asks me for a "Target Install Location". When I select the "eclipse" home dir I get the error that the "Site Already Exists". When I select the "plugins" or "features" subdir, I get the error that "This Site is Contained in Another Site". I don't know what to select here. None of the install instructions I've found even mention this part of the installatin. I know I can just install the zip file without using the Eclipse Software Update manager, and I will if nobody answers this question. Thanks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879800#3879800 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879800 |
|
From: brossi <nu...@jb...> - 2005-06-01 18:37:04
|
Hi , when I try make deploy , I have this error | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java(Compiled Code)) | at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java(Compiled Code)) | at $Proxy8.deploy(Unknown Source) | at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java(Compiled Code)) | at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java(Compiled Code)) | at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java(Inlined Compiled Code)) | at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java(Compiled Code)) | at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:194) | Caused by: MBeanException: Exception invoking method destroy Cause: LifecycleException: Manager has not yet been started | at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:517) | at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:150) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java(Inlined Compiled Code)) | at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeployInternal(TomcatDeployer.java(Compiled Code)) | at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeploy(TomcatDeployer.java:83) | at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:370) | ... 49 more | Caused by: LifecycleException: Manager has not yet been started | at org.apache.catalina.session.StandardManager.stop(StandardManager.java:680) | at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4496) | at org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1213) | at org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4602) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code)) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code)) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) | at java.lang.reflect.Method.invoke(Method.java(Compiled Code)) | at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503) | ... 54 more | | any idea ? tks! PS : sorry my english, I from Brazil :) :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879799#3879799 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879799 |
|
From: <tom...@jb...> - 2005-06-01 18:13:00
|
I think this is a requirement that Adrian brought up a while back. Just now getting to it. In the context of the remoting code, this only makes sense for oneway calls (async) where the calling thread returns before making the server call: | public void invokeOneway(final Object param, final Map sendPayload, boolean clientSide) throws Throwable | where clientSide is true. Is this what you are wanting; when this call fails, notify an registered exception listener? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879795#3879795 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879795 |
|
From: <bil...@jb...> - 2005-06-01 17:59:57
|
lock()/unlock() should not be used internally in the TransactionLocal implementation as locking is not needed. TransactionLocal does need to provide a lock()/unlock() function so that you can protect the transaction local for multi-threaded transaction access within your code. Like, if in your application code, you need to check and set the tx local. If get() == null then set. You'll want to local.lock() if (get() == null) then set local.unlock(). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879791#3879791 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879791 |
|
From: <ad...@jb...> - 2005-06-01 17:57:46
|
The requirement is for any unrecoverable communication problem. Like in CORBA, Completed No - can be tried by attempting reconnection Completed Maybe - is a problem that needs reporting to the user The server may disallow reconnection if the "grace" period has expired. i.e. it has decided the client has crashed. We discussed this on a JMS thread didn't we? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879790#3879790 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879790 |
|
From: <ad...@jb...> - 2005-06-01 17:53:59
|
Read the javadocs for Connection.setExceptionListener() and it is also required such that the server can detect a vanished/crashed client. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879788#3879788 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879788 |
|
From: <ovi...@jb...> - 2005-06-01 17:34:22
|
Is this a requirement Adrian or I previously posted? Where does http://jira.jboss.org/jira/browse/JBREM-46 come from? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879787#3879787 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879787 |
|
From: <tom...@jb...> - 2005-06-01 17:21:46
|
Per Jira issue JBREM-46, there is a need by the new JMS implementation to have a callback when there is a connection failure during an anync call. I need to get some more detail requirements for this. What is the use case for this and any special information needed in the callback? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879784#3879784 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879784 |
|
From: <ad...@jb...> - 2005-06-01 17:17:56
|
A further option would be to provide the locking described by Bill,
but make it optional, i.e. in TransactionLocal
| public void lock();
| public void unlock();
|
This can then be used by the caller and/or we can provide a subclass that does it
automatically if the user doesn't want to think too hard. :-)
| public class SynchronizedTransactionLocal extends TransactionLocal
| {
| ...
| public Object get()
| {
| lock();
| try
| {
| return super.get();
| }
| finally
| {
| unlock();
| }
| }
| ...
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879783#3879783
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879783
|
|
From: erubinsky <nu...@jb...> - 2005-06-01 16:34:02
|
That works! Thanks for the clairification. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879779#3879779 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879779 |
|
From: <tom...@jb...> - 2005-06-01 16:01:37
|
In JBossRemoting versions 1.0.2 and before, the method signature within org.jboss.remoting.InvokerCallbackHandler? for handling callbacks was: | public void handleCallback(InvocationRequest invocation) throws HandleCallbackException | In version 1.0.1 final the Callback class, which extends the InvocationRequest class, was introduced to be used as the object passed to the handleCallback() method to make it simpler to create the callback payload to be passed. However, the API for InvokerCallbackHandler was not changed in order to maintain backwards compatibility with all 1.0.x versions. Post 1.0.x versions, the method signature has been changed to: | public void handleCallback(Callback callback) throws HandleCallbackException | to make is easier to process the callback payload. The Callback object still extends InvocationRequest, so all the API previously available is still there. Can find more callback info at http://wiki.jboss.org/wiki/Wiki.jsp?page=Remoting_callbacks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879774#3879774 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879774 |
|
From: <ale...@jb...> - 2005-06-01 13:41:30
|
Current binding elements are described here http://www.jboss.org/wiki/Wiki.jsp?page=JBossXB_JBXBAnnotations View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879757#3879757 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879757 |
|
From: <ale...@jb...> - 2005-06-01 13:39:24
|
I've been working on binding bean-deployer XSD to the corresponding Java classes. Current state can be tracked by checking out | package org.jboss.test.xml; | public class JbxbPojoServerUnitTestCase | The annotated schema is 'xml/jbxb-bean-deployer_1_0.xsd' in the src/resources. Though, as I understand, the xsd and classes I have in test/xml got out of date. The programmatic binding still remains for: - map entry binding when we have to create a temporary container for the entry - merging properties (if I am doing this right...) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879756#3879756 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879756 |
|
From: erinol0 <nu...@jb...> - 2005-06-01 13:07:30
|
anonymous wrote : JBossIDE-1.5M1-Hibernate-Tools.zip | which is 18260 KB JBossIDE version 1.5M1 anonymous wrote : hibernate-tools-3.0alpha1.zip | which is 8031 KB Hibernate tools version 3.0alpha1 JBossIDE is a amalgamation of tools for different subprojects in JBoss. Since Hibernate already has a plugin being developed for eclipse, the JBossIDE team incorporates it into their plugin. It is worth noting that there are developers working on both projects. Incidentally, JBossIDE is using Hibernate Tools version 3.0alpha2 according to: http://www.jboss.org/products/jbosside Hope that helps. Raj View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879752#3879752 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879752 |
|
From: <dim...@jb...> - 2005-06-01 13:04:36
|
So from your postings and the code, I gather: 1) TransactionLocal is mt-safe when accessed by threads in different transactions, but non-mt-safe when accessed by threads in the same transaction. 2) To avoid global contention any synchronization would need to happen in the TransactionLocalDelegate implentation, at tx level, with a trimming-dowm of TransactionLocal, as Bill suggested. 3) However, Adrian points out that the caller is really the one who defines the mt access pattern, which most probably would be tx scoped, so it should be his responsibility for applying locking, if needed. My take is that if we don't have known/reported issues of mt problems with TransactionLocal, we are better-off documenting its mt behaviour described in (1), without introducing extra snychronization. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879750#3879750 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879750 |
|
From: <cle...@jb...> - 2005-06-01 12:56:52
|
anonymous wrote : Guess a bigger question would be how to distinquish when to run the particular benchmark receiver task. If include in the build script for a database, I am not likely to have access to the preconfigured database, so guess it would error? Maybe another way to look at it is to have the receiver actually running on the central database server and listen for the benchmark results via jgroups. That way, if on the same network, it will pick up the results. I'm trying to set HSQLDB by default in the script, and generating a simple report at the end of each running for developers. But I liked the idea also of having the FileBenchmarkReceiver being controlled by AntBenchmarkReceiver. But I think I would create two Ant tasks: I - AntFileBenchmarkReceiver II - AntDatabaseBenchmarkReceiver Both receivers would have an equivalent BenchmarkReceiver outside the ant task. Clebert Suconic View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879749#3879749 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879749 |
|
From: <dim...@jb...> - 2005-06-01 11:22:51
|
That's fine. With this change it could make sense to avoid a few objects by making TransactionLocalDelegateImpl a singleton, since it doesn't hold any state, except for the TM which is not used. Not important, anway. Thanks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879738#3879738 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879738 |
|
From: mikezzz <nu...@jb...> - 2005-06-01 11:01:56
|
Create a patch against head and submit it. I can have a look at it. Mike. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879737#3879737 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879737 |
|
From: <tom...@jb...> - 2005-06-01 05:09:58
|
Have added the ability to customize streams for socket invoker. See http://wiki.jboss.org/wiki/Wiki.jsp?page=Remoting_customizations for details. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879702#3879702 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879702 |
|
From: <tom...@jb...> - 2005-06-01 04:26:11
|
I figure there will be two use cases. The first is where want to formally track performance benchmarks over time. The database receiver is best for this and would probably be used for any test machines running continous builds and specific test runs (maybe for release testing). The other use case is for the developer. I will probably never set up a database for this, so the file based persistence works better for me. It is certainly less important, but I just added it so I when am testing locally, I can compare results. Would be nice to have it built into my test build file, but starting it manually is not big deal either. Guess a bigger question would be how to distinquish when to run the particular benchmark receiver task. If include in the build script for a database, I am not likely to have access to the preconfigured database, so guess it would error? Maybe another way to look at it is to have the receiver actually running on the central database server and listen for the benchmark results via jgroups. That way, if on the same network, it will pick up the results. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879697#3879697 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879697 |
|
From: ctoohey <nu...@jb...> - 2005-06-01 00:17:05
|
I'm starting a new project involving JBoss and Hibernate, among other things. I've never used either before. I see that both have Eclipse plug-ins called Hibernate Tools. These seem to be related, as the JBoss Eclipse IDE has links to the Hibernate Tools on hibernate.org. But the JBoss Eclipse IDE also has a download for a file called: JBossIDE-1.5M1-Hibernate-Tools.zip which is 18260 KB whereas hibernate.org has a download for: hibernate-tools-3.0alpha1.zip which is 8031 KB so clearly these plug-ins are substantially different. Can anyone clarify what the differences are and recommend one or the other ? Thanks, Charlie View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879687#3879687 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879687 |
|
From: <ad...@jb...> - 2005-06-01 00:03:09
|
4) Your also going to get into further trouble with these locks competing with other locks for correct ordering, like TransactionImpl's lock()/unlock(). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879685#3879685 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879685 |
|
From: <ad...@jb...> - 2005-06-01 00:00:44
|
"bil...@jb..." wrote : Maybe you didn't read my above email. I'm suggesting that any synchronization done should be done in the TransactionLocalDelegate implementation. For our implementation, we can do it in org.jboss.tm.TransactionImpl.
Yes, I read your previous response.
1) I don't disagree that the delegate needs to be internally threadsafe.
This is not true at the moment:
a) TransactionImpl has an unsynchronized HashMap to store the values.
b) TransactionLocalDelegate.getSynchronization() could register two synchronizations
2) I disagree that TransactionLocal needs to do internal synchronization, it should
just be marked as not threadsafe.
e.g. this code could lead to deadlocks
| public class Blah
| {
| static TransactionLocal local = new TransactionLocal()
| {
| protected Object initialValue()
| {
| return doSomeExternalCalculationThatSynchronizesOnWhoKnowsWhat();
| }
| }
|
| public void doSomething()
| {
| Object value = local.get();
| }
| }
|
The ".get()" could invoke the initialValue() with contradictory synchronizations
to the way doSomething() is used, and you also have the "unknown" synchronization
on the delegate that the user can't see.
This is just a mess.
3) Leave it to the user to correctly synchronize (they know best!)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879684#3879684
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879684
|
|
From: <bil...@jb...> - 2005-05-31 23:34:44
|
"ad...@jb..." wrote : "bil...@jb..." wrote : | | I understand that, but we do control the implementation of 99.99999% of used TransactionLocalDelegate implementations which was my point....The design of TransactionLocal should take advantage of this and not be designed for the 0.00001% of cases. | | Yes, but your argument applies to the delegate callouts, where I used the qualification | "or even" | The initialValue() callout is "user code". | | I don't see how plain synchronization on the TransactionLocal (which is a global object | across all transactions) will ever be the correct thing to do. If you need to do that, | you probably shouldn't be using a TransactionLocal :-) Maybe you didn't read my above email. I'm suggesting that any synchronization done should be done in the TransactionLocalDelegate implementation. For our implementation, we can do it in org.jboss.tm.TransactionImpl. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879677#3879677 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879677 |
|
From: <ad...@jb...> - 2005-05-31 23:33:26
|
"dim...@jb..." wrote : "It could equally use the passed TransactionLocal rather than the implementation since there is a one-one correspondance." | | But it would be no fun then, right? :) | | quite impressive; I'd never guess this one. It's not intended to be obfuscated. Change it to use the passed TransactionLocal if it makes the code easier to read/understand. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879676#3879676 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879676 |
1965 messages has been excluded from this view by a project administrator.
