Hi Chirino
I already saw the code of eclipse. More or less it seems to work similar
to NetBeans but I really had a hard time to figure out how it works.
For this Management GUI we don't need an IDE and I want to keep
the GUI as simple as possible and to avoid to carry around overhead.
But the
Hi
Yes, you are welcome. Right now I am trying to code the server part
making the JBoss manageable. This week I will add the updated
JavaDoc of the JSR-77 classes to the website and you can have a
look at their classes and also a look the JBoss implementation.
The general idea is that JBoss
Bugs item #449025, was opened at 2001-08-08 00:11
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=449025group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to:
-Ursprüngliche Nachricht-
Von: marc fleury [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 7. August 2001 23:38
An: marc fleury; Jboss-Development@Lists. Sourceforge. Net
Betreff: [JBoss-dev] RE: Rabbits and Big-ears
hi again:)
Hi
The general idea is that JBoss implements JSR-77 and the management
GUI uses the JSR-77 interfaces. Therefore the client does not have
to know much about JBoss.
oki.. I will start playing around with JSR-77.
I will try to consolidate the positions and ideas on the JBossMGT
Bugs item #449037, was opened at 2001-08-08 01:30
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=449037group_id=22866
Category: JBossCMP
Group: v2.4 BETA (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned
I'd prefer the idea of creating an own framework which can
be tailored to the specifics of the needs of the JBoss framework
and does not carry too much overhead.
From my opinion, NetBeans and Eclipse will bring too much
functionality that is not needed, but it would be worth having a
closer look
Bugs item #449056, was opened at 2001-08-08 02:42
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=449056group_id=22866
Category: JBossServer
Group: v2.2.2 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned
Bugs item #449059, was opened at 2001-08-08 02:46
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=449059group_id=22866
Category: JBossServer
Group: v2.2.2 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Fuller (neril)
Assigned to:
Hi,
Currently the container verifies that an ejb-link exists inside an
ejb-local-ref.
I read through the spec and don't see this is required.
In most cases the 2 beans will be in the same jar so no problem, but this
limitation should not happen imho.
A second point:
Local interfaces access must
on running the web integration tests in jbosstest
against 2.4.0.23_BETA and the 2.4 branch from CVS
integrated with the latest Jetty I am getting a nasty
:
run-testcase:
[junit] Running
org.jboss.test.web.test.TestWebIntegration
[junit] Found warDeployer named: :service=Jetty
[junit]
Hi Vincent,
The specification does not indicate the limitations of the scope in
which local interfaces are effective, beyond requiring that they be
co-located in a JVM. I wish it did, and I advocated a specific
statement in the spec in a discussion on ejb-interest.
Obviously
|In my opinion, you are not portable using local references between
|EARs. It might be supported by JBoss when Marc solves the
|dumbo problem, but I still wouldn't recommend this approach.
The dumbo problem for applications was solved in december and implemented by
Dr Jung in his deployer (that
Patches item #449099, was opened at 2001-08-08 06:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=449099group_id=22866
Category: JBossMQ
Group: v2.4 BETA (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Riege (lqd)
Assigned to:
on 1-08-08 19.05, Jacob Andresen at [EMAIL PROTECTED] wrote:
JbossMGT client could run on your mobile phone :oP
Yes ... design in a PresenterFactory interface in front of the JSR-77
interface that can be used by a JMX, HTML, WAP, anyOtherProtocol client
classes to generate (transcode) the
Sorry, I don't quite understand .. what was so bad about the ejx approach?
I recognized ejx as a _generic_ powerful, simply to use framework for
building xml-editors. I think, it would be a better idea, to build upon the
existing editors and make them more user friendly, verbose and fool prove.
|Using local interfaces from web would be stupid I agree.
I am not sure that is true, nor what he says.
In fact we already use local stuff in the optimized version. I guess it
wouldn't be portable that's all and would limit your deployment option. But
since we automate that already in the
.. the following should do it:
for f in `find src -name *.java`
do
sed 's/JBoss, the OpenSource EJB server/JBoss, the OpenSource J2EE webOS/g' $f $f.2
mv $f.2 $f
done
You can concatenate everything into one line, if you separate it with ;
If you dont't trust it (even I don't ;-), leave
I just tried this on a freshly updated 2.4 jboss
branch (now reporting itself as Rel_2_4_0_26 and it
seems quite happy.
So I guess this is just a change between 2.4.0.23 and
26 and that jboss and jbosstest are in synch.
Should I stick with 23 for my forthcoming release - or
go for a 26 ?
|Using local interfaces from web would be stupid I agree.
I am not sure that is true, nor what he says.
In fact we already use local stuff in the optimized version. I guess it
wouldn't be portable that's all and would limit your deployment
option. But
since we automate that already in
Long story short,
JAXP stuff was build with the same (beginner) mistake as the JAAS stuff in
its classloader structure.
It seems that it was using classforName() instead of the context class
loader stuff. This of course caused JBoss 3.0 to be miserable if the stuff
was not in the system
can't you replace crimson.jar with (xerces.jar and xalan.jar)
I thought crimson.jar was the old stuff
Filip
~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
[EMAIL PROTECTED]
www.filip.net
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
User: patriot1burke
Date: 01/08/08 09:17:37
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
CMPPersistenceManager.java
Log:
catch and throw RemoveException
Revision ChangesPath
No revision
No
User: patriot1burke
Date: 01/08/08 09:23:46
Modified:src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
Log:
catch and throw RemoveException
Revision ChangesPath
1.30 +7 -2 jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java
Index:
Patches item #449214, was opened at 2001-08-08 10:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=449214group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Stewart Allen
Hi
JSR-77 comes (by default) with a EJB front-end which each
client can use to get the information about the management
domain of application servers (this is mandatory).
My idea about this is:
- we have a dedicated, stripped-down application server
running the management server
- this server
User: pra
Date: 01/08/08 11:01:04
Modified:src/examples/org/jboss/docs/jms build.xml
Log:
Changed to use JBoss deployer for beans
Revision ChangesPath
1.3 +25 -0 manual/src/examples/org/jboss/docs/jms/build.xml
Index: build.xml
User: pra
Date: 01/08/08 11:05:38
Modified:src/etc/conf/default jboss.jcml
Log:
Changed JMSProviderLoader to use XA versions of connection factories
Revision ChangesPath
1.46 +2 -2 jboss/src/etc/conf/default/jboss.jcml
Index: jboss.jcml
Now I am really confused - not just but really ;-)
You say that MGT will use EJB as communication instead of JMX as bus ?
I can se a PresentationFactory using EJB as collector of data before it
delegates to its HTML, Wap, Swing or whatHaveU for presentation specific
processing, but for MGT of
on 1-08-08 19.39, Schaefer, Andreas at [EMAIL PROTECTED] wrote:
- we have a dedicated, stripped-down application server
running the management server
Should'ent all servers in one domain be able to be the MGT server for that
instance domain ? - dynamic swap for service/fail over ?
/peter_f
Hi
Don't be confused. I think JSR-77 group didn't want to
rely on JMX therefore they came up with the EJB front-end.
EJB would be easy to use within JSP and Java clients.
The major reason not to use JMX is that there is no
security.
For JMX we have to wait. There are still discussions about
on 1-08-08 19.39, Schaefer, Andreas at [EMAIL PROTECTED] wrote:
- we have a dedicated, stripped-down application server
running the management server
Should'ent all servers in one domain be able to be the MGT server for that
instance domain ? - dynamic swap for service/fail over ?
On 7 Aug, Hiram Chirino wrote:
From: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Retuning JMS RA connections?
Date: Tue, 7 Aug 2001 15:51:00 -0700 (PDT)
That sees like a bug, but it is important to remember that whats
On 7 Aug, Jason Dillon wrote:
That sees like a bug, but it is important to remember that whats
actually is pooled is the the session, and that should be closed after
each method invocation.
I was not closing the session properly.
Should the connection close all of its sessions?
No it
User: user57
Date: 01/08/08 13:02:26
Modified:src/main/org/jbossmq/server JMSServer.java
Log:
o removed maximum size limits on the server side and client side
PooledExecutors. These values (as well as the other PE params) should
be exposed via JMX for customization.
User: user57
Date: 01/08/08 13:02:26
Modified:src/main/org/jbossmq Connection.java
Log:
o removed maximum size limits on the server side and client side
PooledExecutors. These values (as well as the other PE params) should
be exposed via JMX for customization. Until
Hi Peter
Not quite sure if we should do it this way. Maybe you
have a farm of app. servers w/o a Servlet Engine but
you need one for the MGT server. Also when a server
does down it shouldn't bother the MGT server except
it is his server but then you can just restart it
otherwise you have to make
User: sparre
Date: 01/08/08 13:19:40
Modified:iiop/src/main/org/jboss/iiop/rmi/server InterfaceMapper.java
OperationMapper.java ParameterMapper.java
Log:
Following the lead in redefining JBoss.
Revision ChangesPath
1.2 +2 -2
User: sparre
Date: 01/08/08 13:19:39
Modified:iiop/src/main/org/jboss/iiop/rmi AbstractAnalysis.java
AttributeAnalysis.java ClassAnalysis.java
ConstantAnalysis.java ContainerAnalysis.java
ExceptionAnalysis.java
User: sparre
Date: 01/08/08 13:19:40
Modified:iiop/src/main/org/jboss/iiop/rmi/ir AliasDefImpl.java
AttributeDefImpl.java ConstantDefImpl.java
ContainedImpl.java ContainerImpl.java
ContainerImplDelegate.java
User: sparre
Date: 01/08/08 13:19:39
Modified:iiop/src/main/org/jboss/iiop AbstractTestBase.java
CorbaORBService.java CorbaORBServiceMBean.java
Test.java TestBase.java TestException.java
TestImpl.java
on 1-08-08 22.03, Schaefer, Andreas at [EMAIL PROTECTED] wrote:
Maybe you have a farm of app. servers w/o a Servlet Engine but
you need one for the MGT server.
Scenario :
- I have two machines running JBoss with servlet engines for failover and
loadbalance purposes ! - I would not run one of
I'm finding the switch from PFD1 to PFD2 extremely painful. The use of
remote interfaces and CMR fields, of course, permeates my code. I do have
code that previously used remote interface of an entity bean from a
servelt. I realize in the ideal design world there would be a session bean
in
User: sparre
Date: 01/08/08 14:23:47
Added: iiop patch.sh
Log:
Added a simple shell script for patching JBoss with the IIOP code.
Revision ChangesPath
1.1 contrib/iiop/patch.sh
Index: patch.sh
User: patriot1burke
Date: 01/08/08 15:00:46
Modified:src/main/org/jboss/ejb/plugins
EntitySynchronizationInterceptor.java
EntityLockInterceptor.java
EntityInstanceInterceptor.java
Log:
refactored BeanLock
User: patriot1burke
Date: 01/08/08 15:00:10
Modified:src/main/org/jboss/ejb BeanLock.java
Log:
refactored BeanLock interface
Revision ChangesPath
1.9 +16 -24jboss/src/main/org/jboss/ejb/BeanLock.java
Index: BeanLock.java
User: patriot1burke
Date: 01/08/08 15:01:04
Modified:src/main/org/jboss/ejb/plugins AbstractTxInterceptor.java
Log:
fixed minor NPE bug
Revision ChangesPath
1.4 +24 -17jboss/src/main/org/jboss/ejb/plugins/AbstractTxInterceptor.java
Index:
User: patriot1burke
Date: 01/08/08 15:01:31
Modified:src/main/org/jboss/ejb/plugins/lock
SimplePessimisticEJBLock.java BeanLockSupport.java
Log:
refactored BeanLock interface
Revision ChangesPath
1.5 +18 -3
User: patriot1burke
Date: 01/08/08 15:02:21
Added: src/main/org/jboss/ejb/plugins/lock
QueuedPessimisticEJBLock.java
Log:
new FIFO txWait queue. Should have better performance
Revision ChangesPath
1.1
User: patriot1burke
Date: 01/08/08 15:03:15
Modified:src/main/org/jboss/test/lock/test Main.java
Log:
added testing for QueuedPessimisticEJBLock
Revision ChangesPath
1.8 +38 -0 jbosstest/src/main/org/jboss/test/lock/test/Main.java
Index: Main.java
User: patriot1burke
Date: 01/08/08 15:03:32
Modified:src/resources/lock/META-INF jboss.xml ejb-jar.xml
Log:
added testing for QueuedPessimisticEJBLock
Revision ChangesPath
1.3 +194 -0jbosstest/src/resources/lock/META-INF/jboss.xml
Index: jboss.xml
User: patriot1burke
Date: 01/08/08 15:04:44
Modified:src/main/org/jboss/test/threading/interfaces EJBThreads.java
Log:
added new testNonTransactional method to test non-transactional entity methods
and locking
Revision ChangesPath
1.2 +5 -4
User: patriot1burke
Date: 01/08/08 15:05:34
Modified:src/main/org/jboss/test/threading/mbean Threads.java
Log:
added new testNonTransactional method to test non-transactional entity methods
and locking
Also, when stop is called, print out a message that thread is complete
User: user57
Date: 01/08/08 15:19:03
Modified:src/lib jbossmq.jar
Log:
o updated jbossmq .jars for the PooledExecutor max size fix
Revision ChangesPath
1.16 +679 -615 jboss/src/lib/jbossmq.jar
Binary file
Since JmsSession nor JmsManagedConnection needs to be synchronized to call
the underlying TopicSession or QueueSession object, lets drop it and let the
impl descide if it needs to be sync'd.
What do ya think.
--jason
On Wed, 8 Aug 2001 [EMAIL PROTECTED] wrote:
On 7 Aug, Jason Dillon wrote:
User: pkendall
Date: 01/08/08 17:21:43
Modified:src/main/org/jbossmq/il/jvm JVMServerILFactory.java
Log:
Major updates (especially to topics).
Speed improvements.
Make JVM IL work (by using a singleton JMSServer).
Message Listeners re-implemented using client-side thread.
User: pkendall
Date: 01/08/08 17:23:56
Modified:src/main/org/jbossmq/il/jvm JVMServerILService.java
Log:
Major updates (especially to topics).
Speed improvements.
Make JVM IL work (by using a singleton JMSServer).
Message Listeners re-implemented using client-side thread.
User: user57
Date: 01/08/08 17:25:00
Modified:src/main/org/jnp/server Main.java
Log:
o gave the main listen thread a name.
Revision ChangesPath
1.9 +4 -2 jnp/src/main/org/jnp/server/Main.java
Index: Main.java
User: pkendall
Date: 01/08/08 17:27:38
Modified:src/main/org/jbossmq/il/rmi RMIServerIL.java
RMIServerILRemote.java
Log:
Major updates (especially to topics).
Speed improvements.
Make JVM IL work (by using a singleton JMSServer).
Message Listeners
User: pkendall
Date: 01/08/08 17:27:21
Modified:src/main/org/jbossmq/il/oil OILClientIL.java
OILClientILService.java OILServerIL.java
OILServerILService.java
Log:
Major updates (especially to topics).
Speed improvements.
Make JVM
User: pkendall
Date: 01/08/08 17:28:42
Modified:src/main/org/jbossmq/il/uil UILClientIL.java
UILClientILService.java UILServerIL.java
UILServerILService.java
Log:
Major updates (especially to topics).
Speed improvements.
Make JVM
Hi all,
tried to compile the embedded catalina stuff from
the cvs sources together with tomcat-4-beta6 today.
It failed (to start with) because there is a line
import org.apache.catalina.Resources;
in org/jboss/contrib/catalina/ConfigMapper.java - but
the Resources class got moved to the
Hi
-Original Message-
From: Peter Fagerlund [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 08, 2001 1:48 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] A new user interface for JBoss
on 1-08-08 22.03, Schaefer, Andreas at [EMAIL PROTECTED] wrote:
Maybe you have a
User: pkendall
Date: 01/08/08 18:18:27
Modified:src/main/org/jbossmq/il/oil OILClientIL.java
OILClientILService.java OILServerIL.java
OILServerILService.java
Log:
Major updates (especially to topics).
Speed improvements.
Make JVM
User: pkendall
Date: 01/08/08 18:18:28
Modified:src/main/org/jbossmq/il/uil UILClientIL.java
UILClientILService.java UILServerIL.java
UILServerILService.java
Log:
Major updates (especially to topics).
Speed improvements.
Make JVM
User: pkendall
Date: 01/08/08 18:18:27
Modified:src/main/org/jbossmq/il/jvm JVMServerIL.java
JVMServerILFactory.java JVMServerILService.java
Log:
Major updates (especially to topics).
Speed improvements.
Make JVM IL work (by using a singleton JMSServer).
User: pkendall
Date: 01/08/08 18:18:28
Modified:src/main/org/jbossmq/pm PersistenceManager.java
TxManager.java
Added: src/main/org/jbossmq/pm Tx.java
Log:
Major updates (especially to topics).
Speed improvements.
Make JVM IL work (by using a
User: pkendall
Date: 01/08/08 18:18:27
Modified:src/main/org/jbossmq/il ServerIL.java
Log:
Major updates (especially to topics).
Speed improvements.
Make JVM IL work (by using a singleton JMSServer).
Message Listeners re-implemented using client-side thread.
Revision
User: pkendall
Date: 01/08/08 18:18:28
Modified:src/main/org/jbossmq/pm/logged PersistenceManager.java
SpyMessageLog.java SpyMessageLogTester.java
SpyTxLog.java
Log:
Major updates (especially to topics).
Speed improvements.
Make
User: pkendall
Date: 01/08/08 18:18:28
Modified:src/main/org/jbossmq/pm/rollinglogged IntegrityLog.java
PersistenceManager.java
PersistenceManagerMBean.java SpyMessageLog.java
SpyTxLog.java
Removed:
User: pkendall
Date: 01/08/08 18:18:28
Modified:src/main/org/jbossmq/pm/file MessageLog.java
PersistenceManager.java
Log:
Major updates (especially to topics).
Speed improvements.
Make JVM IL work (by using a singleton JMSServer).
Message Listeners
User: pkendall
Date: 01/08/08 18:18:28
Modified:src/main/org/jbossmq/pm/jdbc MessageLog.java
PersistenceManager.java TxLog.java
Log:
Major updates (especially to topics).
Speed improvements.
Make JVM IL work (by using a singleton JMSServer).
Message
User: pkendall
Date: 01/08/08 18:19:28
Modified:src/etc/conf/default jboss.jcml
Log:
Use rolling logged persistence because it rocks!
Revision ChangesPath
1.9 +1 -1 jbossmq/src/etc/conf/default/jboss.jcml
Index: jboss.jcml
Patches item #449369, was opened at 2001-08-08 19:17
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=449369group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Cameron (camtabor)
I mentioned a while ago something about trimming all whitespace from
metadata values, but that was rejected because some data might need that
whitespace. I also added support to auto trim attribute values from
jboss.jcml.
Now I would like to suggest changing things such that all leading
and
Hi,
I like it.
Don't we also need a dtd for jboss.jcml (or is there one I haven't found?)?
My experience with adding a dtd indicates whitespace handling may be
affected-- maybe we should add the dtd and validation first?
At the risk of changing the subject ;-)
There seem to be two
yes...
When Message are placed on the JMSQueue object, they get placed on a list
until we have a consumer that will accept the message. The deal is that
with an async consumer (like a MDB), when he subscribes to the destination,
we just 'turn on the message valve' allowing messages to flow
77 matches
Mail list logo
