compilation issue with the latest 0.8.9 version

[Miroslav Genov]

Hello, 

I'm experiencing strange compilation issue with the latest version of sitebricks. After I changed my pom.xml to use 0.8.9 instead of 0.8.8 I get the error that is displayed in the attached screenshots. 

The same error is occurring and with maven compile. Tried with different javac compilators on different machines (MacOS and Linux) and the result is same.

Is anyone experiencing similar issue ? 

Thanks in advance

[Dhanji R. Prasanna]

Do you mind submitting a test case for this please? I will look today. Also I am back in town so I will do the release today as well.

Thanks!

--
You received this message because you are subscribed to the Google Groups "Google Sitebricks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-sitebri...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Miroslav Genov]

Hello, 

I've made a sample project that re-produces the problem.

You can checkout it from: https://github.com/mgenov/sitebricks-test

[Dhanji R. Prasanna]

Thank you, I will take a look.

[Miroslav Genov]

I've checked and with the latest release 0.8.10 and the problem still occurs. Probably there is some dependency issue or something.  Tried also with empty local repository (all dependencies to be re-fetched) with no success. 

Any ideas? 

[Miroslav Genov]

I got it. 

The problem is in the definition of the Request interface. 

public interface Request<P> {

It seems that when interface is defined as template class and it's methods are different templates, the compiler raises an error (JVM Issue?). Is the design of this interface is going to be that way and in the future?

Seems strange to me, using of the following definitions: 

@Post
public Reply<?> sample(Request<String> request) {  // what String actually means?
  Person person = request.read(Person.class).as(Json.class);
  return Reply.saying().ok();
}

Commit message contains information that this change is required only for FileItem for multipart forms, so to provide this client code that is using this API have to use Request<String> all over the place ?

Actually in our team we have discussed some improvements like:

@Post(accepts=Person.class, transport=Json.class) 

public Reply<?> sample(Provider<Person> person) {

   Person p = person.get();

}

or 

@Post(accepts=Person.class, transport=Json.class) 

public Reply<?> sample(Person person) {

   //...

}

so when headers are not required and etc, users would be able to process objects directly. The idea of this design is that it will improve testing and etc. 

[Dhanji R. Prasanna]

Yea this is wrong, it comes from someone's contrib that I unfortunately let through too quick. Will fix.

[Miroslav Genov]

Dhanji, 

What are your plans for this fix? 

Is it going to be applied over the SNAPSHOT version or in e 0.8.10 release? Maybe 0.8.11 ?

[Dhanji R. Prasanna]

Hi Miroslav

I will apply it for the next release.  sorry about this--I have been down with the flu.

[Miroslav Genov]

Hi Dhanji, 

Any progress on this issue? 

Still no new release or commits about this interfaces and etc.  

I saw that Takari lifecycle was added, which looks promising. 

[Dhanji R. Prasanna]

Hi Miroslav,

So sorry about this. I am back in town now and working on fixes regularly.

For now, if you declare the request as Request<String> does it compile? The idea was that a request with a string encoding (most requests) would be declared this way and requests with multipart data (files) would be declared as Request<FileItem>

I did not design this API though I did merge the PR. In hindsight I think the API can be a bit nicer as Requests are 99% string encoded and do not need this verbosity everywhere.

I will work on removing the parameter but just want to explain.

Dhanji.

[Miroslav Genov]

Hi Dhanji, 

Thanks for your feedback. 

Yeah, Request<String> makes it working, but I have few modules with many services and many tests, so such change is a really big effort from my point of view. It would be really nice if the design is kept as it was in the old versions. 

[Dhanji R. Prasanna]

Yes I agree, I'm going to revert this and design a slightly different file upload interface.

[Dhanji R. Prasanna]

This change is now in master. I will roll out a release later in the week.

To unsubscribe from this group and stop receiving emails from it, send an email to google-sitebricks+unsubscribe@googlegroups.com.

[Miroslav Genov]

Dhanji,

Are you ready with this release ? 

I looked at the main repository, the last commit is for the fix of this issue but there are no follow up commits for the release. 

[Dhanji R. Prasanna]

Hmm this hasn't gone out? Sorry about that! I thought it had. Let me try the release again today.

[Miroslav Genov]

Sorry for bothering again, but version is still not released. 

Maybe jvanzyl could help about this ? 

[Dhanji R. Prasanna]

Hi sorry, I thought Jason had done this already. I will ask him if it's possible this weekend. Sorry again