[JBoss Web Services Users] - web services and virtual hosts (jbossws 3.0.5 on AS4.2.2)
by brettcave
theres a few topics on this, and doesn't seem to be resolved yet, although jbossws-native 3.0.3 addressed the issue - is there perhaps a step missing, or is this an issue with a component other than just jbossws (ejb2.1 endpoints?)
1) upgrade jboss to jbossws-native 3.0.5 and restart (all libs and the jbossws.sar updated in deploy)
2) update libraries in my project classpath (ide and compile cp's) - specifically jbossws-spi.jar for the annotations (jaxb-api stays the same). recompile and redeploy project.
jboss-web.deployer/server.xml:
<Host name="my.virtual.host"
| ......>
| <Alias>my.virtual.host.name</Alias>
| <Alias>my.virtual.host.name:80</Alias>
| <Valve ... />
| </Host>
|
The default "localhost" virtualhost is still configured, and listens on 0.0.0.0:8080 to all headers excluding the virtualhost aliases above.
MyWSBean.java (seam 2.1.1):
@Name("myWS")
| @Stateless()
| @WebContext(virtualHosts = {"my.virtual.host"}, contextRoot = "/services")
| @WebService(name="myWS", serviceName="myWS")
| public class MyWSBean {}
|
See theres a few jira issues about this, assuming there is no working for jboss 4? (5.0.1 is resolved).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267270#4267270
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267270
14 years, 10 months
Re: [jboss-user] Hibernate proxy class problem
by samk＠twinix.com
See Thread at: http://www.techienuggets.com/Detail?tx=15288 Posted on behalf of a User
Hi,
did you resolve your issue?
I have the same problem and am searching for a solution to solve it?
Best Regards,
Sascha
In Response To:
Hi,
I'm having the following odd situation:
| @Entity
| @Inheritance(strategy = InheritanceType.JOINED)
| public abstract class Customer { @Id private int id; }
|
| @Entity
| public class SomeCustomer extends Customer { private String name; }
|
I'm using Entity Manager to retrieve entities by their primary key:
| entityManager.find(Customer.class, 5);
|
The primary key 5 belongs to a SomeCustomer entity. It's in the id field of both Customer and SomeCustomer tables (due to join inheritance). However, the query returns an object that has the type Customer_$$_javassist_16 that cannot be cast to SomeCustomer (ClassCastException).
However, if I execute the following query:
| entityManager.find(SomeCustomer.class, 5);
|
I will see a warning in my logfile: ProxyWarnLog: Narrowing proxy to class SomeCustomer - this operation breaks ==
Subsequent call to the first find() query will now also return the right object of the right type.
Does anybody know what's going on here or how I can manually narrow down my proxy object to what I want to have if it fails?
Thanks a lot,
Georges
14 years, 10 months
[jBPM Users] - Re: How to use timers?
by mauromol
Thank you Martin, you actually helped me and I got it to work!!
I'm going to summarize it up because I think that certain things are not so intuitive for a "jBPM scheduler"-newbie like me.
First of all, the default implementation of the scheduler service, provided by jBPM, is DbSchedulerServiceFactory, which uses the database to store information about scheduled actions associated with timers. This means that a database is needed even to write a simple JUnit test case that uses timers and this justifies the need to deploy your process definition (it's needed to store the related timers and timer jobs in the database, as well). I would assume that a different scheduler service implementation could be made to avoid the use of a database, however let's talk about the default implementation.
Even if a database is needed, there's no need to extend AbstractDbTestCase, which provides many methods to create and clean the schema and to interact with the database. In fact, in the simplest case, jBPM (thanks to Hibernate) will create automatically an in-memory database for you when you go to deploy your process definition and/or schedule a timer action. In this case, however, you should take care of the db lifecycle, however I think (but I may be wrong) that if you destory the jbpmConfiguration (by calling close) the in-memory db will be destroyed too...
Anyway, in my case I was running an only test method, so it's not so important how the db is handled between multiple test methods invocations.
In my previous example (TRIAL 2) timer actions were correctly saved in the database by the DbSchedulerServiceFactory, but they were not executed because no JobExecutor thread was started. The JobExecutor thread is actually a thread that periodically reads from the database, searching for saved timer actions (jobs) and executes them.
So, if I change my test case by calling jbpmConfiguration.startJobExecutor() just after the configuration creation, I make sure that the "scheduler" is started. Actually, I would rather say that there is no scheduler to start, but that the default scheduler service implementation expects that a JobExecutor thread is present to execute timer actions. In other words, the JobExecutor is itself part of the default scheduler service implementation. I think that this only sentence would be enough to say that my original problem is not so stupid as kukeltje says and that the documentation could be drastically improved on this subject (I'm also wondering what is http://docs.jboss.com/jbpm/v3.2/userguide/html_single/#schedulerdeployment all about!?).
Anyway, this is not enough, because another action is needed in order to make the JobExecutor run timer actions in my test case: just after the signal invocation, that moves my process instance to the waiting state (with attached timer), I have to close the jBPM context in order to commit things (the deployed process definition, the process instance state and the related saved timers and jobs), otherwise the JobExecutor, which works on another thread, wouldn't find anything to executoe. Having the whole scenario cleared, this sounds reasonable and obvious, but I think it might not be so straight away for a first time user that is writing a simple JUnit test case. Using the AbstractDbTestCase class mentioned by Martin, this would be automatically achieved because the method processJobs(long) does a "commit" before starting the JobExecutor.
Thank you again Martin and please correct me if I've written something wrong.
Anyway, if this is considered to be a simple answer to a basic question (as kukeltje said)... well, I'm wondering why kukeltje couldn't write it himself: he would have certainly spent much less time that writing his two previous smart posts, as Martin's kind answer demonstrated.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267259#4267259
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267259
14 years, 10 months