We have successfully ported or
> application from Weblogic 5.1 to JBoss/Jetty and are happy so far with
> the move.
Well, it's nice to have it end good, but it's sad that you had such a
bumpy road. Hopefully some of the sillier items on the list will improve
as we go along.
re
Very very nice :-) Well done Stacy!
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
___
Jboss-development mailing l
>yes EJX doesn't really belong here anymore. Also rickard is not supporting
>it, it doesn't really work, and finally they are com.dreambean classes not
>JBoss open sourced.
That is true, so yes, removing it is a good idea.
>So that will mark the end of its life in JBoss, it is free to come back
>yep, also for those that really want I believe the for pay add-on will be a
>killer...
>
>look who is still lurking :)
>
>hey kiddo, when you pull your head out of your arse and your coma, you can
>come and help us again, it is a shame to see so much talent go to waste...
>do you like what you he
On Mon, 25 Jun 2001, Rickard Öberg wrote:
> AFAICT the only problem in integrating with Tomcat is the whole
> ClassLoader architecture.
AFAIK no it isn't. That was nailed ages ago. Works great.
What doesn't work great is Tomcat. It's dead slow. Do some benchmarks
>> There, I said it, it pisses me off. The J2EE stack is a dream but nothing
>> more unless Tomcat is fixed.
>>
>
>Which is why Jules has been busy getting Jetty working.
Let me be more specific then: unless Jasper is fixed (which Jetty uses too).
There is work underway to correct this, but it'l
>> On Mon, 25 Jun 2001, Rickard Öberg wrote:
>>AFAICT the only problem in integrating with Tomcat is the whole
>>>ClassLoader architecture.
>>>
>>
>> AFAIK no it isn't. That was nailed ages ago. Works great.
>
>
>Except that Jasper has dif
AFAICT.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourcefor
t, yes. Common
operations are lookup of home objects, and to create data structures. In
those cases pooling is essential.
I assume that pooling is still optional, for those cases that need it,
yes?
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Ce
/lang/ref/ReferenceQueue.html
http://java.sun.com/j2se/1.3/docs/api/java/lang/ref/WeakReference.html
Combine for wanted effect (that we discussed, marc).
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Emai
k, yes. If you do "on demand" it's back to
wait-on-init-land, but replenishing in background could be ok.
/R
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
__
code can now poll this queue instead of creating new objects
all the time.
Whether or not it will be a real improvement or just fancy code remains
to be seen. Potentially it could work very well though.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ub
tion is(was at least) that MDB's aren't
ContainerInvoker-invokable, i.e. they have no remote interface and such.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mas
ement
CIC, then there is no need for the CIC interface. Then remove it, but
instead of using Error's it might be a better idea to use the
java.lang.UnsupportedOperationException.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Ce
>The recents questions posted by James Cook got me thinking. Maybe we
should
>ditch the current entity locking scheme in favor of using
>. It would greatly simplify the entity/cache locking
>mechanism, thus probably making it much more robust than it currently is.
>Of course, we'd have to improv
JBoss+Cataline it's not very interesting since people
will find it too difficult to set up on their own.
How hard would it be to add this to the binaries?
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Maste
arting from scratch using the Tomcat 3.2
plugin as base might be a better idea.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
_
gt; BTW, where are the sources for the EjbJar ResourceManager? I only found
> > jBossEjbJar and decompiled the ejxejb.jar
>
> Some of the EJX parts is closed source ...
EJX is OpenSource, BSD license. What parts do you think are closed
source?
/Rickard
--
Rickard Öberg
Software Devel
ind source - lot of barfing - had
> to add some obscure .jar
So, does this reasoning apply to all .jar files in JBoss that do not
have their source in JBoss CVS???
Come on...
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of
e - sorry ...
Yes, I can see how it is possible to interpret it that way. No problemo.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
__
;d suggest a refactoring of that code somehow.
Anyway, I do have JBoss 2.4 working with Tomcat 4.0b7. Should this be
bundled up somehow as a binary? I think more people will be interested
in it.
regards,
Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitou
Nick Betteridge wrote:
>
> Sounds good - I'm certainly interested.
>
> Did you manage to set up JAAS/JNDI etc to work with jboss?
Nope, just basic deployment. That was frustrating enough. One step at a
time.
/R
--
Rickard Öberg
Software Development Specialist
xlurc -
be so cool.
:-)
BTW, in my current project we have dropped EJB's in favor of MBeans +
Jini. So, the EAR hot deployment is not so interesting, but .sar hot
deployment would be :-)
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Cente
hat you had pionneered to its real final form and
> its logical conclusion. The microkernel stuff is real and solid imho, even
> if it doesn't look like much, it is, I like to believe, ground breaking
> work.
Yes, agree.
Now, couple that with a Jini-based deploy interface and
sive, i.e. both can be used at the
same time.
More clear?
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
___
Jboss-developmen
marc fleury wrote:
> sure thing! why don't you submit that :) you are about to lose your rw
> passwd for inactivity in JBoss, you know we have the 3mo rules of
> contribution for active developers.
I know, and it would be kinda sad to loose the rw 8-)
/R
--
Rickard Öberg
Softwa
*CHEERS* *APPLAUSE* *HOORAY!*
Absolutely fabulous! Now I don't need EJB's anymore, just plain jane
MBeans and JDO will do the trick :-) Maybe a twinkle of Jini just for
fun. And it's...ahhh.. manageable... :-)
/R
--
Rickard Öberg
Software Development Specialist
xlurc - X
s well as
> building a fault tolerant distributed event system.
It is indeed so.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
__
nd in LDAP. The JDO RI has pluggable state managers (but the
license is still bad though, so it's a wee bit in the future right now).
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research
ually promotes this way of doing it (look at the
PersistentMBean/ModelMBean interface). That said, the actual MBean could
still be using get/set methods, it's just that the MBean itself uses
some util code to get the config and call these methods by using
reflection on itself. The result is a m
on service types.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists
r SF projects I'm
running too anyway). Use the mail admin to set back to list reply.
Reply-to-poster is just annoying :-)
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering R
terface really). And I mean *class* since that includes version
information that the *name* will not be able to provide. Due to the
distributed interface of the lookup service you will not have
classloader issues, if that's what you're concerned about.
/Rickard
--
Rickard Öberg
Softwar
to the service as being a service. The Jini stuff is more
for what the service actually *does*. The service API's it provides.
Because of this I don't really see a vs relationship between JMX or
Jini, although I guess you could adopt that standpoint if you wanted to.
/Rickard
--
Ri
lective and JMX is the communication channel.
Which is very similar to what I proposed I guess it was a year ago when
I started rambling about Jini for clustering. I'm all with Andy on this
one.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linkö
t the Jini community, and having
talked to Jini folks on this topic recently, it is now very easy to
write clients and services in Jini, but it's still pretty awkward to
actually run the damn critters. Enter JBoss, which can provide all the
gory stuff (conf, lifecycle) that they need. Pa
one is licenced one is open !
Oh please. Jini is also open: you get the code, you can distribute your
apps, you can distribute the Jini binary, etc.
Please read the Jini FAQ or licensing stuff before making these kinds of
comments. No FUD please.
/Rickard
--
Rickard Öberg
Software Development Sp
, but there must be order to take an idea and turn it
> into a reality.
When the service deployment stuff in JBoss3 stabilizes that should be
pretty much it. MBean wrappers for core Jini services such as the LUS
and transaction service would be n
he education of the public.
If not for the simple fact that toasters et al won't be able to run Java
VM's. Boy what a marketing blunder that was.
/R
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Masterin
- since I was then
> looking at a way to have "self-discovery" over geo spatial boundaries, I
> ditched JINI ... becouse of its bradcast nature ...
If you want Jini discovery over large distances (=multiple subnets),
simply use a bridge.
/Rickard
--
Rickard Öberg
Software Develo
>But you really don't know what you are talking about when you talk about
>transactions?
Is this a question or sarcasm? I just can't tell...
/Rickard
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo
ing.
KISS.
> (because we do need this communication semantic).
Can you explain why and where this is needed? It seems like this depends
on a particular implementation strategy.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research
t in all your nodes and routers, then a
> think JINI, or any technology based on special os configuration needs,
> is a good choice.
This is pure FUD. Just drop it.
> Or has things changed? Am I just naive and uninformed?
Yup, that seems like the case.
/Rickard
--
Rickard Öberg
Softwar
g that The JBoss Group can easily get. If that's
not done, then users have to download Jini binaries separately.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Em
Peter Antman wrote:
> Otherwise multicast/broadcast won't work, and that there is no
> difference in that regars between using JavaGroup and JINI?
Not really, except Jini can use Unicast as well. Multicast is bonus, but
not required. I don't know about JG on this point.
/R
-
ired. I don't know about JG on this point.
>
> But unicast does not help with clustering, we want multicast.
Well, you still get the leasing support, it's just that you need more
admin to get it going (pointing out all nodes, etc.). Using multicast is
more admin-free, but it's
the readme
for setup.
I have not yet looked at security, EJB JNDI-reference, or jboss-web.xml
integration. But at least it works now.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
domain
name. Recommended workaround.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAI
Scott M Stark wrote:
> I looked at integrating the catalina final release with integrated
> security and JNDI and I find that everything works except for optimized
> EJB calls.
Did you use the updated Catalina support that I've added?
/Rickard
--
Rickard Öberg
Software Developm
_
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
> _______
> Jboss-development mailing list
> [EMAIL PROTECTED]
marc fleury wrote:
> jason,
>
> to be very honest I don't think it is a good idea i mean updating the
> website and each time going through the xdoc generation is a pain.
Yup, that is a bit of a pain.
Have you guys tried Mozilla lately? It has a demo where they use an XML
file that is rendere
>|Implementation model
>|
>|Let's start with the basics. The JMX MBeans in JBoss are all based upon
>|the Standard MBean model. This has worked well, and is especially a very
>|lightweight and simple way to make components manageable. The downside
>|is that you can't add very i
>|>You just mean that "invoke()" is a more natural way to String together
>|>detyped services but you could argue that for the price of putting the
>|>Dynamic Proxies right behind the standard MBean interface you can
generate
>|>the same invoke() call and thus string a stack behind it.
>|
>|You ca
d be wrong).
100% agree. It wouldn't scale.
> |For the *end-user client* stuff your invokers et al becomes much more
> |interesting. Absolutely.
>
> Refine this... it is interesting even on the server side, where you can for
> example schedule asynchronous shuttle-bundles bet
COND that the second grade developers at these companies can come up with
> the same. It is stealing but we know better.
We're all proffessional thieves, in some sense. :-) It's how good you
are at putting different things together in different dimensions that
makes it interesting
ot;route mapper" at the gates.
Which, as discussed, need to be hand-holding the MI as it travels along
the stack.
/R
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
___
I didn't think about that before, but if you are right and we can indeed use
> the ONE dynamic MBean instead of custom stacks per bean, the we could very
> well have the mbean be the interceptors.
It would require the above to work I think, but it's definitely doable.
/
and each interceptor just increases the index and delegates to
the next? Or how is the stack controlled? What is the driver of the
interceptor delegation?
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Res
own. Avoiding the delegation back to it.
Yes, pass it down along with the MI. That'd work. Didn't figure that one
out initially. That would indeed be much better.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author
n progress using the old version get to finish with that old
version.
Nice.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
_
> indirect in JMX at every point)
Yup. It will be more of an interesting configuration problem, than a
programming/design problem. How do you get this to work without getting
config files the size of the planet? :-)
/R
--
Rickard Öberg
Software Development Specialist
xlurc - X
lace them.
So, if an MI has a particular stack it won't change, even if the config
changes.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
erences, and also mbean
> configuration for each interceptor individually.
You may be right. It could be ok.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
__
ML has entities :-)
Just put this into a file:
]>
&logfile;
--
Then *that* file will read as valid XML.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
___
(AFAICT) they work the same way.
Is there a particular reason why the JMX way is not used? Are there any
limitations in using the MLet+DLR combo that drove the decision to
implement a custom solution instead?
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping
of CacheKey all together?
Hehe... if it is removed I have only one thing to say: "told you so"... >:-)
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Bordet, Simone wrote:
> eee, man this guy seem to *always* be right. Ah well, pure alien
> category.
> Rickard, ehrm, who will win the football league this year ? :-))
I *could* tell, but that'd spoil the fun ;-)
/Rickard
--
c.cfm?id=383845&type=issue&coll=portal&dl=ACM&idx=J79&part=magazine&WantType=Magazines&title=CACM)
have lots of great articles on the subject, and there are lots of
parallels with how JBoss works already.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
(compare with JMX/Jini)
* The EJB persistence model is flawed, compared with JDO.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
d with JDO.
>
> true boloney, sliced thick, with peanuts in the middle, will end up as
> chunky 2c toilet wisdom
Thanks for your input, you really helped show why EJB is good, or
rather, why my reasons to not use EJB are false. Thanks again.
Now back to our regular p
arch but there is really no reason why intercepting mbeans wouldn't be
> close to it.
Yes, scripting will make it easier to insert aspect join points. Good
point. To me it seems like AspectJ has this scripting aspect to it,
although it uses pre-runtime compilation to get it into bytecode.
ss state.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
r things they
shouldn't use it for, especially for web applications where the web
client and EJB's are in the same JVM. And you still need to go through
the remote interface, thus introducing a whole bunch of heavyweight
patterns such as Data Transfer Objects.
/Rickard
--
Rickard
the MBeanInfo, and do its work.
If it is stateful, how will the interceptor get its metadata? I hope it
won't load it itself... that would make it dependent on the type of
object the interceptor chain is being used on (since it may be used on
hat, and also get log output. I'm not
doing it as MBean's though, but as a WAR file. The app just hooks
directly into log4j without going through JMX.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https:/
It is most definitely faster to compute it yourself.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
n the
system over time.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
nyway.
Is this really necessary, and would it be possible to change it? As it
is, we have a redeploy cycle of about a minute, which is not nice...
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.source
gt; then on to Jetty which creates it's WebApp
> ClassLoader, B, as a child of A, then asks B to load
> class X. B does not delegate to A, but loads class A
> for a second time.
So you need to put all classes in the EAR scope instead of in the webapp
scope to make things work
more complex and portable case.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
;t have to do the check,
since it will be implied from what type of proxies that are used. Hey,
it's portable too.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
t, but now that it does... well.. what's the point? Backward
compatibility with people who have written apps that takes advantage of
it, yes, but that should be it. All new apps should use local interfaces
if you want local behaviour.
/Rickard
--
Rickard Öberg
___
on it
being available).
Now, because of all this bundling going on, the EAR quickly grows HUGE,
which means that for development you want hot-deploy on exploded EAR
files. Unfortunately JBoss does not currently support that, so the
cycling time becomes somewhat excessive. :-(
/Ric
rtrag1/tsld008.htm)
Architecture is rarely transparent, although it is often quite possible
to *localize* the impact of it to some degree.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/li
Greg Wilkins wrote:
> What class does it fail for? Can't you remove that class/jar from
> the webapplication, so that it can only be loaded from the EJB classloader?
It should be loaded by the EAR loader methinks.
--
Rickard Öberg
__
ng
> and they would get picked up and recompiled. Haven't tried this though.
No good. So, I change a file, and get it to work. I then change a class
and rebuild. Poof, my changed JSP file is gone.
No, it needs to be clean, or there's just no point.
/Rickard
--
Rickard Öberg
__
it went" docs as well at
their site (mozilla.org).
I'm gonna try and use RDF for as much as possible in my future projects.
At some point critical mass is reached and you can do all sorts of funky
stuff. Hey, it's only XML anyway, so no lo
oyment layer to clean it up
> and add support unarchived ears.
That would be sooo appreciated. It would save us so much time it
aint funny...
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://li
.
One solution is to use a template engine such as Velocity instead of
JSP. Then there's no problem whatsoever: just have it pick up changed
templates from your /src dev directory.
That is, if you have a choice in the first place.
/Rickard
--
Rickard Öberg
_
the changes. Only problem I see is automatically finding the
> correct tmp deploy directory again after redeployment of the whole ear.
Exactly.
Paaain..
/R
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
ense. Not a problem, see above. The only thing
that's important is that we can *close* them when *we* want to. Other
than that its fine that the URLCL hangs onto open connections.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
and deal with it. So KISS the
> URL.
There would be no loading time problems. See previous descriptions.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
; that to copy the file.
The open/close only happens at deploy time, so no problem
> Also the file must inflated anyway and do I miss something ?
AFAIK the file would *not* have to be inflated. What are the reasons it
must be inflated?
/R
hough. Wouldn't it be possible to
make a custom URL handler that returns a connection wrapper that we can
drop under the covers. I.e. even if the URLClassLoader hangs onto it, we
can still close the file under the covers. I think that would make it
work, and wouldn't be *that* intrusiv
one is going to replace the file so
> you can't be "open most of the time".
>
> Do we agree here?
We were talking about different files, that was the problem.
> almost, some googoo on my glasses still (or is it yours?)
As above, we talked about different thin
would be no locking.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
s. Instead it uses Class.forName(), which doesn't work properly.
If this is changed in Castor, your code will work just fine.
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
http://developer.java.sun.com/developer/bugParade/bugs/4388666.html
Finally.
--
Rickard Öberg
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
any other place where MO's are used.
/Rickard
--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic
Got blog? I do. http://dreambean.com
---
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. S
alls in JBoss. That's all.
/Rickard
--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic
Got blog? I do. http://dreambean.com
---
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and a
100 matches
Mail list logo
