jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Javassist development Forum] - Re: Array access

[<kab...@jb...>]

Hi Chiba,

I heard from Emmanuel that you'd discussed array interception with him and that it might be possible, but with some limitations.

Could you please explain the limitations a bit?

In particular Emmanuel mentioned differences between different compilers and reassignment of the array variables. As a first cut, I think it would be fine to not allow reassignment of variables, but the Hibernate and POJOCache guys will need to  verify if this works for them.

Thanks,

Kabir

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955764#3955764

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955764

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: Error redeploying dependent war

[vickyk <do-...@jb...>]

Scott,
I have been able to implement this 
>>This method should really be removing the war dependency from the service in addition to nulling out all of these variables as the war has been 
>>undeployed and should no longer be usable.
The code snippet doing this will look like this 

  | protected void destroyService()
  |    {
  | try
  | {
  | ObjectName jmxName = (ObjectName) di.context.get(AbstractWebContainer.WEB_MODULE);
  | ServiceControllerMBean serviceController = (ServiceControllerMBean)
  | MBeanProxyExt.create(ServiceControllerMBean.class,
  | ServiceControllerMBean.OBJECT_NAME, di.getServer());
  | serviceController.remove(jmxName);
  | }
  | catch (Exception e)
  | {
  | System.out.println("Exception in destroyService"+e);
  | }
  | this.di = null;
  |           this.container = null;
  |           this.deployer = null;
  |    } 
  | 


>> The redeployment of the properties service 
>>would then have no dependent war to start. 
Yes this is done when I made the above changes .

The following feature needs to be discusses here .
>>What is really needed is a redeploy notion that 
>>would recycle the dependent deployments, but such a notion 
>>does not exist.
Now the war which depends on the property service is removed from the nameToServiceMap attribute of the ServiceController. The DeploymentScanner can not figure out that the "WAR" needs to be redeployed as this has not been modified. 
So we will have to modify the destroyService() so that it deos 
1) Remove the web Deployment From the ServiceController
2) Remove the Deployment From the MainDeployer	
3) Recycle the Deployment of the Web application , in case the web is the sub-deployment then we need to recycle the parent deployment .

I propose the changes in the following files 
1) org.jboss.web.WebModule
2) org.jboss.deployment.scanner.URLDeploymentScanner
3) org.jboss.deployment.scanner.URLDeploymentScannerMBean
4) org.jboss.deployment.MainDeployerMBean
5) org.jboss.web.AbstractWebContainer

Here goes the changes 
org.jboss.web.WebModule

  | protected void destroyService()
  |    {		
  | 	  try
  | 	  {
  | 		ObjectName jmxName = (ObjectName) di.context.get(AbstractWebContainer.WEB_MODULE);     
  | 		ServiceControllerMBean serviceController = (ServiceControllerMBean)
  | 		MBeanProxyExt.create(ServiceControllerMBean.class,
  | 		ServiceControllerMBean.OBJECT_NAME, di.getServer());
  | 
  | 		// Remove the Deployment From the ServiceController
  | 		serviceController.remove(jmxName);
  | 		MainDeployerMBean mainDeployer = (MainDeployerMBean)
  | 		MBeanProxyExt.create(MainDeployerMBean.class,
  | 		MainDeployerMBean.OBJECT_NAME, di.getServer());
  | 
  | 		// Remove the Deployment From the MainDeployer		
  | 		Map deploymentMap = mainDeployer.getDeploymentMap();
  | 		deploymentMap.remove(di.url);
  | 
  | 		//Recycle the Deployment.
  | 		javax.management.ObjectName OBJECT_NAME=
  | 			org.jboss.mx.util.ObjectNameFactory.create("jboss.deployment:type=DeploymentScanner,flavor=URL");
  | 		URLDeploymentScannerMBean deployerScanner = (URLDeploymentScannerMBean)
  | 		MBeanProxyExt.create(URLDeploymentScannerMBean.class,
  | 		OBJECT_NAME, di.getServer());
  | 		Set deployedSet = deployerScanner.getDeployedSet();
  | 		long timeModifier = System.currentTimeMillis();
  | 		System.out.println("URL is "+di.url);
  | 		deployerScanner.redeployUrl(di,timeModifier);
  | 	  }
  | 	  catch (Exception e)
  | 	  {
  | 		System.out.println("Exception in destroyService"+e);
  | 	  }
  | 	  this.di = null;
  |       this.container = null;
  |       this.deployer = null; 
  |    }
  | 
