jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of EJB 3.0] - Re: Multiple .par files

[epbernard <nu...@jb...>]

you can put your "abstract" entities in the classpath and reference them in your .par file thruogh the  element

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

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

[Jboss-dev-forums] [Design of EJB 3.0] - Re: Using @Id to set autoicrement field

[msly <nu...@jb...>]

Thanks epbernard. 

For anyone else working with EJB3 you set this property in the persistance.xml file in your par archive for the entity beans.

Here is the file:

  | <?xml version="1.0" encoding="UTF-8"?>
  | <entity-manager>
  |   <name>survey</name>
  |   <jta-data-source>java:/jdbc/SybaseDB</jta-data-source>
  |   <properties>
  |     <property name="hibernate.hbm2ddl.auto"
  |               value="create-drop"/>
  |  <property name="hibernate.dialect" value="org.hibernate.dialect.SybaseAnywhereDialect"/>
  |     <!-- This is for ASE -->
  |     <!-- property name="hibernate.dialect" value="org.hibernate.dialect.SybaseDialect"/ -->
  |   </properties>
  | </entity-manager>

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

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

[Jboss-dev-forums] [Design of JBoss jBPM] - FieldInstantiator doesnt consider inherited fields.

[d_jiten <nu...@jb...>]

I have an actionHandler which is inherited from baseHandler. I use config-type=field in the xml definition. 
  | <event type="node-leave">
  |   <action name="updateWorkflowId" class="com.xx.UpdateHandler" config-type="field" >
  | 	<myBaseClassField>123</myBaseClassField>
  | </action>
  | </event>

Now i tried to set some fields of the base class and it wouldnt set it. When i looked at the source org.jbpm.instantiation.FieldInstantiator it uses the following method to get the fields. :
 Field f = clazz.getDeclaredField(propertyName);

If instead of this clazz.getField(propertyName) was used it could have got the inherited fields.  Is there any reason why this is not done ? Are there any side effects if i change the source to do it this way for my deployment.

Thanks,
Jiten


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

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

[Jboss-dev-forums] [Design of EJB 3.0] - Re: Hibernate NonUniqueObjectException when creating several

[epbernard <nu...@jb...>]

no this is not possible since the persistence context get track of the entity *instances* to manage their state changes

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

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

[Jboss-dev-forums] [Design of EJB 3.0] - Re: Automatically creating indexes

[epbernard <nu...@jb...>]

Hibernate will provide and @Index annotation in the next release.

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

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

[Jboss-dev-forums] [Design of EJB 3.0] - Re: Using @Id to set autoicrement field

[epbernard <nu...@jb...>]

