[JBoss AS Development] - Performance issue: VFSClassLoaderPolicy uses URL.hashCode(),
by ttarhan
I believe I have found a performance issue in JBoss AS 5.1.0.GA caused by the use of a ConcurrentHashMap with URL objects as the hash key. The offending usage is in VFSClassLoaderPolicy, in a member field named manifestCache. The field manifestCache is initialized as ConcurrentHashMap<URL, Manifest>();
The underlying issue is that URL.hashCode() is a non-trivial operation, often requiring a DNS lookup. This DNS lookup can take a long time to timeout, adding up to 1-minute to the startup time of the application server .The issue is also encountered during runtime if certain class loader features are used (ie. getResource), causing up to a 1-minute delay when such features are used.
The DNS lookups will never resolve in most cases, as the URL objects in question are usually in the form of:
vfsmemory:aa15-xok7cr-fznfpulr-1-fznfpxto-7...
A simple fix is to use the String returned form URL.toString() as the map key.
Can anyone confirm that this in in fact a bug? The delays can be a significant issue, especially the runtime delays.
Backtrace showing URL.hashCode causing a DNS lookup when used in ConcurrentHashMap from VFSClassLoaderPolicy:
| Inet6AddressImpl.lookupAllHostAddr(String) line: not available [native method]
| InetAddress$1.lookupAllHostAddr(String) line: 849
| InetAddress.getAddressFromNameService(String, InetAddress) line: 1200
| InetAddress.getAllByName0(String, InetAddress, boolean) line: 1153
| InetAddress.getAllByName(String, InetAddress) line: 1083
| InetAddress.getAllByName(String) line: 1019
| InetAddress.getByName(String) line: 969
| Handler(URLStreamHandler).getHostAddress(URL) line: 420
| Handler(URLStreamHandler).hashCode(URL) line: 337
| URL.hashCode() line: 857 [local variables unavailable]
| ConcurrentHashMap<K,V>.get(Object) line: 768
| VFSClassLoaderPolicy.getClassPackageInformation(String, String) line: 606
| BaseClassLoader.definePackage(String, URL) line: 722
| BaseClassLoader$2.run() line: 567
| BaseClassLoader$2.run() line: 532
| AccessController.doPrivileged(PrivilegedAction<T>, AccessControlContext) line: not available [native method]
| BaseClassLoader.loadClassLocally(String, boolean) line: 530
| BaseClassLoader.loadClassLocally(String) line: 507
| DelegateLoader(BaseDelegateLoader).loadClass(String) line: 134
| ClassLoadingTask$ThreadTask.run() line: 452
| ClassLoaderManager.nextTask(Thread, ClassLoadingTask) line: 251
| ClassLoaderManager.process(Thread, ClassLoadingTask) line: 150
| ClassLoaderDomain(BaseClassLoaderDomain).loadClass(BaseClassLoader, String, boolean) line: 265
| ClassLoaderDomain(BaseClassLoaderDomain).loadClass(BaseClassLoader, String) line: 1119
| BaseClassLoader.loadClassFromDomain(String, boolean) line: 798
| BaseClassLoader.loadClass(String, boolean) line: 441
| BaseClassLoader(ClassLoader).loadClass(String) line: 252
| ToClassInvoker.toClass(ToClassInvokerPoolReference, CtClass, String, ClassLoader, ProtectionDomain) line: 88
| JBossClDelegatingClassPool.toClass(CtClass, ClassLoader, ProtectionDomain) line: 81
| CtNewClass(CtClass).toClass(ClassLoader, ProtectionDomain) line: 1094
| TransformerCommon$ToClassAction$2.toClass(CtClass, ClassLoader, ProtectionDomain) line: 331
| TransformerCommon.toClass(CtClass, ClassLoader, ProtectionDomain) line: 139
| ProxyFactory.createProxyClass(ClassLoader, ProxyMixin[], Class<?>[]) line: 126
| ProxyFactory.createInterfaceProxy(GUID, ClassLoader, Class<?>[], ProxyMixin[], InstanceAdvisor) line: 96
| ProxyFactory.createInterfaceProxy(GUID, ClassLoader, Class<?>[]) line: 86
| Remoting.createRemoteProxy(Object, ClassLoader, Class[], InvokerLocator, List<Interceptor>, String) line: 102
| ManagedOperationProxyFactory.createDispatcherProxy() line: 203
| ManagedOperationProxyFactory.start() line: 109
| NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
| NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
| DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
| Method.invoke(Object, Object...) line: 597
| ReflectionUtils.invoke(Method, Object, Object[]) line: 59
| ReflectMethodInfoImpl.invoke(Object, Object[]) line: 150
| BasicMethodJoinPoint.dispatch() line: 66
| KernelControllerContextAction$JoinpointDispatchWrapper.execute() line: 241
| KernelControllerContextAction$JoinpointDispatchWrapper(ExecutionWrapper).execute(AccessControlContext) line: 47
| KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContext, ExecutionWrapper) line: 109
| KernelControllerContextAction.dispatchJoinPoint(KernelControllerContext, Joinpoint) line: 70
| StartStopLifecycleAction(LifecycleAction).installActionInternal(KernelControllerContext) line: 221
| StartStopLifecycleAction(InstallsAwareAction).installAction(KernelControllerContext) line: 54
| StartStopLifecycleAction(InstallsAwareAction).installAction(ControllerContext) line: 42
| StartStopLifecycleAction(SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62
| StartStopLifecycleAction(AccessControllerContextAction<S,T>).install(ControllerContext) line: 71
| KernelControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51
| AbstractKernelControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348
| AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1631
| AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 934
| AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1082
| AbstractKernelController(AbstractController).resolveContexts(boolean) line: 984
| AbstractKernelController(AbstractController).install(ControllerContext, boolean) line: 774
| AbstractKernelController(AbstractController).install(ControllerContext) line: 540
| ServiceController.doInstall(KernelController, ServiceControllerContext) line: 670
| ServiceController.register(ObjectName, Collection<ObjectName>, boolean, Object) line: 373
| ServiceControllerRegistrationLifecycleCallback.install(ControllerContext) line: 104
| NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
| NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
| DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
| Method.invoke(Object, Object...) line: 597
| ReflectionUtils.invoke(Method, Object, Object[]) line: 59
| ReflectMethodInfoImpl.invoke(Object, Object[]) line: 150
| BasicMethodJoinPoint.dispatch() line: 66
| AbstractBeanInfo.invoke(Object, String, String[], Object[]) line: 300
| AbstractKernelControllerContext.invoke(String, Object[], String[]) line: 286
| AbstractLifecycleCallbackItem.install(ControllerContext) line: 87
| AbstractKernelController(AbstractController).handleLifecycleCallbacks(ControllerContext, ControllerState, boolean) line: 1568
| AbstractKernelController(AbstractController).handleInstallLifecycleCallbacks(ControllerContext, ControllerState) line: 1533
| AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 943
| AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1082
| AbstractKernelController(AbstractController).resolveContexts(boolean) line: 984
| AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 822
| AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 553
| ServiceController.doChange(KernelController, ServiceControllerContext, ControllerState, String) line: 688
| ServiceController.start(ObjectName) line: 460
| ServiceControllerStartStopLifecycleCallback.install(ControllerContext) line: 44
| NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
| NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
| DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
| Method.invoke(Object, Object...) line: 597
| ReflectionUtils.invoke(Method, Object, Object[]) line: 59
| ReflectMethodInfoImpl.invoke(Object, Object[]) line: 150
| BasicMethodJoinPoint.dispatch() line: 66
| AbstractBeanInfo.invoke(Object, String, String[], Object[]) line: 300
| AbstractKernelControllerContext.invoke(String, Object[], String[]) line: 286
| AbstractLifecycleCallbackItem.install(ControllerContext) line: 87
| AbstractKernelController(AbstractController).handleLifecycleCallbacks(ControllerContext, ControllerState, boolean) line: 1568
| AbstractKernelController(AbstractController).handleInstallLifecycleCallbacks(ControllerContext, ControllerState) line: 1533
| AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 943
| AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1082
| AbstractKernelController(AbstractController).resolveContexts(boolean) line: 984
| AbstractKernelController(AbstractController).install(ControllerContext, boolean) line: 774
| AbstractKernelController(AbstractController).install(ControllerContext) line: 540
| BeanMetaDataDeployer.deploy(DeploymentUnit, BeanMetaData) line: 121
| BeanMetaDataDeployer.deploy(DeploymentUnit, Object) line: 51
| BeanMetaDataDeployer(AbstractSimpleRealDeployer<T>).internalDeploy(DeploymentUnit) line: 62
| BeanMetaDataDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 50
| DeployerWrapper.deploy(DeploymentUnit) line: 171
| DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1439
| DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1157
| DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1178
| DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1098
| DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348
| AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1631
| AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 934
| AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1082
| AbstractKernelController(AbstractController).resolveContexts(boolean) line: 984
| AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 822
| AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 553
| DeployersImpl.process(List<DeploymentContext>, List<DeploymentContext>) line: 781
| MainDeployerImpl.process() line: 702
| MainDeployerAdapter.process() line: 117
| ProfileDeployAction.install(Profile) line: 70
| ProfileDeployAction(AbstractProfileAction).install(ProfileContext) line: 53
| AbstractProfileService.install(ControllerContext, ControllerState, ControllerState) line: 361
| ProfileContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348
| ScopedProfileServiceController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1631
| ScopedProfileServiceController(AbstractController).incrementState(ControllerContext, boolean) line: 934
| ScopedProfileServiceController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1082
| ScopedProfileServiceController(AbstractController).resolveContexts(boolean) line: 984
| ScopedProfileServiceController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 822
| ScopedProfileServiceController(AbstractController).change(ControllerContext, ControllerState) line: 553
| AbstractProfileService.activateProfile(ProfileKey) line: 306
| ProfileServiceBootstrap.start(Server) line: 271
| ServerImpl(AbstractServerImpl).start() line: 461
| Main.boot(String[]) line: 221
| Main$1.run() line: 556
| Thread.run() line: 619
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255422#4255422
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255422
16 years, 6 months
[EJB 3.0 Development] - Re: HornetQ JCA Adapter question
by clebert.suconic＠jboss.com
I had a conversation about the JCA adapter today with Carlo.
Basically Carlo agrees with Jesper.
Here is the transcript for future reference:
anonymous wrote :
| (03:33:56 PM) wolfc: clebert: delivering multiple message within a single tx is against spec, so I'm very curious how others implement this
| (03:34:52 PM) clebert: wolfc: it's probably against the spec...
| (03:34:52 PM) clebert: also.. I believe others support sub-transactions... so I guess they used that as a way to sneak in the rule on Specj
| (03:35:10 PM) clebert: wolfc: it's against the spec.. but useful...
| (03:35:22 PM) clebert: wolfc: IMO actually: it should be made as part of the spec somehow
| (03:35:32 PM) clebert: say.. you're doing this:
| (03:35:32 PM) clebert: (forget MDBs)
| (03:35:39 PM) clebert: pseudo code coming... sec:
| (03:36:07 PM) wolfc: forget MDBs means I'm off the hook :-P
| (03:36:30 PM) clebert: int i = 0;
| (03:36:30 PM) clebert: while (true)
| (03:36:30 PM) clebert: {
| (03:36:30 PM) clebert: i++
| (03:36:30 PM) clebert: msg = consumer.receive();
| (03:36:30 PM) clebert: if (i == 500) tx.commit();
| (03:36:30 PM) clebert: }
| (03:36:38 PM) clebert: if a rollback happens here.. everything would be rolled back
| (03:36:45 PM) clebert: and everything redelivered
| (03:37:11 PM) clebert: most people will do this kind of thing when not using MDBs.. but have to do single syncs when doing MDBs
| (03:39:18 PM) clebert: wolfc: I said forget MDBs just as an example...
| (03:39:19 PM) clebert: when not using MDBs users can do this kind of thing... but when on MDBs they have to use single-syncs
| (03:39:34 PM) wolfc: but we're not talking simple MessageReceivers, we're talking JCA
| (03:40:06 PM) clebert: wolfc: yes.... I know.. this should be part of the JCA spec somehow
| (03:40:19 PM) clebert: wolfc: I mean.. IMHO
| (03:42:40 PM) wolfc: clebert: the only thing I've been seeing is that such a feature gives customers headaches.
| (03:42:53 PM) wolfc: for example: https://jira.jboss.org/jira/browse/JBPAPP-2260
| (03:43:48 PM) wolfc: basically you see support case where people complain about messages being unduly redelivered
| (03:44:19 PM) clebert: wolfc: well.. that was a bug.. right?
| (03:44:19 PM) clebert: Bugs are bugs :-)
| (03:44:53 PM) clebert: wolfc: It's very common users just using MDBs on the Application Server...
| (03:44:53 PM) clebert: But the performance for MDB is horrible because of that
| (03:45:11 PM) wolfc: yeah, the bug was batching
| (03:46:11 PM) clebert: wolfc: if we use batching... we would need to use a single consumer on the MDB... and the user would have to use it carefully.
| (03:47:05 PM) wolfc: clebert: right, which is horrible for them to implement and horrible to tune
| (03:47:28 PM) clebert: wolfc: for them .. you mean.. customers?
| (03:47:34 PM) wolfc: yes
| (03:48:11 PM) clebert: wolfc: that would be the same as doing the pseudo code above... the user would have the choice of doing it through MDBs
| (03:48:35 PM) clebert: wolfc: right now if you want performance on receiving messages.. we have to say don't use MDBs
| (03:49:09 PM) wolfc: clebert: what's faster: 1 consumer doing 100 batched or 100 MDBs?
| (03:50:16 PM) clebert: wolfc: it depends on the use case....
| (03:50:16 PM) clebert: some users need strict ordering.. that means you can only have 1 consumer.
| (03:51:35 PM) wolfc: I think I see the trick: Delivering batches of messages to each MDB endpoint can improve performance particularly when used with Acknowledge mode set to Duplicates-ok auto-acknowledge.
| (03:51:44 PM) bobmcw_ left the room (quit: Remote closed the connection).
| (03:51:46 PM) clebert: wolfc: from Messaging point of view... 100 consumers would scale.. but on the Application server that would mean 100 threads.... what would end up on more resources.
| (03:51:46 PM) clebert: at the end if you need performance we just say.. don't use MDBs
| (03:52:38 PM) wolfc: clebert: that's on WAS, but it doesn't say anything about the tx
| (03:53:22 PM) clebert: wolfc: yeah... Duplicates-ok is fine.. but most users also need to control transactions...
| (03:53:22 PM) clebert: Expand that loop to:
| (03:53:22 PM) clebert: loop
| (03:53:22 PM) clebert: {
| (03:53:22 PM) clebert: msg = consumer.receve();
| (03:53:22 PM) clebert: if (counter++ == 500) xa.commit;
| (03:53:22 PM) clebert: db.inserts, updates...etc;
| (03:53:22 PM) clebert: }
| (03:53:23 PM) wolfc: clebert: still if the ack mode is dups-ok we have some leeway
| (03:53:30 PM) clebert: say.. a store is receiving a new table or something...
| (03:53:38 PM) clebert: if you commit msg by msg.. that would take forever
| (03:54:35 PM) clebert: right now.. the user can only do this by hand with a consumer.. without using MDBs
| (03:55:14 PM) clebert: well.. the user could go around.. like.. a msg saying... get the new table.. on the onMessage it starts a consumer on another queue
| (03:55:18 PM) kkhan left the room (quit: ).
| (03:56:50 PM) clebert: wolfc: that's something I know BEA and WebSphere have
| (03:58:41 PM) wolfc: clebert: where does it say that?
| (03:58:55 PM) clebert: sec
| (04:00:33 PM) clebert: wolfc: I read both docs once.. I didn't want to link to our JIRA as I didn't want to look like plagiarism
| (04:00:46 PM) clebert: wolfc: let me see if I can find it here real quick
| (04:02:28 PM) clebert: wolfc: http://74.125.155.132/search?q=cache:kp8szn4Jc6kJ:e-docs.bea.com/wls/docs...
| (04:02:28 PM) clebert: It disapperared.. I could only read it from the cache
| (04:02:34 PM) clebert: look for Transaction Batching of MDBs
| (04:03:54 PM) wolfc: clebert: okay the bea doc at least explicitly states multiple msgs / tx
| (04:04:41 PM) clebert: wolfc: I don't care much about the spec on this case... all I care is I think it's a valid use case...
| (04:04:41 PM) clebert: Maybe this should be included on the spec.. that's my point
| (04:05:36 PM) wolfc: clebert: if we want this it should be part of the proxy endpoint, not part of the RA
| (04:06:06 PM) wolfc: hmm, no that's not possible
| (04:06:32 PM) clebert: wolfc: what's not possible? add it to the spec?
| (04:06:54 PM) wolfc: no, make it part of the proxy endpoint
| (04:08:01 PM) wolfc: clebert: the RA could do option B, but do multiple deliveries instead of 1
| (04:08:15 PM) clebert: wolfc: we are doing option B ATM.
| (04:08:26 PM) clebert: wolfc: we have actually an open issue with TCCL ATM
| (04:08:30 PM) wolfc: clebert: option A is 1 msg / tx
| (04:08:38 PM) clebert: wolfc: that' s why we are asking you to look at that thread
| (04:08:52 PM) bstansb_afk is now known as bstansberry
| (04:09:17 PM) bstansberry: any maven lovers know any place maven caches snapshots besides in ~/.m2/repository ?
| (04:09:24 PM) clebert: wolfc: the batch transaction will be probably fixed later.. it's a nice to have feature
| (04:10:36 PM) clebert: wolfc: but the TCCL is a current bug we have.. any help would be appreciated on that EJB3 dev forum thread
| (04:10:36 PM) clebert: Jesper said both options need to be on the proxy endpoint.. but like what you just said goes against that I think
| (04:13:51 PM) rruss left the room (quit: Read error: 110 (Connection timed out)).
| (04:15:34 PM) wolfc: clebert: there are more points where the proper tccl isn't set in ejb3, so it's not an isolated problem
| (04:15:47 PM) wolfc: clebert: and the current proxy endpoint implementation is very messy
| (04:15:59 PM) wolfc: clebert: hacked together to work with JBossMQ
| (04:17:07 PM) clebert: wolfc: we are adding a hack in our code...
| (04:17:07 PM) clebert: we created a property hackOn
| (04:17:07 PM) clebert: If (hackOn) setTCCL(endpoing.getClass().getClassLoader());
| (04:17:07 PM) clebert: Or something like that
| (04:17:11 PM) wolfc: clebert: for the moment just use option B and you're set to go
| (04:17:25 PM) rruss [n=rruss@redhat/jboss/rruss] entered the room.
| (04:17:25 PM) mode (+v rruss ) by ChanServ
| (04:17:50 PM) clebert: wolfc: option B .. but what about beforeDelivery and afterDelivery...
| (04:17:50 PM) clebert: we don't need to call that, right?
| (04:17:50 PM) clebert: we can just use the hack and set the TCCL ourselves?
| (04:18:24 PM) wolfc: clebert: don't make matters worse.
| (04:18:24 PM) wolfc: clebert: just use option B
| (04:18:34 PM) wolfc: I don't see why that should be a problem
| (04:20:19 PM) wolfc: clebert: basically option A RAs don't function and since the proxy endpoint code has been duplicated just about everywhere you'll run into more issues with other components.
| (04:21:30 PM) clebert: wolfc: Andy is the one doing it... we needed more control over transaction.. so we are using a different option...
| (04:21:42 PM) clebert: (I don't recall if A or B.. all I know is the one where you don't call beforeDelivery)
| (04:21:45 PM) wolfc: clebert: the RA can never control the tx
| (04:22:34 PM) clebert: wolfc: can you input that on the thread pls.. so Andy will get it for sure?
| (04:22:38 PM) wolfc: I should say: the RA can never control the tx directly
| (04:24:56 PM) wolfc: clebert: jesper already put that in the thread
| (04:25:20 PM) clebert: wolfc: ok.. I was just wondering if what we were discussing about batching would still apply on that...
| (04:25:55 PM) wolfc: clebert: yep it'll. In that case we'll use option B, but do multiple deliveries and tell the proxy endpoint to not complain about it.
| (04:26:21 PM) clebert: wolfc: ok
| (04:26:31 PM) clebert: wolfc: I will put this conversation on that thread if you don't mind
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255404#4255404
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255404
16 years, 6 months
[JBoss Microcontainer Development POJO Server] - Re: Deploying ValidatorFactory
by pete.muir＠jboss.org
Hi Stan,
I've tried out the getting the ValidatorFactory from the DeploymentUnit, however, I'm running into a problem, which *I think* is probably a bug, but I'm happy to be convinced otherwise :-)
If you have an EAR, the current deployer attaches the ValidatorFactory to the relevant modules of the EAR (e.g. war, ejb jars), and not to the top-level-deployment-unit (the EAR itself). I think it should (also) be attached to the top level deployment unit, because the ValidatorFactory is an application wide instance, not a per-module instance. Adding this to the deployer solves it:
if (!unit.isTopLevel() && !unit.getTopLevel().isAttachmentPresent(ValidatorFactory.class))
| {
| unit.getTopLevel().addAttachment(ValidatorFactory.class, vf);
| }
If you are happy with this, I'll commit it.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255370#4255370
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255370
16 years, 6 months
[Javassist Development] - how to Modify j2me class file without preverification
by shivkumar.ms
Hi All,
I am using Javassist to modify a MIDlet class. I was successfully able to change the midlet class file and view the changes in Bytecode Viewer.
But when i try to run the application with WTK emulator it gives me an error as follows:
Error verifying method com/test/TestApp commandAction(Ljavax/microedition/lcdui/Command;Ljavax/microedition/lcdui/Displayable;)V
Approximate bytecode offset 9: Inconsistent or missing stackmap at target
Method............: 10233084 'com/sun/midp/midlet/MIDletState.createMIDlet (static)'
I tried calling the following methods at the end to see if it fixes the problem but it didnt
1) methods.getMethodInfo().rebuildStackMap(classPool) on all the methods of the midlet class
2) CtClass.rebuildClassFile() but didnt help.
If I run preverification on jar with the modified class files in it and then run the application in the simulator, i am able to run it. I am guessing that the preverification tool rebuilt the stackmap and hence i could run the midlet in the simulator.
My question is there any way to modify j2me class files without having to run preverification ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255369#4255369
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255369
16 years, 6 months