You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2007/06/02 00:03:05 UTC
Code i don't like... feel free to jump in :)
So we're looking good in all things related to complying to EJB 3.
Along the way I've fixed some code that I thought, "man this is ugly,
i'll have to come back later and clean it up." If you've spotted any
code that could use a good cleaning, chime in.
1. The usage of "beanTransaction" in the
StatefulInstanceManager.BeanEntry class. We use it to track when a
transaction is associated with the stateful bean instance. For one,
this only applies to beans with bean-managed-transactions, but it
gets filled in all the time. Two, it gets filled in in a really
indirect way. I fear the code may be getting used for other thing,
but it's just spooky enough that I can't tell.
2. The big three block if/then/else in the core.ivm proxy Handler
code (BaseEjbProxyHandler i think). There's a huge block in there
that tests if it should do a copy of the args and if so what kind of
copy (in the same classloader or across classloaders). It started as
simple code and grew, which is actually better than over architecting
it from the get-go. We just have to go back and clean that up.
3. Our exception converting code in the various proxy handlers that
does the work of "if this is a local interface, throw this exception.
if this is a business interface, throw this exception..." etc. As I
mentioned in a mail about adding the invoked interface to the
Container.invoke() signature, we can now do this in a much cleaner way.
4. We still eat exceptions in a million different places. I sent a
note on that with a list of exceptions, but I never turned them into
JIRAs. So little time.
Gee, that's it off the top of my head. I'm sure I will think of
more. If you have any, definitely post.
-David
Re: Code i don't like... feel free to jump in :)
Posted by Mohammad Nour El-Din <no...@gmail.com>.
HI Karan...
Would you please open a JIRA with this kind of exception eating situation as
explained in the Wiki page you found, and then submit this patch under this
JIRA and all other patches you will do for this type of situation, and
please add a comment that these patches should be applied separately.
On 6/2/07, Karan Malhi <ka...@gmail.com> wrote:
>
> David,
> I found the list of exceptions on the wiki
> Is this the kind of "Exception eating" you are talking of.
>
> try {
> clazz = Thread.currentThread
> ().getContextClassLoader().loadClass(mainClass);
> } catch (ClassNotFoundException e) {
> throw new IllegalStateException("Command " + commandName + "
> main.class does not exist: " + mainClass);
> }
>
> Where do I submit a patch for something like this. Is there a JIRA issue
> for
> this?
>
> On 6/1/07, David Blevins <da...@visi.com> wrote:
> >
> > So we're looking good in all things related to complying to EJB 3.
> > Along the way I've fixed some code that I thought, "man this is ugly,
> > i'll have to come back later and clean it up." If you've spotted any
> > code that could use a good cleaning, chime in.
> >
> > 1. The usage of "beanTransaction" in the
> > StatefulInstanceManager.BeanEntry class. We use it to track when a
> > transaction is associated with the stateful bean instance. For one,
> > this only applies to beans with bean-managed-transactions, but it
> > gets filled in all the time. Two, it gets filled in in a really
> > indirect way. I fear the code may be getting used for other thing,
> > but it's just spooky enough that I can't tell.
> >
> > 2. The big three block if/then/else in the core.ivm proxy Handler
> > code (BaseEjbProxyHandler i think). There's a huge block in there
> > that tests if it should do a copy of the args and if so what kind of
> > copy (in the same classloader or across classloaders). It started as
> > simple code and grew, which is actually better than over architecting
> > it from the get-go. We just have to go back and clean that up.
> >
> > 3. Our exception converting code in the various proxy handlers that
> > does the work of "if this is a local interface, throw this exception.
> > if this is a business interface, throw this exception..." etc. As I
> > mentioned in a mail about adding the invoked interface to the
> > Container.invoke() signature, we can now do this in a much cleaner way.
> >
> > 4. We still eat exceptions in a million different places. I sent a
> > note on that with a list of exceptions, but I never turned them into
> > JIRAs. So little time.
> >
> > Gee, that's it off the top of my head. I'm sure I will think of
> > more. If you have any, definitely post.
> >
> > -David
> >
> >
>
>
> --
> Karan Malhi
>
--
Thanks
- Mohammad Nour
Re: Code i don't like... feel free to jump in :)
Posted by Karan Malhi <ka...@gmail.com>.
David,
I found the list of exceptions on the wiki
Is this the kind of "Exception eating" you are talking of.
try {
clazz = Thread.currentThread
().getContextClassLoader().loadClass(mainClass);
} catch (ClassNotFoundException e) {
throw new IllegalStateException("Command " + commandName + "
main.class does not exist: " + mainClass);
}
Where do I submit a patch for something like this. Is there a JIRA issue for
this?
On 6/1/07, David Blevins <da...@visi.com> wrote:
>
> So we're looking good in all things related to complying to EJB 3.
> Along the way I've fixed some code that I thought, "man this is ugly,
> i'll have to come back later and clean it up." If you've spotted any
> code that could use a good cleaning, chime in.
>
> 1. The usage of "beanTransaction" in the
> StatefulInstanceManager.BeanEntry class. We use it to track when a
> transaction is associated with the stateful bean instance. For one,
> this only applies to beans with bean-managed-transactions, but it
> gets filled in all the time. Two, it gets filled in in a really
> indirect way. I fear the code may be getting used for other thing,
> but it's just spooky enough that I can't tell.
>
> 2. The big three block if/then/else in the core.ivm proxy Handler
> code (BaseEjbProxyHandler i think). There's a huge block in there
> that tests if it should do a copy of the args and if so what kind of
> copy (in the same classloader or across classloaders). It started as
> simple code and grew, which is actually better than over architecting
> it from the get-go. We just have to go back and clean that up.
>
> 3. Our exception converting code in the various proxy handlers that
> does the work of "if this is a local interface, throw this exception.
> if this is a business interface, throw this exception..." etc. As I
> mentioned in a mail about adding the invoked interface to the
> Container.invoke() signature, we can now do this in a much cleaner way.
>
> 4. We still eat exceptions in a million different places. I sent a
> note on that with a list of exceptions, but I never turned them into
> JIRAs. So little time.
>
> Gee, that's it off the top of my head. I'm sure I will think of
> more. If you have any, definitely post.
>
> -David
>
>
--
Karan Malhi
Re: Code i don't like... feel free to jump in :)
Posted by Karan Malhi <ka...@gmail.com>.
David,
Just started looking at the hotdeploy options. Couldnt work on the issue for
the past couple of months. As i was readying through the code trying to
understand the server startup and deploy process, i did find places with
empty catch blocks. I would like to see if your list of exceptions apply at
those places. Since i have not kept track of the mailing list for a while,
if possible, could you please resend that list of exceptions. I do have some
questions on the hotdeploy issue though, will send them in a seperate email
later.
On 6/1/07, David Blevins <da...@visi.com> wrote:
>
> So we're looking good in all things related to complying to EJB 3.
> Along the way I've fixed some code that I thought, "man this is ugly,
> i'll have to come back later and clean it up." If you've spotted any
> code that could use a good cleaning, chime in.
>
> 1. The usage of "beanTransaction" in the
> StatefulInstanceManager.BeanEntry class. We use it to track when a
> transaction is associated with the stateful bean instance. For one,
> this only applies to beans with bean-managed-transactions, but it
> gets filled in all the time. Two, it gets filled in in a really
> indirect way. I fear the code may be getting used for other thing,
> but it's just spooky enough that I can't tell.
>
> 2. The big three block if/then/else in the core.ivm proxy Handler
> code (BaseEjbProxyHandler i think). There's a huge block in there
> that tests if it should do a copy of the args and if so what kind of
> copy (in the same classloader or across classloaders). It started as
> simple code and grew, which is actually better than over architecting
> it from the get-go. We just have to go back and clean that up.
>
> 3. Our exception converting code in the various proxy handlers that
> does the work of "if this is a local interface, throw this exception.
> if this is a business interface, throw this exception..." etc. As I
> mentioned in a mail about adding the invoked interface to the
> Container.invoke() signature, we can now do this in a much cleaner way.
>
> 4. We still eat exceptions in a million different places. I sent a
> note on that with a list of exceptions, but I never turned them into
> JIRAs. So little time.
>
> Gee, that's it off the top of my head. I'm sure I will think of
> more. If you have any, definitely post.
>
> -David
>
>
--
Karan Malhi