Ensest siteler - En son videolar - Yüksek kalite resimler
Sýnýrsýz porno arþivi yenilendi: Onlarca film ve fotoðraf
Normal internet baðlantýnýzdan 10 kat hýzlý bir baðlantýyla, videolarý kendi
bilgisayarýnýzdan izlediðiniz gibi izlemek veya aklýnýza gelebilecek her kategoride
binlerce
Hi,
Currently, if the jdbctype of a database column is one of the above
types, the data is explicitly serialized by JBoss 3.x.
I've been researching this over the last few days and it seems to me
that the materialisation/dematerialisation of these types is really in
the domain of the JDBC
Stephen Coy wrote:
Hi,
Currently, if the jdbctype of a database column is one of the above
types, the data is explicitly serialized by JBoss 3.x.
I've been researching this over the last few days and it seems to me
that the materialisation/dematerialisation of these types is really in
I suspected that something like that was a possibility. If that is the
case, then you may as well use one of the binary types, because using
JAVA_OBJECT doesn't get you anything at all.
On Wednesday, October 2, 2002, at 07:21 PM, Michael Bartmann wrote:
Stephen Coy wrote:
Hi,
Currently,
Hi,
Do you know the IDE Togethet Control Center?
Are you interested in an audit of the different modules of JBoss?
This audit can sometimes show problems in the source code :-),
though it don't really tell where and why there is a bug... :-(
Best regards,
Loic
This message and any
Bugs item #617517, was opened at 2002-10-02 14:01
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617517group_id=22866
Category: JBossSOAP
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Dr. Christoph Georg Jung (cgjung)
Assigned
Title: Nachricht
Hi,
Axis RC2has
just been successfully integrated into Jboss.Net@cvs-head.The testsuite has
been added a chapter for the different ways of dealingwith stateful
services through the web-service scope (thanks Kevin Connor for the
inspiration).Thatpart of the testsuite now
Hi all,
Now for the interesting stuff... At this point, I have dynamic creation of
MBeans figured out -- I can even get them to persist and reload their state
through a manually-assisted process. The next step is to complete the cycle
by loading the metadata of the MBeans at runtime.
There
Bugs item #617574, was opened at 2002-10-02 16:20
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Bartmann (bartmann)
Assigned to:
Bugs item #617574, was opened at 2002-10-02 16:20
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M
A slight correction -- when I refer to *-service.xml, I really mean
*-service.xml _and_ the XMBean definition XML.
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Matt
Munz
Sent: Wednesday, October 02, 2002 10:06 AM
To: [EMAIL PROTECTED]
Bugs item #617585, was opened at 2002-10-02 09:39
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617585group_id=22866
Category: JBossServer
Group: v3.1
Status: Open
Resolution: None
Priority: 5
Submitted By: PEte Clark (pc3)
Assigned to: Nobody/Anonymous
Bugs item #617596, was opened at 2002-10-02 10:11
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617596group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Munz (mattmunz)
Assigned to: Nobody/Anonymous
Bugs item #613360, was opened at 2002-09-23 21:00
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=613360group_id=22866
Category: JBossServer
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dain Sundstrom (dsundstrom)
Assigned to:
Bugs item #608412, was opened at 2002-09-12 09:48
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=608412group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Later
Priority: 5
Submitted By: Steve Wolfangel (swolfangel)
Bugs item #613349, was opened at 2002-09-23 20:34
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=613349group_id=22866
Category: JBossServer
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dain Sundstrom (dsundstrom)
Assigned to:
Bugs item #617574, was opened at 2002-10-02 14:20
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M
Bugs item #617585, was opened at 2002-10-02 16:39
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617585group_id=22866
Category: JBossServer
Group: v3.1
Status: Open
Resolution: None
Priority: 5
Submitted By: PEte Clark (pc3)
Assigned to: Nobody/Anonymous
Bugs item #617574, was opened at 2002-10-02 16:20
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M
Bugs item #617574, was opened at 2002-10-02 16:20
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M
Bugs item #617574, was opened at 2002-10-02 16:20
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M
Hello,
I come back again with my old trick that hadn't much success in the past.
To solve the system class loader problem definitivly, at least with JDK 1.4
and upper, why not use the java.system.class.loader system property (see
javadoc of java.lang.Classloader.getSystemClassLoader).
This
I don't have time to think this through extensively, but I would like the
MBeanRegistry to persit the mbean info of either
--all mbeans
or
--all mbeans with a particular descriptor in their mbeaninfos.
I want to change the use of the ServiceController/Creator/Configurator so
it is ONLY used
Bugs item #589808, was opened at 2002-08-01 13:17
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=589808group_id=22866
Category: JBossServer
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bergman (davber)
Assigned to:
Bugs item #589808, was opened at 2002-08-01 13:17
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=589808group_id=22866
Category: JBossServer
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bergman (davber)
Assigned to:
Bugs item #617596, was opened at 2002-10-02 08:11
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617596group_id=22866
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Matthew Munz (mattmunz)
Assigned to: Scott M Stark
Hi,
I come back again with my old trick that hadn't much success
in the past.
To solve the system class loader problem definitivly, at
least with JDK 1.4
and upper, why not use the java.system.class.loader system
property (see
javadoc of java.lang.Classloader.getSystemClassLoader).
Hi,
I'm thinking about adding some code to JBoss to provide better granularity
to the [hot] deployment of directories. Here's the situation: I'm getting
tired of repackaging my EJB's into a JAR, creating a WAR, combining them
into an EAR, dropping the EAR file into the deployment directory, and
Hello,
I agree the SCL is not in play here.
Why does the HeirarchicalLoaderRepository2 synchronize on itself
in loadClass()? A plain UnifiedLoaderRepository2 does not.
Regards,
Adrian
From: Bordet, Simone [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE:
I think it is a beautiful idea. In fact I would want it to work even
with the web packages to redeploy pages instead of the whole jsp
enchillada and the whole site. Go ahead with this work and we will
generalize to the web layers
marc f
-Original Message-
From: [EMAIL PROTECTED]
On Wed, 2 Oct 2002, marc fleury wrote:
I think it is a beautiful idea. In fact I would want it to work even
with the web packages to redeploy pages instead of the whole jsp
enchillada and the whole site. Go ahead with this work and we will
generalize to the web layers
Hmm. Most(all?)
Maybe I am missing something or I misunderstood your proposal ?
A feeling I have is that it is a plain old bug in
HierarchyCL, but it's just a feeling (since it does not seem
related to the ClassCircularityError we had in the past).
keep your feelings to yourself, you already proved
David,
Thanks. That helps a lot.
Regarding persisting MB info...
I want to change the use of the ServiceController/Creator/Configurator so
it is ONLY used when you first deploy a package, NOT when you shut down
jboss and restart it.
What about re-deployment? If, after server start, I
I come back again with my old trick that hadn't much success
in the past.
To solve the system class loader problem definitivly, at
least with JDK 1.4 and upper, why not use the
java.system.class.loader system property (see javadoc of
java.lang.Classloader.getSystemClassLoader).
Sacha
Nevermid the previous reply, I thought your were talking about UnifiedLoaderRepository,
not UnifiedLoaderRepository2. The self synchronization of the
HeirarchicalLoaderRepository2
does look questionable.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
Because the HeirarchicalLoaderRepository2 went from a complicated multi-level
locking mechanism to ensure only a single thread was actively loading classes
into the repository to a coarse single lock with delegation from the calling
class loader. I'm sure this is just an issue of a access path
for the sake of completeness on background and context and so people
don't think it is unfounded
keep your feelings to yourself, you already proved incapable
of solving the old bugs and just plain left them there (when
it was your rewrite that was causing them). It took Scott to
and then
Hi,
I think we have to consider race conditions here.
What keeps a deployment scanner from starting in the
middle of an update when only some (i.e. inconsistent)
changes have occured yet.
We might have to somehow lock the directory during
changes and unlock it afterwards. But this lowers
the
Bugs item #617574, was opened at 2002-10-02 16:20
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M
Bugs item #617574, was opened at 2002-10-02 07:20
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M
We might have to somehow lock the directory during
changes and unlock it afterwards.
It's interesting the way Cruise Control deals with the same issue. A time
interval could be specified where the deployment scanner would wait to see
if there were any more updates before proceeding with the
I'm totally convinced.
I really like this approach.
Michael
Matt Munz wrote:
We might have to somehow lock the directory during
changes and unlock it afterwards.
It's interesting the way Cruise Control deals with the same issue. A time
interval could be specified where the deployment
microwave popcorn -- Wait until 2 seconds between pops
before removing from the microwave.
clear communication is Good,
just go ahead guys,
marc f
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
On Wed, 2 Oct 2002, David Jencks wrote:
For making it work in the short term perhaps only persisting mbeans with a
particular descriptor will be the best plan, you can set this descriptor
for your dynamically created mbeans now, and we can set it for all the
others later.
yes, agreed, add a
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
On Wed, 2 Oct 2002, Matt Munz wrote:
Perhaps we're using 'persist' differently. The mbean registry contains
object references to all of the mbeans in the server.To me, persisting
the registry (or a part of it), means serializing those objects completely
(MB info + data).
no, the
Had a look at testing your theory. I think l can do it. I'll get back to you
when l have a result.
- Original Message -
From: David Jencks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, October 01, 2002 11:15 PM
Subject: Re: [JBoss-dev] XADataSource wrapper for JBoss 4
I
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
Number of tests run: 976
Successful tests: 959
Errors:15
Failures: 2
[time of test: 2 October 2002 1:50 GMT]
[java.version: 1.3.1_03]
[java.vendor: Sun Microsystems
Number of tests run: 934
Successful tests: 930
Errors:4
Failures: 0
[time of test: 2 October 2002 16:7 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
EJB's as XMBeans (also known as Dave's plan for world domination:-)
We've claimed for a long time that in JBoss ejb's are mbeans. Well, they
sort of are, but the container is the mbean, and it calls an interceptor
chain and ends up maybe doing something with one of a bunch of objects from
a
Hey guys
My name is Rafael Ferreira [but I go by Ophion] and Im
really interested in joining the Jboss dev community.
I have a BS in Computer Science from Arizona State and even though
most of my current work is in the SysAdmin area, I
have a lot of experience with enterprise java and
Please try to hold off on commits to build.xml files until I have
finished... or commit them right now please.
FYI, I have removed the need for the _available targets and I am making
more usage of the buildfragments to reuse common target logic.
--jason
We've claimed for a long time that in JBoss ejb's are mbeans.
Well, they sort of are, but the container is the mbean, and
it calls an interceptor chain and ends up maybe doing
something with one of a bunch of objects from a cache or pool.
Meanwhile the mbeans have their own interceptor
On 2002.10.03 00:29:14 -0400 marc fleury wrote:
We've claimed for a long time that in JBoss ejb's are mbeans.
Well, they sort of are, but the container is the mbean, and
it calls an interceptor chain and ends up maybe doing
something with one of a bunch of objects from a cache or
- Hit the bug reports and look into providing fixes
and testcases
- Look at the forum todo - development forum on www.jboss.org/forums
- Read the www.jboss.org developer guides
Scott StarkChief Technology
OfficerJBoss Group, LLC
-
Really? You want 2 complete sets of interceptor definititions with exactly
the same functionality?
I don't. The whole ejb interceptor layer should be deprecated if not replaced
in 4.0.
1. change all the ejb interceptors so they only have an
invoke method, no invokeHome. The kind of
Hello Adam,
(I think I will remember your name all my life ;) Your entrance on jboss-dev
was so ... hot)
drool! Is this code completly generic? How tied is it to
jboss(not that I
really care, but if it could be a separate project, ...).
it is in jboss-all/server. Maybe one day it will be
On Wed, 2 Oct 2002, Sacha Labourey wrote:
(I think I will remember your name all my life ;) Your entrance on jboss-dev
was so ... hot)
Yeah, I was too forceful. I need to prove myself to you guys first, before I
start demanding things of you. Which is why I have been lurking and reading
61 matches
Mail list logo
