July 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: Setting up the designer to develop in eclipse

by sgodden

anonymous wrote : There is no problem with the manifests in CVS AFAIK. Then I must be doing something wrong. I checked out the project, started up eclipse with the workspace pointed at ROOT/jbpm.3/designer/jpdl Then I added plugin projects and feature project as necessary for: * org.jbpm.gd.jpdl.core * org.jbpm.gd.jpdl.db * org.jbpm.gd.jpdl.feature * org.jbpm.gd.jpdl.db.help * org.jbpm.gd.jpdl.db.site * org.jbpm.gd.jpdl.db.ui * org.jbpm.gd.jpdl.db.ui.test Result: loads of red crosses in the 'ui' project. After editing the manifest to include further plugin dependencies, the crosses go away. (OK ui is obsolete) Would it be possible for you to do a quick WIKI page on how you set it up and run it. I know that will change, but the WIKI page shouldn't take long. Alternatively just scribble your instructions as a reply here, and I will validate them and do the WIKI page myself, if that helps. anonymous wrote : Before I forget, to actually build the feature, the best thing to do is to check out the jbpm.3/designer/jpdl project and invoke the ant build. Make sure that you have the correct cvs client and the correct zip/unzip software installed on your system path. OK understood, and I have done that successfully. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958394#3958394 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958394

19 years, 8 months

1
0
0 / 0

[Design of JBoss Eclipse IDE (dev)] - Re: JBossSeam IDE proposal

by max.andersen＠jboss.com

"cdelashmutt" wrote : | I think that linking in knowledge of Seam components in your build path is a critical feature to add. | Do you just mean adding the seam related jars into the build path or is there more to it ? anonymous wrote : | What I mean by this is, first, content assist that can help you complete references to seam components and properties or methods (depending on the context). | Where I have been trying to work on this is in JSF/JSP pages to have the EL completion know about Seam components. Unfortunately the JSF el-code completion in Eclipse is currently very weird and 100% tied into having projects structured as WTP.....but it is doable, I know how to do it - just need the time (or someone who would like to do it ;) What other places or ways are code completion relevant ? (e.g. what are you thinking about when you say "depending on the context" ? anonymous wrote : | I think also, a browser of some sort that shows you all of the known Seam components, plus the built in ones would be good as well. Of course, drag and drop from the browser to code would be a nice feature as well. | "Browser of all known seam components" should basically "just" be to show a list of all beans with a @Name annotation correct? What should drag-and-drop actually do ? (and wouldn't code completion be better here or?) anonymous wrote : | I think the pinnacle in my mind right now is a JSF visual editor (possibly WTP's effort?) that is Seam aware. Basically couple the component browser with the JSF editor to allow a drag of a component property or method and drop on a property of a JSF component to "bind" it to that component. This sort of thing might even be something that we can release as JSF preview of a page, and then move to more editing in the future. | Yes, this is the scope of the JSF project in Eclipse (the drivers here are Oracle and Sybase) and in NetBeans the Studio Creator has such a thing. The last one is the most mature one and i'm looking into it in more detail this weekend just to see if it is as good as the flashdemos indicate. anonymous wrote : | I'd love to do this sort of thing, but I'm only one person, and I'm already on the hook for a SPNEGO JAAS authentication module for JBoss SX. :) That being said, I'd like to discuss this functionality further to try and break it down into chunks that might be small enough for me to do. | We always like extra hands ;) Do you have any experience with eclipse or netbeans development ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958385#3958385 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958385

19 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Reactivating SharedStoreCacheLoader

by manik.surtani＠jboss.com

What about something like this - 1) New node becomes coord 2) Triggers a process in the singleton cache loader to take over ownership of the singleton cache. 3) Starts by walking the tree to get a picture of the in-memory state (by doing _get? Bad, since no locks are obtained. Perhaps by passing in a flag to bypass cache loading?) 4) Make calls to cacheLoader.put() for each node visited in the tree. Yes, this is brute-force and slower than getting/setting state as bytes, but at least this sticks with data format contracts without having to make assumptions. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958367#3958367 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958367

19 years, 8 months

1
0
0 / 0

[Design of POJO Server] - ClassLoadingDeployer behavior

by scott.stark＠jboss.org

One issue I'm seeing with implementing a class loading deployer that would handle issues such a manifest Class-Paths, OSGI bundle headers, some custom class loader metadata is that this would conflict with a class loader specified at the bean deployer level. For example, |  | <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="urn:jboss:bean-deployer:2.0 bean-deployer_2_0.xsd" | xmlns="urn:jboss:bean-deployer:2.0"> | <bean name="VFSClassLoader" class="org.jboss.vfs.classloading.VFSClassLoader"> | <constructor factoryClass="org.jboss.vfs.classloading.VFSClassLoaderFactory" | factoryMethod="newClassLoader"> | <parameter>${jbosstest.deploy.dir}</parameter> | <parameter> | <array class="[Ljava.lang.String;" elementClass="java.lang.String"> | <value>org.jboss.server.support.jar</value> | </array> | </parameter> | <parameter><inject bean="MainDeployer" property="VFSFactory"/></parameter> | </constructor> | </bean> | <bean name="TestBean" class="org.jboss.test.server.support.TestBeanImpl"> | <classloader><inject bean="VFSClassLoader"/></classloader> | <property name="intProperty">1234</property> | <property name="integerProperty">4321</property> | <property name="stringProperty">string-x</property> | </bean> | </deployment> | I guess that the BeanDeployer could indicate that beans were seen with ClassLoaderMetaData, but it still would not be know if this was an override, or a class loader that should be augmented with deployment manifest settings. About the only thing I can think to do is have the ClassLoadingDeployer be responsible for the deployment context class loader, and the BeanDeployer could create a child class loader for any bean deployment local class loader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958364#3958364 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958364