org.jboss.deployment.scanner.URLDeploymentScanner

  | 	public Set getDeployedSet()
  | 	{
  |       return this.deployedSet;
  | 	}
  | 	public void redeployUrl(DeploymentInfo di, long lastModified1)
  | 	{
  | 		//Call Deployer.deploy()
  | 		URL redeployUrl = null;
  | 		DeploymentInfo current = di;
  | 		DeploymentInfo parentDI = di;
  | 		//System.out.println("Before current url ----->"+current.url);
  | 		while(current!=null){
  | 			//System.out.println("After current url ----->"+current.url);
  | 			parentDI = current;
  | 			current = current.parent;
  | 		}
  | 		for (Iterator i = deployedSet.iterator(); i.hasNext();)
  |          {
  |             DeployedURL deployedURL = (DeployedURL) i.next();
  | 			URL url = deployedURL.url;
  | 			long deployedLastModified = deployedURL.deployedLastModified;
  | 			long lastModified = deployedURL.getLastModified();
  | 			if(url.equals(parentDI.url))
  | 			{
  | 				System.out.println("Going to Redeploy url  ----->"+url);
  | 				//System.out.println("deployedLastModified ----->"+deployedLastModified);
  | 				//System.out.println("lastModified ----->"+lastModified);
  | 				deployedURL.deployedLastModified=lastModified1;
  | 				return;
  | 				//System.out.println("lastModified is set at ----->"+lastModified1);
  | 			}			
  | 		 }
  | 	}
  | 
org.jboss.deployment.scanner.URLDeploymentScannerMBean

  |    java.util.Set getDeployedSet();
  |    void redeployUrl(DeploymentInfo di,long lastModified);
  | 
org.jboss.deployment.MainDeployerMBean

  |    Map getDeploymentMap();
  |    void setDeploymentMap(Map deploymentMap);
  | 
org.jboss.web.AbstractWebContainer

  | public synchronized void destroy(DeploymentInfo di)
  |       throws DeploymentException
  |    {
  |       ObjectName jmxName = (ObjectName) di.context.get(WEB_MODULE);
  |       try
  |       {
  |          if( jmxName != null )
  |          {
  |             serviceController.destroy(jmxName);
  | 			//Changed by Vicky , July 6 2006 
  |             //server.unregisterMBean(jmxName);
  | 	    //Changed by Vicky , July 6 2006
  |          }
  |       }
  |       catch (DeploymentException e)
  |       {
  |          throw e;
  |       }
  |       catch(Exception e)
  |       {
  |          throw new DeploymentException("Unable to stop web module", e);
  |       }
  |       // Generate an event for the shutdown
  |       super.destroy(di);
  |    }
  | 


Does this make a sense , I have tested these changes seems to be working fix for the  JBAS11 and JBAS-1748 .
Please provide your review comments ....

Regards
Vicky

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955763#3955763

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955763

[Jboss-dev-forums] [Design of JBossCache] - Re: Pluggable state transfer factory

[<man...@jb...>]

What are you proposing, a getStateTransferGenerator() method on the SPI?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955760#3955760

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955760

[Jboss-dev-forums] [Design of JBoss Serialization] - Re: JBoss Serialization is very slow?

[slump <do-...@jb...>]

Hi, clebert:

I just copy your code and run the test
but the result is:
jboss=644
java=557

I have run it more than 10 times , the reuslt is similar

I use RHEL4 and jdk 1.5.0_06

is there something I missed?

and I found that if there isn't log4j.properties, the jboss code become very slow (2333ms),  so I think you should put the note in the README



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955724#3955724

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955724

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: KernelControllerContextAware

[<kab...@jb...>]

An easy way to do the differentiation would at first glance seem to be to have the AspectBeanMetaDataFactory check to see if the beanfactory has any dependencies. This information does not seem to be available in the BeanMetaData though and so does not appeat to be available at the time AspectBeanMetaDataFactory.getBeans(). It does not seem to be available until later when it is populated in the KernelControllerContext?



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955690#3955690

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955690

[Jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-2520 - HASingleton stopping problem

[<bst...@jb...>]

Thanks for the input on interoperability; we'll leave the issue for 5.0.1.CR1.

I'm packing up my house right now, so will defer further comment for a couple weeks until I'm resettled :)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955674#3955674

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955674

[Jboss-dev-forums] [Design of JBossXB] - JBoss-4.0.4.GA and XB-1.0.0.CR5+

[<ale...@jb...>]

There is a confusing compatibility issue between XB versions up to 1.0.0.CR4 and 1.0.0.CR5 that I would call as binary-but-not-Java-API incompatibility. The issue itself is described here http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossXB100CR5InJBoss404GA

The reason for removing the API that's causing the trouble is that the API is old and not actually used by anyone. So, I don't want this API to appear in the future CR's and releases (if ever) of XB.

