After thinking about this somemore, and enabling thread info in server.log I
realize now that the timer is not an issue, there is never an instance where
the timer thread attempts to use the wrapper over the SFSB... the work
completes too fast.
And due to the fact that I sync'd the wrapper
Or perhaps I am not using the JMS resource propertly within the bean...
Should I be able to save a QueueSession and QueueSender as fields and use them
over multipule calls inside of a SFSB? Or do I need to recreate the session
and sender each time?
If that is the case it rather sucks...
Hello,
I am now testing FoeDeployer and have a question that, probably, affects
behaviour of other deployers too.
Suppose we have deployment units in the deploy dir waiting for the
deployer. And the deployer is at last deployed. I expect the following
sequence of calls on the deployer:
Hi Alex!
Does log4j guarantee to display the log messages in the order they
timely occured ?
With the old logging that wasn't the case (it was NOT guaranteed). It do
not know for log4j.
Just a thought,
Tobias
Alex Loubyansky wrote:
Hello,
I am now testing FoeDeployer and have a
Hello Tobias,
good question. I'd like to know too.
Friday, May 24, 2002, 1:55:26 PM, you wrote:
TF Hi Alex!
TF Does log4j guarantee to display the log messages in the order they
TF timely occured ?
TF With the old logging that wasn't the case (it was NOT guaranteed). It do
TF not know for
I looked at the jmsra code a bit. You should be able to hold onto the
session over method calls (new feature w/ new jca impl) but not anything
you get from the session, such as the sender. The session may be
associated with different physical connections on each (SFSB) call, and the
sender
I think that would be safer. That will also allow the session to go back
into the session pool thus you will share your resources better.
Regards,
Hiram
From: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], Scott M Stark
[EMAIL PROTECTED]
Subject: Re:
I am using jboss 3.0 rc3. I am seeing a classloader lockup when I am
deploying an ear file. The two threads are below. I noticed that Simon
updated the classloader code , does this fix it? Is it only on the 3.1
branch?
CCRAPoll prio=5 tid=0x88adcf8 nid=0x20e waiting for monitor entry
Hi,
I am using jboss 3.0 rc3. I am seeing a classloader lockup when I am
deploying an ear file. The two threads are below. I noticed that Simon
updated the classloader code , does this fix it? Is it only on the 3.1
branch?
It is supposed to fix it, for now is in 3.1, but unfortunately I'm
Scott,
Does the 'server name' (server identity) need to be part of the getPort request, if
it is spec'd in the svc bind mbean config? if the server name was set on the mbean,
then the port maps could be keyed off that (in addition to service name). So, the
request for getport could assume the
From your description below I think FoeDeployer depends on
WebLogicConverter. If you explicitly state this dependency with a depends
tag the deployment system will create WLC before FD and start WLC before
FD. If FD is designed to accept lots of converters you can use a
depends-list element.
Ok. Let me know when you are done. I will test it
On Fri, 2002-05-24 at 09:08, Bordet, Simone wrote:
Hi,
I am using jboss 3.0 rc3. I am seeing a classloader lockup when I am
deploying an ear file. The two threads are below. I noticed that Simon
updated the classloader code , does
Hello David,
I asked that because I found it strange that the deployer not being
started already deploys some units, if the log is right. So, the log
is like:
[FoeDeployer] Starting
[MainDeployer] Adding deployer:
[MainDeployer] Starting deployment of package: waitinig unit
[FoeDeployer]
Hello David,
Friday, May 24, 2002, 4:20:33 PM, you wrote:
DJ From your description below I think FoeDeployer depends on
DJ WebLogicConverter. If you explicitly state this dependency with a depends
DJ tag the deployment system will create WLC before FD and start WLC before
DJ FD. If FD is
Hello Alex,
I've got it.
[FoeDeployer] Starting - the beginning of the method
FoeDeployer.startService()
[FoeDeployer] Started - the end of it.
But it looks messy in case of deploying (actually any) deployer when
there are waiting deployable units.
alex
Friday, May 24, 2002, 4:53:33 PM, you
The FoeDeployer should register with MainDeployer as the last thing it does
in startService(), when it is in fact usable. So at least you should move
super.startService() to the end.
I just looked at the code and think that a simpler design would be to
simply have the WLC be a SubDeployer. You
On 2002.05.24 10:02:08 -0400 Alex Loubyansky wrote:
Hello David,
Friday, May 24, 2002, 4:20:33 PM, you wrote:
DJ From your description below I think FoeDeployer depends on
DJ WebLogicConverter. If you explicitly state this dependency with a
depends
DJ tag the deployment system will
Hello David,
Friday, May 24, 2002, 5:17:19 PM, you wrote:
DJ The FoeDeployer should register with MainDeployer as the last thing it does
DJ in startService(), when it is in fact usable. So at least you should move
DJ super.startService() to the end.
Yes, it even caused problem determining
I think it is a good idea. I vote for it. There were some notes in one my
emails on the 20th with a suggested approach.
On the DeploymentInfo, I think David is correct about eventually wanting
the DeploymentInfo as an MBean. A friend of mine comparing Weblogic and
JBoss, was miffed at the
On 2002.05.24 11:31:46 -0400 Frederick N. Brier wrote:
I think it is a good idea. I vote for it. There were some notes in one
my
emails on the 20th with a suggested approach.
On the DeploymentInfo, I think David is correct about eventually wanting
the DeploymentInfo as an MBean. A
This is in regards to the MBean viewer on port 8082. Instead of using an
HTML interface, what if we made it a SOAP interface with a Java
Client? This could tie into JAAS security and limit access. I wrote a
similar GUI on another Java project. I don't want to cause anyone nausea,
but the
There is already an ejb exposing the mbean server, thus providing security,
and a project to create a servlet based viewer. Exposing something via
jboss.net seems like a good idea also.
Are you interested in working with the guys on the improved viewer? I think
the discussion is on the jmx
Hi David
The FoeDeployer should register with MainDeployer as the last thing it
does
in startService(), when it is in fact usable. So at least you should move
super.startService() to the end.
Done.
I just looked at the code and think that a simpler design would be to
simply have the WLC
Bugs item #516953, was opened at 2002-02-13 13:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=516953group_id=22866
Category: None
Group: v2.4 (stable)
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Chris Harris (charris)
Assigned to:
I was trying to back track and read the messages on jsr-77. My apologies,
I had never heard of it, so I am playing catch up. There seems to be a
never ending stream of APIs. I just skimmed the JavaOne Presentation 1717
and looked at the http://java.sun.com/j2ee/tools/management/ web page
Bugs item #516953, was opened at 2002-02-13 05:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=516953group_id=22866
Category: None
Group: v2.4 (stable)
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Chris Harris (charris)
Assigned to:
The local use of the mbean will not use this as you say its a bound property
of the mbean the service requesting portmapping is talking to. This
information
needs to be part of the ServiceBinding object for use in remote access to
a central authority as well as debugging.
There is no guarentee of log message ordering in the standard log4j
appenders.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Tobias Frech [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 24,
A problem that keeps popping up with the JSR77 integration
is that it is rather invasive and if it fails it breaks existing code.
A better integration path would be strictly as external listeners
to JMX events. This would clean up the integration, make it easy
to disable and require that key
Bugs item #560310, was opened at 2002-05-24 13:45
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=560310group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Steve Wolfangel
GADDAMIT,
these pools are ridiculous, it is just the company voting for it, and
comatose products like oracle has got the full company behind it,
so here is our call, if you are on our lists and you haven't voted for us
yet, please please go and vote, I did this morning :)I hadn't before.
Ok I
Hi Scott
A problem that keeps popping up with the JSR77 integration
is that it is rather invasive and if it fails it breaks existing code.
A better integration path would be strictly as external listeners
to JMX events. This would clean up the integration, make it easy
to disable and
The source of the problem is management setup such as this from
SARDeployer where over 60% of the code is JSR77 setup with
implicit dependencies on the org.jboss.management.* pkgs that
if it fails, prevents the service from being created. Why can't these
steps be performed based on an event
I can't run the 3.0 testsuite on OSX right now because of xdoclet puking:
compile-mbean-sources:
[mkdir] Created dir:
/usr/local/jboss/JBoss3.0/jboss-all/server/output/gen-src
sourcepath is deprecated. the preferred way to design sources is via nested
fileset
Running xdoclet.XDocletMain
Remember that your vote doesn't count until you vote the 30 (gasp)
categories and receive the corresponding email. So be patient.
marc fleury wrote:
GADDAMIT,
these pools are ridiculous, it is just the company voting for it, and
comatose products like oracle has got the full company behind
Hi Scott
The source of the problem is management setup such as this from
SARDeployer where over 60% of the code is JSR77 setup with
implicit dependencies on the org.jboss.management.* pkgs that
if it fails, prevents the service from being created. Why can't these
steps be performed based on
The point is that the current integration is too heavy for something
that is at best experimental and I should be able to configure a
deployment that runs without it. I would like to see a looser integration
that allows for this.
Scott Stark
Chief Technology Officer
I suppose they do. AFAIK they must be like NASA, which is said to have
running each and every piece of software in the world.
Dain Sundstrom wrote:
Don't the DOD and State Department already use JBoss?
-dain
Scott M Stark wrote:
Microsoft tries to squelch Open Source at the pentagon,
I think you are right... though it kinda sucks. I think there is something up
with the current tx inside of SpySession, someone is setting it to null...
could be due to my missuse, but I will find out soon enough.
--jason
On Friday 24 May 2002 05:54 am, Hiram Chirino wrote:
I think that
Number of tests run: 750
Successful tests: 727
Errors:20
Failures: 3
[time of test: 25 May 2002 0:47 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
I just ran into:
[xdoclet] Error parsing
org.jboss.ejb.plugins.CMPFilePersistenceManager:Lexical error at line 289,
column 44. Encountered: u (117), after : \'\\
Where the code is:
cmpField.setChar(instance,'\u');
I will not generate an interface for this, but we should get this
Number of tests run: 744
Successful tests: 720
Errors:19
Failures: 5
[time of test: 25 May 2002 2:22 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
Any idea what these files are for? Are they still used? Looks like it could
be left overs from EJX?
--jason
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas --
Hi. Some interesting ideas. I do not think we can or should drop the HTML
interface. It is very handy for administration on machines where you can not
install a Java client app.
I don't want to stop you from creating a SOAP adapter to JMX, which is what is
sounds like you want to
That is legacy EJX junk. I removed it long ago I don't know why it
is back.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 24, 2002
This is really strange... I end up with a null tx id
(SpySession.currentTransactionId is null), so I updated my local copy of
SpySession to limit access to currentTrasnactionId through a getter and
setter, which appeared to limit the problem a little... though I only did it
so I could get
Number of tests run: 599
Successful tests: 598
Errors:1
Failures: 0
[time of test: 24 May 2002 20:20 GMT]
[java.version: 1.3.1_03]
[java.vendor: Sun Microsystems
Thank you. I didn't know about the jsr-77 stuff though. So first I'll
review its features and design, and see what the architects think of the
ideas. I might not get involved in that until after July, but I am
interested in creating a management console. My first focus is first on
the
48 matches
Mail list logo