19 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Proper usage for data gravitation with buddy replication

by manik.surtani＠jboss.com

I reckon this should be passed on to the user. At the end of the day when we talk about 'users' in this context, it is not end-users who write Java applications, but rather developers who implement frameworks such as Tomcat session clustering (a.k.a. Brian :) ) A separate method call will just add clutter. If PojoCache needs to be aware of a data gravitation (so it can gravitate internal space as well) then it should sniff for the option being present in the Invocation Context. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958359#3958359 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958359

19 years, 8 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: JBAOP-87 - Annotation Dependencies

by bill.burke＠jboss.com

the interface isn't weaved, the class that is annotated is weaved. (for the jdk1.4 interface replacement of annotations). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958352#3958352 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958352

19 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Proper usage for data gravitation with buddy replication

by ben.wang＠jboss.com

In the PojoCache 1.4 release, I have used the data gravitation option during the getObject to gravitate the data (if there is any) for buddy replication. However, I am not quite happy with it for two reasons: 1. It is kind of ad-hoc, meaning future refactoring may mess up the logic. 2. It can be inefficient. PojoCache by nature can call getObject (or attach in 2.0 API) recursively for it object graph. This means potentially multiple times of distributed get (for data gravitation). Then this is also exacerbated by the new PojoCach 2.0 design where the real POJO storage happens under an internal region. Do you guys thin it will make more sense to delegate this to the user's code to do it? Or should PojoCache expose an additional API for user to do data gravitation, e.g., gravitateData(/JSESSIONID/sessionid); this will gravitate all the necessary data (including those in the internal space) over first. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958336#3958336 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958336

19 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Another JBESB Example - Data Transformation

by daniel.brum＠jboss.com

Nice work Dave - when you see the next release you will see even more possibilities available to you. Keep sending us your examples, we might incoroporate them into the documentation/samples, and I'm sure other users here appereciate the time you take to document your efforts with JBossESB. thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958282#3958282 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958282

19 years, 8 months

1
0
0 / 0

[Design of JBoss Web Services] - question design of wstools java-wsdl

by agun

I have not got any answer to this question in the users forum, so so I'll try here. With JBoss 4.0.4, the JBoss developers have passed on the responsibility of specifying the package to namespace mapping of java-wsdl to the user. As a result, people who are writing tools that takes in user-defined interfaces and use wstools to generate the wsdl need to figure out and supply the package name to namespace mapping in the java-wsdl config. This works fine as long as the SEI and its associated classes that it references are in the same package, but in an enterprise setup, this is a rarity - the SEI uses classes from various other packages. At the moment, JBoss expects that all pkg->namespace need to be supplied, which puts a heavy burden on the tool-writer in this case. Is this a first shot approach and the goal is to add the code to generate a default mapping if the user does not supply them (like what is done by all other vendors) at a later stage? Or is this a permanent design that will always expect the user to supply the mapping? If yes, then I am curious why you chose this approach where all the other vendors provide a default mapping and have the user-defined mapping as optional. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958235#3958235 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958235

19 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Nulling properties on uninstall

by scott.stark＠jboss.org

I am seeing a related problem that seems like a bug on shutdown of the kernel where a long property is being nulled out: | 6125 TRACE [AbstractKernelController] Uninstalling VFSDeploymentScanner from Configured | 166547 TRACE [ConfigureAction] Ignored for org.jboss.joinpoint.plugins.BasicMethodJoinPoint@1d31859 | java.lang.IllegalArgumentException: Wrong arguments. setScanPeriod for target org.jboss.deployers.plugins.scanner.VFSDeploymentScannerImpl@10e7c9e expected=[long] actual=[null] | at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:224) | at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59) | at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:107) | at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) | at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:65) | at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:97) | at org.jboss.kernel.plugins.dependency.ConfigureAction.uninstallAction(ConfigureAction.java:68) | at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.uninstall(KernelControllerContextAction.java:128) | at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58) | at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:236) | at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:605) | at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:575) | at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:510) | at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:194) | at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:367) | at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:346) | at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:149) | at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.undeploy(BasicKernelDeployer.java:76) | at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.undeploy(BasicXMLDeployer.java:84) | at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.shutdown(BasicKernelDeployer.java:90) | at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdownKernel(ServerImpl.java:719) | at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:691) | at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.run(ServerImpl.java:674) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958228#3958228 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958228

19 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2006