http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#configuration-optional-dialects

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

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

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: Web Services for jBPM (cnt'd)

[aguizar <nu...@jb...>]

Consumption

Libraries: The only library required at compile time is saaj.jar. Runtime requirements vary depending on the actual SAAJ implementation. JBossWS requires the following libraries:
-axis-ws4ee.jar (JBossWS Axis base)
-jboss-ws4ee-client.jar (JBossWS additions to Axis)
-jboss-common-client.jar (JBoss Logger and other stuff)
-jaxrpc.jar (Axis dependency)
-activation.jar (SOAP Attachments use the JavaBeans activation framework)
-commons-discovery.jar (Axis dependency)
-jbosssx-client.jar (JBossWS dependency)
-commons-logging.jar (commons-discovery dependency)

Setup: Set the values of the ?javax.xml.soap.MessageFactory? and ?javax.xml.soap.SOAPConnectionFactory? system properties to the fully qualified names of the factory classes in your SAAJ implementation.

Production
SAAJ does not define a server programming model; JAX-RPC/WS4EE does. JAX-RPC lets you work at the SOAP message level through the handler mechanism.  The compile time dependencies are jaxrpc.jar and saaj.jar; runtime dependencies are irrelevant as this code runs inside the app server.

Inclusion in the project
Considering that most dependencies are specific to the implementation, we can add saaj.jar to the jbpm.3 classpath (jaxrpc.jar will be needed later for production) and develop the invoker in a new package (org.jbpm.webservices?). The implementation libraries are still needed for testing, so we can put them somewhere in the project outside of the class path and use a particular runtime configuration for these tests that includes those libraries.

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

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

[Jboss-dev-forums] [Design of EJB 3.0] - Re: Composite primary keys

[epbernard <nu...@jb...>]

mappedBy = "rolProceso" => mappedBy = "proceso"

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

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

[Jboss-dev-forums] [Design of EJB 3.0] - Re: @PrePersist Callback Problem

[epbernard <nu...@jb...>]

This bug has been fixed in CVS, will be released as part of the next version

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

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

[Jboss-dev-forums] [Design of EJB 3.0] - Re: Reassigned existing entities to other entities does not

[epbernard <nu...@jb...>]

don't copy the collection instance, add the entities to a new collection isntance.

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

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

[Jboss-dev-forums] [Design of EJB 3.0] - Re: Caching problems after tx rollback

[epbernard <nu...@jb...>]

What strategy?
What Cache provider?

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

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

[Jboss-dev-forums] [Design of JBoss Integration] - Re: Proposed Foundation for JBI

[<ovi...@jb...>]

anonymous wrote : The Message Core only becomes a bus when you put a broker in front of it e.g. for the jms facade, create channels that implement queues/topics and add them to the destination manager. 


For a JMS system, routing is external. The producer must decide what destination to use, so it uses the "broker" to mediate the transport of that message to the destination's receivers, by passing the message and the destination to the broker. A service plugged into an ESB shouldn't have to do this. It should simply pass the message to the bus and the bus should route the message to its destination based on arbitrary rules, most likely involving the abstract destination service definition or other message metadata. 

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

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

[Jboss-dev-forums] [Design of JBoss Integration] - Re: Proposed Foundation for JBI

[<ovi...@jb...>]

anonymous wrote :   For instance, a BC would not be able to acknowledge a message as received until it is pushed to NMR and NMR acknowledges the message is in its queue and persisted. Otherwise recovery would not be possible. 

Correct. But SE shares a thread with the application it acts as container for and BC is based on a synchronous protocol. If the component receives a positive acknowledgment from the NMR, everything is fine, if not it propagates the error back to the caller, either as an exception or an error code.


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

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

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Re: MDB pooling - JBAS-2047

[<ad...@jb...>]

You can already attach multiple invoker proxy bindings to an MDB.

e.g. you can get an MDB to listen to multple topic subscriptions (either from the same
jms server or different ones)

So I guess the solution would be to have a "template invoker proxy binding"
and add management methods to the MDB Container that lets you add/remove
invoker proxy bindings with specific overrides like your selector.

Such a solution would also apply to JCA1.5 with the "activation config properties".

Why don't you experiment?

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

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

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Re: MDB pooling - JBAS-2047

[genman <nu...@jb...>]

In terms of a priority for JBoss, probably it's not a general feature many people would use, but it makes MDBs more useful for processing requests where certain resources need to do the work for particular messages are slow or unavailable.

Alternatively, an easier way to dynamically deploy MDBs (with selectors) would be nice to have.  Then some sort of interceptor or whatever could deploy a new MDB instance/thread pool to do the work for a certain message.  I guess if you could take a deployed "template" MDB and via JMX deploy a "clone" with a different selector that would work well enough.


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

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

[Jboss-dev-forums] [Design of EJB 3.0] - DO NOT POST USER QUESTIONS HERE!

[<ad...@jb...>]

This forum is for design discussions on the implementation of JBoss's EJB3
not for help trying to use EJB3.

If you are looking for HELP use the EJB user forums

http://www.jboss.org/index.html?module=bb&op=viewforum&f=47

and read this

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossHelp

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

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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: what is supply/demand?

[<ad...@jb...>]

I think they could be used as aliases, but I haven't tried it to see whether this works,
I don't see why it shouldn't...


  | <bean ...>
  |     <property name="Something"><inject bean="LogicalName"/></property>
  | </bean>
  | <bean ...>
  |     <supplies>LogicalName</supplies>
  | </bean>
  | 


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

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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: what is supply/demand?

[<ad...@jb...>]

The intention of supply/demand is to provide a dependency on something
that is "not known" to the MC. I have not done any extensive testing on this
feature yet (other than the proof of concept classloading dependency tests).

It works with the KernelRegistryPlugin to see whether the thing exists.

You could for example register a POJO that implements KernelRegistryPlugin
to do lookups on JNDI to see whether the binding exists.

  | public JNDIRegistryPlugin implements KernelRegistryPlugin
  | {
  |    public KernelRegistryEntry getEntry(Object name)
  |    {
  |        try
  |        {
  |           Object o = context.lookup((String) name);
  |           return createRegistryEntry(name, o);
  |        }
  |        catch (NameNotFoundException e)
  |        {
  |             return null;
  |        }
  |    }
  | }
  | 

Then use it in a demands

  | <bean ...>
  |     <demands>jnp://remotehost:1099/something</demands>
  | </bean>
  | 

The supplies is so you can have abitrary dependency names without
having to create a registry plugin...

  | <bean ...>
  |     <demands>LogicalName</demands>
  | </bean>
  | <bean ...>
  |     <supplies>LogicalName</supplies>
  | </bean>
  | 

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

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

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: HARDeployer removal proposal

[<ste...@jb...>]

"sco...@jb..." wrote : The lack of an instant reply does not neccessarily mean lack of interest.
Understood.  Had simply realized that I had been a bit scatter-brained in some of my responses; just wanted to pull them all together.

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

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

[Jboss-dev-forums] [Design of Security on JBoss] - Generalizing the JAAS/Authentication Service

[<sco...@jb...>]

In addition to generalizing the authorization layer, we also need to generalize the authentication layer and have a well defined SSO framework that can be used across JEMS.

The JSR-196 (Java Authentication SPI for Containers) draft has finally seen the light of day and so authentication will also be a better defined as a pluggable aspect of a j2ee container. There is no notion of SSO in this spec however, so as part of update the authentication service to support JSR-196, we also need to consider how SSO via standards such as SAML and Liberty are going to be supported.


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

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

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: HARDeployer removal proposal

[<sco...@jb...>]

The lack of an instant reply does not neccessarily mean lack of interest.

An interface is not necessarily needed, and in general is not useful as the service layer deals with mbeans, not instance implementation.

It would be that the service exposed such an attribute on the mbean interface. The xmbean deployment already has similar notions for a service that wants to know its MBeanService and ObjectName without having to subclass ServiceMBeanSupport. This is handled via reflection rather than an interface contract as the xmbean container is driven by attributes on descriptor rather than interfaces on the pojo.

However, I think this is better handled as an extended service lifecycle event such as init(DeploymentInfo).  The DeploymentInfo could be made available to the ServiceController/ServiceConfigurator either explicitly, or via a MainDeployer query if its not already there. 


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

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

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: HARDeployer removal proposal

[<ste...@jb...>]

So to be completely clear...

I totally agree with you that it is completely silly having a ~400 line class (HARDeployer) whose sole resposibility is to set a single MBean attribute (just look at my comments in HARDeployer ;).  If there were some other simple way for an MBean to know about the DeploymentInfo (or even just the DeploymentInfo.url) from whence it came, I'd be all for using that instead of a full deplyer.  But in my limited knowledge of the AS internals, there does not seem to be such a simple alternate approach.  Please, if I am wrong, correct me.

In the end, I think the "aggresive scanning" of the deployment classpath entries is very, very good idea.  But based on the previous discussion regarding multiple SessionFactoys, I think it makes sense as an option on the MBean rather than as the defacto way in which mappings are discovered.


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

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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - what is supply/demand?

[<bil...@jb...>]

Are they aliased dependencies?

Thanks

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

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

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: HARDeployer removal proposal

[<ste...@jb...>]

So I guess something like this is not possible/desireable...

I think we need to ditch this attempt to remove the HARDeployer by reading classpath info.  Losing the ability to deploy multiple segmented SessionFactories from within the same top-level deployment is unacceptable.

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

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

[Jboss-dev-forums] [Design of EJB 3.0] - Re: Multiple databases - one entity bean class

[<bil...@jb...>]

That's because "java:/managedEntityFactory...." is for INTERNAL USE ONLY!

The next release will provide a way to lookup ENtityManager, ENtityManagerFactory in global JNDI.

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

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