AS test case weirdness....
by Max Rydahl Andersen
Hi Rob et.al.,
I had "fun" with WTP server modules today - or maybe it was our
implementation that was weird...in any case I created a ASTestCase which
tries to verify the classpath behavior.
And Rob, it is truly weird. If I only create *one* runtime then things
work...but if I create more than one weird things happen.
It also seem like WTP (or our impl) creates duplicate runtimes (with
same id's) when you do not pass an id in from the get-go..don't know if
the UI does that, but the javadoc says it should be fine since it uses
autogenerated ids.
Anyway - Marshall also added a jbossas dir to the testsuite so tests now
can use jbossas to have fun with. See
http://jira.jboss.com/jira/browse/JBIDE-855 for details.
Rob - take a look and tell me if i'm crazy or I or WTP is just doing
things wrong....
/max
17 years, 3 months
Seam perspective...
by Max Rydahl Andersen
Hi guys,
I've rearranged the seam perspective a bit.
e.g. included Project Explorer in the left part since it has both Seam
components and option of showing the structure of any file we support
via xmodel.
In that process I also moved Seam component view to the bottom - should
we include it all now when Project Explorer can show it ?
I also included both JBoss Server View and Servers view. I wanted to
just have Jboss Server View there but then realized that it does not
include the "status" column for the servers.
Rob - any reason why the bottom part isn't just children of the servers
directly ?
/max
17 years, 3 months
Proper Email Lists
by Rob Stryker
We recently (few weeks ago?) moved all JIRA issues over to JBoss Tools,
the public JIRA board, from EXIN-xyz.
Is it also about time we move most discussion back to
jbosstools-dev(a)lists.jboss.org?
- Rob
17 years, 3 months
Re: [jbosstools-dev] Re: [Fwd: [jbosstools-commits] JBoss Tools SVN: r2969 - trunk/seam/plugins/org.jboss.tools.seam.core/src/org/jboss/tools/seam/internal/core/el.]
by Max Rydahl Andersen
> From yesterday we have excluded the scopes from the Seam EL content assist processor by your comments and requirement.
yes - saw that. Thanks.
> This was true only when we edit some component's java file and we have a scope. For all other cases (xml, xhtml, jsp and so on) we have no scope defined, so we didn't use it.
Got it.
> Previously Slava (because the SeamProject utility had been used to get the project variables and Slava is responsible for it) did this filtering using the scope of component.
> The search rules was based on context search priority (See "3.1.9.
Context search priority" in
http://docs.jboss.com/seam/2.0.0.B1/reference/en/html/concepts.html#d0e2517).
Yes - these are all default runtime lookups rules but at a given point a
component can be access and at that time the method can have access to
all of these scopes, and the context search priority just defines which
order things will be looked up in...and that means all scopes and
variables are available.
> Again, for now the scope isn't used anymore and all the project variables are used as possible proposal (the following filtering goes to the EL prefix and resolved type).
thanks.
/max
> Victor
>
>> -----Original Message-----
>> From: Max Rydahl Andersen [mailto:max.andersen@redhat.com]
>> Sent: Thursday, August 09, 2007 4:22 PM
>> To: ruby(a)exadel.com
>> Cc: jbosstools-dev(a)lists.jboss.org
>> Subject: Re: [jbosstools-dev] Re: [Fwd: [jbosstools-commits] JBoss Tools
>> SVN: r2969 -
>> trunk/seam/plugins/org.jboss.tools.seam.core/src/org/jboss/tools/seam/in
>> ternal/core/el.]
>>
>>
>>
>> btw. in short, any variable is available in any place in Seam 1.2.
>>
>> In Seam 2 Gavin has started to add the concept of imports which will
>> become relevant in filtering of possible completions - something we need
>> to look into supporting down the road.
>>
>> But for now I don't understand what scope rules you are using to define
>> the filtering ...since there are none afaik.
>>
>> /max
>>
>>> Victor V. Rubezhny wrote:
>>>> Hi Max,
>>>>
>>>> 1. The scope is playing the role in completions, IMHO, due to prevent
>>>> usage of variables defined in scope, that is "invisible" to the
>>>> component as well as run-time variable "visibility" problems.
>>>>
>>>> Currently the scope is used only for the components. In other cases
>>>> (f.e. while editing components.xml or some jsp-/xhtml-file) the scope
>>>> cannot be used (this means "is not used") to filter the variables (the
>>>> proposals are collected regardless of the scopes).
>>>>
>>>> But for the component, IMHO, it's important to give only valid
>>>> proposals (the variables that are visible within the
>> component's scope).
>>> I don't follow this; what scoping rules are you using to define this ?
>>>
>>> e.g. if you have a component with default scope Conversation
>> then inside
>>> one of its methods e.g. doSomething() we have a log statement referring
>>> to #{someVariable} that "someVariable" is resolved at *runtime*
>>> completely independent of the components default scope.
>>>
>>> Meaning depending on what runtime context that method is
>> invoked in seam
>>> looks up through the current active scopes and that can be essentially
>>> be *all* possible scopes.
>>>
>>>> 2. I understand and agree that the sorting of proposals depending on
>>>> their scope is right and usefull thing. But there is no guarantee that
>>>> the proposals will not be re-sorted after SeamELContentAssistProcessor
>>>> returns them to Content Assistant.
>>> Why not ? Proposals has a ordering/priority flag afaik...or is that not
>>> true for xml completions ?
>>>
>>> /max
>>>
>>>> Victor
>>>>
>>>>> -----Original Message-----
>>>>> From: Max Rydahl Andersen [mailto:max.andersen@redhat.com]
>>>>> Sent: Thursday, August 09, 2007 1:06 AM
>>>>> To: jbosstools-dev(a)lists.jboss.org; Viktor Rubezhny
>>>>> Subject: [Fwd: [jbosstools-commits] JBoss Tools SVN: r2969 -
>>>>>
>> trunk/seam/plugins/org.jboss.tools.seam.core/src/org/jboss/tools/seam/in
>>>>> ternal/core/el.]
>>>>>
>>>>>
>>>>> Hi Victor,
>>>>>
>>>>> I just noticed this one being committed:
>>>>>
>>>>> "http://jira.jboss.com/jira/browse/JBIDE-670 xhtml code completion
>>>>> does not update it's list of completions
>>>>>
>>>>> Seam scope usage is fixed."
>>>>>
>>>>> and project.getVariablesByScope(scope, true); used in context of code
>>>>> completion...(before it was getVariablesByScope(scope);)
>>>>>
>>>>> Why is scope playing a role here in completions ?
>>>>> Scope can't be used to filter the list of possible matches - in the
>>>>> best case it can be used to *order* the list of completions.
>>>>>
>>>>> /max
>>>>>
>>>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
17 years, 3 months
Re: [Fwd: [jbosstools-commits] JBoss Tools SVN: r2969 - trunk/seam/plugins/org.jboss.tools.seam.core/src/org/jboss/tools/seam/internal/core/el.]
by Max Rydahl Andersen
Victor V. Rubezhny wrote:
> Hi Max,
>
> 1. The scope is playing the role in completions, IMHO, due to prevent usage of variables defined in scope, that is "invisible" to the component as well as run-time variable "visibility" problems.
>
> Currently the scope is used only for the components. In other cases (f.e. while editing components.xml or some jsp-/xhtml-file) the scope cannot be used (this means "is not used") to filter the variables (the proposals are collected regardless of the scopes).
>
> But for the component, IMHO, it's important to give only valid proposals (the variables that are visible within the component's scope).
I don't follow this; what scoping rules are you using to define this ?
e.g. if you have a component with default scope Conversation then inside
one of its methods e.g. doSomething() we have a log statement referring
to #{someVariable} that "someVariable" is resolved at *runtime*
completely independent of the components default scope.
Meaning depending on what runtime context that method is invoked in seam
looks up through the current active scopes and that can be essentially
be *all* possible scopes.
> 2. I understand and agree that the sorting of proposals depending on their scope is right and usefull thing. But there is no guarantee that the proposals will not be re-sorted after SeamELContentAssistProcessor returns them to Content Assistant.
Why not ? Proposals has a ordering/priority flag afaik...or is that not
true for xml completions ?
/max
>
> Victor
>
>> -----Original Message-----
>> From: Max Rydahl Andersen [mailto:max.andersen@redhat.com]
>> Sent: Thursday, August 09, 2007 1:06 AM
>> To: jbosstools-dev(a)lists.jboss.org; Viktor Rubezhny
>> Subject: [Fwd: [jbosstools-commits] JBoss Tools SVN: r2969 -
>> trunk/seam/plugins/org.jboss.tools.seam.core/src/org/jboss/tools/seam/in
>> ternal/core/el.]
>>
>>
>> Hi Victor,
>>
>> I just noticed this one being committed:
>>
>> "http://jira.jboss.com/jira/browse/JBIDE-670 xhtml code completion does
>> not update it's list of completions
>>
>> Seam scope usage is fixed."
>>
>> and project.getVariablesByScope(scope, true); used in context of code
>> completion...(before it was getVariablesByScope(scope);)
>>
>> Why is scope playing a role here in completions ?
>> Scope can't be used to filter the list of possible matches - in the best
>> case it can be used to *order* the list of completions.
>>
>> /max
>>
>>
>
17 years, 3 months
Deploying a .ds (or any resource)
by Rob Stryker
Here is some example code I've thrown together. The code below should
work, except that the publisher is *not* yet ready to handle it.
However, the APIs will work.
// get a path somehow. you can also use resource. Look at
SingleDeployableFactory's static methods
IPath p = new Path("/abc/1.txt");
// mark this path or resource deployable.
SingleDeployableFactory.makeDeployable(p);
// get the actual module object from the factory
IModule module = SingleDeployableFactory.findModule(p);
IServer s = someServer // wherever you get your
server from
// convert it to a DeployableServer instance
Object o =
s.loadAdapter(DeployableServerBehavior.class, null);
// if its not null, the adaptation worked.
if( o != null )
// custom API to deploy / publish only one module.
((DeployableServerBehavior)o).publishOneModule(IServer.PUBLISH_FULL,
new IModule[] {module}, ServerBehaviourDelegate.ADDED, new
NullProgressMonitor());
If there are any questions ask me. Again, the last step will not yet
work because the publisher is not ready to handle these, but the factory
should be up and running.
- Rob Stryker
17 years, 3 months
