jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Re: JBAS-993 broke the dependency contract

[<ale...@jb...>]

Then the only way to fix the dependency issue I see is to to move PM initialization to EntityContainer.createService and PM start to EntityContainer.startService. So that the first container to start will start all the PM's in the module, not the last container like it has been until now.
But this will reopen JBAS-993 again.
Other alternatives I can think of are broken in some way.

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

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

[Jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-2499 Configurable Policy to Elect HASingleton Maste

[<bst...@jb...>]

Great. Thanks :-)

If the user doesn't inject an HASingletonElectionPolicy, will HASingletonController default to creating an instance of HASingletonPolicySimple with a position of 0?


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

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

[Jboss-dev-forums] [Design of POJO Server] - VDF deployer update

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

I have gone through the system2 (can be checked out as part of the jbossmc cvs alias or this eclipse project set: http://fisheye.jboss.com/viewrep/JBoss/build/mc/eclipse.psf) and updated the vdf prototype to align with the two phase deployment model we talked about in JBW that is needed for use with the profile service.

As part of this I went over the existing vdf discussion and jira items (see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=58404) and I have the following changes to discuss:

1. I don't see a need to separate structural deployers from runtime deployers.  In the previous discussion there was a notion that the structural phase would run a separate deployer stack and that the first deployer that recognized the deployment would win. With the extension of the structural phase to one that essentially parses a physical deployment info metadata that supports the profile service configuration and management view behaviors, essentially every deployer can contribute both forms of metadata to a deployment. 

2. Related to this, a DeploymentContext (the object representation of a subdeployment) does not have an associated AspectDeployer. Instead there is a set of deployment types that identify the AspectDeployer that contributed to the metadata and will want to process this context at runtime.

3. The org.jboss.deployers.vdf package which essentially was the virtual file system concept has been replaced with the existing container org.jboss.vfs.* classes. A DeploymentContext has a VirtualFile rather than a VDFComponent.

4. The notion of deployer suffixes in this vdf deployer scheme seems a legacy bootstrap notion at best. The org.jboss.deployers.plugins.MainDeployerImpl externalizes the notion of how a deployment is started to a org.jboss.deployers.spi.DeploymentGraphBuilder which returns a Graph that is a directed graph of the deployment contexts. A depth first traversal of this graph with execution of each deployer that matches the DeploymentContext registered deployment types defines the deployment processing.

The deployment order can therefore be based on the legacy structure/suffix notion, explicit deployment unit/context ordering, ...

5. The JARDeployer notion seems obsolete. The deployment structure is handled by vfs, ClassloaderDeployer, and the deployers themselves. 

6. In addition to breaking the AspectDeployer into two distinct phases, there is a notion of a manged object that represents the view a management client would use to update a deployment. This ties into the profile service support for being able to update a deployment in a profile without having a running jboss instance. This is the biggest implementation change to deployers as currently the management interface is an implicit detail based on the jmx beans that happen to show up.

I'm still working on getting this update to the state of actually deploying mc beans and integrating with the profile service. After that getting the other deployers ported over to the vdf needs to be done to fully flesh this out.


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

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

[Jboss-dev-forums] [Design of JBoss ESB] - Re: Looking for a real life ESB transformation example

[tfennelly <do-...@jb...>]

Dave, do you need this for something real??

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

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

[Jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-2499 Configurable Policy to Elect HASingleton Maste

[AlexFu.Novell <do-...@jb...>]

The code change has been checked in. The sample configuration can be found at: testsuite/src/resources/ha/electionpolicy/META-INF/jboss-service.xml.

A HASingleton mbean will look like this:

  |    <mbean code="org.jboss.ha.singleton.examples.HASingletonMBeanExample" 
  |           name="jboss.examples:service=HASingletonMBeanExample_1">
  |    </mbean>
  | 
  |    <mbean code="org.jboss.ha.singleton.HASingletonElectionPolicySimple"
  |           name="jboss.examples:service=HASingletonMBeanExample-HASingletonElectionPolicySimple_1">
  |      <attribute name="Position">0</attribute>
  |    </mbean>
  | 
  |    <mbean code="org.jboss.ha.singleton.HASingletonController" 
  |           name="jboss.examples:service=HASingletonMBeanExample-HASingletonController_1">
  |       <depends>jboss:service=${jboss.partition.name:DefaultPartition}</depends>   
  |       <depends>jboss.examples:service=HASingletonMBeanExample_1</depends>
  |       <depends optional-attribute-name="HASingletonElectionPolicyMBean"
  |          proxy-type="attribute">jboss.examples:service=HASingletonMBeanExample-HASingletonElectionPolicySimple_1</depends>
  |       <attribute name="PartitionName">${jboss.partition.name:DefaultPartition}</attribute>
  |       <attribute name="TargetName">jboss.examples:service=HASingletonMBeanExample_1</attribute>
  |       <attribute name="TargetStartMethod">startSingleton</attribute>
  |       <attribute name="TargetStopMethod">stopSingleton</attribute>
  |       <attribute name="TargetStopMethodArgument">true</attribute>
  |    </mbean>
  | 


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

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

[Jboss-dev-forums] [Design of JBoss Collaboration Server] - Re: MailListener should return null or a message?

[<go...@ic...>]

If the to doesnt exists in JBCS, if you mean "rcpt to:", then the JBCS should reject the mail sending attempt with i think a 550 error

haven't looked at nukes, but your right, that seems logical way to go

what happens when you add the nukes listener and then the JMS listener, wonder if JMS errors as your seeing.

mails from a specific address should be processed differently? hmmm, that shouldnt be hard, you could...

if message is special, stick on special queue
if message not special, dont stick it on the localDelivery queue

I imagine then, it would not get delivered....

Might work

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

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

[Jboss-dev-forums] [Design of JBossCache] - Re: Security for JBossCache?

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

This really just should be the same authentication aspect that is applied to ejb3 to obtain the current current caller context, along with whatever authorization interceptor applies to the call. I should not need a wrapper to introduce jms/jdbc type of connection based authentication. We don't need this for ejbs, and we should not need it in general.

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

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

[Jboss-dev-forums] [Design of JBossCache] - Re: Security for JBossCache?

[genman <do-...@jb...>]

You'd need to create some sort of "connect" facility, something along the lines of what's used for JMS or the database.

The Cache itself would have a security interceptor that would check that the principal was set, then match the roles/etc. against the permissions for modifiying or reading nodes in a particular region.

Here's one idea:

  | Cache cache = (Cache)new  
  |    InitialContext().lookup("java:comp/env/mycache");
  | cache.connect("joe", "secret");
  | cache.get("foo", "key1");
  | // 
  | cache.logout();
  | 

Alternatively, to keep the cache interface small, maybe a wrapper?

  | cs = new CacheSecurity(cache);
  | cs.connect("joe", "secret");
  | cs.logout();
  | 

The security association would be kept in a thread local. One thing that is sort of bad is that the association might leak without the logout called each time. Maybe this would be more robust:


  | public interface SecureCache extends Cache {
  |   public void connect(String user, String pw) throws CacheSecurityException;
  |   public void logout();
  | }
  | SecureCache c = SecureCacheFactory.lookup("java:comp/env/mycache");
  | cs.connect("joe", "secret");
  | cs.logout();
  | 

Each "SecureCache" would be a simple wrapper around a regular cache. This way, the assocation would be matched against the instance variable. Also, if the cache in JNDI was accessed in the normal way, it would fail.

One fine point would be to have the allowed roles and regions set in the connect method and the interceptor would simply do the method checks.


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

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

[Jboss-dev-forums] [Design of JBoss Build System] - common-jdk5 version

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

There are some utility classes like the graph classes in the jbossbuild module that I would like to move into common, and update to support generics. Some of the existing util classes should be updated with jdk5 implementations and generic support as well. 

Once we get the current svn refactored, we should create a 2.0 branch (or make it the trunk) for this. The current refactored code should be under a 1.0 branch.


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

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

[Jboss-dev-forums] [Design of JBossCache] - Re: [JBCACHE-669] Enable data gravitation for PojoCache inte

[<man...@jb...>]

Hmm, SFSB and HTTP state replication is the primary use case for BR.  And the (soon to be) default way of doing is this with fine grained repl, using PojoCache.  

This combo should not break down otherwise it beats the point of us doing this.

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

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

[Jboss-dev-forums] [Design of JBossCache] - Re: PojoCache 2.0 Interface

[<man...@jb...>]

yeah, thats how it is in 1.4, which is crap.

in 2.0.0, I'm going to add a static call on InvocationContext to get the current context.  So you'd just do:

InvocationContext.getCurrentContext() which returns an instance of the current invocation context.

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

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

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: Ordering of .ear subdeployments

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

Sounds ok, but we need testcases for both the suffix based odering and the application.xml based ordering that validate deployments are started in the expected order in both cases.

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

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

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Re: JBAS-993 broke the dependency contract

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

It does not match our service life cycle contract in that a service is generally not usable until its started and the dependent service has its start called.

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

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

[Jboss-dev-forums] [Design of JMX on JBoss (JBoss/JMX)] - Re: How are the Notifications send in ServiceController hand

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

The usecase is illustrated by the current jsr77 implementation. Originally this was a tightly coupled feature of the deployers. Now the deployers simply emit their state change notifications and the jsr77 implementation is layer on top that builds the jsr77 tree.

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

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

[Jboss-dev-forums] [Design of JMX on JBoss (JBoss/JMX)] - Re: Can MainDeployerMBean call the deploy directly ?

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

The reason for using the typed proxy is that we believe that code is more readable/understandable when the proxy is used. Otherwise you are using a reflective type call every time an invocation is done, as opposed to a typed proxy.

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

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

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: compilation problem in head

[<tom...@jb...>]

...97...98...99.... 100 !

BTW: The dutch just can't handle a good beer.  They're used to #SENSORED# !  And #BEEEEP# dutch soccer #BEEEEEEEEEP#

damn... now i have to start all over again

1...2...3...

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

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

[Jboss-dev-forums] [Design of Persistence on JBoss] - Entity - how dynamically change mapped table database schema

[kmrol <do-...@jb...>]

I have an Oracle database with multiplies oracle schemas. Every oracle schema represent a project. All projects contain tables with same structure but have different data. 
Now we're using ejb2.1 bmp entity beans to represent a data.
every finder method have a "project" parameter to modify sql:
"select ... from " +project+".table ..."

Could anyone tell me how to achive the same result using CMP EJB3?
That is how to dynamically change database schema while calling find() and other methods...

Thanx!

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

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

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: compilation problem in head

[kukeltje <do-...@jb...>]

ok, you asked for it..... 

BELGIUM WASN'T EVEN AT THE WORLD CHAMPIONSHIP FOOTBALL

Or

BELGIUM BEER SUCKS

Oh, ant by the way, say 100 hail mary's to get be free of sins again

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

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

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: Aop field interceptor to provide filtering for method ca

[<kab...@jb...>]

Hmmm, I'm not getting you, please elaborate.

BTW the interceptor I outlined was for field interception, and would be used only for a field for a particular instance. I see now that it was a bit too simple. It should really be scoped PER_JOINPOINT, so that the "done" book-keeping is only done for a particular field. Now, this is not possible with the existing InstanceAdvisor API, since per instance aspect added there apply to ALL joinpoints. However, with the new AOP 2 weaving this is possible. Take a look at 
org.jboss.test.aop.dynamicgenadvisor.DynamicTester to see how this works.

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

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

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: compilation problem in head

[<tom...@jb...>]

anonymous wrote : Please don't feel picked on. 

I feel i SHOULD be picked on !

:-)


btw, i now see the java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory as well.  I'll clean up...

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

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

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: Aop field interceptor to provide filtering for method ca

[<ben...@jb...>]

Sounds good. But we need to consider the following calling stack:


  | pojo.methodA();
  | pojo.methodB();
  | ...
  | pojo.methodB(); // so we can skip this field interception
  | pojo.methodA(); // oops, it will fail.
  | 

So in essence, we need to have a local thread array done[] such that this will work properly. 

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

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

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: compilation problem in head

[jimrigsbee <do-...@jb...>]

Tom,

Please don't feel picked on.  We've all made CVS check-in errors, it's easy to do!  

Thanks for looking into this.  I can build in Eclipse now :)  I'm having a little problem with the command line build at the very end (line 36), will research and get back to you...it's complaining that LogFactory is not there CNF but it is...

