[JBoss-dev] [ jboss-Bugs-809152 ] LoginContext between WAR and JAR in EAR
Bugs item #809152, was opened at 2003-09-19 01:34
Message generated for change (Settings changed) made by starksm
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=809152group_id=22866
Category: JBossSX
Group: v3.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Juan Martinez (juanmartinez)
Assigned to: Nobody/Anonymous (nobody)
Summary: LoginContext between WAR and JAR in EAR
Initial Comment:
I've made small testcase that shows that LoginContext
fails in an EAR file (servlet calls slsb).
10:07:05,000 ERROR [SecurityInterceptor]
Authentication exception, principal=null
10:07:05,005 ERROR [LogInterceptor] EJBException,
causedBy:
java.lang.SecurityException: Authentication exception,
principal=null
at
org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:164)
at
org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:81)
at
org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:120)
at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:93)
at
org.jboss.ejb.StatelessSessionContainer.internalInvokeHome(StatelessSessionContainer.java:319)
at
org.jboss.ejb.Container.invoke(Container.java:720)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
java.lang.reflect.Method.invoke(Method.java:324)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
at
org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:101)
at
org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90)
at
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
at
org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45)
at
org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:173)
at
org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85)
at $Proxy37.create(Unknown Source)
at web.EJBServlet.doGet(Unknown Source)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
You must define a MyRealm (UsersRoles) in
login-config.xml
application-policy name = MyRealm
authentication
login-module
code=org.jboss.security.auth.spi.UsersRolesLoginModule
flag = required /
/authentication
/application-policy
and Sample in .java.login.config with the
ClientLogin
Sample {
org.jboss.security.ClientLoginModule required;
};
If I run the WAR from Jetty to the EAR everything
works.
Ran on jboss-3.2.2rc4 release using tomcat (jetty was
4.2.12).
Hope that this can be used (I'm a J2EE newbie still).
Juan
--
Comment By: Scott M Stark (starksm)
Date: 2003-09-19 13:49
Message:
Logged In: YES
user_id=175228
The WEB-INF/jboss-web.xml descriptor needs to have a
security-domain element mapped to a config in the
login-config.xml file that includes the ClientLoginModule.
There is one called client-login so use:
jboss-web
security-domainjava:/jaas/client-login/security-domain
context-root/web/context-root
...
I don't know where you got the .java.login.config config
file, maybe some jetty thing that does not apply to when a
web container is embedded inside of JBoss.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=809152group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Problem during Connection
Hi , I am using JBoss 3.x. I have successfully deployed Beans to JBoss server and in order to test the functionality of bean, i am testing it through Jython scripts. Client is able to locate correctly the JNDI name reference but when client is making call to Bean, following exception is raised, could any one help me in tracing out the cause of error. I am also pasting my jython and startup script with that mail. Thanks in advance, Harish - Traceback (innermost last): File console, line 1, in ? File startup.py, line 31, in makene java.lang.reflect.UndeclaredThrowableException at $Proxy1.createNE(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java) at org.python.core.PyMethod.__call__(PyMethod.java) at org.python.core.PyObject.__call__(PyObject.java) at org.python.core.PyObject.invoke(PyObject.java) at org.python.pycode._pyx0.makene$3(startup.py:31) at org.python.pycode._pyx0.call_function(startup.py) at org.python.core.PyTableCode.call(PyTableCode.java) at org.python.core.PyTableCode.call(PyTableCode.java) at org.python.core.PyFunction.__call__(PyFunction.java) at org.python.pycode._pyx4.f$0(console:1) at org.python.pycode._pyx4.call_function(console) at org.python.core.PyTableCode.call(PyTableCode.java) at org.python.core.PyCode.call(PyCode.java) at org.python.core.Py.runCode(Py.java) at org.python.core.Py.exec(Py.java) at org.python.util.PythonInterpreter.exec(PythonInterpreter.java) at org.python.util.InteractiveInterpreter.runcode(InteractiveInterpreter.java) at org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java) at org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java) at org.python.util.InteractiveConsole.push(InteractiveConsole.java) at org.python.util.InteractiveConsole.interact(InteractiveConsole.java) at org.python.util.jython.main(jython.java) Caused by: javax.ejb.CreateException: Could not dereference object at com.alcatel.gem.ems.ne.ejb.NEContainerEJB.ejbCreate(NEContainerEJB.java:285) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.StatelessSessionEnterpriseContext.init(StatelessSessionEnterpriseContext.java:52) at org.jboss.ejb.plugins.StatelessSessionInstancePool.create(StatelessSessionInstancePool.java:35) at org.jboss.ejb.plugins.AbstractInstancePool.get(AbstractInstancePool.java:146) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:58) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:243) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:117) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:322) at org.jboss.ejb.Container.invoke(Container.java:674) at sun.reflect.GeneratedMethodAccessor98.invoke(Unknown Source) at org.python.core.PyCode.call(PyCode.java) at org.python.core.Py.runCode(Py.java) at org.python.core.Py.exec(Py.java) at org.python.util.PythonInterpreter.exec(PythonInterpreter.java) at org.python.util.InteractiveInterpreter.runcode(InteractiveInterpreter.java) at org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java) at org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java) at org.python.util.InteractiveConsole.push(InteractiveConsole.java) at org.python.util.InteractiveConsole.interact(InteractiveConsole.java) at org.python.util.jython.main(jython.java) Caused by: javax.ejb.CreateException: Could not dereference object at com.alcatel.gem.ems.ne.ejb.NEContainerEJB.ejbCreate(NEContainerEJB.java:285) at
[JBoss-dev] TEACH AND GROW RICH !! ($400 Daily minimum)
TEACH AND GROW RICH !! If you are motivated and a qualified communicator, I will personally train you to do 2, 20-minute presentations per day and show you how to have the propsects call you. Plus, I will demonstrate to you that you can make $400 daily (minimum) from the comfort of your home. I get direct payments daily and I'll show you how! You will also be introduce to a person who makes well in excess of $1,000,000 annually and he will gladly give you free instructions. We will take as much time as you need to see if this program is right for you. Please do not reply unless you are Genuinely Motivated. I need people who have either made large amounts of money in the past or are ready to start generating large amounts of money now. E-mail me back if you are interested and put "PUT ME IN" in the subject line just click the link below: CLICK HERE: Please include your Name and Phone number in text area. Name__required Phone #___required Best time_ I promise you no "hype or sales talk" and absolutely no "high pressure" just a nice chat and straight, honest answers to your questions. Don't let the next 5 years be like the last 5 years. Sincerely, Carl If you feel you have received this in error or wish to be removed from our contact list, just put "Remove" in subject line and click below. Sorry for the inconvenience. Click Here:
RE: [JBoss-dev] Re: [jboss-group] JRMPInvokerProxy
- Generalization of the proxy factory framework to loose the ejb specific items manifestly showing up in the org.jboss.proxy.GenericProxyFactory which should be a more generic metadata representation. The only difference between the http proxy factory and jrmp proxy factory is a different Invoker type and the lack of a jndi name. Great - The whole Invoker layer needs to be migrated to the more general remoting framework. The remoting Ok, I am unfamiliar with that framework. The only 'surface' problem I would have would be to tie it to JMX. The targets need to be identified by logical names. The logical names are mapped to 'handlers', for example a JMX one that understands the target identifier as a JMX MBeanName etc. - There is an XMBean interceptor which implements the invoke(Invocation) handling in the 3.2.1 admin/devel book which should be rolled into the codebase. The problem here is that is has to deal with 2 types of Invocations and two type of Interceptors. This needs to be unified. Unifying the interceptors would be a good idea. The only thing that needs to be multiple is AOP that deals with interfaces (Dynamic Proxy) or the AOP that deals with raw objects and the javassist framework. But definitely the SIGNATURE of the invocation should be unified so that interceptors themselves come in ONE flavor Public Invocation invoke(Invocation) And then we can weave these in the EJB contaienr, the XMBean container (the first two should be unified in their constructions as well as you point out) and raw AOP containers with assembly based on the XML bill has. But all the interceptors should have the same API, same thing with the Invocation object itself, good call on that. Marcf --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-group] JRMPInvokerProxy
Unifying the interceptors would be a good idea. The only thing that needs to be multiple is AOP that deals with interfaces (Dynamic Proxy) or the AOP that deals with raw objects and the javassist framework. But definitely the SIGNATURE of the invocation should be unified so that interceptors themselves come in ONE flavor Public Invocation invoke(Invocation) Right now, the new signature that Bill implemented is something like: public InvocationResponse invoke (Invocation) throws Throwable More specifically, when an exception is thrown, it is not wrapped inside the InvocationResponse but thrown back directly (not even wrapped). This is bad IMHO as this prevent to attach payload to invocations that generate exceptions. If we want to always be able to send back data to the client side, we don't care if an Application Level exception (even system in fact) has been thrown. One way to solve that and if we want to keep the good old (working) try...finally construct we have today in the interceptors would be to change the signature like that: public InvocationResponse invoke (Invocation) throws InvocationException And have the InvocationException exception wrap the source Exception/Error and allow attachement of arbitrary payload. Cheers, Sacha xxx Sacha Labourey General Manager JBoss Group (Europe) SàRL xxx --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-group] JRMPInvokerProxy
Keyo, InvocationException extends Invocation InvocationResponse extends Invocation So you get the original context in both cases marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sacha Labourey Sent: Saturday, September 20, 2003 11:34 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Re: [jboss-group] JRMPInvokerProxy Unifying the interceptors would be a good idea. The only thing that needs to be multiple is AOP that deals with interfaces (Dynamic Proxy) or the AOP that deals with raw objects and the javassist framework. But definitely the SIGNATURE of the invocation should be unified so that interceptors themselves come in ONE flavor Public Invocation invoke(Invocation) Right now, the new signature that Bill implemented is something like: public InvocationResponse invoke (Invocation) throws Throwable More specifically, when an exception is thrown, it is not wrapped inside the InvocationResponse but thrown back directly (not even wrapped). This is bad IMHO as this prevent to attach payload to invocations that generate exceptions. If we want to always be able to send back data to the client side, we don't care if an Application Level exception (even system in fact) has been thrown. One way to solve that and if we want to keep the good old (working) try...finally construct we have today in the interceptors would be to change the signature like that: public InvocationResponse invoke (Invocation) throws InvocationException And have the InvocationException exception wrap the source Exception/Error and allow attachement of arbitrary payload. Cheers, Sacha xxx Sacha Labourey General Manager JBoss Group (Europe) SàRL xxx --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-group] JRMPInvokerProxy
On Sat, 2003-09-20 at 16:33, Sacha Labourey wrote:
Unifying the interceptors would be a good idea. The only thing that
needs to be multiple is AOP that deals with interfaces
(Dynamic Proxy)
or the AOP that deals with raw objects and the javassist
framework. But
definitely the SIGNATURE of the invocation should be unified so that
interceptors themselves come in ONE flavor
Public Invocation invoke(Invocation)
Right now, the new signature that Bill implemented is something like:
public InvocationResponse invoke (Invocation) throws Throwable
More specifically, when an exception is thrown, it is not wrapped inside the
InvocationResponse but thrown back directly (not even wrapped). This is bad
IMHO as this prevent to attach payload to invocations that generate
exceptions. If we want to always be able to send back data to the client
side, we don't care if an Application Level exception (even system in fact)
has been thrown.
One way to solve that and if we want to keep the good old (working)
try...finally construct we have today in the interceptors would be to change
the signature like that:
public InvocationResponse invoke (Invocation) throws
InvocationException
And have the InvocationException exception wrap the source Exception/Error
and allow attachement of arbitrary payload.
Hi Sacha,
I had an argument with Bill about this a while back, but
I couldn't convince him.
With this approach you have to consider whether you get the response
object from the return value or the exception.
The overall exception handling also is way more complicated.
You get something like the following scattered around our code.
InvocationResponse response;
try
{
doBefore(invocation);
response = invocation.invokeNext();
doAfter(invocation, response);
}
catch (InvocationException e)
{
response = e.getResponse();
if (e instanceof WeAreInterestedInException)
{...}
else
throw e;
}
catch (Throwable t)
{
rethrowAsInvocationException(t, response);
}
finally
{
doSomethingWith(response);
}
return response;
Besides, RuntimeExceptions and Errors ignore the model anyway,
you loose your response unless everything catches Throwable
and everything remembers to include the response in custom exceptions.
My preferred solution is put the InvocationResponse in the
invocation. The only place where extra complication is needed
is during marshalling it back (it is this layer that establishes the
Invocation object so it will always be able to determine
the response - if any). With my approach it is impossible for
the response object to be lost.
Invocation invocation = unmarshallInvocation();
InvocationReponse response;
try
{
Object result = dispatch(invocation);
response = invocation.getOrCreateResponse();
response.setResult(result);
}
catch (Throwable t)
{
response = invocation.getOrCreateResponse();
response.setThrowable(t)
}
return response;
With unwrapping code on the other end.
Mailine code just does invocation.getResponse() it is always there
or null if it hasn't been initialised. e.g. My previous example becomes
try
{
doBefore(invocation);
Object result = invocation.invokeNext();
doAfter(invocation, result);
return result;
}
catch (WeAreInterestedInException e)
{
...
}
finally
{
doSomethingWith(invocation.getResponse());
}
It has the added advantage that if there is no result, no
extra response data and no marshalling there is
no object construction for the response object or
exception wrapper.
Regards,
Adrian
Cheers,
Sacha
xxx
Sacha Labourey
General Manager
JBoss Group (Europe) SRL
xxx
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-809833 ] Typo in jboss-ds_1_0.dtd
Bugs item #809833, was opened at 2003-09-20 19:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=809833group_id=22866 Category: JBossCX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Frank Langelage (lafr) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in jboss-ds_1_0.dtd Initial Comment: In line 26 the word prepared of prepared-statement-cache is misspelled. There is an 'e' missing. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=809833group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-809833 ] Typo in jboss-ds_1_0.dtd
Bugs item #809833, was opened at 2003-09-20 17:25 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=809833group_id=22866 Category: JBossCX Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Frank Langelage (lafr) Assigned to: Adrian Brock (ejort) Summary: Typo in jboss-ds_1_0.dtd Initial Comment: In line 26 the word prepared of prepared-statement-cache is misspelled. There is an 'e' missing. -- Comment By: Adrian Brock (ejort) Date: 2003-09-20 17:49 Message: Logged In: YES user_id=9459 Fixed and added the element definition -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=809833group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Official notice to all e-gold users
Dear e-gold user. At 09.19.2003 our company has lost a number of accounts in the system during the database maintenance. If you still not confirmed your e-gold membership, please check your account if it is still active and your current balance is right. If you find that your account is inactive, please let us know immediately at e-mail [EMAIL PROTECTED] To check your account, please click on the link below: https://www.e-gold.com/acct/login.html 2003 e-gold Ltd.
[JBoss-dev] [ jboss-Bugs-808689 ] JRMPProxyFactyory defaults to wrong client interceptor
Bugs item #808689, was opened at 2003-09-18 09:30
Message generated for change (Comment added) made by starksm
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=808689group_id=22866
Category: JBossMX
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: pmoore (paulmoore100)
Assigned to: Scott M Stark (starksm)
Summary: JRMPProxyFactyory defaults to wrong client interceptor
Initial Comment:
JRMPProxyFactory has a default pair of ClientInterceptors
public JRMPProxyFactory()
{
interceptorClasses.add(ClientMethodInterceptor.class);
interceptorClasses.add(InvokerInterceptor.class);
}
unfortunately the import for ClientMethodInterceptor is
import
org.jboss.invocation.http.interfaces.ClientMethodIntercep
tor;
So the JRMP proxy factory defaults to creating a client
side proxy that uses HTTP.
--
Comment By: Scott M Stark (starksm)
Date: 2003-09-18 21:46
Message:
Logged In: YES
user_id=175228
Fix in cvs, 3.2.2RC5.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=808689group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-group] JRMPInvokerProxy
Oh great then, logical names and all then marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Haynie Sent: Saturday, September 20, 2003 4:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Re: [jboss-group] JRMPInvokerProxy Nice to see Marc is still on the remoting is tied to JMX kick which is completely and utterally incorrect. ;) Remoting has nothing to do with JMX, except that as a convenience the connectors serve as MBeans. - Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 20, 2003 11:22 AM Subject: RE: [JBoss-dev] Re: [jboss-group] JRMPInvokerProxy - Generalization of the proxy factory framework to loose the ejb specific items manifestly showing up in the org.jboss.proxy.GenericProxyFactory which should be a more generic metadata representation. The only difference between the http proxy factory and jrmp proxy factory is a different Invoker type and the lack of a jndi name. Great - The whole Invoker layer needs to be migrated to the more general remoting framework. The remoting Ok, I am unfamiliar with that framework. The only 'surface' problem I would have would be to tie it to JMX. The targets need to be identified by logical names. The logical names are mapped to 'handlers', for example a JMX one that understands the target identifier as a JMX MBeanName etc. - There is an XMBean interceptor which implements the invoke(Invocation) handling in the 3.2.1 admin/devel book which should be rolled into the codebase. The problem here is that is has to deal with 2 types of Invocations and two type of Interceptors. This needs to be unified. Unifying the interceptors would be a good idea. The only thing that needs to be multiple is AOP that deals with interfaces (Dynamic Proxy) or the AOP that deals with raw objects and the javassist framework. But definitely the SIGNATURE of the invocation should be unified so that interceptors themselves come in ONE flavor Public Invocation invoke(Invocation) And then we can weave these in the EJB contaienr, the XMBean container (the first two should be unified in their constructions as well as you point out) and raw AOP containers with assembly based on the XML bill has. But all the interceptors should have the same API, same thing with the Invocation object itself, good call on that. Marcf --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-809151 ] InstanceAlreadyExistsException exception during redeploy
Bugs item #809151, was opened at 2003-09-19 01:29 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=809151group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Doychin Bondzhev (doychin) Assigned to: Nobody/Anonymous (nobody) Summary: InstanceAlreadyExistsException exception during redeploy Initial Comment: AlreadyRegistered exception during redeploy of module which failed to deploy previously. If I redeploy module which does not failed everything is fine but when module has failed for some reason - incorrect information in service xml or failed ependency when reason or failure is removed and module is redeployed it genrates InstanceAlreadyExistsException exception: Log from server console: 11:29:28,406 ERROR [EjbModule] Initialization failed javax.management.InstanceAlreadyExistsException: jboss.j2ee:jndiName=ConvertorBe an,service=EJB already registered. at org.jboss.mx.server.registry.BasicMBeanRegistry.add (BasicMBeanRegistr y.java:617) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerM Bean(BasicMB eanRegistry.java:198) at sun.reflect.GeneratedMethodAccessor1.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.interceptor.ObjectReferenceInterceptor.invo ke(ObjectRefe renceInterceptor.java:59) at org.jboss.mx.interceptor.MBeanAttributeInterceptor.invok e(MBeanAttrib uteInterceptor.java:43) at org.jboss.mx.interceptor.PersistenceInterceptor2.invoke (PersistenceIn terceptor2.java:93) at org.jboss.mx.server.MBeanInvoker.invoke (MBeanInvoker.java:76) at javax.management.modelmbean.RequiredModelMBean.invo ke(RequiredModelMB ean.java:141) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.server.MBeanServerImpl.registerMBean (MBeanServerImpl.jav a:997) at org.jboss.mx.server.MBeanServerImpl.registerMBean (MBeanServerImpl.jav a:327) at org.jboss.ejb.EjbModule.createService (EjbModule.java:296) at org.jboss.system.ServiceMBeanSupport.create (ServiceMBeanSupport.java: 158) at sun.reflect.GeneratedMethodAccessor159.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:976) at $Proxy12.create(Unknown Source) at org.jboss.system.ServiceController.create (ServiceController.java:310) at org.jboss.system.ServiceController.create (ServiceController.java:243) at sun.reflect.GeneratedMethodAccessor3.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy10.create(Unknown Source) at org.jboss.ejb.EJBDeployer.create (EJBDeployer.java:522) at org.jboss.deployment.MainDeployer.create (MainDeployer.java:776) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:631) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at sun.reflect.GeneratedMethodAccessor17.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy6.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.de ploy(URLDeploymen tScanner.java:302) at org.jboss.deployment.scanner.URLDeploymentScanner.sc an(URLDeploymentS canner.java:476) at org.jboss.deployment.scanner.AbstractDeploymentScann
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Results: 98 % ( 1499 / 1529 ) - nearly there - who is gonna get us to 100%!
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === JBoss daily test results SUMMARY Number of tests run: 1529 Successful tests: 1499 Errors:25 Failures: 5 [time of test: 2003-09-20.23-17 GMT] [java.version: 1.4.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_05-b01] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.20-20.7] Useful resources: - http://jboss.kimptoc.net/linux1/logtests/testresults/reports/html//2003-09-20.23-17 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: RemotingUnitTestCase Test:unknown Type:error Exception: junit.framework.AssertionFailedError Message: Timeout occurred - Suite: TransientUnitTestCase Test:testDummy Type:error Exception: javax.naming.NameNotFoundException Message: test not bound - Suite: TransientUnitTestCase Test:testServerFound Type:error Exception: javax.naming.NameNotFoundException Message: test not bound - Suite: TransientUnitTestCase Test:unknown Type:error Exception: java.net.MalformedURLException Message: no protocol: /home/jbossci/jbossci2/jboss-head-test/testsuite/output/lib/cachetest.jar - Suite: TransientUnitTestCase Test:unknown Type:error Exception: java.net.MalformedURLException Message: no protocol: /home/jbossci/jbossci2/jboss-head-test/testsuite/output/lib/cachetest.aop - Suite: MBeanUnitTestCase Test:testServerFound Type:error Exception: javax.naming.NameNotFoundException Message: TreeCacheMBeanTester not bound ===Sun Sep 21 01:42:22 BST 2003 ===Linux nog 2.4.20-20.7 #1 Mon Aug 18 14:56:30 EDT 2003 i686 unknown ===java version 1.4.1_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_05-b01) Java HotSpot(TM) Client VM (build 1.4.1_05-b01, mixed mode) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] COOPERATION
Dear Ladies and Gentlemen Those yahcts which listed below will offer you %10 commission, In this list below the prices are very low than the worlds market. O L G A P R I C E 440.000 PROPERTIESEQUIPMENTSACOMMODATION Type Ketch Dingy, 21 kWa Generator4Double Cabins Wc+ Shower Loan 26.00 mt 80ft Hydrolic Lift, Music System1Master cabin Wc+shower Beam 6,80 mt 20ft Tv, Vhf, Radar, Gps, Sonar,Full air conditioned,Hot Water Fuel Tank 4,000 lt Fishing Diving EquipmentHolding Tang, Ice Maker Rigging Furling Wind Surf, Canoe, Jet skiDeep Freeze, Max.14 Person Water Tank 7,000 lt Life Rafts for 25 personsDate of building 2000 Engines 440 Man Turbo Original Marin ===Motor Yacht, Sunseeker P R I C E 1.550.000 At the moment Sunseeker Manhattan 74 is moored in Bodrum. (very close to Kos Island). We will be glad to guide you in Bodrum. TVA is paid. it s built in 1999 in POOL , ENGLAND LOA: 22 m (66ft) BEAM: 7 m (21ft), 2 generators 20 V and 12 V, 220 V 2 engines 1100 hp Man navigation time: 351 hours Kitchen includes dish washer, refrigerator, microwave, hotplate, ice maker. 2 deepfreeze electric windows, 4 cabins + 1 cabin for crew. Each cabin has a tv and music system wc and shower. central aircondition. diving equipment. As you understand from navigation time boat is not used regularly. Boat never faced with an accident. Boat was not used for charters ==T U Z L A P I A N OPRICE 135.000 == Type : Motor BoatMain Engine: 150 Hp CumminsEquipment Tv Stereo Musi System Port: Bodrum TURKEYGenerator: 12 kvA 220 VRefrigirator Dingy2.60 Date of Construction: 1992 Water Tanks: 1200 ltZodiak Boat LOA: 13.20m-40 ftFuel Tanks : 1000 lt BEAM:4.30m-13 ftAcommodation: 2 Master Cabin ==S A D K O 282PRICE 125.000 = LOA : 22.50 M / 74 FT ENGINE: 240HP DELPHIN BUILT: 1994 HULL: PINE / MAHOGANYI NTERIOR: MAHOGANY CABINS : 8 DOUBLE CABINS ALL CABINS WITH EN-SUITE WC+SHOWER GUEST CAPACITY: 16 ELECTRICITY : 12V WCs SHOWERS : FLUSH TYPE WCs ENCLOSED SHOWERS CREW : 1CAPTAIN, 1CHEF, 2 DECHANDS WATER CAPACITY: 6.000L FUEL CAPACITY: 2.000L WASTE WATER CAPACITY : 1.500L OTHER EQUIPMENT - TEAK DECK, GALVANIZED RIGGING, ALL CABINS WITH EN-SUITE WC SHOWERS AND HOT WATER, ICE BOXES , 2 STEERING POSITIONS, HYDRAULIC WINDLASS, SUN MATRESSES, DECK CHA Your sincerely Sadko Travel Yachting General Manager HacýAKDEMIR Manager Sadettin AKDEMIR Mobile:+ 90 536 6371646 +90 537 2732137 Tel: +90 252 3135235 Fax: +90 252 3135236 BODRUM OFFICE ISTANBUL OFFICE MOSCOW OFFICE Cumhuriyet caddesi No:53Ordu Caddesi No:292 Minsk Otel Kat: 7 Bodrum-MUGLA/TURKEYLaleli-ISTANBUL/TURKEYMOSCOW/RUSSIA Tel: +90 252 3135235 Tel:+90 212 5705727Tel:7095 2991740 Fax:+90 252 3135236 Fax:+90212 5201370 Fax:7095 2991733 [EMAIL PROTECTED]com [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] We wish you a great success in your business. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-809151 ] InstanceAlreadyExistsException exception during redeploy
Bugs item #809151, was opened at 2003-09-19 11:29 Message generated for change (Comment added) made by doychin You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=809151group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Doychin Bondzhev (doychin) Assigned to: Nobody/Anonymous (nobody) Summary: InstanceAlreadyExistsException exception during redeploy Initial Comment: AlreadyRegistered exception during redeploy of module which failed to deploy previously. If I redeploy module which does not failed everything is fine but when module has failed for some reason - incorrect information in service xml or failed ependency when reason or failure is removed and module is redeployed it genrates InstanceAlreadyExistsException exception: Log from server console: 11:29:28,406 ERROR [EjbModule] Initialization failed javax.management.InstanceAlreadyExistsException: jboss.j2ee:jndiName=ConvertorBe an,service=EJB already registered. at org.jboss.mx.server.registry.BasicMBeanRegistry.add (BasicMBeanRegistr y.java:617) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerM Bean(BasicMB eanRegistry.java:198) at sun.reflect.GeneratedMethodAccessor1.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.interceptor.ObjectReferenceInterceptor.invo ke(ObjectRefe renceInterceptor.java:59) at org.jboss.mx.interceptor.MBeanAttributeInterceptor.invok e(MBeanAttrib uteInterceptor.java:43) at org.jboss.mx.interceptor.PersistenceInterceptor2.invoke (PersistenceIn terceptor2.java:93) at org.jboss.mx.server.MBeanInvoker.invoke (MBeanInvoker.java:76) at javax.management.modelmbean.RequiredModelMBean.invo ke(RequiredModelMB ean.java:141) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.server.MBeanServerImpl.registerMBean (MBeanServerImpl.jav a:997) at org.jboss.mx.server.MBeanServerImpl.registerMBean (MBeanServerImpl.jav a:327) at org.jboss.ejb.EjbModule.createService (EjbModule.java:296) at org.jboss.system.ServiceMBeanSupport.create (ServiceMBeanSupport.java: 158) at sun.reflect.GeneratedMethodAccessor159.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:976) at $Proxy12.create(Unknown Source) at org.jboss.system.ServiceController.create (ServiceController.java:310) at org.jboss.system.ServiceController.create (ServiceController.java:243) at sun.reflect.GeneratedMethodAccessor3.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy10.create(Unknown Source) at org.jboss.ejb.EJBDeployer.create (EJBDeployer.java:522) at org.jboss.deployment.MainDeployer.create (MainDeployer.java:776) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:631) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at sun.reflect.GeneratedMethodAccessor17.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy6.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.de ploy(URLDeploymen tScanner.java:302) at org.jboss.deployment.scanner.URLDeploymentScanner.sc an(URLDeploymentS canner.java:476) at org.jboss.deployment.scanner.AbstractDeploymentScann