I understand that asking clients who want to use JBossWS version that relies on XB-1.0.0.CR5 or later to recompile 4.0.4.GA with the required XB version is not going to work.

To workaround the incompatibility I could release a special binary for 4.0.4.GA every time I release a new version of XB. These binaries could be used with any JBoss version. But all JBoss versions after 4.0.4.GA should be compiled with the XB-1.0.0.CR5 or later.

Would this work for everyone? Or do you think I should reinstate the old API now and proceed with the long planned refactoring that includes SchemaBinding API and public API cleanup (probably creating new Java packages for them) on another branch? But the compatibility would still be a question to answer.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955661#3955661

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955661

[Jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-2520 - HASingleton stopping problem

[ScottMarlowNovell <do-...@jb...>]

Alex and I discussed some of our options (using a policy driven approach versus a listener.)  

It seems to me now that users can already detect the error in their implementation of stopSingleton by surrounding the logic with a try {} catch(java.lang.Throwable).  So, I don't think we need to do anything else.  

If we do decide to implement a cluster wide error listener, we could include the stopSingleton failure in the list of events that can be observed.

Other thoughts?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955653#3955653

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955653

[Jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-2520 - HASingleton stopping problem

[ScottMarlowNovell <do-...@jb...>]

anonymous wrote : Scott, can you take a look at this in conjunction with what Alex did on configuring the HASingleton election policy and try to determine if solving this will require some change that breaks interoperability between releases (as opposed to just introducing a new feature). If it will break interoperability, please reschedule to 5.0.0.Beta. Otherwise, let's do this for 5.0.1.CR1.

I don't see an interoperability issue here.

>From a cluster management point of view, it would be nice to apply a generic solution for handling cluster errors such as SingletonService stop failure.  The handling code as previously suggested, could deal with solving the problem or notifying someone that can deal with it (email/pager/send snmp trap).  Otherwise, we can continue to log the error as we do now and continue execution (starting the new singleton) with the hope that something might work.  Of course users can catch the exception directly in their code and do something better (if there is a better thing to do.)

Should we invite someone from the JBoss ON team to give input on this (cluster management) issue?



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955617#3955617

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955617

[Jboss-dev-forums] [Design of JBoss ESB] - Re: Format of Documentation

[<dan...@jb...>]

If we're going to keep using Word format, I'd suggest we start saving the files in RTF or something a little more portable for people using programs other then MS Office.

Yes, a heck of a lot easier then DocBook.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955506#3955506

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955506

[Jboss-dev-forums] [Design of JBoss ESB] - Re: Format of Documentation

[<mar...@jb...>]

Or OpenOffice format. I've had problems in the past with RTF and diagrams ;-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955507#3955507

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955507

[Jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Re: Standardization on runtime dependencies in JBossIDE

[<max...@jb...>]

All of those situations is *clear* for me (except the jbpm.jar) ;)

When do you not need to run against the jbpm.jar in e.g. your unittests ?

What i'm trying to say is that for me there still are only two kind of libs in this discussion: libs for the IDE and libs for the users development/runtime.

The last part is of course not just one big bundle of jars, but very much dependent on what kind/"facet" of development the user is doing - this is where Facet's become usefull since you here can define different "configurations" or simply just "facets".



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955579#3955579

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955579

[Jboss-dev-forums] [TODO - DEVELOPMENT] - How Do Install jboss-4.0.4.GA On Redhat ES 4 ?

[jack_psys <do-...@jb...>]

run this 1 :

[root@ns168 ~]# java -version
java version "1.4.2"
gcj (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

run this 2 :

[root@ns168 ~]# java -jar jboss-4.0.4.GA-installer.jar
Warning: -jar not understood. Ignoring.
Exception in thread "main" java.lang.NoClassDefFoundError: jboss-4.0.4.GA-installer.jar
   at gnu.gcj.runtime.FirstThread.run() (/usr/lib/libgcj.so.5.0.0)
   at _Jv_ThreadRun(java.lang.Thread) (/usr/lib/libgcj.so.5.0.0)
   at _Jv_RunMain(java.lang.Class, byte const, int, byte const, boolean) (/usr/lib/libgcj.so.5.0.0)
   at __gcj_personality_v0 (/root/java.version=1.4.2)
   at __libc_start_main (/lib/tls/libc-2.3.4.so)
   at _Jv_RegisterClasses (/root/java.version=1.4.2)

How install Jboss-4.0.4 On Redhat ES 4 ?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955550#3955550

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955550

[Jboss-dev-forums] [Design of JBoss Profiler] - Re: Nodes - Unique Identification

[<cle...@jb...>]

The way I though it should work is:

OrderEJB.processOrder is a node.
   OP A, is another node, under OrderEJB.processOrder node.

We will have to navigate in trees. We shouldn't have a flat structure.
Because you still need to analyze the rood node processOrder combining A + C = total of the node.

Makes sense?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955545#3955545

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955545

[Jboss-dev-forums] [Design of JBoss Profiler] - Nodes - Unique Identification

[nickman <do-...@jb...>]

I am in the process of documenting some of the primary structures in the production profiler and their constituent cardinalities.

One issue I have run into is the cardinality and identification of Nodes. I had originally thought that a Node would be unqiuely identified as a Category Name and an Operation Name.

For example, consider an EJB Method "OrderEJB.processOrder". We might assign it an identifier as follows:

Category Name: Stateless Session Bean
Operation Name: OrderEJB.processOrder
Unique Identifer: "Stateless Session Bean:OrderEJB.processOrder"

However, what this does not take into account is the potential for different execution paths within that operation.

OrderEJB.processOrder-->Op A --> Op B --> Op C
OrderEJB.processOrder-->Op C --> Op X --> Op Y

In this instance, I would think these two code paths should be represented by two different nodes, but the naming and tracking will now get substantially more complex.

Any thoguhts ?

//Nicholas


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955543#3955543

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955543

[Jboss-dev-forums] [Design of JBoss ESB] - Re: Format of Documentation

[<mar...@jb...>]

Ignore DocBook for now. Try RTF in OpenOffice.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955521#3955521

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955521

[Jboss-dev-forums] [Design of JBoss ESB] - Re: Format of Documentation

[jplenhart <do-...@jb...>]

I am not familiar with Docbook - sounds like that may be a good thing:-D

I will give OpenOffice a shot both RTF and Docbook formats.  Unless anyone disagrees.

I agree that Word could be problematic as many people may be wanting to verify something in the docs but not have Word at their disposal.  



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955520#3955520

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955520

[Jboss-dev-forums] [Design of JBoss ESB] - Re: Format of Documentation

[<mar...@jb...>]

"DocBook" and "preference" doesn't parse ;-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955519#3955519

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955519

[Jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Re: Eclipse 3.2 + JBossIDE-200607022024-nightly-ALL.zip issu

[<rob...@jb...>]

When I say "it could be that there's a bug", I mean in the IDE, not your jar ;)  

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955513#3955513

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955513

[Jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Re: Eclipse 3.2 + JBossIDE-200607022024-nightly-ALL.zip issu

[<rob...@jb...>]

Can you send me an email or a link to the packaged .jar file you're trying to deploy? It could be that there's a bug and I'd like to use your jar to test.

Thanks.  

- Rob Stryker
rob...@jb...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955512#3955512

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955512

[Jboss-dev-forums] [Design of JBoss ESB] - Re: Format of Documentation

[<Kev...@jb...>]

It's possible to have openoffice generate docbook, this would be my preference :-)


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955511#3955511

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955511

[Jboss-dev-forums] [Design of JBoss ESB] - Re: Format of Documentation

[<mar...@jb...>]

Word/OpenOffice are fine too. That's what we use for JBossTS. Either are fine and a lot easier to use than DocBook ;-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955503#3955503

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955503

[Jboss-dev-forums] [Design of JBoss ESB] - Re: Format of Documentation

[<dan...@jb...>]

I think @ JBoss we use DocBook format for most of the other projects - a pain in the but to work with till you get used to it.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955502#3955502

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955502

[Jboss-dev-forums] [Design of JBoss IIOP on JBoss] - problem trying to run a Scheduler MBean from a deployed appl

[deilginis <do-...@jb...>]

I am using jboss 3.2.7

I am trying to use a Scheduler within an application I am developing.
In tests I can use a scheduler declared in conf/jboss-service.xml with the corresponding class put into a jar that I put into ... default/deploy/lib
What I want to do is to put the classes or jar within the application (.ear) file.
When I try to do this within the .war file (within the ear) I get a class not found exception when I start up jboss with my application deployed. The configuration file works (xxx_scheduler-service.xml) as I tried it with my classes put in a jar and put into the deploy/lib folder, and it worked fine.

The question is: how can I force jboss to put my Scheduler classes into the classpath before jboss tries to activate the corresponding timer MBean


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955491#3955491

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955491

[Jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Re: Standardization on runtime dependencies in JBossIDE

[<koe...@jb...>]

The obvious case where you want to develop against api and not against impl's is for all of the jee standard stuff... You don't need all of the JBoss runtime classes in the classpath of your project in order to develop a jee app. 
Also, if you develop a pure jee app using the api jars, it should be fairly easy to port them between JBoss 4.0.x versions. This is (at this point) not possible easily with e.g. jBPM in the first part because of the non-existence of a jBPM-api.jar. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955483#3955483

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955483