[Design the new POJO MicroContainer] - Re: Recursive JDKCheckerFactory usage?
by adrian＠jboss.org
It's a bug.
It's trying to see whether this is the JDK trying to load a system class
e.g. sun.*
but not using the system classloader. i.e. it expects to be able to load
them from any classloader.
But in this case the JDKChecker hasn't been initialized so it tries
to load the implementation through the TCL which in this case is a BaseClassLoader
at org.jboss.classloader.spi.ClassLoaderPolicy.isJDKRequest(ClassLoaderPolicy.java:221)
| at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:228)
| ...
| at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:372)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
| at org.jboss.classloader.spi.jdk.JDKCheckerFactory$1.run(JDKCheckerFactory.java:56)
| at org.jboss.classloader.spi.jdk.JDKCheckerFactory$1.run(JDKCheckerFactory.java:1)
| at java.security.AccessController.doPrivileged(Native Method)
| at org.jboss.classloader.spi.jdk.JDKCheckerFactory.<clinit>(JDKCheckerFactory.java:43)
|
So it ends up calling itself before it is properly nitialized.
There's one of two possible fixes:
1) Ignore loading from the TCL when it is a BaseClassLoader in
JDKCheckerFactory
2) Use the "default" JDKChecker (AbstractJDKChecker)
if JDKCheckerFactory returns null,
i.e. it is part way through loading a custom checker from the current classloader
(2) Is a bit hacky, but it does allow custom JDKCheckers to be outside
$JBOSS_HOME/lib
You should be able to workaround the problem for now by doing
JDKChecker..getChecker()
before you setup the classloading (or at least before you setup the TCL).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166606#4166606
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166606
17 years, 8 months
Query regarding JBoss JCA
by priyanka.maheshwari＠wipro.com
Hi Everybody,
My Requirement:
1. Remove the usage of cleartext password from mysql-ds.xml
2. Use the custom password manager to retrieve the password
Given Solution by extending the SecureIdentityLoginModule:
JBoss connector API's provides SecureIdentityLoginModule to encrypt
database passwords rather than using clear text passwords in the
datasource configuration. I have implemented a custom login module by
extending this class and overridden the commit method, which will call
password manager to retrieve the password.
Problem:
By going thru the above approach of custom login module, JBoss JCA takes
~25 milliseconds to return the connection. And this 25 milliseconds
doesn't count the time to call password manager. But if I don't use
cleartext password, it takes hardly 1 millisecond.
I want to understand:
1. How JCA works when login module is used which takes ~25 milliseconds.
2. Is there any way I can configure JBoss JCA to verify the password
only for the 1st time, and for the subsequent calls, it just returns the
connection directly from connection pool to reduce the time taken to ~1
milliseconds.
Regards,
Priyanka
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
17 years, 8 months
[Design of JBoss jBPM] - Re: iCalendar wrapper
by aapthorp
Thought I'd just post a quick update on this...I got a bit side tracked with limitations of various user agents and also seeing what the potential was...
In addition to the basic capabilities to provide task entries (as a .ics) via http and handling task invitations via e-mail I've been playing with CalDav...having written a rather crude CaldDav server on top of jBPM. This allows me to update tasks directly via a calendar agent (e.g. Lightning). So I can mark a task as complete and jBPM fires the transition. This could easily be extended to create standalone tasks in jBPM if I added handling for externally created UIDs.
Having discovered Mozilla Lightning invite attendees window for tasks I've been trying to figure out how to support this...so manual task delegation can be done via the user agent.
The main issue I've had is the different capabilities of various user agents. My main test agents are Lightning, Kontact and Evolution. Lightning has Caldav support but, doesn't handle attachments or task/todo invitations. Kontact doesn't handle Caldav, but does handle attachment and task/todo invitations. Just checking out the latest version of Evolution.
I now to do some refactoring...before I can post something stable.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166560#4166560
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166560
17 years, 8 months
[Design the new POJO MicroContainer] - Recursive JDKCheckerFactory usage?
by scott.stark＠jboss.org
I'm seeing this NPE an app client test usage I'm trying to create a testcase for:
| 153771 ERROR [AbstractKernelController] Error installing to Instantiated: name=ClientContainer state=Described
| java.lang.ExceptionInInitializerError
| at org.jboss.classloader.spi.ClassLoaderPolicy.isJDKRequest(ClassLoaderPolicy.java:220)
| at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:228)
| at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1056)
| at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:728)
| at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:372)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
| at java.beans.Introspector.instantiate(Introspector.java:1453)
| at java.beans.PropertyEditorManager.findEditor(PropertyEditorManager.java:91)
| at org.jboss.reflect.plugins.ValueConvertor.convertValue(ValueConvertor.java:136)
| at org.jboss.reflect.plugins.ClassInfoImpl.convertValue(ClassInfoImpl.java:491)
| at org.jboss.reflect.spi.DelegateClassInfo.convertValue(DelegateClassInfo.java:236)
| at org.jboss.beans.metadata.plugins.StringValueMetaData.getValue(StringValueMetaData.java:125)
| at org.jboss.kernel.plugins.config.Configurator.getParameters(Configurator.java:593)
| at org.jboss.kernel.plugins.config.Configurator.getConstructorJoinPoint(Configurator.java:188)
| at org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getConstructorJoinPoint(AbstractKernelConfigurator.java:132)
| at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:57)
| at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:1)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1394)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:786)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:914)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:836)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:626)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:443)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:331)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:309)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
| at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
| at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:88)
| at org.jboss.test.classloading.vfs.client.support.launcher.ClientLauncher.deploy(ClientLauncher.java:258)
| at org.jboss.test.classloading.vfs.client.support.launcher.ClientLauncher.launch(ClientLauncher.java:404)
| at org.jboss.test.classloading.vfs.client.test.ClientClassPathUnitTestCase.testClientMainClassPath(ClientClassPathUnitTestCase.java:119)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| ...
| Caused by: java.lang.NullPointerException
| at org.jboss.classloader.spi.ClassLoaderPolicy.isJDKRequest(ClassLoaderPolicy.java:221)
| at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:228)
| at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1056)
| at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:728)
| at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:372)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
| at org.jboss.classloader.spi.jdk.JDKCheckerFactory$1.run(JDKCheckerFactory.java:56)
| at org.jboss.classloader.spi.jdk.JDKCheckerFactory$1.run(JDKCheckerFactory.java:1)
| at java.security.AccessController.doPrivileged(Native Method)
| at org.jboss.classloader.spi.jdk.JDKCheckerFactory.<clinit>(JDKCheckerFactory.java:43)
| ... 55 more
|
I'll check in the test even though its currently failing. I'm having trouble restricting the load of the app client main through the vfs class loader of the mc deployment since its visible to the system class loader.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166557#4166557
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166557
17 years, 8 months
[Design of POJO Server] - Re: JRMPProxyFactory equivalent for POJO Services
by bstansberry＠jboss.com
"ron.sigal(a)jboss.com" wrote :
| bstansberry(a)jboss.com" wrote :
| | If the "factory" element supported a nested "bean" element it would be a bit cleaner.
| |
|
| Just to be sure I understand, you're talking about a microcontainer feature, right, not something I should do with RemotingProxyFactory?
Yep. Just a minor thing. Instead of this:
| <bean name="SampleTargetProxyFactory" class="org.jboss.aspects.remoting.RemotingProxyFactory">
|
| ......
|
| </bean>
|
| <bean class="org.jboss.aspects.remoting.test.proxy.SampleInterface1">
|
| <annotation>
| @org.jboss.aop.microcontainer.aspects.jndi.JndiBinding(name="proxyTestJNDI")
| </annotation>
|
| <constructor factoryMethod="getProxy">
| <factory bean="SampleTargetProxyFactory"/>
| </constructor>
|
| </bean>
|
You'd nest the factory bean:
| <bean class="org.jboss.aspects.remoting.test.proxy.SampleInterface1">
|
| <annotation>
| @org.jboss.aop.microcontainer.aspects.jndi.JndiBinding(name="proxyTestJNDI")
| </annotation>
|
| <constructor factoryMethod="getProxy">
| <factory>
| <bean class="org.jboss.aspects.remoting.RemotingProxyFactory">
|
| ......
|
| </bean>
| </factory>
| </constructor>
|
| </bean>
|
The nesting just reduces the visibility of the factory vs. the proxy, plus saves having to name the factory bean.
"ron.sigal(a)jboss.com" wrote :
| I think the use of the factory element here is also pretty cool. The one thing that strikes me is that the bean with the factory element is defined with a single interface class, even though the proxy will, in fact, implement two interfaces. I certainly don't know the microcontainer internals, but superficially it seems like a bean with a factory element could live without a class attribute, since it could be derived from the factory method's return type.
The class attribute is optional in the schema; I don't know if omitting it would work. I believe in the past it was required, but the MC guys are improving stuff all the time.
You could also use org.jboss.aop.proxy.Proxy instead of the interface. In fact you might have to, since that's the return type from the factory method. I used the interface because that's the idiom I'd used previously with a factory bean for creating a JBoss Cache instance. But the return type on their factory was the interface org.jboss.cache.Cache.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166541#4166541
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166541
17 years, 8 months