[Persistence] - @Column atttributes name and length does not work in JBoss5.
by harshajbharsha
| @Entity
| public class ColumnAttribsTesting {
|
| @Id
| @GeneratedValue(strategy=GenerationType.AUTO)
| private Integer id;
|
| private Integer column1 ;
|
| private Integer column2 ;
|
| public ColumnAttribsTesting() {
|
| }
|
| public Integer getId() {
| return id;
| }
|
| public void setId(Integer id) {
| this.id = id;
| }
|
| @Column(name = "abcde", length=1024)
| public Integer getColumn1() {
| return column1;
| }
|
| public void setColumn1(Integer column1) {
| this.column1 = column1;
| }
|
| public Integer getColumn2() {
| return column2;
| }
|
| public void setColumn2(Integer column2) {
| this.column2 = column2;
| }
|
| }
|
persistence.xml
| <?xml version="1.0" encoding="UTF-8"?>
| <persistence xmlns="http://java.sun.com/xml/ns/persistence"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
| http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" version="1.0">
|
| <persistence-unit name="atspu" transaction-type="JTA">
| <jta-data-source>java:ats</jta-data-source>
| <class>org.hibernate.ejb.HibernatePersistence</class>
| <properties>
| <property name="hibernate.hbm2ddl.auto" value="update" />
| <property name="hibernate.show_sql" value="true"/>
| <property name="hibernate.dialect" value="org.hibernate.dialect.MySQL5Dialect"></property>
| <property name="hibernate.transaction.manager_lookup_class"
| value="org.hibernate.transaction.JBossTransactionManagerLookup" />
| </properties>
| </persistence-unit>
| </persistence>
|
the table get created. but jpa does not create a column with the name abcde but column1, and the length is always defaults to 255 chars irrespective of the length attribute
i wonder how the basic annotation does not work in JPA.
Am i missing something? mysql installation, mysql-ds.xml are fine
please help
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254726#4254726
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254726
15 years, 4 months
[jBPM Users] - Re: workflow design about wait states
by mmusaji
"kukeltje" wrote :
|
| You use async but do you have a job executor in your unit test? If not, the jobs are never executed and your custom nodes are never executed
|
|
They are executed. I can see that in the output as well as in the objects when I retrieve them. Using the job executor before didnt work correctly as the jobs were being executed sync not async.
Here's a bit of the output to show the job executing
| 12:33:44,091 FIN | [BaseJbpmTestCase] === starting testSimple =============================
| Parsing process Request
| 12:33:45,419 FIN | [ExecuteActivity] executing activity(evaluate parse result)
| process ID: PROCESS_ID 001
| 12:33:45,451 FIN | [ExecuteActivity] executing activity(find providers)
| Finding Providers
| 12:33:45,451 FIN | [ExecuteActivity] executing activity(fork)
| 12:33:45,466 FIN | [DefaultIdGenerator] generated execution id process.112.validate one
| 12:33:45,466 FIN | [ExecutionImpl] created execution[process.112.validate one]
| 12:33:45,466 FIN | [JobExecutorMessageSession] sending message ExecuteActivityMessage
| 12:33:45,466 INF | [JobExecutorThread] starting...
| 12:33:45,466 INF | [JobExecutorThread] starting...
| 12:33:45,466 INF | [DispatcherThread] starting...
| 12:33:45,466 INF | [JobExecutorThread] starting...
| 12:33:45,466 FIN | [DefaultIdGenerator] generated execution id process.112.validate two
| 12:33:45,466 FIN | [ExecutionImpl] created execution[process.112.validate two]
| 12:33:45,466 FIN | [JobExecutorMessageSession] sending message ExecuteActivityMessage
| 12:33:45,482 FIN | [DefaultIdGenerator] generated execution id process.112.validate three
| 12:33:45,482 FIN | [ExecutionImpl] created execution[process.112.validate three]
| 12:33:45,482 FIN | [JobExecutorMessageSession] sending message ExecuteActivityMessage
| 12:33:45,482 FIN | [AcquireJobsCmd] start querying first acquirable job...
| 12:33:45,482 FIN | [AcquireJobsCmd] locking jobs []
| 12:33:45,482 FIN | [GetNextDueDateCmd] getting next due date...
| 12:33:45,482 FIN | [GetNextDueDateCmd] next due date is null
| 12:33:45,482 FIN | [DispatcherThread] DispatcherThread will wait for max 600ms on org.jbpm.pvm.internal.jobexecutor.JobExecutor@171194d
| 12:33:45,482 FIN | [DispatcherThread] DispatcherThread woke up
| 12:33:45,482 FIN | [AcquireJobsCmd] start querying first acquirable job...
| 12:33:45,482 FIN | [AcquireJobsCmd] locking jobs [109]
| 12:33:45,482 FIN | [DispatcherThread] pushing jobs on the queue [109]
| 12:33:45,482 FIN | [DispatcherThread] added jobs [109] to the queue
| 12:33:45,482 FIN | [JobExecutorThread] took job(s) [109] from queue
| 12:33:45,482 FIN | [AcquireJobsCmd] start querying first acquirable job...
| 12:33:45,498 FIN | [ExecuteJobCmd] executing job ExecuteActivityMessage[109]...
| 12:33:45,498 FIN | [AcquireJobsCmd] locking jobs [110]
| 12:33:45,498 FIN | [DispatcherThread] pushing jobs on the queue [110]
| 12:33:45,498 FIN | [DispatcherThread] added jobs [110] to the queue
| 12:33:45,498 FIN | [AcquireJobsCmd] start querying first acquirable job...
| 12:33:45,498 FIN | [AcquireJobsCmd] locking jobs [111]
| 12:33:45,498 FIN | [JobExecutorThread] took job(s) [110] from queue
| 12:33:45,498 FIN | [DispatcherThread] pushing jobs on the queue [111]
| 12:33:45,498 FIN | [DispatcherThread] added jobs [111] to the queue
| 12:33:45,498 FIN | [AcquireJobsCmd] start querying first acquirable job...
| 12:33:45,498 FIN | [JobExecutorThread] took job(s) [111] from queue
| 12:33:45,498 FIN | [AcquireJobsCmd] locking jobs []
| 12:33:45,513 FIN | [ExecuteJobCmd] executing job ExecuteActivityMessage[111]...
| 12:33:45,513 FIN | [ExecuteJobCmd] executing job ExecuteActivityMessage[110]...
| 12:33:45,513 FIN | [ExecuteActivity] execution[process.112.validate one] executes activity(validate one request)
| 12:33:45,560 FIN | [GetNextDueDateCmd] getting next due date...
| 12:33:45,576 FIN | [GetNextDueDateCmd] next due date is null
| 12:33:45,576 FIN | [DispatcherThread] DispatcherThread will wait for max 600ms on org.jbpm.pvm.internal.jobexecutor.JobExecutor@171194d
| 12:33:45,576 FIN | [ExecuteActivity] execution[process.112.validate two] executes activity(validate two request)
| 12:33:45,576 FIN | [ExecuteActivity] execution[process.112.validate three] executes activity(validate three request)
| 12:33:46,169 FIN | [DispatcherThread] DispatcherThread woke up
| 12:33:46,169 FIN | [AcquireJobsCmd] start querying first acquirable job...
| 12:33:46,169 FIN | [AcquireJobsCmd] locking jobs []
| 12:33:46,169 FIN | [GetNextDueDateCmd] getting next due date...
| 12:33:46,169 FIN | [GetNextDueDateCmd] next due date is null
| 12:33:46,169 FIN | [DispatcherThread] DispatcherThread will wait for max 600ms on org.jbpm.pvm.internal.jobexecutor.JobExecutor@171194d
|
I have output which is from the classes so i know for sure they are being executed.
I can't remove "async"... they need to run async. This is the problem I think of why the wait state cannot be found.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254725#4254725
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254725
15 years, 4 months
[EJB] - Re: Not able to Deploy Local ejbs across multiple ears
by anandlramadurg
I have found the work around for such scenario,
In JBoss, unlike Weblogic, you cannot deploy same local ejb with same local jndi name across multiple ears. ( However this is nowhere specified in ejb specification ).
Work around for such scenario in JBoss is,
While deploying local ejbs in JBoss, dont specify the jndi for ejbs ( i.e. Remove the jboss.xml file ). Server will assign a random jndi name to it.
Make use of ejb-local-ref in web.xml, just configure the ejb you want access in web.xml
<ejb-local-ref>
<ejb-ref-name>MySession</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local-home>mySessionlocalHOme</local-home>
mySessionLocal
<ejb-link>MySession</ejb-link> //give the same name here ( ejb name )
</ejb-local-ref>
This you have to do it in all ear files.
Regards
Anand
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254718#4254718
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254718
15 years, 4 months
[jBPM Users] - Re: workflow design about wait states
by kukeltje
"mmusaji" wrote : I'm working on a unit test, appreciate your feedback so far. I tried to do this before but because of the fork the unit test would always fail as the unit test thread would continue and fork would not be complete.
So? Your unittest fails because the behaviour of your app is not what you expect... Great, that is what unittests are for :-)
You use async but do you have a job executor in your unit test? If not, the jobs are never executed and your custom nodes are never executed
If you look at the examples in the source you can find these things out. As always, ttry to minimize the testcases. e.g. if you remove async on the custom nodes it might work. So you are more closer to the cause. That is debugging/troubleshooting etc.... ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254716#4254716
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254716
15 years, 4 months
[jBPM Users] - Re: workflow design about wait states
by mmusaji
My classes in the custom nodes do very little. I don't understand how these would have an impact on wait state which is after they execute.
| public class ValidateOneRequest implements ActivityBehaviour {
|
| private static final long serialVersionUID = 1L;
| ExperianDetails experianDetails;
|
| public void execute(ActivityExecution execution) throws Exception {
| Thread.sleep(2000);//simulate a delay in processing.
| OneDetails oneDetails= (OneDetails)execution.getVariable("oneDetails");
| oneDetails = update(oneDetails); //update the object in some way (change a name)
| execution.setVariable("oneDetails", oneDetails);
| }
| }
|
I'm working on a unit test, appreciate your feedback so far. I tried to do this before but because of the fork the unit test would always fail as the unit test thread would continue and fork would not be complete.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254711#4254711
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254711
15 years, 4 months