Cheers,
Jim

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

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

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: Aop field interceptor to provide filtering for method ca

[<kab...@jb...>]

I think the simplest approach is to have an interceptor at the start of the chain, which manages this.


  | public class ReentrancyStopperInterceptor implements Interceptor
  | {
  |    ThreadLocal done = new ThreadLocal();
  |    
  |    private Object invoke(Invocation invocation) throws Throwable
  |    {
  |       boolean wasDone = ((Boolean)done.get()).booleanValue();
  | 
  |       try
  |       {
  |          if (!wasDone)
  |          {
  |             done.set(Boolean.TRUE);
  |             return invocation.invokeNext();
  |          }
  |          else
  |          {
  |              //Needs adding, and will invoke target joinpoint skipping the rest of the chain
  |             return invocation.dispatch(); 
  |          }
  |       }
  |       finally
  |       {
  |          if (!wasDone)
  |          {
  |             done.set(Boolean.FALSE);
  |          }
  |       }
  |       
  |       return ret;
  |    }
  | }
  | 

I could implement the new dispatch() method pretty quickly, and I think this interceptor should belong in the aop module.

Similar functionality _could_ be added to the woven bytecode, but I don't think it is a good idea to code use-case stuff in there. 


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

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

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: compilation problem in head

[<tom...@jb...>]

i screwed up with my cvs synchronization somehow.

i just resynchronized (as i thought i had done before) and some changes showed up.

- i merged the execute and returnvalue method on the commands
- and a slightly refactoring of the expression evaluation methods.

please try to be less mean as i would be with you when you screw up like this :-)

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

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

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: Ordering of .ear subdeployments

[vickyk <do-...@jb...>]

anonymous wrote : I was thinking of using the DeploymentInfo.context map with a "comparator" key. If you want these as explicit fields then your right that two fields are needed. 
I don?t think providing the explicit information regarding the deployment sorter in the DeploymentInfo will be helpful , I can think of the use case doing this.
Anyway Can I make the changes in the following files? 
1) DeploymentInfo .java , will add two fields as specified by the Dimitiris , yes we go for explicit information .
2) MainDeployer.java , here I will have to do the optimization for the 5 times sorting 
3) EARDeployer.java  , here I will have to set the flag indicating that the sorting has been done .


Regards
Vicky

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

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