[JBoss jBPM] - JBoss 3.2.2 Customization issues and correct zip file locati
by ptaborda
Good afternoon to all:
I'm currently trying to integrate jBPM 3 into a new business platform for the utility industry (electricity) started adapting jbpm 3.1.4 and compared to version 3.2.2 and i discovered differences between the databses models used, including diferent coding styles in the jbpm-console. Anyway I decided to dowload the 3.2.2 version from sourceforge but the current zip uploaded there doesn't contain any test cases or the build folder with the ant build files required to make any customization required by my current project, I tried to downloaded the soucre files via CVS using OpenSSH and Eclipse CVS plug-in, but keept receiving connect refuse messages then I decideed to ping the server mentioned on the wiki (anoncvs.forge.jboss.com -> alias for samus.prod.at12.jboss.com/64.74.196.43) but all I got was connection time-out.
Is there any other server or way to get the proper 3.2.2 source files with their ant build files and test cases, this due to what I want to achieve:
1.- Add schema="workflow" to the hibernate mappings
2.- Customized the jbpm-console web console to authenticate to openldap, btw I understood there is a confusion in how to turn-off the identity component in jbpm)
2.- Customized the ejbs to our current environment
JDK 5.0/JBoss 4.2.1; Hibernatr 3.2.5, H Annotations 3.2.0, Postgres SQL 8.2
I have another question I saw changes in the database model between version 3.1.4 and 3.2.2 are there any paper or procedure to migrate from one database model to the other, there will any migration documents any time due to development decisions or maturity of the code sobe can upgrade JBPM versions with the less hassle?
Thanks,
Pedro
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148664#4148664
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148664
16 years, 4 months
[JBoss Cache: Core Edition] - Setting eviction policies dinamically
by Sancheski
Hi guys,
I am trying to configure different eviction policies to different regions dinamically and I am facing some problems.
This is what I want:
| Create an eviction policy in /NODE
| Create an evcition policy in /NODE/SUBNODE_1
| Create an eviction policy in /NODE/SUBNODE_2 and so on
| Even create an eviction policy in /NODE/SUBNODE_1/SUBNODE_A and so on
|
|
| I expected that I could create them dinamically as I am able to create them using the tree cache config file, but I have encountered some problems.
|
| First of all, if I try to create a new eviction for, let's say /NODE/SUBNODE_1, and /NODE already had one, it throws a
| RegionNameConflictException because at the time of creating the new Region (/NODE/SUBNODE_1) it checks for region conflicts. As I see in the source code, it will never allow to create a new Region under an existing one. Should work that way?
|
| Secondly, I tried to remove any parent region of a given one from the RegionManager to avoid conlflicts from first point, and then configure all eviction policies bottom-up. That is, following last example, first I set an evcition policy to /NODE/SUBNODE_1 and then to /NODE.
|
| In this case, it seems that everything is configured fine, but only the eviction policy configured for every subnode is working. As I see, there are no node entries in the eviction queue for the parent region, check it out yourself below:
|
|
| | /NODE/
| | class org.jboss.cache.eviction.FIFOConfiguration
| | LFUConfiguration: maxNodes = 2
| | Nodes in eviction queue: 0
| |
| | /NODE/SUBNODE_1
| | class org.jboss.cache.eviction.FIFOConfiguration
| | LFUConfiguration: maxNodes = 5
| | Nodes in eviction queue: 2
| |
|
| This is, mainly, how I set the eviction policies:
|
|
| | public final void addEvictionPolicy(EvictionPolicy evictionPolicy,
| | String fqn) {
| | // Activate eviction Policies
| | RegionManager regionMgr = getUnderlyingTreeCache().getEvictionRegionManager();
| | // get EvictionConfiguration
| | EvictionConfiguration config = getEvictionConfiguration(evictionPolicy);
| | if (regionMgr.hasRegion(fqn)) {
| | Region region = regionMgr.getRegion(fqn);
| | region.setEvictionConfiguration(config);
| | logger.debug("Region[{}] configured with {}", fqn, somEvictionPolicy);
| | } else {
| | EvictionPolicy policy = getEvictionPolicy(evictionPolicy);
| | policy.configure(getUnderlyingTreeCache());
| | try {
| | regionMgr.createRegion(fqn, policy, config);
| | } catch (RegionNameConflictException e) {
| | logger.error("Region Name conflict", e);
| | }
| | logger.debug(
| | "Region[{}] does not exist in RegionManager. Created and configured with {}",
| | fqn, evictionPolicy);
| | }
| | }
| |
|
| Hope someone have any idea of how to set dinamically an eviction policy over a region that already its own parent region has one set. By the way, I am using JbossCache 1.4.1.SP8 and JbossAS-4.2.2
|
| I think this is a normal case that it could come up in a real application, so I think that someone who already had at any time encountered this requirement could help me.
|
| Thanks in advance!
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148656#4148656
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148656
16 years, 4 months
[JBoss Cache: Core Edition] - Re: Remoting On Existing POJO Channel
by kblanken
Hi there,
thank you, Shorrockin, for describing the problem and more importantly the solution in detail. In fact, I'm having the very same problem of creating a TreeCache instance with a multiplexer channel (JBoss Cache 1.4.1.SP9).
Here's my code:
JChannelFactory factory=new JChannelFactory();
| factory.setMultiplexerConfig(getClass().getResource("stacks.xml"));
| Channel channel = factory.createMultiplexerChannel("udp-safe", cacheName);
| channel.setOpt(Channel.AUTO_RECONNECT, Boolean.TRUE);
|
| cache = new TreeCache((JChannel) channel);
|
| PropertyConfigurator configurator = new PropertyConfigurator();
| configurator.configure(cache, getClass().getResourceAsStream("replSync-pessimistic-service.xml"));
|
| cache.createService();
| cache.startService();
When executing this code, the last line of this snippet hangs. The stacktrace is
Vector(Object).wait(long, int) line: not available [native method]
| Vector(Object).wait() line: 199
| TreeCache.getCoordinator() line: 1840
| TreeCache.determineCoordinator() line: 1818
| TreeCache.startService() line: 1580
|
Obviously no one is calling notify() on the Vector object. The only place this could happen is in the viewAccepted method of the MembershipListener interface. As this is just what Shorrockin has described, it seems to me that he has had the same problem back then.
Am I missing something here? BTW, I'm outside JBoss AS, so I can't access the cache MBean. (Can I?)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148654#4148654
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148654
16 years, 4 months
[EJB 3.0] - Re: EJB with SSL does not work with JBoss AS 4.2.2
by jaikiran
"jthinaka" wrote : Jaikiran,
| Thanks for your reply, however we need to have 0.0.0.0 set because our server has multiple addresses and needs to be accessible by all of them. So even if the fix worked, it would not really work for us.
|
| Dave,
| Thanks for posting, if it helps, your experience is exactly like mine, which in some way or form is heartening. Let's hope the Jboss dev group finds a resolution soon.
|
| Cheers to both of you.
| TJ
I was able to reproduce this on my local JBoss-4.2.2 setup and even able to get it working after knowing what was going wrong (atleast in my case).
Steps to reproduce this exception:
1) Start with this guide http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/t.... I guess, everyone in this thread too has followed the same.
2) My SLSB looks like this:
| package org.myapp.ejb.impl;
|
| import javax.annotation.Resource;
| import javax.ejb.Remote;
| import javax.ejb.Stateless;
| import javax.persistence.EntityManager;
|
| import org.jboss.annotation.ejb.RemoteBinding;
| import org.jboss.annotation.ejb.RemoteBindings;
| import org.myapp.ejb.AppManager;
|
| @Stateless
| @Remote ({AppManager.class})
| @RemoteBindings({
| @RemoteBinding(clientBindUrl="sslsocket://0.0.0.0:3843", jndiBinding="AppManagerBeanSSL"),
| @RemoteBinding(jndiBinding="AppManagerBeanNormal")
| })
| public class AppManagerBean implements AppManager {
|
|
| public String getVersion() {
|
| return "1.0";
| }
|
|
| }
|
3) Modified the jboss-service.xml in %JBOSS_HOME%\server\< serverName>\deploy\ejb3.deployer\ejb3.deployer\META-INF folder to add (as mentioned in that doc):
| <mbean code="org.jboss.remoting.transport.Connector"
| name="jboss.remoting:type=Connector,transport=socket3843,handler=ejb3">
| <depends>jboss.aop:service=AspectDeployer</depends>
| <attribute name="InvokerLocator">sslsocket://${jboss.bind.address}:3843</attribute>
| <attribute name="Configuration">
| <handlers>
| <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
| </handlers>
| </attribute>
| </mbean>
4) Created the keystore and truststore files and started JBoss passing it the keystore filename and password:
| run.bat -c jaikiran -b 0.0.0.0 -Djavax.net.ssl.keyStore=C:\jdk1.5.0_07\bin\localhost.keystore -Djavax.net.ssl.keyStorePassword=opensource
5) Wrote a simple standalone client to use the AppManagerBean:
| package org.myapp.core;
|
| import javax.naming.Context;
| import javax.naming.InitialContext;
|
| import org.myapp.ejb.AppManager;
|
| public class SSLBeanLookup {
|
| public static void main(String args[]) {
| try {
|
|
| Context ctx = new InitialContext();
|
| AppManager appManagerSSL = (AppManager) ctx.lookup("AppManagerBeanSSL");
| System.out.println("AppManager : " + appManagerSSL);
| System.out.println("AppManager version returned is : " + appManagerSSL.getVersion());
|
| } catch(Exception e) {
| e.printStackTrace();
| }
| }
|
| }
|
6) Ran this standalone client without passing any parameters:
java org.myapp.core.SSLBeanLookup
The client failed with the exact same exception as mentioned in this thread. The server side also showed the similar exception:
| 2008-05-05 20:19:44,569 ERROR [org.jboss.remoting.transport.socket.ServerThread] Worker thread initialization failure
| java.lang.reflect.InvocationTargetException
| at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
| at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
| at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
| at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
| at org.jboss.remoting.transport.socket.ServerThread.createServerSocketWrapper(ServerThread.java:720)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:368)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
| Caused by: java.net.SocketException: Socket Closed
| at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:201)
| at java.net.Socket.setSoTimeout(Socket.java:988)
| at com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(SSLSocketImpl.java:1971)
| at org.jboss.remoting.transport.socket.SocketWrapper.setTimeout(SocketWrapper.java:85)
| at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:171)
| at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)
| at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:46)
| ... 7 more
|
I then downloaded the JBossRemoting source code and a bit of debugging and modification to the code (to print out the exception) showed exactly what was going wrong. I changed the ClientSocketWrapper to catch and print out the exception:
try
| {
| out = createOutputStream(serializationType, socket, marshaller);
| in = createInputStream(serializationType, socket, unmarshaller);
| } catch (Exception e) {
| //Jaikiran: Added this catch block for debugging
| System.out.println("Exception caught " + e);
| e.printStackTrace();
| }
| finally
| {
| setTimeout(savedTimeout);
| log.debug("reset timeout: " + savedTimeout);
| }
Turns out, the root cause of this exception is this:
| 2008-05-05 20:19:44,569 ERROR [org.jboss.remoting.transport.socket.ServerThread] Worker thread initialization failure
| java.lang.reflect.InvocationTargetException
| at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
| at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
| at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
| at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
| at org.jboss.remoting.transport.socket.ServerThread.createServerSocketWrapper(ServerThread.java:720)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:368)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
| Caused by: java.net.SocketException: Socket Closed
| at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:201)
| at java.net.Socket.setSoTimeout(Socket.java:988)
| at com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(SSLSocketImpl.java:1971)
| at org.jboss.remoting.transport.socket.SocketWrapper.setTimeout(SocketWrapper.java:85)
| at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:171)
| at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)
| at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:46)
| ... 7 more
|
| .................
| .................
| 2008-05-05 20:20:34,711 INFO [STDOUT] Exception caught javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
| 2008-05-05 20:20:36,149 ERROR [STDERR] javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
| 2008-05-05 20:20:36,149 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
| 2008-05-05 20:20:36,149 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:117)
| 2008-05-05 20:20:36,149 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1584)
| 2008-05-05 20:20:36,164 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:866)
| 2008-05-05 20:20:36,164 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030)
| 2008-05-05 20:20:36,164 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:622)
| 2008-05-05 20:20:36,164 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
| 2008-05-05 20:20:36,164 ERROR [STDERR] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
| 2008-05-05 20:20:36,164 ERROR [STDERR] at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
| 2008-05-05 20:20:36,164 ERROR [STDERR] at java.io.ObjectOutputStream$BlockDataOutputStream.flush(ObjectOutputStream.java:1628)
| 2008-05-05 20:20:36,164 ERROR [STDERR] at java.io.ObjectOutputStream.flush(ObjectOutputStream.java:666)
| 2008-05-05 20:20:36,164 ERROR [STDERR] at org.jboss.remoting.marshal.serializable.SerializableMarshaller.getMarshallingStream(SerializableMarshaller.java:90)
| 2008-05-05 20:20:36,180 ERROR [STDERR] at org.jboss.remoting.marshal.serializable.SerializableMarshaller.getMarshallingStream(SerializableMarshaller.java:72)
| 2008-05-05 20:20:36,180 ERROR [STDERR] at org.jboss.remoting.transport.socket.ClientSocketWrapper.createOutputStream(ClientSocketWrapper.java:207)
| 2008-05-05 20:20:36,180 ERROR [STDERR] at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:163)
| 2008-05-05 20:20:36,180 ERROR [STDERR] at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)
| 2008-05-05 20:20:36,180 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:46)
| 2008-05-05 20:20:36,180 ERROR [STDERR] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
| 2008-05-05 20:20:36,180 ERROR [STDERR] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
| 2008-05-05 20:20:36,180 ERROR [STDERR] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
| 2008-05-05 20:20:36,180 ERROR [STDERR] at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
| 2008-05-05 20:20:36,180 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.createServerSocketWrapper(ServerThread.java:720)
| 2008-05-05 20:20:36,196 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:368)
| 2008-05-05 20:20:36,196 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
|
This exception provides enough clues.
How to fix this:
Pass the truststore file and truststore password -Djavax.net.ssl.trustStore and -Djavax.net.ssl.trustStorePassword arguments when running the standalone client:
| java org.myapp.core.SSLBeanLookup -Djavax.net.ssl.trustStore=C:\jdk1.5.0_07\bin\localhost.truststore -Djavax.net.ssl.trustStorePassword=opensource
That's it. With these arguments passed to the client, i got my expected output without any exceptions.
The whole confusion is because of the original exception stacktrace not being clear enough.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148646#4148646
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148646
16 years, 4 months